the5fire

其实这个也不能算是详细设计，不过是为了让别的开发者能够对我们的项目进行二次开发而写的文档，只是文档的详细程序已经赶上详细设计，甚至是比详细设计更详细。
这时的文档也不能称之为“设计”，称之为“说明”才更为恰当。
在写文档的时候我就一直在想，如何才能够写的清晰明了、无歧义，让其他开发人员能够很好的理解你的代码在做什么。
就我个人看来，要人另外的开发人员能很好的理解你的代码是一件相当困难的事，因为里面包含的不仅仅是你所用到的技术，更多的是整个项目的业务逻辑。
因此，妄图通过一个说明性质的文档来让人理解的行为是愚蠢的。最佳的方案就是通过javadoc工具生成一个chm格式的文档，供人快速查看，随用随查。
但，你懂的，要使用javadoc生成文档，你需要提前写好java注释，这点极其重要。无奈的是着手过这个项目的开发人员似乎没有这样的习惯，或者说觉得自己写的代码十分通俗易懂。
也包括我自己在内，有时候写一个方法的时候觉得挺好理解，但是回过来看的时候会发现其实要理解的不是代码，而是业务。
不得不说这个项目的整体架构是比较合理的，因为需求修改到目前为止，所有的情况依然尽在掌握。
但是也不得不说这个项目的局部质量确实令人难受。

从这个项目中我也领悟到一些项目开发的真谛：所谓项目就等于一个优秀的经得住折腾的架构加上一群能折腾的程序员的代码。
公司做项目是要挣钱的，这点无可厚非，所以最终的目的不是说出来一个具有优秀代码的项目，而是要一个能交付客户的项目，其中的内部结构如何，who care！

写了差不多九十多页的文档，想象一下如果要是我看到这样的文档我会不会晕掉。不过一个懂得看大纲视图的程序员应该会觉得天气还是很晴朗的，因为通过大纲视图可以快速的定位包和类。

为了写这个文档也是有机会把整个项目捋了一下，发现涉及不到业务的地方编码质量都相当的好，面向对象发挥的很充分（这个主要是数据库访问层）。但是涉及到业务逻辑的地方代码写的都很草率。
或者说接近数据库的代码是直接用的原有的设计也不一定。

最后写完觉得，这样一个项目其实不需要你有多高的编程技巧，只需要你能很好的理解业务逻辑，理解行业。
我也在想，这样下去或许当个项目经理就是很自然的事情了。

但这并不是我想要的


- from the5fire.com