关于架构师和架构设计的一些常见误解（转） -

russelltao

浏览: 157674 次
性别:
来自: 杭州

最近访客更多访客>>

morelily

Coolieo

三九马如龙

siemens800

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

关于架构师和架构设计的一些常见误解（转）

相当不错的文章，值得一看！ 前几天看到一篇架构师已死的文章，颇为有趣，仔细想想，架构师之所以兴盛和之所以必死，多半是因为太多的人对软件架构师的工作存在诸多误解的缘故。而诸多媒体和原厂商出于自身利益在国内行业进行的过度吹捧，给予了架构和软件架构师太多的光芒，程序员们自然而让的就把个人的职业规划扔到了聚焦点上。 写一些自己对架构设计和架构师的一些不是很成熟的看法，写到哪算那，全当口水了。 
架构的概念非常广泛，解决的问题域空间也各有差距，不能从一而论，此处单指企业应用的范围而已，和互联网应用等其他范畴有较大差距。 1. 架构是设计出来。 这是很多人对软件架构的一个最大误解。 传统的瀑布模型里，人为的划分设计和编码实现过程，也划出了设计和验证过程的鸿沟，整体设计（概要设计）的可验证性，要在项目的中后期才能得到体现，这时候为时已晚。而为了保证设计的质量，回避中后期风险，又往往会强调加强设计粒度和评审粒度，这样一来，无形中又继续加大了设计和验证的鸿沟，拖长了问题反馈周期，规模越大的项目，问题越为突出。 据我的印象，业界中最早的最有影响的关于架构和架构师的界定其实来源于RUP.有别于传统的瀑布模型的中的概要设计，软件架构很难再说是按流水线方式设计出来。架构设计和概要设计的最大差别在于架构设计更看重反馈和验证过程，更看重架构师在整个软件开发过程中的由始而终的参与。在rup中，项目早期的关键迭代都和架构设计有直接关系。 架构设计应该强调通过更好的反馈-沟通-验证机制，能在项目的较早期就得到技术和业务上的验证，为整个项目打下稳定的基础。在某些敏捷开发过程中，架构设计并不会作为一个显著的KPI提出，更多是作为一种隐喻。通过使用迭代和其他更好的反馈交流机制，让项目的架构设计在在项目的前期以验证和演进的方式完成。可以说一个真正的架构设计，必须是可以有效验证的。 而现在很多公司和组织流行的先让大拿组织做设计，设计做完再评审，然后丢给小兵去干活的架构设计流程，实际是对瀑布模型的继续，我个人认为是完全背道而驰的。我多次参加过这样的架构设计评审，基本上可以说没有什么有真正营养的东西，只是一些流行概念的堆砌，昨天EJB,今天SSH，明天又是 OSGI，这样的架构设计作出来也有可能会大幅度修改，或者坚决不修改让下面的人痛苦不堪，所谓的评审和存档过程只是自欺欺人而已。再考虑现在各大公司流行的CMM/CMMI，过程改进管理，这些paper的工作还可能会因为引入复杂的审批修改流程把人拖入泥潭。 这种做法，在java圈子里面，因为早期sun和一些大公司对架构和模式概念的极力鼓吹，大为盛行。某些人甚至只是看完了blueprint，做了几个tutorial，就摇身一变架构师，开始了架构设计生涯。 这样的架构师也往往很少编写代码（我们可以理解，一个人写完300页的设计文档以后，还有多少意愿再去写实现代码？），很少参与项目的开发工作，只满足做一些试验性质的代码工作（对呀，现在开源东西这么多，流行的东西组装一下架构设计就算over了么，还实现什么设计）和指导工作，甚至有些 paper的架构师，完全就是靠粗读各种pattern和x宝典来做设计，设计的可行性和高风险性，可想而知，早期大量EJB的滥用导致的项目失败，其实根本原因在于甚少有架构师以验证演进的手段来决定是否应该使用EJB，怎样合理的使用EJB，将架构设计草率的外包给各大原厂商鼓吹的概念或者各种 blueprint。而小兵们在面对架构+模式两顶大帽的时候也只会怯懦的怀疑自己的个人能力，然后坚持不懈的向架构师这一伟大位置继续奋斗。 而另一方面项目管理者也往往会误以为有了正规的架构设计就可以更好的保证软件项目质量，可以将项目的重心放置在需求和非技术工作之外，可以不用再考虑一般程序员的技术能力问题，可以大幅度的xxx，xxx，最后一堆苦水，然后再把责任归咎于架构师不成熟。 我早年经历过的几个项目就有此方面沉痛的教训，事后我个人复审设计，发现基本上整个方向都是错误的，个别项目设计者甚至连EJB的一些基本概念都没有了解，自己重头实现了一遍。过长的验证周期导致后期已经无法再做任何修改，只能咬牙吞下。 真正实用的架构是以逐步严谨的方式验证出来的，即便是自称中国java NO.1的袁红岗告诉你EJB非常好，没有EJB的架构就不是真正的J2EE架构，你也要验证以后再说，在此顺便bs一下csdn。 在那篇架构师之死的小品里，boss问小兵，你如何说服大家要使用hibernate？其实答案很简单，架构又不是设计出来的，为什么要说服？ 2. 架构师是一个纯粹的技术工作 某方面讲这是对的，但又不全对，因为技术工作只是架构师工作做的一个核心关注点而已。一个ｎｂ程序员可能在技术方面是ｎｂ的，但是在很多方面确实欠缺的，并不适合做架构师。 做企业应用的，牵涉的面太广，加上行业生存环境又不是很好，企业管理普遍也不规范，所以很难象某些领域，架构师就是一个纯粹的技术工作。 首先，如何获取项目经理和管理层对你的信任和支持，是你开始工作的起点，这一块和技术并没有直接的关系，取决于你的表达能力和主动性，你如何展现你的实力，你做事是否足够主动，是否有意识和能力去推动项目。不能让老板感觉你就是一个greek，这一条是很多不错的技术人员难以做到的。而实际工作中，你也绝不能把所有时间都花在技术上，你至少要拿出4分之一的时间去和pm，和老板沟通，协商问题，才能得到你的生存空间。 其次，如何获得团队成员对你的信任和支持，是你展开工作的基础，如果你不够传奇，就需要你做一个牧师或者善于聆听的人，通过熟悉自己的团队成员的构成和技术特点，才能充分发挥他们的所长，赢得他们的信任和支持，看起来这好像是pm的工作，但是不尽然，如1所诉，架构设计并非是一个个体脱离团队的行为。和团队成员打交道，多半又要花掉你4分之一以上的时间。 好吧，你还要明白，为啥要叫架构师而不是高级工程师（这个已经out了），是因为你还需要承担售前售后任务，如何简单清晰的向不懂技术或者半懂技术的客户讲清楚技术问题，这是个学问，要做到这点，按我以前的老板说法，你必须有常识，常识要多道可以用一些简单的故事例子把东西讲出来，所以有空要多看看电视，多和销售学学，顺便还得学点基本礼仪，上次我差点把某公司来给我们推销产品的工程师给踢出去了，在我提了意见以后，丫居然坚持跟我说他们东西是最好用的，你敬业没错，但是好歹我才是用户吧。 如果你的公司是做项目为主的，恭喜你，你还要学会如何和客户周旋，如何回避到客户内部以及客户和其他供应商之间的矛盾里去。因为某方面，作为架构师，你就代表了技术上的权威，你要明白一点，管理上出了问题，从来都是往技术上推是最简单的。项目之外的话，说起来一定要谨慎，再谨慎。比如如果有客户不愿意购买设备和软件实现负载均衡，找你咨询，你随口一说，啥啥免费软件可以做，好吧，你完蛋了，你要么就是得罪了某供应商（搞不好还就是你们公司卖的），要么，就是等着将来客户给你套口子吧。 而且，作为一个企业应用的架构师，你不可避免的要和各类厂商打交道，这里面也是大堆的学问，虚虚实实的东西大把，偶尔你甚至会受到美色或者银弹的攻击（记住，只是偶尔，人家一般不乐意在你这个级别上下血本）你要一不小心分不出真假，很可能就做了大堆钱公司的小白鼠，搞的在客户和公司间里外不是人。 还有，架构设计往往还需要考虑到技术的生命周期问题，那么你对客户公司，对开发公司的状况的了解，对整个行业的发展趋势的了解，也会影响到你设计的决策，这种东西往往跟市场有关，并不取决于技术，这考核的就是你的视野和对问题的敏感程度。打个比方，你开发了一个很好的系统，但是到了你离职的时候，客户却发现你选择的这种技术已经淘汰了，现在很难再找到合适的人员进行维护了，这样的架构师，算合格么？ 说完了外面的东西，再说里面的。 一个成熟的企业应用的架构师，除了对行业技术应用有准确的把握和经验积累之外至少还需要有丰富的业务知识。 一般来说，架构设计由几个面构成，其中一个面是技术架构，还有一个面是业务架构，技术架构必须通过后者的验证。积累一个行业的业务知识，少则一年半载，多则3年5年，这都不是单纯看书阅读资料可以获得的。客户可不会只因为你的技术如何先进，nb 就验收项目的。 再有，再好的架构，也需要向程序员沟通和推广，那么你至少也要是个合格的技术讲师吧？兄弟们管你叫那个师，你总还得有能力教人家一点东西吧？ 某些项目，技术甚至可能根本就不是关注点，我曾经参与的一个项目，在我加人的时候架构设计和开发工作都已经完成，而且是基本构建在相对错误的道路上，基于项目进度的压力，我已经没有可能重新推到再来，所以我把工作的重心转移到如何培养提高团队成员的技术能力，降低不成熟架构对他们工作的干扰，换句话说，我干的工作就是打补丁。这些看实不够nb的工作大部分都和技术无关，和流程图，模式无关，但是有效的弥补了架构的缺陷，保证了项目的顺利进行。 既然不能选择离开，那么菜刀也是刀，对吧。 最最后，你还要有点人脉，有在天涯海角到处混的兄弟，这样你搞不定问题的时候，卡住的时候，或者他们一个小小的提示就可以救你于水火之中。不会不是你的错，解决不了问题才是你的错。 在我看来架构师的工作，是一个混合了各种知识和经验的工作，架构师更象酒店里的行政大厨，只会炒菜那是绝对不行的，很难单纯的定义为技术工作。当然，动不动就把架构师抬举为艺术家，开口闭口XX的艺术，哪还是过了，你以为画画的都是艺术家么？我家狗仔还能用嘘嘘画地图来着。 指望多读书，多写代码，一个人对着电脑就能迅速成长为架构师，嗯，我觉得可能性不是很大。 3. 架构设计的好坏只取决于架构师的能力，和开发团队无关 经常会听到这样的抱怨，我做出的架构设计，下面的人能力不够，无法实现。这个架构是XX推荐的，为啥做下来问题会这么多？我们的架构师只会说，其实水平不行，做出来的东西很难用等等。 其实认同我说的1的人应该已经明白，架构既然是渐进验证的，那么架构的可行性就是一个必须考虑的问题。架构师需要熟悉自己的团队成员的构成和技术特点，在此基础上对设计做权衡，再好再优秀的架构也要取决于团队成员的理解能力和执行能力，这点对很多人来说居然完全不理解。 和现在的各路有志青年一样，我也曾经努力奋斗要做一个架构师，我在01年参加了sun的架构师认证考试。那时候的SCEA考试并没有什么参考资料和贩卖答案。各路精英只能在一个国外论坛上泡着交流经验，经常看到某某高分过了的消息，又看到某某平常表现不错，又差了多少分没过云云。 我看了很多书，也颇有些项目经验，通过成绩却一般，80分左右，所以很想知道别人的设计是如何做的，什么样的设计可以得到更高的分。经过协商，我和一个挪威人，一个德国人（有20年的开发经验）交换了通过考试的作业。让我震惊的是德国人设计的粒度，他的架构设计几乎想日本人做的详细设计一样，只要简单的翻译工作就已经可以run，即便是对德国人的严谨细致早有所闻，我还是难以想象这是一个小项目的架构设计。和德国人做了交流，他说他必须做得这么细，否则他的团队成员理解会产生偏差， face to face的交流也不能弥补这个问题，因为他的小伙子不是都足够聪明。 这让我第一次意识到，架构师的工作的一个中心，并不是直接面对客户，面对老板而是面对技术团队成员。其后的工作中我又多次碰到类似的问题，同样的需求，一个架构师面对不同的团队成员的时候，很可能作出截然相反的设计。架构师必须针对团队成员的特点，认真考虑团队成员的技术能力和学习能力，有针对性的选择和平衡，甚至是牺牲，才能保证架构的可行性。 在一个理想的技术团队，架构师固然可以只关心技术，但是这样的团队现实中存在的概率有多少？就如death to march 2nd中所说，现实的软件开发团队，大部分都要面对一个资源短缺问题， 不能说服老板给你足够的资源，那么只能选择充分使用现有的资源，菜刀也是刀，对不对。 我不知道有多少项目架构师脱离开发团队能获得真正的成功，一般来说，强调架构设计的项目都是中等以上规模的项目，人数一般都会超过10个以上，对项目管理，对技术人员有着更高的要求。不少公司都乐意高薪聘请外援进行架构设计来解决问题，但是结果都不理想，原因即如此。 我非正式的咨询过2个项目，架构设计都由大堆钱的工程师完成，pm哭丧着脸跟我抱怨，我们的架构没问题，都是大堆钱做的, 国外啥啥都这么用，但是我们的程序员不行，无法很好的将架构实现。 姑且不谈大堆钱为了推销自己的产品加塞的东西，单就这种丝毫不考虑团队成员构成，千人一面的拷贝设计，都已经注定成功只能是偶然了。这样的架构，又如何说没问题？一个架构师最低限度的责任，既是将这种大众face裁剪调整到适合自己团队的面孔，交钥匙的做法是没戏的。我只能很无奈的告诉他们，这样复杂的过度设计，如果不做裁剪，即便我给你找到合适的程序员，你也无法承担时间上的成本，何况性能始终都会是个大问题。 不少中小公司的同胞们敬仰着大堆钱公司，指望他们能解决根本的问题，殊不知，某种意义上，架构设计的工作，是没法外包的，你可以咨询，可以顾问，但是干活是另外一回事。这点和互联网应用什么的，还是挺大差别的。