[转载]架构师的封装抽象癖好

原文出处 作者：javamonkey

 

文章转载，深有感触，所以收录了，非常的棒，讨论也很深入

 

javamonkey 2010-06-07

跟有的架构师打交道时间长了，发现有的架构师特别爱拿别人的东西封装抽象一下，甚至每个项目的方方面面都言必封装抽象。举个极端例子来说。都知道Java对象都继承于java.lang.Object,有的的架构师，通常写一个MyObject（继承Object）,然后要求开发人员的类都继承此类。 

   封装抽象癖好带来过度设计，从而引发学习难，开发难，调试难，运行慢，以及更难扩展和适应变化。这些癖好原因我可以归纳为架构师的几个如下问题。 
   1 妄图解决扩展性问题。 由于需求不清楚，或者架构师对需求不完全理解，他需要通过抽象或者封装来适应将来的变化。然而，就我个人经验来说，即使不抽象和封装，一定限度的需求变化也能用别的办法来解决，如改代码，使用重构工具。 
   2 妄图解决重用。架构师当然想着自己的产品能用好多年并且也能用到别的项目上去，然后事实常不是这样。为了将来所谓的能重用，带了成本和风险都很大的。我同事曾向他的项目经理诉苦：“这样的重用10后都不一定用不到，现在按照这个方式开发太麻烦了” 

  如果前面俩个还是架构师的好的一面，那下面俩点就是架构师的阴暗面了 
   3 由于自己对所用技术和产品不熟习，因此让人封装成自己理解的模型，或者API。譬如架构师对Portlet规范不熟悉，自己只知道Servlet,因此要求开发人员对Portlet进行封装。再比如，架构师对Flex不熟习，因此要人实现某某Flex框架，妄图让开发着不会 Flex情况下也能开发Flex代码（这可能么！！！）。 
  4 为了显示自己有水平，项目所有的技术都是由他提供的，架构师把所有用的技术都包一个皮，所谓的MyObject,MySpring,MySchedule等等，声称是自己写的。不明就里的开发人员因此对他很崇拜，公司领导也认为此架构师水平了得。这样的架构师我是最痛恨的。因为他已经远离了技术，走向了“政治”，带来的还是学习难，开发难，调式难，运行慢。 
 
   其实任何技术和架构，如果架构师都能把握本质，熟练应用，也不会像这样的架构师言必谈封装和抽象。就像倚天屠龙记里 张三丰问张无忌还记得刚才学的招式么，张无忌说我不记得了。 

javamonkey 2010-06-09

想起一个同事设计的框架，打算采用分层设计，直接能做的事情绕了好几个弯子，后来我看懂他的设计就乐了原来 A--> B 就齐活的的事情，变成了A->C->D->A=>B。

凤舞凰扬 2010-06-10

     呵呵，形容得好。不过javamonkey 碰到的一个关键问题是，架构师闭门造车，然后在造出来后要求所有人跟从，却不予解释。
     这种事情的出现不仅仅在架构师身上，在很多设计师，高级程序员上都会出现。
     优秀的架构师应该是设计解决方案。其实不管架构师做出来什么东西，封装也好不封装也好，他必须解答6个W：
为什么要这么做（Why）：架构师要解释这样做的目的和相关的背景条件。
做出来的东西包含了什么（What）：方案中包括些什么东西，解决了什么问题？
谁会从中获得好处（Who）： 架构选择这种做法，谁能得到益处？开发人员、客户还是公司？
设计的思路是怎么样的（How）：整个设计的思路及过程是怎样的。
是否还有更好的选择或者做法（Whether）：是否有比现在更好的解决方案？是不是做过其他方案的分析比较？
它的设计时效是什么（When）：它是一个长期解决方案还是临时的？

     如果一个架构师在设计完，并能向自己的同事很好地解释和回答以上问题，我相信封装也好，简单使用也好，都会得到尊重和认可的，各位同意么？

sys53 2010-06-12

从你说描述的4点来看，没有一个是符合架构师的标准？ 

也就是你说的人的本就是“伪架构师” 

1,好的架构师都是聚合优先继承，不是动不动就继承; 
2,尽可能的开闭原则还是合理的，好的架构师会综合考虑现实成本，需要权衡，推敲；同步讲究不断重构； 
3,连需要用到的技术都不知道，如果架构，纯属扯蛋; 
4,喜欢用My或者自己名字命名类的，特别是抽象公共组件的；很可能是刚入门，或者是做测试代码。一般来说（不是绝对），达到架构师的人，所定义的抽象类应该见名如见义(对象，模块，组件的责职)，所定义的名称也是抽象的; 

根据你的四点，一一对比，证明，你说的不是架构师，或者只是冠以“架构师”之名而已.

faye.feelcool 2010-09-06

   架构师，个人认为首先应该是开放的，如果这点做不到。起码不算真正的架构师。因为架构师首先是一个工程师，而不是科学家。工程师，是做什么的？将知识用于实践工作的人，而不是去执迷于发明一些新的理论。
   架构师，为什么要架构师？ ->成本！如果没有时间开发维护的压力，有那么迫切要个架构师吗？！我们可以花个几百年去得到一个金品系统。
   所以衡量一个好的架构师的标准，就是你用多少现成的东西（低成本），去帮助团队更快更好的完成项目。
   封装一般的情况，只会出现在扩展的地方，比如系统要支持多种通讯方式，而公司由于成本考虑不会去选购一些现成的组件，这是为了应变可能需要封装。
   封装和抽象是高级开发人员的基本功，架构师何苦要凑那个热闹呢，职责不在那呀，你要考虑的是低成本高产出！快交付、好质量。