不好意思，让大家久等了，博士太忙了！
今天讲的不是只针对编程的，当然编程当中我也经常遇到这种问题，就是编码开始的太早了，却没有经过仔细的考虑，规划，设计，就草草的开始编码，最后的结果是，代码乱的自己都分不清东西南北了，我问他，这一段是干嘛的，他要仔细研究上下文之后才能够给我答案。
我一直在强调计划，设计的重要性，这不仅是在编程中，做任何事情，都需要有计划，有秩序，有节奏的进行。我从前在本科期间，参与组织过很多的活动，每次需要我组织一个活动的时候，我会很详细的写下每一个环节，时间，地点，人物，道具，需要什么，安排什么，这些还没有发生的事情像电影一样在我的脑子里过好几遍，而基本每一次我都能够找到我还没有考虑到，或者说疏漏的地方，组织的次数多了，以后每次遇到一件事情，我就很自然的开始进行计划了，而好的计划总是能够让我事半功倍，所谓磨刀不误砍柴工，当真是至理名言。
说到编程，计划就意味着各种设计，你要在你自己的脑子里面非常清楚，你要写的这个程序或者软件，写出来应该是什么样子的。我连写一个HTML页面，一个简单的CSS布局都要在草纸上画出分布图，这种设计可能别人根本看不懂，但是对我很有用，我设计一个导航条是怎样的，然后按照设计制作背景图，边框，最后的结果是一个像素也不差。这就是计划，设计给你带来的便利，给你带来的好处。否则，你要修改CSS，你要修改图片，改来改去自己都乱了。
很多时候我看他们的代码，很乱，这个乱指的是没有规划，至少没有很好的规划，拿到需求就开始编码，从来没想过我要从这里面抽象出几个函数，每个函数都完成什么样的功能，每个函数携带什么参数，是否需要重载等等；有时候就算规划了，也是在脑子里面灵光一闪，当真正写代码的时候就忘记了，好记性永远不如烂笔头，记住这句让很多人重复了很多次的名言吧。我在告诉他们应该如何编码的时候，我很少只是简单的说，很多时候我拿出一张草纸，如果我想的很清楚了，那么我会给他写出伪代码，这就是我的设计思路，如果是我自己编码，我也会这样写的；如果我并没有完全想好程序的结构，我会很清楚的列出第一步如何做，第二步如何做，我这么做的目的是想让他们能够很容易的了解程序的结构，从而对编码进行规划和设计。但是我很失望的看到：他们对规划的重视程度远远不够。
可能你在编码的时候会遇到这个问题，有一个功能我在这里遇到了，在另外一个地方也遇到了，或者是类似的功能，只要是这样的情况，就必须把这些东西抽象出来，抽象成一个函数，一个类，甚至一个模块，如果在设计的时候并没有考虑到就开工了，那么你就会发现，这个程序的结构已经乱了，这时候有两种方案：第一，停下编码，进行设计，这是明智的，所谓亡羊补牢，犹未晚也；第二，不管他，这两个地方功能不是差不多吗？我把刚才那一段代码复制粘贴过来稍加修改不就OK了？这种方式很快，可以让你很容易的实现第二个类似的功能，可是这样真的Ok吗？如果你第三次，第四次遇到了同样的类似的功能或者代码段的时候，你怎么办？如果你第一次写的代码就是错的，那么你复制粘贴过来的全部都是错的，需要改动的地方很多很多。
上述问题的另外一个弊端是程序的可读性。你现在看你的代码，觉得每一行我都能很清楚的知道到底是干嘛的，可是一周之后，一个月之后，一年之后，你还知道吗？如果一个月之后程序出现问题了，你再回来读，基本上就和读陌生的代码没什么区别了，而遇到上述“几块儿代码基本都一样”的问题，会严重的迷惑你：为什么一样的代码出现了这么多次？同时这些代码成为你程序出问题最值得怀疑的地方，因为说不定就是哪一次你复制粘贴的时候，少改了一个参数。
设计的好处，还可以表现在改动上。好的设计可以让你在需求改变时做最小的改动。我们把链接数据库的类单独抽象出来，就是为了这个。最原始的做法是：写一段链接数据库的代码，然后复制粘贴到每一个JSP页面中。可是一旦数据库地址或者端口改变了，这需要多大的改动量？可能你现在觉得把数据库抽象出来是理所当然的，因为我们一直就是这么做的，那么在设计自己的类，自己的程序代码的时候，为什么就不能花一些时间把公共的部分抽象出来呢？直到需要修改N个地方的时候你才发现，这里本来应该可以抽象成一个公共模块的，那样就方便很多了。记住：就算简单到一个只有几行的函数，也必须进行仔细的考虑和设计，这是一个很好的习惯。
如果你从未进行编码，或者编码很少，要做到很完美的设计太困难了，必须遇到几次这样的问题可能你才能真正理解这种抽象，设计的魅力，我写这篇文章并不是要大家马上就能设计抽象出很完美的结构和模型，而我也无法教给你如何去做，这些都必须依靠你自己在编码时总结完成。我是要给你提个醒：要重视设计，第一次没设计不要紧，第二次尝试着去做做看，第二次设计的不好不要紧，总结经验，把设计写下来，和最后的程序比较一下，看看设计的时候哪些问题被忽略了，下一次好好设计一下，但是如果你做了五次都没有意识到应该进行提前的抽象，设计，那么你这五次编码不过是在做苦力罢了，除了编码更熟练以外，不会有太多的进步。
这次的主题词就是：不要贸然开工，设计先行，哪怕是只有你自己看的程序，也要设计。
好了，希望本文对大家有所帮助，下期预告：《编程的坏习惯之百密一疏》。
以一个门外汉的身份来看，
不光编程，
其实做什么事情都一样，
首先得有一个大体的计划和框架。。
@chanthon 所言极是啊，这算是一种能力吧
说实话，在做南京党建系统详细设计的时候，初期给我唯一的感觉就是浪费时间，可能是有些东西，我确实不知道怎么实现，设计的必然会有偏差。真正实现的时候更感觉漏洞百出，有的设计甚至需要全盘否定。
其中一个模块之前做过，写详细设计的时候思路也非常的清晰。
我觉得详细设计成功与否与我们平时练习的多少也是息息相关的。只有做过才能真正的描述出来。（抒发一下感情，哈哈）
在做别的项目的时候，我也深深的感受到设计的重要性，由于考虑不周，设计不当等等，很多地方返工了好多次，大大降低了效率。
@Hope 你看看我上面给yxp回复的，设计和编码是一个反复循环的过程，就好像理论与实践要相辅相成，共同发展一样，设计和编码不能够互相脱离
一直知道设计的重要性，可是真正实施的时候总感觉就跟预想的出现偏差，而且设计的时候总感觉有不明确的地方，这时应该怎么办呢？
说到设计，我就想起了做四方那个项目，刚开始的时候，主程序框架是贾导带着我写的伪代码（应该是哈），虽然后来需求变了很多，一而再再而三的改服务器部分，但相对来说还算比较好改。
@sunshineyxp 在需求分析和用户体验设计方面，有一种方式，我记不得叫什么名字了，大概意思就是，在需求和用户之间不断循环，并不开始编码，然后经过若干次之后，需求越来越接近用户的要求。你的问题和这个类似，可以使用伪代码的形式，让伪代码越来越接近真实代码，如果出现问题，马上更改设计，然后继续伪代码，有问题再改设计，循环到最后真正的代码基本形成，和设计基本上是相符合的。
好的设计肯定会给修改带来便利的
虽然代码写的不多，但是四方那个项目确实让我见识了设计的重要性，要不然后期改动时，就够麻烦的了。
ps：我发现你写博文速度很快，就听你啪啦一会键盘，洋洋撒三几千字就出来了，看来就是说相声的呵呵，赞一个
ps：貌似这次我又是沙发。。。。。。。。。
@myonlystar 写了半个小时还多，时间够长的，和说相声感觉关系不大，主要是要有东西写
@老杨 这次评论回的也很快啊
@myonlystar 嗯，咱有邮件提示，就是牛，哈哈