软件工程中设计与编码

 

GF常说我吃家里饭操别人的心。

父亲常被母亲这样“骂”，这是我家的宿命。

 

以前都是一个人开发，从有想法，到最后发布到网上。

而且都是一些很小的工具软件，因此，没有体会到设计的重要性。

 

由于喜欢编程，在这方面的文章看得自然多一些，知道有种说法是：软件工程70%的设计，写代码只占30%。

 

最近，由于5个人在开发一个小项目，前期只有几个页面，由于涉及到后期的东西，为了后期考虑，将业务层写得很复杂，将现实中的事物基本是一对一的映射成类/集等。

 

其实几个页面，一个人几下搞定，但是为什么，我们目前还没有完成呢？

 

不是项目经理没努力，也不是成员们偷懒。

 

那谁来承担责任呢？

 

这不是问题，谁承担责任，对以后的项目有好处吗？没有！

 

找到导致此情况的原因，并在以后的项目中避免再犯此错。

 

设计！！

 

是设计！

 

在我仅参加的一次项目会议上，记得已经有人提出了问题，是那种由感而发的问题，感觉到有某个地方有点不正常。

 

的确，他感觉到了，并提出了－－“设计稍显粗糙”。

 

 

现在，我们为此付出代价了，周一应该测试的，可我们周末加2天班，仍然没有看到曙光！

 

今天周二了，曙光在哪里，我仍没看到。

 

那这么久，我们在作了什么？

 

项目经理，是最累的，大家都看得到。

 

可以说“头发都想白了”，这话来形容，太贴切了。

 

其他4人呢？

 

在内耗！注意在这里“内耗”是中性的意思。非贬非褒！

 

由于没有细致的设计阶段应该出来的文档，成员们只有事无具细都找项目经理交流。

 

你想，换谁，再好的脾气，再好的涵养也会疯狂的。

 

4个人，每人一天问N个问题。N>20。而被问的这个人，不是专门解答问题的，他还在“想白头发”的在思考，如何设计。

 

他此时会是多少进程在同时运行，还不断有4个无规律的中断事件进来发出请求。电脑都要死机，何况是人。

 

 

在这种情况下，设计出来的东西，当然不算好，分配任务也不会很合适。

 

于是成员们，会花很多的时间来猜测和寻找，自己需要的数据，从哪个类，用哪个方法取出来。如果有一点不清楚，先自己想（都不忍心再去打扰项目经理），花了N多时间，没解决，然后，再去找项目经理。

 

即使这样，进展也很缓慢。质量也不高。而每个人都觉得很艰难。

 

正好，这样恶性循环，进展慢，时间紧，“头发白”想出来的，业务层设计，注释和说明就尽量的少了，节省时间嘛。导致，其他人看不明白，又不好意思频繁地去刺激老大，只有自己想，实在想不出再去刺激老大一下。

 

如果遇上老大在苦想阶段，这交流效果肯定不好，两个人说了半天，都还不知道对方的意思。

 

 

好了，不再唠叨这没有详细设计就开工的负面情况了。

 

 

如果！我们来总结一下，加上如果。至少今后，可以按“如果”来作作。我在此只是设想一下，如前所述，我一个人开发惯了。并没有团队开发的经验。如有不对之处，还请指证。

 

 

一个项目，不论大小，只要不是一个人开发，就需要每个参与者都对此项目很了解，特别是要了解“它”是如何设计的。哪个类，哪个方法，是作什么的。这个是起码的要求。

 

但是在缺乏设计文档的情况下，一边开发，一边定义类，接口，而以时间紧为由，没有写清楚，这定义的这些东西是作什么的？怎么用？

 

那别人会花更多的时间来猜测这个东西是作什么的，怎么用？浪费的时间，比别人自己从数据库写到表现层更多。

 

 

在设计阶段，我们几个开发人员一起，进行N次讨论（或称会议吧），作什么呢？

 

从用例讨论到抽象，从界面层的按钮的放置到数据表的字段定义。并形成文档。

 

文档细致到有每个类及类应该有的属性，方法。

这样每个方法返回什么，实现什么功能，都确定好了。

 

而且有一个好处是：避免了在始真正写代码时，发现这也缺一点，那也不合适，这样调整起来，会发现，改了这里一个问题，那里又出了更多问题。

 

这样会将前期的设计搞得面目全非－－－（套用一句话，真的会“连他妈都不认识”）。

 

如果设计时，大家一起讨论并一起将这些细致到类和接口及其目标和参数，如果有不妥的地方，会在下一次讨论时，大家一起修正。

 

修正文档和在实际开发中修正代码容易不是一点两点，对吧。

 

 

到这里，我们就可以真正的实现设计70%（大家在一起讨论，气氛很好，不会紧张和觉得打扰到对方）。

 

在编码的时，可以从文档中依葫芦画瓢，轻松简单，不会再频繁地去打扰其他成员的思路。

 

编码真就成了一个体力活了，不会常常看到扣破脑袋的情形了。有的只是边听音乐，边优雅的敲击键盘。

 

 

于是一个项目就在轻松团结的背景下完成了。