谈谈通常项目的开发过程？

管理好需求列表。
要有必要的设计。
做好配置管理。
严肃正经地测试。

一、管理好需求列表。
个人项目是典型的原型/迭代开发，由于所有活动都是同一个人完成，因此很多在多人项目中为沟通而设置的活动就没有必要了（诸如计划会议、例会、周报等）。但是正因为如此，个人项目更容易失去对项目的掌握，导致偏离计划的情况屡不鲜见。

有一个很有用的scrum实践就是：管理好需求列表、排出优先级。

由于个人需要完成所有的活动，在此情况下，技术风险对计划的干扰就会被放到最大。简单来说，有时突然间想到一个UI效果，但以前没用过，那么很有可能就要花费计划外的时间去查API手册、看别人的例子、写一段小代码做试验。往往在试验过程中，发现某些思路不对，需要推翻重来。像这种情况一多，计划就变得完全不可控。

我的习惯是用一个文本或excel表格，记录出所有的思维闪光点以及需要完成的功能点，按重要程度和技术依赖顺序，排出优先级，并做好标记（待开发、正在开发、完成）。如果临时有新的想法，一定要先把想法填入需求列表，仔细权衡一下是否要调整优先级，然后才按新的优先级来工作。除非新的idea会完全推翻原有设计方案，否则不要对设定的优先级作出重大调整。

二、要有必要的设计。

个人项目经常会有项目范围失控的情况，除了因为需求管理失败导致之外，还有一个很重要的因素是技术方案不成熟。人的大脑容量是有限的，当项目功能越来越多，功能的运行逻辑越来越复杂的时候，大脑就不够用了。我的习惯是，对于一些关键的业务场景，我必定先写一份简单的设计方案，例如：状态机、静态逻辑结构、关键模块的运行序列图等。这对于掌握（对个人而言的）大型项目有很重要的作用。

对于一些设计思路，也必须要用文档记录下来。具体形式不限，可以以注释的形式记录在源代码中。例如：某些精巧的事件驱动设计、回调函数设计、共用数据区的同步设计、钩子和异常等。虽然说如果代码能自解释就不用写文档，但对于某一些相对比较晦涩难懂的技巧，我还是倾向于使用自然语言再描述一遍，特别是对于那些代码上下文隔比较远的函数，为了提高今后自己写代码和维护代码的效率，文档和注释是必不可少的。

三、做好配置管理。
自己做项目最怕就是做试验的时候把弄好的功能给冲掉。因此结合实践一（需求列表），每达成一个新的里程碑，我都会基线化一次。具体配置管理工具不限，最简单的就是拷贝整个工程目录，另存一份副本。这种习惯已经成为我的强迫症，每当完成一个功能就备份一次已经成为基因里本能的活动。实在是有过太多配置管理不当导致重写代码的惨痛教训了。

四、严肃正经地测试。
作为程序员，有一个天然的盲区就是，所有的自测试都按自己的设计思路来测试，因此很难发现程序的bug。我的做法是尽量坚持做TDD，功能没写好之前，先想一想测试的办法。在具体写代码当中，可以使用注释部分代码、插入测试代码的方式来测试。例如状态机，就必定要想办法把每一条迁移路径都要测试到，确保状态机的运行是没问题的。之所以要强调严肃正经，那是因为测试行为一定要按IPO的形式来定义，不经严格定义的测试用例，有些程序的路径和分支就很难走得到。对于复杂的业务逻辑，我倾向于先写测试用例和确定测试场景，程序完成后，再按事先设计好的测试用例来测试，这样可以避免程序自己测试自己产生盲点。