阅读目录：

• 1.背景
• 2.项目管理，质量、度量、进度
• 3.软件开发是一种设计活动而不是建筑活动
• 4.快速开发（简单的系统结构与复杂的业务模型）
• 5.技术人员的业务理解与产品经理的业务理解的最终业务模型
  • 5.1.产品的业务理解（业务流程、数据流程及场景）
  • 5.2.技术人员的业务理解（领域模型、设计模型、抽象建模）
• 6.技术债务（腐烂的遗留代码）
• 7.软件项目管理与软件工程的鸿沟（项目管理得有语境上下文）
  • 7.1.软件项目管理其实应该多去重视一些技术层面的管理
  • 7.2.软件工程才是指导软件开发的科学方法论
  • 7.3.代码质量、可持续迭代、快速开发（需要软件方法论的支撑才能做好软件项目管理）
• 8.敏捷、极限编程，精益思想
  • 8.1.重软件项目管理不等于重软件项目质量（否则瀑布模型就不会失败）
  • 8.2.Scrum不等于敏捷开发只能算是敏捷过程（此时只是重视过程而不是最终的软件质量）
    • 8.3.结合XP最终落实到软件质量上（比如结对编程、互相code review、快速重构）
• 9.偿还技术债务的成本（拖得越久成本越大，而且是指数级的）
  • 9.1.技术债务与快速开发
  • 9.2.技术债务的偿还方式是有技术门槛的
  • 9.3.偿还技术债务只是其一，关键是如何避免技术债务（重新开发不等于不会有新的技术债务）
• 10.软件过程瓶颈
  • 10.1.代码最终会成为你的最大的开发瓶颈（而且是无法解决的瓶颈）
• 11.不合格的技术人员对公司的副作用是很大的（要做一名合格的技术人员）
  • 11.1.技术人员应该重视编程而不是各种高大上的技术名词和互联网浮躁的心态
• 12.总结

1.背景

最近对软件开发有了一个新的认识，这个认识源自连续看了两本Craig larman大师的书籍《UML与模式应用》、《精益与敏捷开发大型应用实战》和公司目前的项目情况这两件事情一起碰撞导致的感悟。

先说下前者，为什么会想到看Craig larman大师的书籍。其实我收藏的书籍已经上千本，在各个电商平台上都有帐号，目的只有一个就是收藏好的书籍。家里也堆了很多，没事浏览新书是我现在最大的乐趣。我相信有这种感觉和爱好的不止我一个人，家里堆上几十本书的在IT行业算是很正常的。

书多了有时候不知道要看些什么也很正常，我的原则就是随时调整，看目前所面临的困惑。根据我以往的经验总结，在实际问题面前寻找答案最容易让你有新的感悟和提升。我相信书中自有黄金屋、书中自有颜如玉，要在对的时间看对的书，说白了就是在有困惑的时候就去寻找给你答案的这方面书籍。为什么要看Craig larman大师的书，是因为最近的工作内容有很多自己搞不懂的地方，希望能通过大师的指点有所感悟，果然受益匪浅。

再说下后者，最近一直在和这几个事情打交道：遗留代码、技术债务、项目管理、项目质量、开发进度、快速开发、重构、单元测试、敏捷开发、Scrum、XP，你可能会有点疑惑，有些东西是重复的，比如项目管理中包含了项目质量、开发进度，再比如敏捷开发与Scrum和XP，似乎我在把一个大的概念拆解成多个小重复的概念。我之所以这么做，是因为我想强调这些概念的区别和真正的相互作用，从软件工匠的艺术角度出发来真正的看待这些概念。比如说，项目质量与代码有关系吗，开发进度与遗留代码有关系吗，项目管理与技术债务有关系吗等等，这些问题的本质是完全不同的，作为技术人员尤其是应用开发的技术人员一定要强调概念，一定要明白不同的概念的本质含义，如果你不强调概念我想你的代码是写不好的，对业务的理解也不会深刻。

最近我将自己的技术生涯的目标定为“软件工匠”，其实说实话我不在乎title，我只在乎自己的工作内容是什么。软件工匠是没有边界的，只要和软件开发有关系的内容都是属于工匠需要去专研的领域。如果工匠离开工具就丧失了工匠的真正价值所在，所以说千万别放弃写代码。不管你是一名架构师还是一名开发经理，代码永远是产品的最终设计，一旦你离他而去就离产品的质量越来越远，后面我也会讲下为什么代码如此重要。

2.项目管理，质量、度量、进度

这节的标题是不受欢迎的，大家知道为什么吗。技术人员是能明白的，有过长达5-10年的开发出生的管理者也是能明白的，唯一不明白的就是没有太多开发经验的管理者，或者那些不喜欢开发的管理者，那些逃避开发的管理者，因为他们离真正的产品实现太遥远，他们离软件开发领域真正的问题太遥远，管理一旦忽视代码质量问题就会慢慢找上你，你的项目往后的质量越无法控制，度量、开发进度都会遇到瓶颈。

说个当下的现象，我从事一线开发也有好几年了，陆陆续续看到很多人转作管理，但是你会发现做管理的人一般都是技术水平一般的人，或者对技术没有太多追求的人，更夸张的是在有些小公司的管理者可能就没写过代码。

为什么会出现这种现象，其实主要原因有两个，首要的就是个人的职业规划，在就是公司的价值导向。先说价值导向，往往写代码的人的价值没有项目管理的价值大，这在一些中小公司还是很普遍的，真正的科技型公司这类问题几乎没有。而职业规划是完全可以接受的，毕竟每个人的兴趣和追求不同，这无可厚非，应该尊重每个人的选择。但是这里的问题是，一旦没有太多技术底蕴的技术人员坐上项目管理者的职位后会对技术的理解360度大转弯。这其实是不对的，项目的成败不可忽视技术。

不继续讨论这个话题了，这不是本篇文章的重点，人各有志，选择是正常的，但是要明白的是选择的本质不是价值导向，而是兴趣导向，这才不会让你忽视另外一个角度，因为一个软件产品的最终成功是要靠项目管理和软件工程相共同的努力，缺一不可。

这里想聊聊项目管理的三个重要的方面，质量、度量、进度。首先我不是一个专业的项目管理者，但是我是一名专业的软件工程师，我不知道项目管理的具体内容有哪些，但是我知道项目管理的最终目标是和软件工程的目标是一致的，都是为了项目高质量的完成。

项目的成败光靠项目管理是解决不了的，如果可以就不会出现《软件工程》、《设计原本》了。保证软件项目的真正成功是需要软件工程的支撑才行，而管理更加是对开发的组织、协调、沟通上的，这是两个层面两个角度互相作用的。项目管理中不会有设计、抽象、可维护性等这些内容。

这里尤其想讨论的就是软件项目的质量，现在看来衡量软件项目的质量忽视了代码的质量，客户验收、功能完成、稳定上线，没耽误进度，这就是完成了一个项目，我们忽视了一个就是代码的质量，为什么要关心代码的质量。

度量，度量是对开发周期内所有发生的事情进行数据可视化，BUG数、发布回退数、代码行数（比较特殊）、需求变更数等等，还有些我不是太清楚的度量数据，总之应该会有很多。度量的目的是为了什么，是为了能够在这些数据出来后改善项目的各方面质量，控制各个不稳定的方面。

开发进度，“质量”一段中我最后抛出了一个问题“为什么要关心代码的质量”，因为他直接决定了你的项目进度，当你的代码质量越来越差的时候你就失去了对项目进度的控制。你再多的度量指标都是无意义的，就算你可以统计出BUG数上升了，但是你也控制不了BUG数下降，因为你已经偏离正常航线太远，就算你可以控制需求变更的速度和次数，但是你无法控制适应变更的代码的速度和次数。变更是无法避免的，你的代码无法面对这些复杂的变化，因为你的代码不是设计出来的而是堆出来的。最后你的项目质量也无法很好的保证。

（图2：重量、单件重模型）

我用上面的这个模型对重量业务模型进行了重构。将原本很重要的业务概念重量、单件重、不同类型的单件重，进行了概念显示化，保证这些重要的领域模型不被过程式的代码淹没。且用两个工厂封装了创建重量和单件重的业务逻辑。这样做之后我们的模型就具有抗变化性，以后要是对Weight有任何的创建逻辑的变动我们就可以在WeightFactory中处理，如果有新的品类扩充进来后需要对单件重相关的处理我们只需要扩展下ItemCategory和PieceWeightFactory两个模型。如果你需要做为完全配置化，这个时候模型就更有价值。比如，我们可以将IitemCategory拿出去，通过品类扩展的时候自动生成相关的类型，如果你觉得这还不够完美，我们可以进一步将PieceWeightFactory中有关于“根据ItemCategory创建PieceWeight（Decimal） “，做成”Mapper模型“在进行配置化。

这里你会发现一个很奇妙的地方就是，一旦模型化后业务的量变引起的质变可以通过逐步重构模型、提取模型、精华模型来解决。

所以说简单的系统结构是无法表示复杂的业务模型的，如果可以的话OO语言就不会发展成今天的这样子。复杂的业务无法通过简单的系统结构或者说所谓的简单的快速开发框架之类的东西可以解决的。

5.技术人员的业务理解与产品经理的业务理解的最终业务模型

很多时候我们都在强调“多去了解业务、多去熟悉业务”，在业务驱动型公司这是必须的，公司中的任何角色的单位都需要熟悉公司的业务范围。这没有问题，我想说的是不同的角色对于业务的理解最终的业务模型是不同的。

不管是在传统的软件企业中还是互联网企业中，我们要用软件来服务于我们或者客户，当然这里所说的是业务系统。业务系统的核心就是业务，系统的精神就是业务模型及模型之间的关系。

这节我想说的是，技术人员去了解业务后和产品经理去了解业务后最终的业务模型是怎样的。技术人员与产品经理是不同的角色，具有不同的职业背景，不同的知识结构和专业度。现在存在一个普遍的认识错误是，技术人员理解业务后与产品经理理解的业务后的最终的模型是一样的，是怎样的呢。是无法抽象的业务，大概的业务，场景化的业务，无法落地到系统中的业务。此时技术人员并没有用自己的专业度来对业务进行抽象和建模，并没有直接带来真正的价值，而是在交谈和理解需求的时候感觉上的价值错觉。

技术人员不能够业务技术化其实对于公司所说的“当技术人员理解业务后产生的价值是巨大的”其实是不准确的。

5.1.产品的业务理解（业务流程、数据流程及场景）

产品对于业务的理解是整体上的，包括业务流程、数据流程，场景，在他们的脑子里是真实的业务场景，是必须要还原的业务场景，不能够有任何的其他模型在作怪。如果产品用任何的其他知识来抽象和强制理解业务是会出现问题的。

产品对于业务的最终模型是业务流程、数据流程和一个不需要表现的场景。

（图4：“创建订单”相关的领域模型）

有了领域模型之后就需要创建设计模型，也就是各个模型之间的协作关系。还是要强调下，这是一个快速迭代的过程，且无将其看成是瀑布的依赖过程。领域模型的精华也是没有止境的，当后面进行设计模型的过程时会有对领域模型有补充的灵感，此时不可以教条，要快速的精华领域模型然后再进行设计模型的过程。

（图5：“创建订单”相关的设计模型）

基于领域模型创建设计模型中的对象协作模型，设计模型不仅仅只有协作模型一种还有其他的。协作模型是必须的也是最重要的。有了协作模型之后我们就可以走查场景是否满足“创建订单”的这么一个业务动作。当八九不离十的时候就可以进入到编写代码阶段，进行一个快速的构建代码模型，因为这个时候还是会有问题出现，只有在代码模型中没有问题后才是真的没有了。

我这里只是假设一个简单的业务场景作为示例，目的是为了介绍技术人员区别于产品对于业务理解后的最终模型是不同的。技术人员一定要有完善的能将业务技术化的知识结构，这样才能真正的将业务发挥价值。

6.技术债务（腐烂的遗留代码）

技术债务其实是无法避免的，各种原因，时间进度、需求变更、市场迫切等，都迫使研发开始堆积技术债务，代码逐渐开始腐烂，难道我们作为技术人员就只有抱怨和推卸责任吗。这里我有一些个人看法，这些个人看法可能跟你的理解不一样，你可能会说我太理想主义了，但是我想说的是：“作为一个技术人员一定要有情怀，一定要有追求。”用我最尊敬好朋友冯老师的话说：“写代码一定要考究“。就算在时间比较紧的时候可以先写，但是要记住你的工作并没有完全完成。

我是从开发做到架构，经历过很多项目磨练，也深知在项目时间比较紧急的时候自己是在一个什么精神状态下写代码的，自己也干过到处复制代码粘贴代码的时候，加班到12点，眼睛基本上已经很难看清代码，敲代码的速度已经赶不上功能交付的速度。我只能说这也没有办法，市场决定了项目的进度。我们可以吐槽，但是不能抱怨，更不能消极。

其实现实情况下我们做开发的基本上都是在这个节奏下工作，但是我是怎么处理这个问题的呢。首先写好代码是个人对技术的一个追求和职业素养的问题，如果你对代码没有美感你很难能编写出好的代码，你的代码也会到处留有坏味道，时间长了就是腐烂的遗留代码，严重的技术债务，研发整天怨声四起，各种抱怨，吐槽，这样下去其实是不好的，团队里有追求的技术人员会流失。

实话实说，当自己今天晚上12点写好了代码提交了测试，但是我的工作并没有完成，我通常会在早上很早就醒了，我会很早的来到公司对自己的代码进行重构和梳理，早上是大脑特别清醒的时候，在这个时候你进行代码的整理是非常不错的，而且这个时候公司一般都没什么人，特别安静，当你重构完代码舒服舒服的再去整理自己每天早上来的其他事务。

你可能会说那是你个人问题，我不一定会在第二天早上能起的那么早，就算起的来我到了公司也不会对第二天的代码进行整理，因为那已经上线了已经是完成的功能，我该继续下一个需求。

用我的价值观来看的话，其实你的工作只完成了一半，你并没有保质保量的完成工作，你的软件交付质量在产品层面是完成了，但是你在技术层面是有残缺的。你给软件带来了很多的技术债务，你给某个对象带来了腐烂代码的开始。

这点我现在的公司是非常不错的，公司高层对项目的管理者首要的要求就是必须懂技术。

我一没事就会和我的好朋友也是好同事冯老师交流技术，互相review代码，提意见，在互相重构，彼此学习。我们有一个共鸣，就是让写代码有追求的人来把控项目是非常不错的，可以保质保量的完成功能，当然不是光说有写代码能力就OK的，需要综合性的。其实说白了，让一个精通技术的人在去精通业务做出来的软件应该是不错的。 （这里所说的精通技术是指应用开发方面的精通，不是指技术专家、系统层的技术专家）

作为应用开发人员，要时刻记住你所应该具有的专业的职业素养，写代码要讲究，要记住对你来说代码意味着什么。

未完待遇。。。。。。

作者：王清培

出处：http://blog.csdn.net/wangqingpei557

本文版权归作者和CSDN共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

来源：王清培