架构设计的注意事项

 

    新产品从开始编码到现在已经有一年了，第一版的发版也过了有3个月，这一年里，对开放封闭、依赖倒置、单一职责这些设计模式的期待，追求多层次间解偶，向往面向对象面向接口的设计与开发思想。有太多内容塞入到这个需求不够清晰，时间不够充裕却又承担众多经济与政治期望的项目中。 仿佛要通过这么一次的锻炼，我们的团队就要变成技术与设计的双料高手。回顾过去，或许正式这种想法造成了现在我们团队的一个不稳定因素：架构设计和业务实现上的矛盾。

 

架构师说：我们是面向对象面向接口的编程，我这么做要解偶，后台不能受前台影响，你前台的东西我不管。

业务实现说：满嘴跑名词，当老师去吧。你那接口倒是好用点啊，那么多东西我怎么知道该用哪个不该用哪个，对的也是你让的错也是你教的，话全让你一人说完了。我干脆自己实现一个得了，还省的找麻烦。还有我前台按业务需求就要这么做，你后台咋就不能按我的要求支持接口？

 

          没有人想回到代码浆糊的时代，不想再在牵一发而动全身的产品中挣扎。理想总是美好的，现实却又那么残酷。问题到底出在哪?

 

         几年前，当我在做程序员的时候，我编写业务模块实现，产品设计（或叫架构师）总是在研究怎么能把现在写的那点东西简化，写了一套套的类库叫我们来用，可是按他风格写的基础结构我们总是用的不习惯。比如他用collection的共性来代替recordset的特性。虽然说代码少了几行，但我们敲ADO的那点代码费不了多少时间，反而在他包的一层又一层中造成代码嵌套，出了问题经常在两人间扯皮，造成产品不易调试。

        后来，我做了开发经理。我是一个产品的需求+架构设计+主程，我也要求其他人用我的一些基础业务类，有时候也会重现以前的矛盾，只是此时我的角色变了，我对以前那个架构师有了些认同。因为这时我认为我是设计，我的想法是对的，更重要的是我要考虑代码的一致，我要考虑人员流动后我是否能够快速的接手并维护他的代码。

         今天，这个矛盾依然存在，不过我要从更高的角度来看待这个问题。什么是架构设计?到底为谁设计?

         架构是产品的基石这一点毋庸置疑。但是，用户可不管你架构的事，能够准确、高效的满足用户需求就是好产品；对公司来说，这样的产品在开发和维护上花费最少的时间空间成本，就是好队伍。那么，我说架构设计的目的是什么? “ 能够帮助业务实现者用最快的方法实现产品功能并达到用户要求，当需求变化后又能够以相对较小的成本去响应。”

 

1、架构不是用来看的，我们做产品的架构设计不是那种基础理论研究，我们要做的是实践性实效性很强的工作。谁来用这个架构？团队里其他实现产品业务的成员来用，如果这个架构不好用，怎么能做到工作高效？ 再说什么叫好用不好用，客观上讲在一个有限的人群中很难界定。那么只能是大家普遍认为好用，节省了他们开发时间，能够有助于帮助他们完成业务实现的架构就是好用的架构。

 

2、 架构设计虽然是隐藏在产品的后台，具有一定抽象，但这并不代表架构可以不顾产品需求。不用考虑业务需求的万能架构只存在与像MFC/.NET这样的基础库，这个不需要你我来做。我们要做的架构是要服务于业务实现，最终使产品功能满足用户需求。

 

3、即使我们去约定产品生命周期，产品需求还是一定会变化的。必须熟知用户业务，否则很难作出好的架构。道理简单，你考虑了用户8辈子用不到的扩展功能，除了加重产品开发负担，没别的好处；相反如果不能尽可能准确预计未来出现的变化，导致产品僵化，那么除了修改和调试时变复杂，要改的地方一处也省不掉，没有其他架构应有价值。

 

做一下总结：

1、架构设计与业务实现全体人员都要正确认识设计模式。它既不是万金油也不是绣花枕头，对于处在初级水平的我们，要谨慎使用它，事倍功半和事半功倍就在这一瞬间。

 

2、架构设计者必须要掌握产品业务，要有对业务需求敏锐的眼光，要具有前瞻性。

 

3 、架构设计者要站在产品全局考虑问题，要考虑团队整体应用水平，考虑大家的使用感受，从代码角度要加强服务意识而不是只有管理意识。

 

 

诚然，架构设计这个活要做好的话很难，要有技术能创新懂业务善沟通。最重要的是把握平衡，借用阿朱在《软件作坊》中的比喻，他是走钢索的人。