开发人员的事情就是coding，没日没夜的coding，而且大家都是这样在coding，但是效果和结局就不一样：有人coding了N多年，技术还是原地踏步，编写出来的代码还是bug连连；有人coding就变成了技术骨干，甚至有人成为了CTO，架构师等。
为什么？
首先从一个小的故事说起：一个项目，分配给了项目组的人开发。于是大家就热火朝天的干了起来。当时，就发现了一个现象：任务已分配完成之后，有人就开始coding了，噼里啪啦的开始敲代码，不久之后又开始噼里啪啦的改代码，然后又开始不断的调试，找出bug，然后修改bug。很快，这个迭代的期限就到了，原计划要完成的功能很多没有实现，有的人也确实做完了，问题也一大堆，有人也确实完成了，没有bug，但是在审查他的代码的时候，就是看不懂。
这里想起了自己刚刚步入IT开发行业时候的情景。总是希望尽快的把事情搞完，因为只要没有做完，就拖了项目的后腿，很可能被leader训导，甚至可能被认为没有能力而被开除。在写代码的过程中，发现一点：尽管写代码的速度是快了，但是在写完了之后，每次编译，都发现错误，编译通过了吧，逻辑又有错误，然后就这样不断的缝缝补补，功能是完成了，但是心里有一种想法：以后千万不要让我来看和来改这段代码。因为代码写的很烂，烂的连自己都不想看，而且很多实现的方式也是很诡异。反正结果是：功能完成了。其实自己心里也很清楚，在写代码的时候，脑子有点糊，而且写着写着就不知道写什么了。
后来慢慢的发现：如果再这样下去，对自己的发展是没有好处的，而且原本认为很有技术含量的编程活动也变成了一种没有技术含量体力活，有时候甚至不用脑子。
就如软件开发中的需求一样：变化。
人也要：改变。
所以在之后的项目开发过程中，就给自己定了一个目标：写完一个小功能的代码，确保一次就编译通过（当然，在写代码的时候肯定得注意逻辑，但是偏重在使得编译通过），于是，在开发的时候，就开始"用心"了，或者说是更加的细心了。
一段时间的磨练之后，这个目标达到了，而且还超出了期望的值：写完一个大的功能代码之后，编译也没有错误。
所以这里悟出了一点：同样是做事情，做的也是同一件事，目标不同，结果就不一样。
这样之后，写的代码质量确实是提高了，但是另外的问题又出来了：写出来的代码总是在缝缝补补，总是这里差一点，那里差一点。很多地方很欠考虑。
怎么办？
发现了怎么一个问题：每次在任务分配了之后，就开始coding。这没有错。大家都这么做的。但是有一点：每次在实现一个功能的时候，总是一边写代码，一边思考，就这样，一步步的把功能实现。其实这就是问题所在。
就好比下棋，你总是走一步算一步，但是你的对手在走一步的时候，已经想到了后面的3步，4步，甚至更多步怎么走。如果你和这样的对手下棋，输家常常是你。
写代码也是一样的，不要走一步算一步。在写代码之前，首先从业务上，要把这个功能的流程搞清楚，然后再考虑：如果实现这个流程，要怎么写代码。然后在开始写代码，于是带着这个思想，发现自己写出的代码逻辑错误就少了，起码在总体的流程上是对的，可能在有些地方缺少一些考虑，如验证等。这样bug也少了，开发的速度自然快了。
说白了，就是在实现一个功能之前，先要设计，或者专业一点，画画流程图，其实流程图也不一定非得用UML画的那么标准，很多时候，就是拿一支笔和一个练习本开始画了，只要自己认识就行了。
采用这种方式之后，发现不仅自己的设计能力提高了，而且对开发出来的功能也是很有信心的。
一个功能，在草纸上设计，一个模块，也这样设计，甚至一个小的体统也这样设计，慢慢的，就可以上机coding之前，整个功能就已经在头脑中实现了，剩下的就是转为代码的事情了。
在项目中，总是想控制项目的进度，但是每次在开会的估算一个功能什么时候可以做完的时候，往往听到的却是这样的话"应该可以在一周之类完成"，"估计应该可以吧"，等等，诸如此类的没有把握的话，最后的结果是：什么时间规划都是白搭，延期，再延期。
其实很大的程度上就反映了设计的问题。
当我们在估算项目的时候，很多的时候我们没有一个准确的估算，或者说只有一个大概的估算。其实这就是设计做的不够。
当一个任务分配下来之后，我们确实一直在考虑业务流程和怎么实现，但是终究只是停在"考虑"上，没有进一步的细化，细化的颗粒度不够，没有细化到用到几个类，几个方法，很多的时候只是大概的想想怎么实现。就因为这样，项目的风险很大，甚至不能控制项目，而且也不知道项目是否按照计划在在进行。
如果设计做的充分的好，最后的结果就是：整个类，流程都基本敲定，只是填充方法的实现而已，这样项目是否按照计划进行就一目了然。
其实，编程终究是需要动脑的，多多的思考。
本文地址：http://www.nowamagic.net/librarys/veda/detail/478，欢迎访问原出处。
京公网安备 11010802041100号