05程序员修炼之道:从小工到专家之五

Chap7 在项目开始之前

 

需求之坑：需求往往没有被良好地表达，需求、政策与实现往往模糊不清，然而这对于编程很不利，因为需求需要与实现隔离，需求不应有太大变动而政策时常变化。要从用户的角度思考问题。

为了理清需求，可以建立需求文档。需求文档需要有好的形式化，应该由目标驱动。文档应该保持抽象，规定需要的功能即可，过于拘泥细节会限制后续发挥。文档需要远视，不要对一些可能改变的规则进行默认，比如上个世纪将年数默认为19开头，只用存储后两位。为了达到远视，不需要增加许多莫名其妙的功能，而是应该对功能进行抽象，而不要嵌入代码中。

不要不断地增加新特性；为项目维护一个词汇表便于沟通；将需求文档公开用于讨论，就像许多别的文档一样。

 

解开不可能的问题：对于问题的约束有真正的约束，也有一些是表面上的约束。要找到那些真正意义上的约束并给予尊重，对表面上的约束可以适当予以摒弃。

解决“不可能的问题”时，可以问自己这些问题：有更容易的方法吗？我是在解决实际问题还是被技术细节转移了注意力？这件事情为什么是一个问题？什么使它难以解决？它必须以这种方式完成吗？它真的必须完成吗？

 

等你准备好：有时候要依靠直觉，直觉觉得仍有疑虑时不该开始。为了将疑虑与单纯的拖延区分，可以通过开始构建原型检查自己的疑虑在什么地方，或者自己只是单纯懒于工作。

 

规范陷阱：规范重要，但不应归于细致流于琐碎。自然语言本身十分晦涩，过于琐碎的规范往往不能精确地描述意图描述的细节，而且会限制程序员的发挥空间。

 

圆圈与箭头：通过形式方法描述项目很流行，但有一些缺点：1. 形式化的表达需要由人来阐释含义，不如原型的展示清楚明白。2. 形式方法似乎鼓励专门化，但专门化会带来人力的浪费和不好的编码体验。一个小组应该分工，但不应该被分裂成几个不必要的部分。每个人都应该了解项目系统的大体。3. 形式方法往往无法描述系统的动态性。

形式方法只是一个工具，可以使用，但不要被限制。……事实上这个原则似乎适用于所有工具，包括ide、语言、框架等。