One more struggle, and I am free
最近有好几个朋友同事问我，一直都在做软件开发，想做软件架构，要如何入门呢？我从一些提问里感觉到，架构有时会被一些人理解为《葵花宝典》、《九阴真经》一类的秘籍，功力不到绝不能碰，功力到了才能专门修行。
可惜这种认知是不对的。架构的工作虽然比开发复杂，但脱胎于开发，它与开发之间并没有绝对的界限。即便只是做开发，也不妨碍你积累架构经验，从架构方面理解和看待问题，而这些，都是未来成为专职“架构师”的必要积累。所以，我现在尝试回答“做软件架构该如何入门”的问题，为各位正在做开发，但未来希望从事架构的同学们提供几点参考意见。
从某种意义上说，人的一生，就是不断突破个体经验的局限，解决未知问题、体验未知生活的过程——否则，我们只需要简单重复劳动，就足以应付了。也正因为如此，要避免在未知局面下的束手无策，借鉴前人/他人的经验，就是非常有效而且高效的做法。今天我要谈的这本书，正与他人的经验有关。
97 Things Every Software Architect Should Know，这是一本很“奇怪”的书，书名很“托大”内容很“平实”的书。我与这本书结缘也很奇特：去年博文视点的编辑徐定翔告诉我，正在翻译一本书，请我帮忙看看译稿，提提建议（后来才知道译者还有阿里B2B的章显洲）。我虽然没做过架构师，但恭敬不如从命，就答应了。
开始，我关注更多的只是文字和专业名词/术语方面，从技术本身的考虑比较少。因为一来自己不是架构师，也没有这方面的经验；二来，这种口气的标题，总觉得有点狂妄。不过，跟着译稿一篇篇看下来，我的看法逐渐改变了：虽然这本书更类似97篇随笔，但到底是经过选择和编辑的，即便“随笔”，也是围绕着“软件架构师”的“随笔”，它们大致勾勒了架构师这个职业的方方面面——职责、权力、问题等等，我之前以为架构师更多地偏向技术方面，也就是负责“规划”整个软件系统的结构，但本书各位作者，都认为架构师应当是甲方和乙方之间的桥梁，一方面，负责准确理解客户的意图，另一方面，拿出规划给技术部门实施。也正因为这种定位，软件架构师虽然大都是从技术人员成长而来，却不能继续埋头在技术（技术架构）的道路上走下去，而需要补充多方面的知识，培养多方面的能力——怎样与客户沟通，怎样选择合适的架构（不能仅仅从技术方面考虑），怎样说服（注意不是命令）技术部门采纳自己的方案。书中不仅点出了这些问题，也给出了一些解决的建议；譬如第85章就告诉读者，说服甲方，仅仅依靠技术的术语是远远不够的，必须把整个技术方案包装成有吸引力的商业模型，这样说服力才会大大增加。如果希望成为称职的软件架构师，此类知识还是尽早了解的好，毕竟，都依靠自己去摸索，在挫折中学习，实在很不划算。
另一方面，架构师也脱离不开技术，所以，技术人员阅读本书，又可以从另一个角度（也可以说是更高的层次）来审视自己的工作及其意义，我的感觉是，一些经验，自己之前只有模糊的认识和体会，但书中的文章它们挑出来，表述得更明确、更到位，于是自己心里也更加有数了。譬如第82章指出“你客户的客户才是真正的客户”，这是非常之对的，而许多技术人员因为自身角色和视角的关系，往往很少意识到这一点：假设你给客户开发了一个电子商务网站，该网站的信誉评价功能不够完善，对此，你的客户可能仅仅认为“这个功能需要改进”，而客户的客户，也就是真正使用这个网站的人，他们的反应很可能是“这个网站买不到真货”，选择离开。有句俗话说：聪明人就是能多为别人着想的那种人。如果能够明确且重视这一条经验，甲乙双方的合作很可能就会融洽得多，技术人员的价值也会随之上升许多。类似这样的经验，书中还有很多，作为技术人员，阅读的时候很可能会感觉“于我心有戚戚焉”，至少，我看到“要经常反思自己做过的项目”时，就是这种感觉。
鱼与熊掌不能兼得，随笔专辑性质的书，照顾了“广”，就难以照顾“深”，因此，在亚马逊网站上，指责的意见都是针对这方面的：lack of detail，random accumulation…。但是我想，书有很多种，定位当然也不一样，应当各司其职——满足了自身定位的书，就是“好书”。这本书也是如此，读者权当这是在旁听架构师的茶话会好了——资历尚浅的听一听，开阔开阔自己的眼界，资历深的听一听，整理整理自己的经验，都能收获愉快的阅读体验；况且，还有平时难得听见的“小道消息”——世界上最先进的F22战斗机，对飞行控制的要求极端严格，应当选择怎样的软件；M1A1艾布拉姆斯主战坦克，开炮的时候会产生极强烈的电磁脉冲干扰计算机工作，这情况下要采用什么数据库……
