编程黄金过程

转载时请注明出处和作者联系方式
文章出处：http://blog.csdn.net/wswupeng
作者联系方式：吴鹏 <wp_4163196@sina.com>

 

        之前在写程序时，本来任务的工作量是一天，却总会因为这样那样、或高级或低级的错误而无辜的变成了两天、三天，甚至更长。但是完成任务后再回头看，发现很多错误其实都可以很好规避，于是心里想，下次一定不再犯同样的错误。不幸的是，同样的问题依然再次发生：每次代码都能很快写完，但是呢，随之而来的往往是漫长的调试与修改。

 

        作为一个对自己的效率有甚高期望的理想程序员，我总感觉心里堵的慌，因为我太希望整个过程能够清爽一点了。这也促使我思考：能不能自己制定一套标准过程，并通过执行这个过程来提高编程效率？

 

        以下便是我在经历若干次失败的编程任务后，总结经验教训得到的一套东西。不一定说得对，也不一定对所有人适用，但这毕竟是我独立思考后的结晶，欢迎看到这篇文章的人和我交流，大家一起进步，争取早日成为一位高效的程序员。注：我很菜，正扛着键盘和鼠标向小虾迈进！

 

需求分析阶段
1.不迷信下发的规格，带着怀疑的态度审视，尤其是可行性方面。
2.努力干掉需求中的bug。

设计阶段：
指导原则：不屈服于进度压力，遵循逐步求精原则，扎扎实实走好设计阶段，确保产生清晰、全面、可行的设计。耐心，慢工出细活。
1.       对系统中每一块做足够细节的设计，不遗漏，不一笔带过。把所有点串联起来，理清头绪，形成完整的设计。
        A． 自上而下进行设计，精化至足够低的层次。
        B． 在低层，有模糊的地方，立即通过原型代码进行设计。
        C． 形成清晰、明确的流程图，确信它功能模块化并且容易生成代码。
        D． 从实现（代码级）的可行性上进行评审，重现险恶的环境。
        E．  对方案做一定简化。

2.       检查你的设计：模拟真实运行系统、假想说给别人听。抓bug(最重要)

3.       形成易维护、简洁的代码框架。
        A． 单一职责，来去脉络清晰，一种操作集中至一个模块中去操作。
        B． 安心做好自己的事，安全的忽略其他模块细节，各司其职，简单的通过接口交互。

检查表：
1.       是否确信考虑了所有细节，思路从细节到上层都很清晰，整体结构已经稳定。
2.       是否考虑了方案实现的可行性。
3.       效率、复杂度怎样，是否易理解
4.       流程图是否清晰明确，是否模块化易测试。
5.       是否能够很容易的转换为模块化、高可读性、高功能内聚的代码。
6.       是否考虑了扩展性。

 
局限性、不能过度做的事情（相对于编码阶段）：
1.不要以为它能替代编码，把设计阶段就搞得麻烦得不得了。它的最终输出还是框架式的，而不应陷入细节太深（当然，也不能轻视每一个细节，犯想当然的毛病）。
2.设计最多的一次工作是在开始阶段，但并不代表你只需要做一次设计就够了，在编码时还会有设计上的调整。
3.设计无处不在，最根本的设计是发生在草稿纸上的，而不是生成一大堆的文档。重视并实践最根本的设计，文档只是用来整理设计的。

编码阶段

前条件：
A. 设计阶段已经把混乱的全局理清，整个系统全盘每个模块自上而下的流程图已生成，清晰并且易于生成代码。
B. 对流程的可行性进行了足够验证，覆盖了大部分细节。
C．形成了结构良好、稳定的设计， 符合单一职责原则。
D. 对单元测试有一定的考虑。

1.       照着流程图把代码实现。
2.       Code review，避免低级失误。
3.       进行充分的单元测试。仔细设计测试用例，全面考虑各种情况(敏感信息)
4.       在调试器中逐行跟踪，仔细观察其中的异常。
5.       不要放过任何一个异常，深究。

调试阶段
1.       多打印一些过程信息。
2.       在代码中的错误处理要完备，全面展现，更易定位问题。
3.       平台知识对于调试信息的获得非常有益。

 

to sum up:  少犯错，就能有高效率。