有关软件架构设计 的思考

 最近在重构设计。这一回自己吸取了之前的教训，在想清楚整个设计的架构之前，一直没有动手写太多实

际的code，更多的时候是用伪码来描述验证自己的设计思想。

花了三天的时间，在一条设计道路上不断地思考，尝试，最终发现并不太可行，于是 改换另一个思路继

续进行设计，经过一天时间的设计，发现这个思路也存在一定的缺陷，及至今天，才算是基本确定下来整

体设计的框架。

如果自己这一次还是在设计阶段浅尝之后就开始实际动手coding，恐怕就未必能够及时地意识到设计中

存在的不足了。很多时候，虽然在实际编码的过程中我们能够体会到设计中存在一些缺陷， 但是身陷于

细节实现其中，大脑往往被“ 快点搞定它”的想法所充斥，已经无暇再回到比较高的角度来思考整

个架构的合理性了，这种情况下，往往要待到编码到一个 原有的设计缺陷已经无法忍受的状态下，才

会明确清晰地意识到有必要重新考虑设计层面的变化了。

但是到了这种时候，也往往意味着前面大量的实现工作要被推翻重来，不啻为一种浪费。

而在设计阶段，作得细致一些，尽量不要让自己陷入实现的细节中纠缠，即使在仅凭思考和抽象已经不易

把握系统复杂度的时候，也不要轻易诉诸实现，而是借助于流程图，伪码这样的抽象层次较高的手段来协

助自己建立起对系统的具体理解，则有助于以一种有序的方式把握整体的设计了。

设计工作往往是抽象的，不易把握的，甚至是有些痛苦的，因为你往往要从一个空白的起点开始通过抽

象，组合，等等手段构建出一个假想的符合要求的目标架构，这种不够厚实，欠乏实物支撑的感觉经常会

让一个设计经验不是很丰富的开发人员在设计阶段萌生出逃避设计，尽早切入具体coding的想法。

而相比之下，实现工作则具体得多，也易把握得多，也更容易带来 快速成就感，所以开发人员可能更容

易倾心于一个具体模块的实现。 这也是诱使我在前面的开发过程中在设计还未足够明晰的情况下就过早

介入具体实现的主要原因。