关于软件设计

我在第一家公司，花了2-3个月的时间写了一个程序。在以后2年的时间里，一直在维护它，并且不断地调整。调整细节，也调整大块的结构，使得它更加健壮。4年后，当我离开这家公司时，它仍然还健在（虽然现在可能已经寿终正寝了）。

 

最近在思考软件设计的问题，总是会回忆起这个程序。当时我没有什么经验，只知道这个系统的目标，然后就开工。逐渐实现着一个个的细节，再把它们串起来，然后再反复这一过程。当发现无法更好地进行扩展时，就开始大块地调整。当发现某个细节出现问题时，又从头把每个模块检查和修改一遍。

 

当项目比较小时，这样做没有太大问题。我可以随时进行调整。当规划一个比较大的项目时，就需要一个不算太坏的设计才行。

 

对于软件设计，不像土木设计，有固定的框框可以套用。虽然现在有了许多的工具，软件工程也推广了很多年。但也只是个思想，仍然没有银弹的出现。那么，在项目开工之初，如何来设计一套“好”的架构呢？它很健壮、易于扩展、易于维护、高内聚、低耦合，它堪称完美。

 

 

首先，要考虑系统的目标。这个项目是要做什么，用到了哪些技术，这些技术如何衔接起来，前台展示界面应该有哪些，后台应该提供哪些功能，应该分哪几类表，项目组有几个成员，每个成员负责什么模块，模块之间如何衔接……想好了这些比较抽象的东西，就可以开工了。

 

是的，我认为就可以开工了。在开工后，有的成员会发现自己负责的模块原来的设计不易于继续扩展，于是调整了它的架构，但并不改变接口。并且，他通过邮件、周报或项目例会的形式通知了组内成员。遇到类似问题，其他成员就可以避免了。

 

这种方式很简单，将一个比较大的项目切割成几个小份，分给项目组成员，并约定好接口。每个人负责一个‘子系统’，这样，就可以重复我在第一家公司的开发场景了。

 

这样的话，每个人都拥有了比较大的自主权，会不会出现编码不一致？命名不一致？你可能也想到了编码规范。这真的不重要，当用户在使用我的系统时，你觉得他会关心程序代码写的是不是符合编码规范吗？至少，我们的项目在前进，它不会在最初陷入无休止的争论中而导致进展缓慢。

 

那因为编码不一致或者其他原因，它后期的扩展和维护会不会麻烦？是的，这样做，确实是有这样那样的问题，但至少，项目在稳健地向前推进，我们的用户每隔一段时间就看到了新的成果。而且，它是由一个个独立的‘子系统’组合在一起的。

 

 

然后，还是要考虑系统的目标。因为当我们的项目在快速地开发部署应用后，可能项目的目标又发生了变化（这没什么奇怪的，就像我在1年前，根本没想过要离开那家公司）。这时候，我面临的可能需要对现有系统做一次改造，调整一下架构，或者如果运气好，我可以接着在这个系统上加模块。这是我在这个项目之初所预料不到的，也是当时设计时考虑不到的。但没关系，因为这个项目的实现方式，就是一个个独立的‘子系统’，类似于可拆卸组合的零件（当然，比起真正的零件的拆卸组合可麻烦多了），所以，调整架构不会造成太大的麻烦。

 

软件设计只是一种思想，没有哪种架构是最完美的，适合的就是最好的。而适合，是在逐渐的磨合中才实现的。如果有经验，可能会好一些；如果缺乏经验，那么采用这种方式，至少项目在向前推进。这种开发方式也会使得软件自身就具有高内聚与低耦合的特性，扩展它，并不复杂。我现在就是这样做的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/298599/viewspace-694664/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/298599/viewspace-694664/