GF常说我吃家里饭操别人的心。
父亲常被母亲这样“骂”，这是我家的宿命。
以前都是一个人开发，从有想法，到最后发布到网上。
而且都是一些很小的工具软件，因此，没有体会到设计的重要性。
由于喜欢编程，在这方面的文章看得自然多一些，知道有种说法是：软件工程70%的设计，写代码只占30%。
最近，由于5个人在开发一个小项目，前期只有几个页面，由于涉及到后期的东西，为了后期考虑，将业务层写得很复杂，将现实中的事物基本是一对一的映射成类/集等。
其实几个页面，一个人几下搞定，但是为什么，我们目前还没有完成呢？
不是项目经理没努力，也不是成员们偷懒。
那谁来承担责任呢？
这不是问题，谁承担责任，对以后的项目有好处吗？没有！
找到导致此情况的原因，并在以后的项目中避免再犯此错。
设计！！
是设计！
在我仅参加的一次项目会议上，记得已经有人提出了问题，是那种由感而发的问题，感觉到有某个地方有点不正常。
的确，他感觉到了，并提出了－－“设计稍显粗糙”。
现在，我们为此付出代价了，周一应该测试的，可我们周末加2天班，仍然没有看到曙光！
今天周二了，曙光在哪里，我仍没看到。
那这么久，我们在作了什么？
项目经理，是最累的，大家都看得到。
可以说“头发都想白了”，这话来形容，太贴切了。
其他4人呢？
在内耗！注意在这里“内耗”是中性的意思。非贬非褒！
由于没有细致的设计阶段应该出来的文档，成员们只有事无具细都找项目经理交流。
你想，换谁，再好的脾气，再好的涵养也会疯狂的。
4个人，每人一天问N个问题。N>20。而被问的这个人，不是专门解答问题的，他还在“想白头发”的在思考，如何设计。
他此时会是多少进程在同时运行，还不断有4个无规律的中断事件进来发出请求。电脑都要死机，何况是人。
在这种情况下，设计出来的东西，当然不算好，分配任务也不会很合适。
于是成员们，会花很多的时间来猜测和寻找，自己需要的数据，从哪个类，用哪个方法取出来。如果有一点不清楚，先自己想（都不忍心再去打扰项目经理），花了N多时间，没解决，然后，再去找项目经理。
即使这样，进展也很缓慢。质量也不高。而每个人都觉得很艰难。
正好，这样恶性循环，进展慢，时间紧，“头发白”想出来的，业务层设计，注释和说明就尽量的少了，节省时间嘛。导致，其他人看不明白，又不好意思频繁地去刺激老大，只有自己想，实在想不出再去刺激老大一下。
如果遇上老大在苦想阶段，这交流效果肯定不好，两个人说了半天，都还不知道对方的意思。
好了，不再唠叨这没有详细设计就开工的负面情况了。
如果！我们来总结一下，加上如果。至少今后，可以按“如果”来作作。我在此只是设想一下，如前所述，我一个人开发惯了。并没有团队开发的经验。如有不对之处，还请指证。
一个项目，不论大小，只要不是一个人开发，就需要每个参与者都对此项目很了解，特别是要了解“它”是如何设计的。哪个类，哪个方法，是作什么的。这个是起码的要求。
但是在缺乏设计文档的情况下，一边开发，一边定义类，接口，而以时间紧为由，没有写清楚，这定义的这些东西是作什么的？怎么用？
那别人会花更多的时间来猜测这个东西是作什么的，怎么用？浪费的时间，比别人自己从数据库写到表现层更多。
在设计阶段，我们几个开发人员一起，进行N次讨论（或称会议吧），作什么呢？
从用例讨论到抽象，从界面层的按钮的放置到数据表的字段定义。并形成文档。
文档细致到有每个类及类应该有的属性，方法。
这样每个方法返回什么，实现什么功能，都确定好了。
而且有一个好处是：避免了在始真正写代码时，发现这也缺一点，那也不合适，这样调整起来，会发现，改了这里一个问题，那里又出了更多问题。
这样会将前期的设计搞得面目全非－－－（套用一句话，真的会“连他妈都不认识”）。
如果设计时，大家一起讨论并一起将这些细致到类和接口及其目标和参数，如果有不妥的地方，会在下一次讨论时，大家一起修正。
修正文档和在实际开发中修正代码容易不是一点两点，对吧。
到这里，我们就可以真正的实现设计70%（大家在一起讨论，气氛很好，不会紧张和觉得打扰到对方）。
在编码的时，可以从文档中依葫芦画瓢，轻松简单，不会再频繁地去打扰其他成员的思路。
编码真就成了一个体力活了，不会常常看到扣破脑袋的情形了。有的只是边听音乐，边优雅的敲击键盘。
于是一个项目就在轻松团结的背景下完成了。