合格的程序员之路——接到任务之后
?
合格的程序员不同的程序员之路?
3. 任务分解，分解为多个子模块并且知道子模块之间的关联，并分析各个模块大概使用什么技术。这个需要经验，不过我这里有一个想法看看是不是捷径：一个任务就是一个服务，而一个服务的完成需要更多的小的提供服务方提供的服务联合才能完成。上面的例子：知道难点后，我们可以为了可扩展性划分：饮用者模块，饮用方式模块，饮用对象模块。其中饮用者可以是人或者动物，饮用方式模块可以使饮水机或者水龙头，饮用对象模块可以是水或者牛奶。这样三个模块之间便是，饮用者使用饮用方式饮用饮用对象。而且我一个模块不关心你另一个模块里面到底是水还是牛奶这样具体的实现，只需要知道我发什么信号给你你给我什么东西。
4.工作量评估。这个纯属看个人经验，只有自己才知道自己几斤几两。看各个模块都需要什么技术，估计一下自己哪些是熟悉的哪些需要现学，然后是自己的学习能力，综合评估一个时间。
5.?在整个过成功要站在更高层次的角度看自己的任务，知道自己的任务在总的任务里的位置，和其他子系统的关系。
可行性分析1.?确认具体使用什么技术，哪些是自己已经有把我的，哪些是需要学习的。
2.?确认时间分配是否足够，别忘记给自己预留时间，不然如果延期，会被鄙视。
3.?确认和大范围内的其他系统或者模块之间的关系是什么，主要确认你延期或者哪个模块延期会影响到别人的进度，并且知道你的延期会影响到谁。还有没有其他没考虑到的。
4.?任何问题有了明确的答案之后，调整你的计划，然后进行下面的工作
设计你不觉得设计是件比写代码美妙的多得多吗？为啥还要拿到任务就埋头苦干？
1.?首先确定问题已经被抽象的足够好了。
2.?其次根据抽象结果划分模块，并定义各个模块的关系。（计划中的分解任务的模块是思想逻辑上的模块，这里敲定的是代码上的模块，每个模块对外提供接口访问）这里要确定：程序流程设计，数据结构设计，类和接口设计。
小结：一般的设计先出一份产品流程图或者状态图（程序流程设计），然后出一份业务实体类图（数据结构设计），然后是服务类图（类和接口设计），最后是时序图（类和接口交互）。
3.?考虑程序未来的数据量和并发可能性，考虑产品未来的稳定性，可扩展性，可靠性，性能等方面。
4.?出具一份文档：程序设计文档（可以只有UML图）和一份测试用例。这里是很多人不愿意做的事情，但是这个很重要，对公司和你自己来说都很重要。
开发没啥说的，都是程序员了。就是别忘记必要的单元测试（我不是敏捷开发）。
测试这里的测试是指自测，自测到家，按照测试用例自测。最好让测试人员只有拔网线，强删数据库这样极端的测试，其他我们自己搞定。只有0BUG才不丢人！
包括单元测试，接口测试。要测试到和其他子系统或者模块之间调用的正常，性能达到指标。
交付不是只有代码有了可以跑过就是可以交付了：1.可读性强的代码；2.程序设计文档；3.测试用例；4.接口说明。
保证自测到几乎0BUG。
遗留问题。
总结反思在这轮开发任务中，各阶段有没有犯错误的地方？犯错误的原因是什么？今后如何避免？工作量预估是否准确为下次预估做准备？程序中还有什么因为时间关系而没有特别处理的？心得是什么，都写下来吧。咱不求一日一文，至少一个任务一篇心得总得有吧….
