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

Posted 2020-09-21 lxjshuju

阅读文件夹：

• 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共同拥有，欢迎转载。但未经作者允许必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。