完美软件开发的方法和逻辑

十世古今，始终不离于当念；无边剎境，自他不隔于毫端。

—李通玄

当我们试图对完美的软件开发进行阐述时，事实上总是有两类方法可以帮助我们达成目的。

●归纳法。即基于项目经验，总结出一定的规律，再推而广之。在没有反例出现之前，总结出的规律一直成立。

●演绎法。即基于预设的前提，依照逻辑，推导各种结论。这个时候，只要前提没被推翻，逻辑又没有错误，那么得出的结论就具有必然性，虽然这种必然性何时体现在现实之中比较难以测度。

当前软件行业采用的大多数方法论和结论是基于归纳法的。

但一如我们前面所论及的，软件作为一种固化的思维，必然同时具备思维以及思维承载之物的双重特质。而思维承载之物的特质有时候甚至可能产生矛盾，因此基于归纳法得出的结论，容易偏颇并引发争议。

很显然，从数学类软件上得出的结论与业务流类软件上得出的结论并非是共通的；适用于操作系统内核的经验，也并不一定适合于视频播放软件。

与此同时，人的精力是有限的，这就导致一个人既不太可能经历所有的软件开发领域，也不可能穷尽同一类软件下的所有变数。比如说，A所经历的MIS系统和B所经历的MIS系统很可能天差地别。

这很可能是软件行业中纷争不断的一个主要原因—每个人都以为自己看到的就是全部，而当另一种与自己不同的观点出现时，这种观点会因与己不同而被判处死刑，但事实上两者可能同时正确，只是正确的边界不同。

为避免这类争议，在这本书里，我们将主要使用演绎法。为得到各种结论，我们将主要基于以下4个前提，使用逻辑进行推导。

●软件是一种固化的思维。

●意识指导行动。

●项目所能耗费的资源是有限的。

●重复做同样的工作会降低效率。

这4个前提被假设为公理，将不额外进行说明。而为使结论不显得晦涩和突兀，我们将尽可能使用现实里的例子对逻辑链和结论进行佐证和补充。

为了从这4个基本前提推导出属于各个部分（管理、流程等）的相关结论，我们还需要对影响团队创造价值的因素做进一步分解，否则事情会保持在混沌状态，进而无法以正确的尺度判断某一行为所能产生的正、负两方面影响。

如果我们假设一个人的工程素养为E，一个人的工作意愿为W，组织所能提供的力量为O，内耗系数为M，那么对于一个拥有n个人的团队，其在单位时间内最终可能的贡献值可以表示为

[（E₁×W₁+O）+（E₂×W₂+O）+…+（E_nW_n+O）]×M

其中M的取值可以为0～1。0表示完全内耗掉，整个团队完全没有贡献。

注：很多人会对为什么可以用加法累积不同人的贡献这一点产生疑问，比如，架构设计师的贡献和测试人员的贡献为什么可以叠加等，这点将在附录1中统一进行说明。

也就是说，单位时间团队总贡献=[（A的工程素养×A的工作意愿+组织力量）+（B的工程素养×B的工作意愿+组织力量）+…]×内耗系数(https://www.xing528.com)

其中：

●工程素养是指人员的工程能力，比如，需求分析能力，架构设计能力，编码能力等。

●工作意愿是指一个人愿意不愿意工作。工程素养和工作意愿乘起来才是一个人的可能贡献。这并不难理解，一个能力不好的人，再怎么努力，贡献也不会好；而一个能力好的人，每天蒙事，其贡献也不会好。

●组织提供的力量是指常说的组织力。比如说，组织内有比较多的重用代码库，那么不管谁都可以从中受益。探讨组织力，会使范畴发散，因此在本书中大多时候我们会忽视这个维度。

●内耗系数是指人员彼此间贡献耗散的程度。影响因素会比较复杂。比如说，A开发一个模块，但和B开发的模块有80%重叠，这会产生内耗；再比如说，A和B坐在一起工作就会吵架，这也会产生内耗。

上面这段分析可以总结为如图1-4所示的情况。

图1-4 贡献值的分解

那么在指定的时间段，这一团体的生产率为

上面的公式可以用来定性分析贡献值的大小，但并不能用来分析贡献值的效果。

比如说，某个团队可能在上述4方面都没有问题，最终也开发出了比较好的软件，但由于云计算的兴起，公司开发的这类客户端软件已经没有市场。这时候贡献值再好，也体现不出效果。

这意味着要想获得更好的结果，一要保证贡献值尽可能的大，二要保证贡献值使用在正确的方向上。控制方向性虽然重要，但与商业因素等有较大关联，本书中大多时候不会对其进行考量。

演绎法与空谈

经验主义者是不喜欢演绎法的，极端的甚至认为演绎法即是空谈。但我们不应该忘记，《相对论》与《资本论》这两个与演绎法有深刻关联的东西对世界所产生的巨大且深刻的影响。

在软件工程或者项目管理领域中，对演绎法的排斥达到了极点。人们似乎很忌讳谈及形而上学的东西，对经验的推崇则是达到了无以复加的地步。

但事实则证明这并不很有效，几十年下来，软件行业中还是一如既往的纷争不断。

比如说，Linux之父LinusTorvalds每隔一段时间就会站出来贬斥一下C++（有时还连带上面向对象），并经常用垃圾、很差这样的形容词来描述C++。而与此同时世界上很多关键系统是用C++成功开发出来的，拥有许多属于自己的铁杆粉丝。

这似乎很矛盾，也很难判定出是非，但当我们用演绎法来分析这类事情时，就会发现貌似对立的事情并非不可调和。Linus主要专注的领域是内核，所以他的观点在内核领域里一定是不能漠视的，但这并不意味着C++和面向对象就不适合游戏，富客户端，数据库程序等。

这类事实的存在意味着，我们应该切换视角，用演绎法来重新审视软件这个行业，而不能只是用有限领域中得来的经验去臆测无限范围中的事物—这是必将陷入矛盾的方法。