ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 关于软件设计

关于软件设计

原创 Linux操作系统 作者:yuechaotian 时间:2019-02-13 22:09:05 0 删除 编辑
我在第一家公司,花了2-3个月的时间写了一个程序。在以后2年的时间里,一直在维护它,并且不断地调整。调整细节,也调整大块的结构,使得它更加健壮。4年后,当我离开这家公司时,它仍然还健在(虽然现在可能已经寿终正寝了)。
 
最近在思考软件设计的问题,总是会回忆起这个程序。当时我没有什么经验,只知道这个系统的目标,然后就开工。逐渐实现着一个个的细节,再把它们串起来,然后再反复这一过程。当发现无法更好地进行扩展时,就开始大块地调整。当发现某个细节出现问题时,又从头把每个模块检查和修改一遍。
 
当项目比较小时,这样做没有太大问题。我可以随时进行调整。当规划一个比较大的项目时,就需要一个不算太坏的设计才行。
 
对于软件设计,不像土木设计,有固定的框框可以套用。虽然现在有了许多的工具,软件工程也推广了很多年。但也只是个思想,仍然没有银弹的出现。那么,在项目开工之初,如何来设计一套“好”的架构呢?它很健壮、易于扩展、易于维护、高内聚、低耦合,它堪称完美。
 
 
首先,要考虑系统的目标。这个项目是要做什么,用到了哪些技术,这些技术如何衔接起来,前台展示界面应该有哪些,后台应该提供哪些功能,应该分哪几类表,项目组有几个成员,每个成员负责什么模块,模块之间如何衔接……想好了这些比较抽象的东西,就可以开工了。
 
是的,我认为就可以开工了。在开工后,有的成员会发现自己负责的模块原来的设计不易于继续扩展,于是调整了它的架构,但并不改变接口。并且,他通过邮件、周报或项目例会的形式通知了组内成员。遇到类似问题,其他成员就可以避免了。
 
这种方式很简单,将一个比较大的项目切割成几个小份,分给项目组成员,并约定好接口。每个人负责一个‘子系统’,这样,就可以重复我在第一家公司的开发场景了。
 
这样的话,每个人都拥有了比较大的自主权,会不会出现编码不一致?命名不一致?你可能也想到了编码规范。这真的不重要,当用户在使用我的系统时,你觉得他会关心程序代码写的是不是符合编码规范吗?至少,我们的项目在前进,它不会在最初陷入无休止的争论中而导致进展缓慢。
 
那因为编码不一致或者其他原因,它后期的扩展和维护会不会麻烦?是的,这样做,确实是有这样那样的问题,但至少,项目在稳健地向前推进,我们的用户每隔一段时间就看到了新的成果。而且,它是由一个个独立的‘子系统’组合在一起的。
 
 
然后,还是要考虑系统的目标。因为当我们的项目在快速地开发部署应用后,可能项目的目标又发生了变化(这没什么奇怪的,就像我在1年前,根本没想过要离开那家公司)。这时候,我面临的可能需要对现有系统做一次改造,调整一下架构,或者如果运气好,我可以接着在这个系统上加模块。这是我在这个项目之初所预料不到的,也是当时设计时考虑不到的。但没关系,因为这个项目的实现方式,就是一个个独立的‘子系统’,类似于可拆卸组合的零件(当然,比起真正的零件的拆卸组合可麻烦多了),所以,调整架构不会造成太大的麻烦。
 
软件设计只是一种思想,没有哪种架构是最完美的,适合的就是最好的。而适合,是在逐渐的磨合中才实现的。如果有经验,可能会好一些;如果缺乏经验,那么采用这种方式,至少项目在向前推进。这种开发方式也会使得软件自身就具有高内聚与低耦合的特性,扩展它,并不复杂。我现在就是这样做的。

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

请登录后发表评论 登录
全部评论

注册时间:2005-03-28

  • 博文量
    27
  • 访问量
    24260