昨天，久（shi）违（san）多年的华中科技大学出版社徐定翔兄，以近乎于地下党接头的曲折方式联系上我。徐兄送来了好消息：“《恰如其分的软件架构》这两年又销售了近1000册，可以给大家申请1000册稿酬。”稿酬自然不多，但没想到这本译作过了如许几年，销量还能缓慢增长，令我惊喜。
消息中提及的大家，乃《恰如其分的软件架构》翻译三人组，即审校高翌翔，翻译倪健和我。我认识翌翔是通过InfoQ，当时我们同为InfoQ的兼职编辑，在北京有几次谋面。翌翔对技术的热爱令我印象颇深。倪健兄则属于神交，从未谋面。我是在拜读他的大作《简单之美》后，深感一个IT人能把文字写得如此动人，从而滋生“拉他下水”的想法。记得倪健兄定居上海，被我拉下水后，快手译书，倚马可待，终于使得本书的译作能够如期面试。遗憾的是，后来随着我工作变动、工作地点变动，翻译三人组慢慢失去了联系。回想起来，还是令我唏嘘不已。
翻译Just Enough Software Architecture时，我在Thoughtworks就职，relocation在北京，居住在靠近东直门的蜗居内。每日公司宿舍两点一线，过着简朴而又纯粹的生活。过去的回忆一下子又在脑海中鲜活呈现。这篇博客是我写于2013年的旧文，真实记录了当初译稿交付后的点滴感受，叙述了当初翻译的艰难历程。如今发布出来，颇有些“忆往昔峥嵘岁月”的感觉。——是为记。
华中科技大学出版社的徐定翔问我意见，了解我对Just Enough Software Architecture这本书的观感，看是否值得引进。时间是在2010年。从一开始，我就被书名中的Just Enough理念所吸引。它让我想起宋玉的东家姑娘，“增之一分则太长，减之一分则太短”那种不可言说的美丽。我在心里说，架构设计就需要这样。我当时并没有看到本书，只是到Amazon上找到了几篇英文原版样章。犹记得我在读到第一章介绍的RackSpace案例时那种兴奋之情。于是，我迫切地向徐定翔强烈推荐引进这本书，而我则毛遂自荐，希望能作为本书的译者。之后，我在InfoQ上看到对本书的《访谈和书摘》，进一步加强了我翻译本书的信念。于是，出版社开始与作者Fairbanks联系，然而从此音讯如石沉大海。时针指向2011年，我对于本书是否被引进，是否由我翻译，一切未知。我觉得我可能错过了它，思之仍觉怅然。谁知到了九月，消息突然确定，而徐大编辑就不容分说地直接把原书给我寄来了。
拿到沉甸甸的书，第一面就为本书的装帧而惊喜。心里想，我这一辈子若能写出这样一本书，绝对值得生命走过的这一遭了。我并没有迫不及待地开始翻译，这就好似遇到珍馐美味，需得先赏其色，闻其香，然后再品其味。我每天抱着这本书饶有兴味地开始阅读之旅。阅读之旅确乎如行山阴道，沿途之美，目不暇接；可一想到翻译，这种美景就成了一种折磨，因为我害怕辜负这一美景。翻译之初我就举步维艰，那些词语放在那里，我却无法解开“封印”将它们取出来，即使取出来，却又找不到存放的合适位置。一些翻译隐隐约约浮现着，当我竭力去揭开这些词语的真面目时，无论如何用力，总也不能够着。翻译就好像那些年我们一起追过的女孩——追不到，痛苦；追到了，销魂。翻译进度像蜗牛一样的爬着，我终于决定求助了。辗转寻找了好多朋友，都以各种理由拒绝或者放弃了。翻译讲解软件架构的书，确乎不是一件轻松的事儿。那个时候，我的Buddy肖鹏正从翻译《面向模式的软件架构》第五卷的泥潭中爬了出来。每一提及他的这段翻译经历，脸上就会浮现出不堪回首的表情，如看了恐怖片。终于，事情得到转机，最开始是倪健的雪中送炭，再有高翌翔的锦上添花，随着我们这个三人组的建立，翻译才算开始走向正规，我才有了交稿的信心。
自从开始翻译这本书后，我与人谈架构，动辄就会提及“Just Enough，恰如其分”。我像祥林嫂一般地推介着Fairbanks提出的风险驱动模型，并认真地实践着这一模型。我开始对演进的架构有了更深入的理解。我写了《设计恰如其分的架构》这篇博客来详细阐述我对演进式架构的理解。在2011年我参加的技术会议上，我也反复讲解了如何遵循简单之美的原则，运用风险驱动模型设计恰如其分的架构。2012年，在我参加的一个项目中需要针对遗留系统进行技术栈迁移。我撰写了文章《遗留系统的技术栈迁移》，提到了“风险驱动模型”，并在2013年的Scrum Gathering会议上分享了我的一些想法。当然，这个模型并不是锤子，更不是银弹。它更近似于质量属性驱动的架构设计，我们要满足的质量属性，可能就是我们在做架构时需要面对的风险；而在Roy Fielding的那篇关于REST的著名论文中，也提到了对约束的识别，并演示了如何从一个空约束，通过逐步添加约束演化为REST风格的架构。从某种程度上，架构的约束可能是一种风险，也可能成为设计的驱动力。
前几天，我参加Agile China 2013，与我新认识的一位朋友范钢聊到了关于架构重构的问题。事实上，面向对象软件开发到现在，已有十余年之久；各种经验、模式与原则甚嚣尘上并得到较好的推广。然而新的方法、新的语言乃至新的思想仍然层出不穷，尤其是在互联网开发、大数据处理以及移动开发的冲击下，传统软件开发似乎已经开始走向末路。“只见新人笑，不见旧人哭”！？？是，也不是。实际上，在传统的企业开发领域，各种大型系统仍然像一艘庞大如巨型海兽一般的船舰在海面缓缓行驶，它或许就是沉没之前的泰坦尼克，一切还都安然无恙，你甚至可以听到船头甲板传来的悠扬的小提琴声；然而，冰川就在远处出没，船长还未察觉。我们该怎么办？这样的巨型船舰，自然不可能如艨艟快艇那般的敏捷，即使是360度的转身，也可以玩得如此漂亮、优雅。这些大型的企业级软件系统已经走过了漫长的历程，它们如此巨大以至于我们只能看到它的一角，它们的零部件如此复杂以至于没有人能够彻底弄懂。我们必须认识到，这些系统是最有权力的系统，它们很有可能掌握了人类生活的根本命脉——金融管理、股市交易、生命健康、医疗管理、机械制造、国防安全、航空、航天……它们就像政治界、金融界的那些巨头，要是患了病咳嗽两声，也许世界都要抖一抖。它们可以轻易改变吗？不能！然而若是不寻求改变，这些系统会宿命地走向衰亡。若我们无法承受重写的成本，唯一的办法或许就是架构的重构。我们必须清晰地认识到这一点。而我认为，风险驱动模型恰恰可以作为架构重构的指导原则。在进行重构之前，我们需要充分评估重构的价值，回答“为什么我们需要重构”的问题；然后去识别风险。在开始重构之前，我们需要尽可能做到万无一失。风险自然是不可避免的，但如果我们能事先识别出这些风险，就能有的放矢地选择正确的技术。风险驱动模型的第三步，则是评估风险是否得到有效缓解。不要轻视这一步！重构往往意味着还债。可是，我们该用什么来说服管理者们付出成本去做一些看似没有产生直接利益的任务呢？答案就是用数据来说话，通过比较重构前后的系统健康指标，可以加重说服老板的砝码。当然，毫无疑问，这个过程一定是迭代的。
我想，通过这次交谈，我进一步找到了“风险驱动模型”适用的场景。而这正是我翻译并推荐本书的根本意义。
本书可以在当当网购买。