系统为何而优化

我来给大家讲一个故事：当我上大学的时候，选修了一门“高级”的面向对象编程的课程。在此之前我从未涉足此领域。这门课程使用SmallTalk这种语言，并且教学方式很特别；上课第一天，教授就给我们布置了一个将会贯穿4周课程的作业。

我们都非常兴奋，因为我们要写一个游戏。一个类似于Zork的文字输入类的冒险游戏。我们3人一组，来到教授拥挤的小屋里。关于游戏要求的说明都在一页简单的纸上。我们几乎是跑着离开的。

但是，就在我们将要出门时，他又把我们叫了回去（我相信他是特意选了这个时机）：

“哦，对了，差点忘了！两周后，我会对游戏的一些基本内容进行调整，你们需要在调整之后继续进行。”

我对很多的开发团队（包括一些产品的创始人）多次讲过这个故事，他们的反应几乎都一样：

• 哄堂大笑，或者至少是咯咯的笑，经常还能听到一些“Pfffft”这样的话。
• 天呐，这也太没谱了
• 多么严厉的教授——这根本就是不可能的任务

问题就在于，教授并没有告诉他将会做什么样的修改。只是说会修改一些东西——两周后。

你认为我们该如何去完成这个任务？

我们开发时处处设防。

• “哦，不行——如果教授打算改动这个怎么办？”
• “也许应该把这里做成接口——万一教授要求用不同的方式实现它呢？”
• “不行——我们应该把这部分提取出来，这样，当我们修改这部分时就不需要改动模块X了”

这就是我们的做法。我最想说的是，这是一个非常好的作业任务，它让我在面向对象编程和Smalltalk方面学到了很多。感谢你，我们的Davidson教授！

最终，我们做成了一个非常模块化的系统，这使对它们的修改变得很容易。当那一天终于到来，当游戏设计被修改后，我们通过努力在一天内就按照要求修改了程序，使我们能顺利的接着开发界面和怪兽等很酷的部分。

我们为以后的改变而优化系统。因为Davidson教授告诉我们变化很快就会来到。

让我来给你们讲一个故事：这是关于大概25年前开发的一个系统的故事。它是一个瑞典大公司的重要业务系统。我说这是一个重要业务系统，是因为它处理的业务是公司80%的收入来源。

自打一开始，他们就思考的面面俱到，保留的极详细的文档。他们还制定了一套严格的需求变更规范。他们要求尽量避免这样的系统里的变更，因为风险很大，一旦出错会造成巨大的影响。

公司如此为这种事情担心，以至于他们编写了一系列的措施来预防系统出现问题；所有的代码要经非代码原作者的第二人用伪代码注释一遍。而且测试工作不能由代码的作者来执行。

同样，也制定了各种风险管理措施，来管控软件规格说明书的制定。写规格书的人被分成了几个等级，以此确保在递交给相关IT业务部门前经过层层检查。

很快25年过去，如今这些编写文档和管控风险的部门仍然在忙碌。这套措施很少出问题，但却效率很低。一个修改从列入计划到提交到产品中大概要30周的时间。一个想法到正式被写入规格说明书要经过20多个不同级别人的审批。拿着这种说明书的程序员都称自己为“施工人员”，因为他们实际的工作是把伪代码翻译成COBOL语言。

所有围绕这个系统做的事情都是为了掌控风险和需求变更，把稳定放在第一位。他们认为只要修改就会产生意外。但不幸的是，对于一个业务来说，唯一可能发生的事情就是：改变。而且改变的频率会越来越高。

他们为稳定而优化系统。

我想强调一点，第二个故事里的这种想法的人在生活中不占少数。他们是很优秀的人，但他们却被安排去开发以稳定为第一位的系统。这才是真正的风险。

结论

这两个故事让我思考很多：

• 我在写代码时是以何目的而优化？
• 变化随时都会到来。我从开始就知道。“在这个系统运行的25年里我将会不断的修改它的规格说明书”。我该如何去应对这种事情？
• 我是如何看待变化，把它当成风险？还是当成一种驱动？能够快速的应对改变是一种商业优势，是一种管控风险的良方。我如何让我的代码更容易改变？
• 在一个将要进行大量修改的系统里，什么样的文档才能满足我？

你优化系统的目标是什么？

原文地址：http://www.marcusoft.net/2013/04/WhatDoYouOptimizeFor.html