最近有好几个朋友同事问我,一直都在做软件开发,想做软件架构,要如何入门呢?我从一些提问里感觉到,架构有时会被一些人理解为《葵花宝典》、《九阴真经》一类的秘籍,功力不到绝不能碰,功力到了才能专门修行。

可惜这种认知是不对的。架构的工作虽然比开发复杂,但脱胎于开发,它与开发之间并没有绝对的界限。即便只是做开发,也不妨碍你积累架构经验,从架构方面理解和看待问题,而这些,都是未来成为专职“架构师”的必要积累。所以,我现在尝试回答“做软件架构该如何入门”的问题,为各位正在做开发,但未来希望从事架构的同学们提供几点参考意见。

(more…)

从某种意义上说,人的一生,就是不断突破个体经验的局限,解决未知问题、体验未知生活的过程——否则,我们只需要简单重复劳动,就足以应付了。也正因为如此,要避免在未知局面下的束手无策,借鉴前人/他人的经验,就是非常有效而且高效的做法。今天我要谈的这本书,正与他人的经验有关。

97 Things Every Software Architect Should Know,这是一本很“奇怪”的书,书名很“托大”内容很“平实”的书。我与这本书结缘也很奇特:去年博文视点的编辑徐定翔告诉我,正在翻译一本书,请我帮忙看看译稿,提提建议(后来才知道译者还有阿里B2B的章显洲)。我虽然没做过架构师,但恭敬不如从命,就答应了。

开始,我关注更多的只是文字和专业名词/术语方面,从技术本身的考虑比较少。因为一来自己不是架构师,也没有这方面的经验;二来,这种口气的标题,总觉得有点狂妄。不过,跟着译稿一篇篇看下来,我的看法逐渐改变了:虽然这本书更类似97篇随笔,但到底是经过选择和编辑的,即便“随笔”,也是围绕着“软件架构师”的“随笔”,它们大致勾勒了架构师这个职业的方方面面——职责、权力、问题等等,我之前以为架构师更多地偏向技术方面,也就是负责“规划”整个软件系统的结构,但本书各位作者,都认为架构师应当是甲方和乙方之间的桥梁,一方面,负责准确理解客户的意图,另一方面,拿出规划给技术部门实施。也正因为这种定位,软件架构师虽然大都是从技术人员成长而来,却不能继续埋头在技术(技术架构)的道路上走下去,而需要补充多方面的知识,培养多方面的能力——怎样与客户沟通,怎样选择合适的架构(不能仅仅从技术方面考虑),怎样说服(注意不是命令)技术部门采纳自己的方案。书中不仅点出了这些问题,也给出了一些解决的建议;譬如第85章就告诉读者,说服甲方,仅仅依靠技术的术语是远远不够的,必须把整个技术方案包装成有吸引力的商业模型,这样说服力才会大大增加。如果希望成为称职的软件架构师,此类知识还是尽早了解的好,毕竟,都依靠自己去摸索,在挫折中学习,实在很不划算。
另一方面,架构师也脱离不开技术,所以,技术人员阅读本书,又可以从另一个角度(也可以说是更高的层次)来审视自己的工作及其意义,我的感觉是,一些经验,自己之前只有模糊的认识和体会,但书中的文章它们挑出来,表述得更明确、更到位,于是自己心里也更加有数了。譬如第82章指出“你客户的客户才是真正的客户”,这是非常之对的,而许多技术人员因为自身角色和视角的关系,往往很少意识到这一点:假设你给客户开发了一个电子商务网站,该网站的信誉评价功能不够完善,对此,你的客户可能仅仅认为“这个功能需要改进”,而客户的客户,也就是真正使用这个网站的人,他们的反应很可能是“这个网站买不到真货”,选择离开。有句俗话说:聪明人就是能多为别人着想的那种人。如果能够明确且重视这一条经验,甲乙双方的合作很可能就会融洽得多,技术人员的价值也会随之上升许多。类似这样的经验,书中还有很多,作为技术人员,阅读的时候很可能会感觉“于我心有戚戚焉”,至少,我看到“要经常反思自己做过的项目”时,就是这种感觉。

鱼与熊掌不能兼得,随笔专辑性质的书,照顾了“广”,就难以照顾“深”,因此,在亚马逊网站上,指责的意见都是针对这方面的:lack of detail,random accumulation…。但是我想,书有很多种,定位当然也不一样,应当各司其职——满足了自身定位的书,就是“好书”。这本书也是如此,读者权当这是在旁听架构师的茶话会好了——资历尚浅的听一听,开阔开阔自己的眼界,资历深的听一听,整理整理自己的经验,都能收获愉快的阅读体验;况且,还有平时难得听见的“小道消息”——世界上最先进的F22战斗机,对飞行控制的要求极端严格,应当选择怎样的软件;M1A1艾布拉姆斯主战坦克,开炮的时候会产生极强烈的电磁脉冲干扰计算机工作,这情况下要采用什么数据库……