我要专业之设计文档

      作为一个半路出家的程序员，没有经过专业的课程，写程序当然显得业余。“只有专业才有机会”，这句话不论是对企业还是个人都是正确的。想当初，凭借一股编程的热情投身于现在的公司，由于公司规模小，没有专业的培训，只能靠自己一点点的积累，当然身边还有一位大牛可以讨教讨教，也算是幸运了。记得刚开始编程的时候，以为代码才是最重要的，总是无比羡慕崇拜那些一个几万行的程序的作者，梦想自己也能有如此成就。后来因为工作的需要也满足了我大量写代码的心愿，然而在一个个程序写出来以后，自己逐渐就陷入了一个难以自拔的沼泽地，越陷越深。纵使我熬通宵，周末加班也不能让我心理踏实下来，因为自己的程序到了崩溃的边缘。

      在茫然中，我开始反思现在这糟糕的一切。以前习惯性的把导致这一切的缘由归于不断变化的用户需求，而现在看来其实不然。对于软件来说，满足不断修改和增加的用户需求本来就是其最重要的工作，如果用户需求不变，那么也就不会讨论什么代码扩展性了。程序的维护成本就大大降低，因为维护编程了简单的查找已有bug。编写程序在也不用遵守什么耦合度低原则，KISS原则。。。，一切就变得非常简单。工作变得简单对于工作人员来说意味着门槛变低，门槛低意味着什么，你懂得。

       那个自己挖的沼泽地是这样一步步形成的：程序需求不清楚--》程序没有或者几乎没有设计文档--》着手编码--》编码过程中不遵守基本的原则（比如低耦合度，KISS，DRY等）--》修改过程中为了方便，怎么省事怎么来--》沼泽地越挖越大，越挖越深

      沼泽地挖的多深多广，和上面每一个步骤都密切相关。后面的编码技术范围太广，更何况我也就一菜鸟，会都是皮毛，所以等我成为大牛的时候再来摆摆吧。其实这篇文章只是记录自己痛苦的经历，让大家分享下（不厚道~痛苦的经历还让人家分享）

      

     设计文档很重要，这是目前为止我血和泪的总结。当一个人建房子连设计图都不用画，要么是盖猪圈，要么是茅厕。程序也是这样，如果写个小的功能程序，设计重要性就会降低，只要程序上了一定规模，没有前期良好的设计工作，那么等着走进自己挖的沼泽地吧。设计文档中主要包括需求分析，程序设计流程。需求分析是设计流程的前提，对于一个都不清楚程序到底要做成什么样子的程序员来说，写到最后可能就是一个杯具，被全盘推翻掉，费时费力。当前自己编写和维护的一个程序就是由于当初没有重视需求分析，都是口口相传，种下苦果啊。对于明确的需求我们当然要实现，对于潜在的需求这时候我们在设计流程的时候，就需要考虑扩展性了。这就好比菜鸟和大师下象棋，大师走一步看百步，菜鸟走一步看一步。当我们对于产品足够熟悉后，就要尽最大的可能考虑潜在需求，所以这也要求我们对于产品在市场的应用场景有足够的了解，对于行业也要多多关注（这点我是自己做的不够好，以后要多关注监控行业）。

     当我们对于需求有了透彻分析后，流程图就是设计阶段了。关于流程图我有以下几点个人领悟：

      1.要知道流程图是给谁看的？是给别人看的，是给一个并不了解实现细节的人的看的，是给一个完全不懂技术的人看的，是给任何一个想看的人看的。如果我们的流程图可以让一个不懂技术的人都能看的明白的话，那么就画的不错了

      2.流程图和编码实现的关系。个人觉得，如果一个流程图足够好，那么就完全可以用伪代码实现了，然后由伪代码转化为任何你想用的语言。好的流程图可以基本上就可以看做代码了，也许是这样大师把流程图画好，剩下的就交给Coder了

       3.好的流程图到底有啥用？一个清晰的思维不仅要展现在你优秀的大脑里，更应该展现在纸上。好脑子比不上烂笔头，只有在实体介质上体现出来，才能多角度论证，排查，以及交流。我当时写程序的时候，就记脑子里结果现在一脑子江湖，项目经理来确认个问题，我就必须翻代码，效率极低。

       4.继续领悟中。。。

好了，这次就分享这么多痛苦的教训吧，谨以此文纪念我最近加班熬通宵的日子，希望早日能游刃有余，不在是一个半路出家的菜鸟。