软件project—思考项目开发那些事（一）

阅读文件夹：

• 1.背景
• 2.项目管理，质量、度量、进度
• 3.软件开发是一种设计活动而不是建筑活动
• 4.高速开发（简单的系统结构与复杂的业务模型）
• 5.技术人员的业务理解与产品经理的业务理解的终于业务模型
  • 5.1.产品的业务理解（业务流程、数据流程及场景）
  • 5.2.技术人员的业务理解（领域模型、设计模型、抽象建模）
• 6.技术债务（腐烂的遗留代码）
• 7.软件项目管理与软件project的鸿沟（项目管理得有语境上下文）
  • 7.1.软件项目管理事实上应该多去重视一些技术层面的管理
  • 7.2.软件project才是指导软件开发的科学方法论
  • 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行业算是很是正常的。

书多了有时候不知道要看些什么也很是正常。个人原则就是随时调整，看眼下所面临的困惑。依据我以往的经验总结。在实际问题面前寻找答案最easy让你有新的感悟和提高。

我相信书中自有黄金屋、书中自有颜如玉，要在对的时间看对的书，说白了就是在有困惑的时候就去寻找给你答案的这方面书籍。为何要看Craig larman大师的书。是因为近期的工做内容有很是多本身搞不懂的地方，但愿能经过大师的指点有所感悟。果真受益不浅。

再说下后者。近期一直在和这几个事情打交道：遗留代码、技术债务、项目管理、项目质量、开发进度、高速开发、重构、单元測试、敏捷开发、Scrum、XP，你可能会有点疑惑，有些东西是反复的，比方项目管理中包括了项目质量、开发进度，再比方敏捷开发与Scrum和XP。彷佛我在把一个大的概念拆解成多个小反复的概念。我之因此这么作，是因为我想强调这些概念的差异和真正的相互做用，从软件工匠的艺术角度出发来真正的看待这些概念。比方说，项目质量与代码有关系吗，开发进度与遗留代码有关系吗，项目管理与技术债务有关系吗等等，这些问题的本质是全然不一样的，做为技术人员尤为是应用开发的技术人员必定要强调概念。必定要明确不一样的概念的本质含义，假设你不强调概念我想你的代码是写很差的。对业务的理解也不会深入。

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

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

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

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

为何会出现这样的现象，事实上主要缘由有两个，首要的就是我的的职业规划，在就是公司的价值导向。先说价值导向，每每写代码的人的价值没有项目管理的价值大，这在一些中小公司仍是很是广泛的，真正的科技型公司这类问题差点儿没有。而职业规划是全然可以接受的，毕竟每个人的兴趣和追求不一样，这无可厚非，应该尊重每个人的选择。

但是这里的问题是。一旦没有太多技术底蕴的技术人员坐上项目管理者的职位后会对技术的理解360度大转弯。这事实上是不正确的，项目的成败不可忽视技术。

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

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

项目的成败光靠项目管理是解决不了的，假设可以就不会出现《软件project》、《设计本来》了。

保证软件项目的真正成功是需要软件project的支撑才行，而管理更加是对开发的组织、协调、沟通上的，这是两个层面两个角度互相做用的。项目管理中不会有设计、抽象、可维护性等这些内容。

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

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

开发进度，“质量”一段中我最后抛出了一个问题“为何要关心代码的质量”，因为他直接决定了你的项目进度，当你的代码质量愈来愈差的时候你就失去了对项目进度的控制。你再多的度量指标都是无心义的，就算你可以统计出BUG数上升了，但是你也控制不了BUG数降低。因为你已经偏离正常航线太远，就算你可以控制需求变动的速度和次数，但是你没法控制适应变动的代码的速度和次数。

变动是没法避免的。你的代码没法面对这些复杂的变化，因为你的代码不是设计出来的而是堆出来的。最后你的项目质量也没法很是好的保证。

（图1：项目管理与软件project的结合才是完整的软件开发）

近期在看Michael C. Feathers 大师的《改动代码的艺术》一书，感触颇多。里面讲到了咱们面对遗留代码的时候，为了添加一个新的功能要付出多少时间和精力。出现明显的BUG机率有多高，出现隐藏的BUG机率有多高。遗留代码直接决定了上述三个项目管理的方面。Michael C. Feathers 大师强调了很是多关于我上面讲到的项目管理和代码质量之间的关系，这本书很是值得看。

事实上真正推进软件开发不断发展的是软件project、开发方法论，项目管理仅仅是辅助于软件project在时间和空间上有效实施。

这里还要差异下就是项目管理和团队管理的差异，这两个东西是不同的。项目管理基本上不需要软件project的支持，但是团队管理在某些方面是需要软件project的支持才干作的更好。

3.软件开发是一种设计活动而不是建筑活动

在《精益与敏捷开发大型应用实践》一书中是这样描写叙述软件设计和架构的：

1：“软件架构借鉴了建筑的架构，但结果证明这是个不太恰当的类比，而且给软件开发带来了有趣的反作用。

建筑是硬的。因为在这个领域，设计仅仅在施工前进行一次。而后该建筑或者设计就差点儿是永久不变的了。

注意建筑师和施工工人是不一样的。但是软件不是一座建筑。软件是软的，而且编程也不是施工的过程，“软件架构”仅仅只是是一大堆比喻列表中可以选择的一个不太完美类比而已”。

2：“......惟一确实看起来知足project设计条件的软件文档是源码“。

3："我意识到图表和文档并不是真正的设计，而源码才是真正的设计。再次重申“......惟一确实看起来知足project设计条件的软件文档是源码“。

这几句话足以证实软件开发是一个很复杂的过程。是思惟密集型脑力活动，而且体现在每一个编码过程当中。

在许多项目管理中都以为软件开发是一个很easy的活动，主要架构设计好编码是比較简单的，难道真的是这样吗。咱们再看看书中怎么说的：

1：”源码是真正的蓝图“。

2：”真正的架构在哪里，无论好坏、有意或偶然的？是在架构团队维护的文档中？仍是在上万个文件里？显然是后者。源码是真正的设计。而且它的总和反映了真实的大型设计或架构。架构就是架构。不是某人的意愿“。

现在很是多开发人员另外一个明显的技术理解错误就是”写代码“是比較简单的活动。

复杂的是软件架构。仅仅要架构设计好后写代码应该是程序猿的事儿。这里明显有一个错误的价值观，以为写代码的人都是便宜的，不具备不论什么的设计和创造新。

这事实上是一个很是不专业的见解。真觉得一个简单的PPT、WORD文档中的架构图就表示架构了。

事实上这个想法是很是幼稚和肤浅的。用Craig larman大师的话讲，在整个软件生命周期的活动中，复杂的是编写代码。而代码才是架构。因此说架构的就是代码。

你本来理解的架构才是真正难的地方事实上也就是代码才是真正难的地方，不可浮于表面，这样才干更加的接地气才干真正的有价值。

架构师应该深刻到一线參与一些开发，这时会发现很是多问题，而后将问题带到架构的位置，用架构的视角设计方案。在亲自把这个方法带到一线落实下去，这才是架构落地一个技术方案的正确方法。

软件开发是一项设计活动而不是建筑活动。软件是会不断变化的，而建筑一旦敲定是不会改变的。

4.高速开发（简单的系统结构与复杂的业务模型）

这节我想聊聊高速开发。在圈子里面对高速开发的理解大部分都是和高速开发框架相应起来。认为应该有一个框架来支持高速开发。仅仅要有了一个框架就可以进行高速开发。这种见解或想法事实上是错误的，对高速开发的理解太狭隘。

《设计本来》做者。计算机科学巨匠Frederick P. Brooks说过，对于软件开发来讲没有银弹存在。没有所谓的能够用简单发方法来开发复杂的系统。越复杂的系统开发起来不会简单的，开发一个知足100我的使用的系统和开发一个知足1000我的使用的系统在复杂性上已经全然不一样了。

量变引发质变，当业务量、訪问量、数据量等等这些软件指标超出必定的范围以后就和最初的设计全然不一样，设计思路也全然不一样。

回到当下。

我现在经常面临这种一个问题，我现在所从事的业务是比較复杂的，对系统的设计要求很是高。假设用量来比喻的化。事实上我现在所面对的业务量是比較大的，业务量中的业务复杂性的量事实上相比于訪问量、数据量等方面的量在设计方法要难的很是多。一般作设计的架构师都仅仅会考虑并发量、訪问量而忽视业务量。比方业务的多变性、业务的扩展性，业务自己的复杂性，这尤为考研设计能力。考验抽象能力。

这跟你用什么编程语言用什么数据库是没太大关系的。你脑壳里运用的是OO、实体关系。这些与详细技术框架不要紧的设计思惟。

业务量对于编写代码要求要高很是多。同比于其它几个量来讲很是难落地。訪问量、并发量可以经过基础架构的调整优化升级来解决，而业务量的问题域是业务逻辑。是领域模型。当前所面对的业务域，不论什么一个细小的业务都需要在代码中体现。

近期陆续在作一些系统重构的工做。就在前两天我重构了一段代码。不是基础性的代码，是业务逻辑代码。大概状况是这种。

在系统中有一个重要的领域概念“重量”，这个重量的概念存在很是多个业务量的质变可能性。就是说它自己不是简单不变的，随时存在着变化，当咱们品类扩充的时候就马上会变化。

重量的定义是这种：重量=单件重×数量。看上去好像很是easy的样子，事实上不是，这里的单件重是会变化的。有些时候是保留3位小数有些时候是保留6位小数。而且这个重量的业务逻辑是在N多个地方都需要用到的。查看代码下来大概有几十个地方都在反复着编写“重量“的业务逻辑。

后来我在同事的协助下重构了这块业务模型，为何我这里不用业务逻辑来形容个人重构工做，是因为我考虑业务的时候不会是过程式的，假设用”业务逻辑“来思考业务就会给人形成一个错觉就是”过程式“的代码结构。

因此我考虑不论什么业务都是”模型驱动开发“方法，业务要抽象为模型才干重用、扩展、抗变化性。

这事实上是OOA/D的精髓。业务逻辑仅仅是在模型中的一小块一小块的详细动做。它是在模型的范围内使用的，而不能一上来就是业务逻辑，业务逻辑太细小不便于抽象化。

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

我用上面的这个模型对重量业务模型进行了重构。

将本来很是重要的业务概念重量、单件重、不一样类型的单件重，进行了概念显示化，保证这些重要的领域模型不被过程式的代码淹没。

且用两个工厂封装了建立重量和单件重的业务逻辑。这样作以后咱们的模型就具备抗变化性，之后要是对Weight有不论什么的建立逻辑的变更咱们就可以在WeightFactory中处理，假设有新的品类扩充进来后需要对单件重相关的处理咱们仅仅需要扩展下ItemCategory和PieceWeightFactory两个模型。

假设你需要作为全然配置化，这个时候模型就更有价值。

比方，咱们可以将IitemCategory拿出去，经过品类扩展的时候本身主动生成相关的类型，假设你认为这还不够完美，咱们可以进一步将PieceWeightFactory中有关于“依据ItemCategory建立PieceWeight（Decimal） “。作成”Mapper模型“在进行配置化。

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

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

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

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

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

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

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

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

产品对于业务的理解是整体上的。包含业务流程、数据流程，场景，在他们的脑子里是真实的业务场景，是必须要还原的业务场景，不能够有不论什么的其它模型在做怪。假设产品用不论什么的其它知识来抽象和强制理解业务是会出现故障的。

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

（图3：产品的业务理解终于模型—业务流程图）

由于数据流程图比較简单，当前样例中仅仅会有“订单”的数据实体，画出来意义不大，我这里就仅仅画一个业务流程图来表达意思就能够。

在这个程度上是没法直接将流程图落到系统上的。它距离真正编写软件另外一段过程要进化，而如下那段过程才是技术人员理解业务后要发挥的价值和做用。

5.2.技术人员的业务理解（领域模型、设计模型、抽象建模）

技术人员的了解业务要有所側重。你理解的业务和产品理解的业务是不同的。技术人员需要将业务终于技术化才行。技术人员的终于的业务模型是有正确的模式可以參考的。就拿“建立订单”这个流程来讲。等待技术人员需要去提取和抽象的东西是比較多的也是比較复杂的，需要结合很是多的知识来进行设计活动。

比方订单。你需要结合“四色原型”模式来提取“订单”的模型，包含“订单的类型“、”订单的跟踪“。需要结合设计模式来抽象”建立订单的逻辑“，依据”不一样的订单类型建立不一样的终于订单“。还需要进行设计模型的抽象。比方建立订单。各个对象的交互是怎样的，每个交互的输入和输出是什么。这些都需要技术人员理解了业务后应该具备的业务模型，假设需要将模型语言化就需要结合使用UML来建模。

假设技术人员理解业务后和产品经理理解业务后的结果是同样的。那技术人员要去理解有什么价值。技术人员理解业务后要系统化的将各个业务模型落地到详细的领域内或者说某个子系统子服务中，而后各个系统和服务是怎样交互的，逻辑的归属到底是哪边的。终于你写出来的代码才是知足业务的代码模型，才是有核心竞争力的业务系统有别于无核心竞争力的系统差距。

技术人员了解业务后，针对不一样的业务场景開始建立领域模型草图，依据领域草图再进行设计模型草图建立，固然这是一个敏捷的迭代的过程。

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

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

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

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

我这里仅仅是若是一个简单的业务场景做为演示样例，目的是为了介绍技术人员差异于产品对于业务理解后的终于模型是不一样的。技术人员必定要有无缺的能将业务技术化的知识结构。这样才干真正的将业务发挥价值。

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

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

我是从开发作到架构。经历过很是多项目磨练。也深知在项目时间比較紧急的时候本身是在一个什么精神状态下写代码的。本身也干过处处复制代码粘贴代码的时候。加班到12点，眼睛基本上已经很是难看清代码。写程序的速度已经赶不上功能交付的速度。我仅仅能说这也没有办法，市场决定了项目的进度。

咱们可以吐槽，但是不能抱怨，更不能消极。

事实上现实状况下咱们作开发的基本上都是在这个节奏下工做，但是我是怎么处理这个问题的呢。

首先写好代码是我的对技术的一个追求和职业素质的问题，假设你对代码没有美感你很是难能编写出好的代码，你的代码也会处处留有坏味道，时间长了就是腐烂的遗留代码。严重的技术债务，研发成天怨声四起。各类抱怨。吐槽，这样下去事实上是很差的，团队里有追求的技术人员会流失。

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

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

用个人价值观来看的话，事实上你的工做仅仅完毕了一半，你并无保质保量的完毕工做，你的软件交付质量在产品层面是完毕了，但是你在技术层面是有残缺的。你给软件带来了很是多的技术债务。你给某个对象带来了腐烂代码的開始。

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

我一没事就会和个人好朋友也是好同事冯老师交流技术，互相review代码，提意见，在互相重构。彼此学习。咱们有一个共鸣，就是让写代码有追求的人来把控项目是很不错的。可以保质保量的完毕功能，固然不是光说有写代码能力就OK的，需要综合性的。事实上说白了，让一个精通技术的人在去精通业务作出来的软件应该是不错的。

（这里所说的精通技术是指应用开发方面的精通，不是指技术专家、系统层的技术专家）

做为应用开发者，要时刻记住你所应该具备的专业的职业素质，写代码要讲究，要记住对你来讲代码意味着什么。

未完待遇。

。

。

。。。

做者：王清培

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

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