《论软件研发之纲》

什么是软件研发的“纲”

任何软件研发工作都存在“纲”（或可称为“灵魂”），它是软件研发过程中涉及原则、规范、秩序、守则、约束、评价等的统称。如果类比到人的身上，“纲”如同人的灵魂，产出的源代码好比血肉之躯，软件的最终运行效能便是行为能力。

“纲”始终存在于设计（设计是整体性编程）和编程（编程是局部性设计）环节中，它有好坏、强弱之分。优质且强化的“纲”可令软件产品稳如泰山，生命力旺盛，事半功倍；而糟糕或羸弱的“纲”往往使程序员、测试员疲于应付，软件质量和延续性得不到有效保证，事倍功半，间接扩大生产成本。

为什么需要好“纲”

好“纲”能够促成以下作用，但不仅限于此：

能快速承接各类需求的扩展能力

不考虑扩展能力的软件是缺乏生命力的，尤其是在各种需求层出不穷的当下。故软件开发之初和之中，有必要将可预见的扩展情形作为考虑因素。优良的设计原则将促使程序员在设计、代码开发阶段时刻谨记各处的可扩展性和可灵活性。

能灵活适应领域边界内业务的能力

为特定业务领域开发的软件，需要能灵活的适应业务变更（或潜在的业务变更）。这需要设计者、程序员充分吃透业务，从具体业务场景抽象出内在逻辑，并严格地将设计思想转化为可落地的代码实现。而好“纲”正是促成这种软件适应能力的基石。

软件产品的稳健性

所谓稳健性，并不是指软件没有BUG，而是指在出现BUG的时候，能够在极短时间内排查和定位原因，并快速修复的能力，最终促成软件的可靠稳定。假设没有优良的设计原则、严谨的编程守则，处理那些隐藏较深、不能稳定复现的BUG将是困难的。

具备长期的、清晰的可维护性

一个软件项目自开发完首个版本的那一刻开始便进入迭代期。这意味着软件产品需要在设计、编程等各个方面进行优化、变更和再生产，加之项目团队的人员流动性，必须使得软件具备长期、清晰的可维护性，甚至是建立梯队。而优质“纲”便是促成可维护性最有力的保障机制。强劲的可维护性是软件生命力旺盛的源泉。

研发工作是惬意的

人人都希望自己的工作是惬意的，尤其对于已经有足够多烦恼的程序员。这种惬意并非指看街景喝咖啡的惬意，而是特指研发工作中的热情、激情、良好的默契度、满足感、成就感，只有在好的原则、秩序、守则的支持下，这些才会变成现实。

快速稳妥地解决软件开发中的争议

软件研发过程也是思维落地化的过程，是思维就会碰撞，碰撞就会有争议，在多人合作团队中尤甚。而好“纲”恰是解决这些争议的裁定依据，做到以理服人，也是促进团队默契的有效手段之一。团队成员遵从“纲”的时间越长，发生争议的频率就会越低。

好“纲”有哪些组成要素

设计、编程的严谨性及其规范

说到严谨性，有据可依的才能称遵守严谨，没有规矩不成方圆。大部分规矩应该在研发之初被订立，但没有人能保证一次性订立所有规矩，在研发过程中仍需要逐步更正和完善。然而规矩是文字化或口头化的条文，最终需要由人主观能动性地、自觉地、一丝不苟地去履行，这样的规矩才有实际意义。严谨性不光体现在编程时，也体现在软件研发的各个角落。恪守严谨在某些时候会有“小题大做”、“不够变通”的倾向，但只要是合理且合适的严谨，从整体和长远来看这种坚持是值得的。

逻辑严密性的约束

这里的逻辑指软件开发所涉及的一切逻辑，包括业务逻辑、算法、执行流程、功能实现设计、整体规划等等。严密性的目的是为了让软件的整体和局部尽量做到滴水不漏。例如，有多处代码需要增删改一张内部有较多关系的数据库表，假如每一处都按各自的想法进行增、删、改，尽管可行但显然是不安全的，只要有一处未尽到维护表内关系的职责，便会出现问题。严密性约束就是提供考察和检验逻辑是否足够严密的动力，迫使开发者对该表的增删改动作进行统一处理，将表内复杂关系的维护封装起来。

逻辑抽象性的约束

软件开发中的抽象，其目的只有一个便是将复杂问题简单化。恰当且正确的抽象能够令开发工作事半功倍，使代码逻辑、层次、模块职责清晰，也能降低代码的重复度，提升开发和维护的效率，甚至可发展为高级抽象。不论是设计，还是编程，都极度需要抽象能力解决实际问题。对抽象性工作的约束恰是好“纲”中不可或缺的一环，必须促成开发者养成抽象习惯，并在开发过程中合理地运用它。

度量评价

软件开发工作属于脑力劳动，计件或计时均难以准确度量，因此能有效度量开发过程中的思维密度和深度，也属于好“纲”的一部分。由于思维的落地产物是设计文档、源代码等静置化产物，除了Review以外，需要通过沟通讨论将静态化产物转变为活动化产物，方可充分地考察，再通过横向比较给出合理的评价。经过这样的度量，不仅使软件开发的思维量得到近似正确的评估，也能借此发现和纠正BUG，从而进一步提升软件质量。

如何实施

前述内容阐述了好“纲”的作用和基本要素。如果要讨论如何实施的话，只有一句话——不可妥协地严格执行。

结合到实际生产过程中

传统瀑布开发也好，敏捷开发也好，或者其他开发模式，归根结底都要落地到设计和编程上。不论是造小单片机，还是开发大型软件，也不论是单人独立开发，还是多人协作开发，只要有设计和编程环节，“纲”都会存在，且都应进行强化。

软件研发本质上既不是计件工作，也不是计时工作，而是计质工作。这个“质”不仅限于软件的运行效果，还涉及软件在设计、编程等生产过程中的细节质量。计件和计时仅仅只能对体力劳动进行统计，但并不能真实度量脑力劳动。

仅以产品管理为主导或仅以项目进度为主导，似乎能够推进软件开发任务，但实际上却存在诸多问题，久而久之将积重难返。“产品管理”和“项目进度”是软件研发中不可或缺的两大重要工具，但不是主要工具。

在评价一款软件产品是否成功，或评价一名程序员是否优异的时候，除了把软件的功能、性能、运行结果作为参考以外，也需要将开发过程中设计、编程、逻辑思维等环节是否严谨、严密等一系列细节列为考察对象。因此，并不能仅看到运行结果良好就可高枕无忧，也不能仅看到运行结果糟糕就视为失败。

由于现代软件制造过程囊括了更多的角色，由需求（售前）——开发（产品——项目——设计——编程——测试）——运维——运营（售后）等一系列环节组成整个链条。本文论述的“纲”并不适用于设计、编程以外的环节，其他环节应形成符合各自环节所对应的“纲”，但各个环节的“纲”所产生的“纲效”是一体的，它应贯穿于整个链条。

后记

软件研发中的“纲”，一定不会局限于本文所论及之处，还应有更广更深的内容。“纲”的概念也不会仅限于软件研发领域，同样可以泛化适用于其他领域。建立完善、正确、严格的“纲”，是任何领域内开展工作的精髓所在。“纲”是怎样炼成的？是一个值得深究的问题。█

于戊戌年岁末