新加坡政府推荐文章：如何开发出好软件？（上）

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：李宏毅是新加坡总理李显龙之子，不过他对从政并没有兴趣，而是更关心软件开发和公益。他曾经在Google工作过。后来又带领团队开发了Parking.sg、Form.gov.sg以及Data.gov.sg等多个app和服务。李宏毅认为，软件身上的某些特征导致了很难用传统的管理技术去开发；而高效开发要求一种不同的，更具探索性和迭代性的方法。此文原刊载在新加坡政府网站上，原文标题是：How to Build Good Software，是一篇有关软件工程的佳作。36kr将其编译出来，此为上半部分。

相关阅读：新加坡政府推荐文章：如何开发出好软件？（下）

为什么坏软件会发生在好人身上

这个世界上无法用金钱解决的事情不多，糟糕的软件就是其中一个。大型航空公司做出来的航班搜索app经常还比不上那帮学生做出来的。尽管既有的出租公司面临共享乘车服务的威胁，但全世界的出租车公司的打车应用都很糟糕。而那些用起来很痛苦的企业IT系统通常都是拥有大量预算的项目，而且这些项目都是用了多年的时间才开发出来的。所以不管软件糟糕的原因是什么，似乎都跟没钱无关。

令人吃惊的是，糟糕软件的根本原因跟特定的工程选择关系不大，更多是与如何管理开发项目有关。最糟糕的软件项目通常会以非常特殊的方式展开：

项目业主一开始想要开发特定的解决方案，但又从来都没有明确过自己想要解决的问题是什么。然后，他们收集了大量利益相关者的一连串要求。接着把这个清单交给外部相应的大型开发团队，由他们从头开始去开发这一高度定制化的软件。一旦所有要求得到满足，当系统发布，项目宣告完成时，每个人都会弹冠相庆。

糟糕软件的根本原因跟特定的工程选择关系不大，更多是与如何管理开发项目有关。

但是，尽管这套系统技术上符合规范，但把它交到实际用户手中时却发现了严重问题。系统运行缓慢，令人困惑，并充斥着难以捉摸的错误，导致使用起来完全是一种充满挫败感的体验。不幸的是，此时外部开发团队已被解散，已经没有剩余资源来进行必要的修复了。等到数年后再发起新项目时，一切跟这些问题原因有关的知识已经离开了组织，然后又来过一轮。

用什么样的编码语言，系统架构或界面设计合适会因项目而异。但是，软件特有的一些特征始终会导致传统管理的做法失败，但同时却让小型的初创企业用微薄的预算就能取得成功：

• •重用好软件很容易；这是让你可以快速开发出好东西的奥秘；

• •制约软件的不在于投入到开发的资源量，而在于软件在崩溃之前会变得多复杂；以及

• •软件的主要价值不在于生成的代码，而在于编写代码的人所积累的知识。

了解这些特征也许未必能保证好的结果，但这确实有助于说明为什么这么多项目会产生不好的结果。此外，这还引出了一些核心的运营原则，利用好这些原则可以大大地提高成功的机会：

1. 开始要尽可能的简单；

2. 寻找问题然后进行迭代；以及

3. 尽可能雇用最好的工程师。

虽然有很多更加微妙的因素需要考虑，但这些原则构成了可以开始开发好软件的基础。

重用软件可以让你快速开发出好东西

软件很容易复制。就机械级这个层面来说，代码行可以一字不差地拷贝粘贴到另一台计算机上。通常互联网上有很多有关如何用线上提供的现成代码模块来开发不同类型系统的教程。现代软件几乎从来都不是从头开发的。即便是最具创新性的应用，也是通过组合和修改现有软件开发出来的。

可重用代码模块的最大来源是开源社区。开源软件的代码可以自由发布，供任何人查看和使用。开源社区的许多最大的贡献者都是科技巨头。如果你想向Facebook那样使用最先进的可扩展的数据库，只需下载他们在2008年开源的Cassandra代码即可。如果你想亲自试用Google最尖端的机器学习，请下载他们在2015年发布的TensorFlow。用开源代码不仅可以让应用程序开发更快，而且可以让你接触到比自己开发的任何技术都复杂得多的技术。而最流行的开源代码甚至还更安全，因为有更多人关注并及时修复漏洞。这就是数字技术能够取得如此迅速的进步的原因：哪怕是初出茅庐的工程师也可以利用上本行业最先进的工具。

云服务的出现进一步提高了可重用性，让用户只需订阅费即可完全使用甚至包括专有系统在内的资源。想要个简单的网站？用Squarespace 或Wix 等建站服务就行了，点击几下鼠标就可以配置好。想要数据库？可以到Amazon Web Services或Microsoft Azure订阅虚拟版。云服务使得开发人员从专业化中受益；安装、维护都是服务提供商来做，并且不断开发出优质可靠的软件给所有订户使用。这样软件开发人员就不用再解决问题上浪费时间，而是专注于交付真正的价值。

如果你把所有时间都花在重新开发已有技术上面的话，你是无法取得技术进步的。软件工程就是要开发自动化系统，而第一个被自动化掉的东西就是常规的软件工程工作。关键是要了解要重用的合适系统是什么，如何根据你的独特需求去定制好，以及修复在此过程中发现的新问题。

软件工程就是去开发自动化系统，而常规的软件工程工作就是第一批会被自动化掉的东西之一。

软件受制于复杂性

软件的有用性通常受其复杂性的限制，而不是为了开发它所投入的资源量。

IT系统往往功能丰富，但用户还是很讨厌，因为它们变得实在是太令人困惑了。相比之下，排名靠前的移动app往往因其简洁直观而受到称赞。学习使用软件很难。到了一定程度之后，新功能其实还会让用户感觉更糟糕，因为累积下来复杂性开始变得不堪重负。比方说，iTunes作为苹果媒体生态体系的枢纽已经将近20年，到了今年终于拆分成了三个不同的应用（分别用于音乐、播客和电视节目），因为它的功能对于一个应用来说已经变得太过复杂了。从可用性的角度来看，限制不在于实现了多少功能，而在于如何融入到简单直观的界面。

即使忽略了可用性，一旦项目变得过于复杂，工程进度也会停滞不前。给应用增加的每一行新代码都有机会跟其他的每一行发生交互。应用的代码库越庞大，开发新功能时引入的bug就越多。最终，制造出来的新bug的功率盖过了开发新功能的功率。这又被称为“技术债务”，是专业软件开发的主要挑战。为什么许多大型IT系统会存在多年未能解决的问题？这就是原因所在。为项目增加更多的工程师只会增加混乱：代码库瘦身之后，应用反而跑得更快了。

开发好软件需要扩大和减少复杂性的交替循环。

在这种情况下，前进的唯一方法是后退一步，把代码库合理化并进行简化。可以重新设计系统架构以限制意料之外的交互。了非关键的功能哪怕开发出来了也可以删掉。可以部署自动化工具来检查错误和编写错误的代码。比尔·盖茨曾经说过“靠代码行数来衡量编程的进度就好比靠重量来衡量飞机的建造进度一样”。人的头脑只能处理有限的复杂性，因此软件系统能变得多复杂要取决于这种复杂性预算的使用效率。

开发好软件需要扩大和减少复杂性的交替循环。。随着新功能被开发出来，失调就会在自然地在系统中积累。当这种混乱开始引起问题时，开发工作就得放一放以腾出时间去清理。这两步是必要的，因为柏拉图式的好设计根本就是子虚乌有：这要取决于你的需求以及你遇到的实际问题。即便简单如如Google搜索栏这样的用户界面之下也隐藏着庞大的复杂性，而这些复杂性是无法在一次迭代中得到完善的。挑战在于要管理好这个循环，让它变得足够混乱以取得有意义的进展，但又不要让它变得太过复杂以至于不堪重负。

柏拉图式的好设计根本就是子虚乌有：这要取决于你的需求以及你遇到的实际问题。

软件关乎的是知识的形成而不是写代码

在软件开发中，大多数想法都是很糟糕的；这不是谁的错。那只是因为可能的想法数量太多了，多到哪怕非常小心谨慎以及明智地做出选择，任何特定的想法可能都未必见效。要想取得进展，你需要从一堆糟糕的想法开始，抛弃最坏的想法，然后逐步形成最有希望的想法。苹果就是富有远见设计的典范，苹果在推出最终产品之前会经历几十个原型。最终产品看起来可能好像很简单；但其背后却是非常错综复杂的认知的结果，他们是在对比了替代方案之后才选择出特定解决方案的。

即使在产品被开发出来之后，这种认知仍然很重要。如果新团队接管了自己不熟悉的软件代码，这部分软件很快就会出现退化。操作系统会升级，业务需求会变化，会发现需要修复的安全问题。处理这些微妙的错误往往比一开始开发软件还要难，因为这需要对系统的体系结构和设计原则有深入的了解。

在短期内，不熟悉的开发团队可以靠临时修复来解决这些问题。但随着时间的推移，由于额外代码的权宜性，新错误会累积。由于设计范式不匹配，用户界面变得混乱，并且整个系统的复杂性增加。软件不应该看作是静态的产品，而应视为开发团队共同理解的生动体现。

软件不应该看作是静态的产品，而应视为开发团队共同理解的生动体现。

这就是为什么依靠外部供应商来进行核心软件开发很难的原因所在。你也许会得到一个能跑的系统及其代码，但是有关它是怎么开发的，以及为什么做出这样的设计选择的宝贵知识却被带走了。这也是为什么把系统交给新供应商进行“维护”往往会导致问题的原因。即使系统进行了很好的存档，每次新团队接管时都会丢失了一些知识。慢慢地，这套系统变成了许多不同作者的代码拼凑而成。继续运行变得越来越难；到最后，再也没人能真正理解系统是如何运作的。

为了让软件长期保持运转良好，在外部帮助下让你的员工跟着一起学，这样可以让关键的工程知识留在你的组织之内。

译者：boxi。