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

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

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

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

开发好软件的3个原则

1. 开始要尽可能的简单

对于特定领域而言，想成为“一站式解决方案”的项目往往注定是要失败的。做这种项目的理由似乎足够合理：要想确保应用能解决大家的问题，还有什么比让它尽可能多地解决问题更好的方法呢？毕竟，像超市这样的实体店就很管用。但应用的不同之处在于，实体店开张后增加销售的新商品相对容易，而应用的功能要想增加一倍其开发难度可不仅仅是增加一倍，而且也更难用了。

开发优秀的软件需要聚焦：要从可以问题最简单的解决方案开始。一个精心设计但过于简单的应用添加必要功能从来都不是问题。但是，一个什么都可以做但什么都做不好的大型IT系统往往没法简化和修复。即使是像微信、Grab、Facebook这样“什么都做”也做得很成功的应用，也是从非常具体的功能开始的，只是在站稳了脚跟之后才慢慢开始扩展的。软件项目很少会因为太小而失败; 失败是因为太大了。

软件项目很少会因为太小而失败; 失败是因为太大了。

遗憾的是，在实践的时候保持项目聚焦非常困难：光是收集所有利益相关者的需求就已经折腾出了大量功能。

管理这种膨胀的方法之一是采用优先列表。需求还是要收集，但每项需求都要进行标记，看看是分别究竟是绝对关键的功能，还是具有高附加值的功能，还是非常有用的功能。这样计划流程的排期就可以没那么紧张了，因为没有哪项功能被明确排除掉。然后，利益相关者就可以更加安心地讨论哪些功能是最重要的，而不必担心项目会遗漏什么。这种方法也让增加更多功能所需要进行的取舍明确了。利益相关者如果想要提高某项功能的优先级，就必须考虑愿意降低哪些功能的优先级。团队可以从最关键的目标开始，在时间和资源允许的情况下按照这个有限列表做下去。

我们所有最成功的应用均采用了类似的流程。Form.gov.sg一开始只是一个人工操作的Outlook宏，第一个用户的设置工作就花了我们六个小时，但今天它已经处理了约一百万次公开提交。Data.gov.sg最初就是把一个开源项目直接拷贝过去，现在已经发展到每月超过300000次访问。Parking.sg大概还有200项可能的待开发功能，但时至今日它仍有超过110万用户。这些系统虽然简单正是因为如此才受到好评。

2.找出问题然后迭代

事实上，现代软件太复杂了，变更太快了，以至于再多的计划也消除不掉所有的缺陷。这就像写一篇好文章一样，早期草稿的尴尬对于了解最终论文应该写成什么样是必要的。要想开发出好软件，你先得开发坏软件，然后再积极寻找问题并改进解决方案。

这可以先从简单的事情开始，比方说先跟你想要帮助的人交流一下。其目的是了解你想要解决的问题之根源，并避免仅根据先入为主的偏见直接跳到解决方案。我们刚开始做Parking.sg的时候，我们的假设是执法人员会认为计算优惠券的烧脑令人沮丧。但是，在跟经验丰富的执法人员度过了一个下午之后，我们发现，对于专业人士来说，做这些计算其实非常简单。这一次谈话为我们省下来数个月的潜在时间浪费，让我们把项目重点放在帮助司机上面。

要提防伪装成问题陈述的官僚主义目标。“驾驶员在处理停车券的时候感到沮丧”是个问题。“作为我们部门的家庭数字化计划的一部分，我们需要为司机开发app”不是。“用户对在政府网站上查找信息很困难感到恼火”是一个问题。“作为数字政府蓝图的一部分，我们需要重建我们的网站以符合新的设计服务标准”不是。如果我们的最终目标是让公民的生活更美好，我们需要明确承认那些会导致他们的生活更加糟糕的事情。

清楚的问题陈述让你可以对理论上难以确定的不同解决方案的可行性进行实验性测试。跟聊天机器人交流未必比浏览网站更容易，用户可能并不想在自己的手机上安装又一个app，不管它可以如何确保国家的安全。软件看似显而易见的解决方案往往存在致命缺陷，而这种缺陷又是直到投入使用才会出现。其目标还不是开发最终产品，而是先得尽快尽可能低成本地识别出这些问题。用非功能性的原型去测试界面设计。用半功能性的原型去尝试不同的功能。用匆忙写成的原型代码来帮助更快地收集反馈。在此阶段创建的任何东西都应视为一次性的。这个过程的需要输出不是编写的代码，而是更清楚地了解该开发的东西是什么。

提防伪装成问题陈述的官僚主义目标。如果我们的最终目标是让大家的生活更美好的话，我们就得明确承认会让他们的生活变得更加糟糕的事情。

在对合适的解决方案有了充分理解之后，你就可以开始开发实际的产品了。此时你不再去探索新想法并且把范围收窄，以便用你的办法识别出问题。可以先从少数测试人员开始，这是能迅速识别需要修复的bug的人。随着问题得到解决，你可以向更大的人群开放，让他们找出更加难以捕捉到的问题。

大多数人只会提供一次反馈。如果你一开始就面向大量受众开发的话，每个人反馈给你的东西都会是一样的，这样你就会进展不下去。哪怕是最好的工程师开发出的最好的产品创意也会出现重大问题。这里的目的是反复改进输出，细心打磨，直到好产品出现。

即使在完成所有这些迭代之后，发布之后出现的产品问题也是最重要的。出现概率只有0.1％的问题在测试期间可能不会被注意到。但是，一旦你拥有了一百万用户，只要问题一天得不到解决，你每天就得应付一千位愤怒的人。你需要在对用户构成实质性伤害之前先解决新的移动设备、网络中断或安全攻击造成的问题。我们给Parking.sg开发了一系列辅助系统，这些系统可以不断地检查主系统是否存在算错钱，出现重复的停车会话以及app崩溃问题。随着时间的推移，建立一个“免疫系统”可以让你避免不堪重负，因为新问题的出现是不可避免的。

总的来说，我们的办法是利用不同的反馈回环来有效地识别问题。小的反馈回环可以轻松快速地进行修正，但会错过了更广泛的问题。大型的反馈回环可以捕捉到更广泛的问题，但速度会比较慢且费用较高昂。你当然希望同时使用这两者，用紧凑的回环尽可能多地解决问题，同仍保留较大的反馈回环来捕获意外错误。开发软件不是为了避免失败；而是要有策略地尽快遇到失败，从而获取开发出好东西所需的信息。

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

软件做得好的关键是要有好的工程师。Google、Facebook、Amazon、Netflix以及微软都运营着数量庞大的全球最大技术系统，但是，他们的面试流程是出了名的精挑细选，可以说是最严苛的，各自都在为了招募到最能干的面试者而展开激烈竞争。随着这些公司的壮大，哪怕是给应届生的薪水也水涨船高是有原因的，而且这并非因为他们喜欢撒钱。

史蒂夫·乔布斯和马克·扎克伯格均表示，最好的工程师的工作效率至少是普通工程师的10倍。这并不是因为好的工程师写代码的速度要快10倍。而是因为他们做出了更好的决定，从而节省了10倍的工作量。

好的工程师对自己可重用的现有软件掌握得更好，从而可以最大限度地减少必须从头开始开发的东西。他们对工程工具也掌握得更好，会借助来自动完成大部分的日常工作。自动化还意味着把人给解放出来，让工程师可以去解决一些意外错误，最好的工程师在这方面会做得更好。好的工程师设计的系统也更健壮，更容易被他人理解。这就产生了乘数效应，让他们的同事可以在他们的基础上更快更可靠地开展工作。总的来说，好的工程师之所以如此高效，不是因为他们制造出的代码更多，而是因为他们做出的决定可以将你从自己不知道可以避免的工作中拯救出来。

这也意味着最优秀的工程师组成的小团队的开发速度往往比一般工程师组成的大型团队还要快。他们会充分利用可用的开源代码和复杂的云服务，并将普通的任务的繁琐丢给自动化测试和其他工具来处理，这样以来他们就可以专注于工作的创造性问题解决方面。通过确定关键功能的优先级并减少不重要的工作，他们靠用户来快速测试不同想法。这是经典著作《人月神话》的核心论点。（总的来说，增加更多的软件工程师并不能加快项目进度，而只会让它变得更加庞大。）

开发软件不是为了避免失败；而是要有策略地尽快遇到失败，从而获取开发出好东西所需的信息。

跟一般工程师组成的更大团队相比，好工程师组成的规模较小的团队制造出来的错误和安全问题也更少。跟写论文类似，作者越多，最终的组合产品需要协调的编码风格，假设和怪癖也越多，可能会暴露问题的地方也越多。相比之下，由优秀工程师组成的小规模团队开发的系统会更加简洁，一致，也能更好地为创建者所理解。没有简单性就无法得到安全性，简单性很少是大规模协作的结果。

技术工作的协作性越强，就越需要更好的工程师。工程师代码里面出现的问题不仅会影响他自己的工作，也会影响同事的工作。在大型项目中，糟糕的工程师最终会给彼此制造更多的工作，因为错误和糟糕的设计选择造成大量问题。大型项目需要建立在可靠的代码模块上，还需要采用有效的设计，并且要有非常明确的假设。你的工程师越好，你的系统在因为自身重量而坍塌之前就能变得越大。这就是为什么最成功的科技公司，尽管规模庞大，但仍然坚持要求最好的人才的原因。系统复杂性的硬限制不在于技术工作的数量，而在于质量。

结论

好的软件开发要从清楚地了解你想要解决的问题开始。这让你可以去测试很多可能的解决方案，并把精力集中在好的上面。通过重用适当的开源代码和云服务，允许马上访问已做好的软件系统和复杂的新技术，可以加速开发的进程。开发周期会在探索和整合之间交替进行，先是快速而混乱地探索新想法，然后再聚焦和简化以保持复杂性的可管理性。随着项目的推进，它要逐渐接受后续更大范围人群的测试，以便解决日益不常见的问题。发布对于好的开发团队来说才是真正工作的开始：：应该开发一层层的自动化系统来快速处理好问题，并防止对真正用户造成伤害。最后，尽管软件开发会有无限的复杂性，但理解好这一过程可以为处理好如何开发好软件的复杂性奠定基础。

译者：boxi