人是自己的软件

这是我读《软件工程》一书的随想之一。

该书一到三章，讲了：

• 什么是软件工程
• 软件工程师是怎么思考问题的
• 有哪些软件生命周期模型
• 什么是统一过程
• 如果非得提一个前三章的重点的话，那回是：增量-迭代的软件生命周期模型是如何使得瀑布模型变得使用并且契合统一工程的

看了一点点理论，很自然想到的，就是实践这些理论。虽然现实中，我们初出茅庐的程序员往往干的事情，根据《构造之法》的说吧，大多是是从维护、测试现有的项目开始入手的。而自己正在上的软件工程课嘛，课程没有好好组织，组员们各怀鬼胎，也不过是学生们的玩闹罢了。我想实践这些理论，比较理想地去实践一次，从需求到退役。
既然没有现实的项目，那我自己做一个项目总可以吧？自己的项目，不仅仅于代码的项目，用于个人成长和日程安排也是可以的。因为，这正是我的需求：我想要摩尔定律式的成长，我想要合理地安排自己的生活。
于是很自然地，边读这本书，边能在思考，这种情况下的这条经验，能不能用在自己的实践上？有很多，自然是可以的，但是我不能把所有所得壹壹述尽，而且，思考的入口和思考的方法已经在这里告诉了诸位读者，你们自己依此诀看书思考，必然能有超脱于我的表现。按照惯例，我在这里列出最重要的三点启发：

• 需求流，分析流和目标转移问题。
• 没有计划没有测试没有文档的增量-迭代的软件生命周期模型。
• 螺旋生命周期模型。

需求流，分析流和目标转移问题。

需求流和分析流的主要功能是取得具体的软件开发要达到的目标和要满足的各种拘束条件，以及验证目标的可行性合理性等。目标转移问题是指，在开发过程中，需求变了。需求和分析，是很难的一件事情，要了解客户的需求和真正的为客户解决问题，最理想的可能是，你变成了福尔摩斯或者麦肯锡公司一样的角色，比客户还要了解客户。目标转移问题，是常见的一个问题，事实上，在Brook的著名文章，No Silver Bullet里一阵见血得指出那样，现实是易变（changeability）的而软件是必须服从（conformity）的。

The software entity is constantly subject to pressures for change…In others it must conform because it is perceived as the most conformable.
—-Brooks, No Silver Bullet

而，软件开发过程中，在需求阶段犯的错误，是最昂贵的。所以，一个合格的PM或者一个QA团队，会尽可能地通过各种手段来降低在需求和分析时犯错误的可能性。自己，是自己的软件的第一个阶段，就是需求流和分析流。需要了解自己和了解自己所处的环境，是需求流的第一步，然后好好想清楚自己的需求后，需要估计实现这些需求的成本和风险。最后是，这些东西必须书面化，以至于让自己不会活着活着就忘了，也便于下一次的迭代。需求流最难，也最值得大家努力，而，有时候，快速原型的说法是很正确的，不试一试，怎么知道自己到底想要些什么呢，总不能，按照自己的设计并高效地活到了最后，才告诉自己“这是按照我的需求来的，但这真的不是我想要的。”。分析流，就是将需求给清晰化，需要达到那些可以在外部测量的指标，需要哪些保证，大概的计划是什么等等。
举一个自己的例子，在大一大二的时候，我都是拍着胸脯说我随便浪都能保研的，然后最近量化地分析了一下，才发现，自己悬得很。这里有两个问题，第一，是在需求的阶段，我没有把保研的成本和风险给确定好；第二，在分析阶段，我没有把评估自己能不能保研的方法给开发出来也没有准备相应的计划。
目标转移问题的道理很简单。你可能不一会自己的目标就变了，也可能不一会你所处的环境就变了。也许出现了新的机遇，你要不要去争取？也天有不测风云，你又有如何应对？又或者你厌倦了江湖厮杀，只想涉川涉川，一瓣河川。按照应对目标转移问题的通常处理，是要从需求流重新开始的，偷懒不得，不然，机会可能就错过了，天也塌了。

时间有限，接下来这两点我只能粗略地讲讲。

没有计划没有测试没有文档的增量-迭代的软件生命周期模型。

计划、测试和文档是应贯穿于整个流程的事情。计划是近乎废话地必须的，一旦有了不如意的情况，就要再计划，而测试时发现如意的不如意的情况的最好方法，而且保证了知道自己在做什么，而文档，这是提供了一种在思维上可回溯的方法，也是一种是思维上的思考的工具。我一直觉得，没有书面化的思想，有两种，一种是东方哲学里面的“道可道，非常道”的写意式的思想，只有这种思想是不需要书面化的；另一种是脑子里面混乱的，应该主客分离的西式的应该有结构的思想，这种思想不书面化的话很可能就是垃圾。事实上，昨天我开通csdn博客的“导火索“就是对文档的强调和注重。一个人的关键的所思所想所作所为以及这么做的理由，都应该找到某种书面化的形式给记录下来。计划、测试和文档，应该互为依赖并在任何合适的时候实践。增量-迭代强调的是一种模式，不能说一下子达到自己的目标。有些需求是错的，有些需求是对的但一辈子都实现不了的。放轻松，不能一下子吃成一个胖子。

螺旋生命周期模型。

在我看了螺旋生命周期的模型的精髓不是风险管理，而是提供了一种改造进化树模型的方法，如果你是一个保守的人，希望保守地走好人生的每一步，于是直接选择有螺旋生命周期模型就好，而如果你有别的偏好，把这个模型强调的风险管理的部分，改为自己需要的部分即可。

结语

最后，自己永远是自己写不完的一款软件。人变了，世道变了，都得重新设计和分析。但是，存在一成不变吗？存在随心所欲而不逾矩吗？——当然是存在的，因为，你的客户，就是你自己。“就是你自己”，“就是你自己”的话永远是寂寥的。人的理想还可以再高一点，不仅仅是你自己。而，从终极自私的角度讲，作为一款软件，你希望自己尽可能的存在，哪怕肉身泯灭了，也要继续存在，继续地满足着你那些已经不存在的需求，持续地给你带来荣誉、爱慕、金钱和子嗣甚至知识！哪怕，哪怕再最后的最后，你想要的，只是一份宁静而已……