软件开发中的11个系统思维定律

Posted 2020-10-02

英文原文：11 Laws of The System Thinking in Software Development

　　“我会更加努力地工作” —— 一匹名叫Boxer的马（出自乔治?奥威尔的《动物农庄》）
　　彼得?圣吉在其著作《第五项修炼》中提到的系统思维定律相同适用于软件开发。
　　
1. 今日的问题源于昨日的解决方式（Today’s problems come from yesterday’s solutions）
　　当解决这个问题时，我们会感到非常高兴。我们常常不考虑后果。

令人感到意外的是。我们提出的解决方式可能会产生反作用，并带来新问题。
? 作为对取得巨大成功的团队的奖励，公司决定为团队中的少数骨干成员发放奖金并晋升职位。团队中的其它成员会感到不公平，而且会丧失积极性。终于使团队成员之间的关系更加紧张。兴许项目也就非常难再取得成功。
? 项目经理频繁要求开发人员修复一个新的软件Bug，或者处理客户的紧急需求，而开发人员尽力满足这些要求。

可是，过于频繁地分散精力会妨碍他们完毕迭代过程中的主要任务。

因此，项目进展非常慢。
2. 用力越大。系统的反作用力也越大（The harder you push, the harder the system pushes back）
　　当事情的进展结果并不是如我们所愿时。我们会固执地坚持自己的方法。我们没有时间来停下来思维并寻找更好的替代方案。而是“义无反顾”地向前冲。有时候尽管攻克了问题，但往往又发现深陷于其它问题之中。

? 当一个系统远未完毕时，经理一般会不断催促员工加班加点地工作，而且要求按时完毕。系统bug数量的持续添加及总体质量的急剧下降。导致很多其它的延误。因此，须要做很多其它的工作来部署软件系统。

? 为了满足新系统的要求，开发人员勇敢的对原有的系统架构进行扩展，但死板陈旧的方法已经不能满足这些新需求。他们忙于做这件事，以至于没有时间停下来细致分析而且改变方法，从而导致系统质量下降。
3. 福兮祸之所伏（Behavior grows better before it grows worse）
　　短期的解决方式，会给我们带来短暂的歇息和状况的临时改善，可是不会从根本上解决这个问题。这些问题终究会使情况变得更糟。
? 公司为顾客提供丰厚的优惠并投入巨资宣传。让非常多人购买软件 。可是。顾客购买之后非常不惬意，由于软件无法使用也不可靠。
? 管理层承诺。假设开发团队能够按时完毕系统开发，公司会提供巨额的奖金。

一个团队開始努力的工作，但非常快他们就意识到这是不可能实现的。于是开发人员变得悲观并丧失动力。
4. 最容易出去的方法往往会导致返回来（The easy way out usually leads back in）
　　在生活中学到的一些解决方式能够帮助我们轻易地而且更早的地获得成功。

我们总是试图把它们强加到不论什么情形上，而忽略了特殊的背景以及相关人员。
? 开发人员还没有准备好接受结对编程或者測试驱动开发这种实践时，敏捷教练强行实现全然的极限编程。

这会给不论什么敏捷方法带来压力、冲突以及负面影响。
? 开发人员把设计模式应用到不论什么地方。这是徒劳的，而且这会让系统变得复杂。
5. 治疗带来的结果可能会比疾病导致后果更严重（The cure can be worse than the disease）
　　有些熟知的方法可能会更危急，比方在编程的时候喝啤酒。来减轻不切实际的任务期限带来的压力。

? 由于不信任全职开发人员，一家公司雇佣了大量的承包商来开发核心功能。结果，系统不具有概念完整性。自己公司的开发人员看不懂，而且无法做出改动。

所以，公司员工也不了解相关领域的知识、解释以及概念。

? 开发人员会走捷径。拷贝类似功能的代码来赶进度，而且争取尽快发行第一个版本号。他们一開始进展迅速。可是代码终于会变成大泥球(比喻系统结构不清晰)。

6. 欲速则不达（Faster is slower）
　　当我们看到成功的曙光，我们会全力以赴，不再小心慎重。然而。最优增长速率一般会比可能的最快增长速率要慢得多。
? 经理们往往为已经成功的项目添加非常多人手，但总体进展就会变慢，由于交流所用的花费添加，以及团队成员之间失去默契。

? 在没有对代码进行合理重构及改善的情况下，开发人员高速的为系统加入新的功能，会使系统变得难懂，而且难以改动。

7. 在时间和空间上，因果并不密切相关（Cause and effect are not closely related in time and space）
　　我们善于为出现的困难寻找原因。即使这些原因非常牵强，而且远非是真正的根本原因。
? 为了按时完毕系统，开发团队不再接受来自客户的需求改变。因此，客户对发行的软件不惬意。
? 实时系统历经坎坷之后，管理层迫使开发人员允许。而且在给系统做出不论什么改动之前撰写具体的技术说明。

结果开发人员失去了为系统做出不论什么改进的动力。而且開始迟延。
8. 微小的改变能够产生明显的效果，但这种杠杆效应最大的地方往往也最不明显（Small changes can produce big results-but the areas of highest leverage are often the least obvious）
　　像改变公司政策、愿景或者广告用语这样显而易见而且关系重大的解决方式往往不起作用。相反。小而普通，但持续的改变却会带来大不相同的效果。
? 开发人员每天都与客户进行交流，而且做出大部分决定。因此。能够更好地理解客户的需求、做出更好的决定而且给出最优的解决方式。

? 开发人员为系统的每项功能设计自己主动化单元測试。因此。设计更灵活、人们更自信、系统在每此改动之后都能得到全然的測试。
9. 鱼与熊掌能够兼得，但不是同一时候兼得（You can have your cake and eat it too – but not at once）
　　我们常常会面对刻板的“非此即彼”选择。

假设我们改变一下自己的观点及系统规则。这些选择有时并不会使我们进退两难。
? 经验丰富的项目经理知道添加系统特性的数量与削减时间和开支不可兼得。

然而，假设我们完好一下想法、寻找合适的人才而且避免过度开发，这也是可能做到的。
? 开发人员觉得他们应该要么採用事务脚本，要么採用域模型体系架构模式。然而，复合域中的高性能解决方式能够将两者结合。以得到最佳性能。
10. 把一头大象分两半不会得到两头大象（Dividing an elephant in half does not produce two small elephants）
　　无法总体了解系统，往往会做出次优决定。
? 项目经理往往通过生成的代码量和迭代过程中实现的功能数来评估开发人员。而开发人员往往会生成大量无用代码。
? 管理层承诺，每发现一处系统bug，測试者将得到5美元。

測试者对跟开发人员合作不再感兴趣，而且不再试图消除产生bug的根本因素。团队之间良好而且高效的关系不复存在。

11. 无可非议（There is no blame）
　　我们喜欢归咎于客观条件，或对别人指指点点，甚至对此深信不疑。可是。我们自己以及问题的解决办法都是系统的一部分。
? 今天早上团队没有公布系统全然是乔的过错。即使项目经理亲切地为其提供了免费的啤酒、T恤以及披萨，他也没能在一晚上的时间内修复全部的缺陷。

? 人们不会使用一个公司优秀的Web 2.0社会化应用，用户喜欢简单有用的东西。而且不会感激你辛勤工作的成果。

　　然后呢？
　　以上11条系统思维定律表明。我们提出的全部解决方式都会产生一定的后果，有时非常严重并出乎意料。我们周围的系统本就那样，我们不应苛责它们。而是要从中学习。

要掌握系统思维方式并控制这些系统，我们须要做到例如以下几点：
　　1. 要明确我们是在跟什么样的系统打交道，是人或是软件。
　　2. 有意识地学习相互关系、因果链。
　　3. 把系统看做一个总体，而且视其为其它系统的一部分。
　　系统思维方面有非常多挑战，通过获取而且利用有关系统工作方式的知识，我们能够战胜当中的非常多挑战。可是。大部分严峻挑战是我们人类与之相冲突的本性。

我们的激情、感情以及本能能够轻易改变我们理智、条理分明的思维方式。

掌握系统思维方式的第一步就是要学习怎样跟自己合作