文档介绍：客户需求重于个人简历
Don't Put Your Resume Ahead of
the Requirements
尼廷·博万卡(Nitin Borwankar)

作为工程师,我们常常要向客户推荐技术、手段,甚至方法论来解决问题。但
有时我们心里不是想寻求解决问题的最佳方案,而是希望借此丰富自己的简历。
这样做很可能得不偿失。
积累一批满意的客户,选择切合实际的技术解决他们的难题,让他们乐于推荐
你,才是最好的履历。信誉远胜过时髦的编程技巧和流行的范式。掌握最新的
技术趋势,与时俱进固然重要,但不能让客户为此买单。作为架构师,职业操
守绝不能忘。公司托付重任给你,是期望你恪尽职守,不受利益诱惑。如果你
觉得项目不够尖端,挑战性不足,无法满足职业发展的需要,大可另栖高枝,
另谋高就。
万一你别无选择,必须参与这样的项目,不要为简历所累。忍痛割爱放弃时髦
光鲜的方案确实不容易(哪怕它们并不适合当前的项目),但只有脚踏实地替客
户着想,最后才能皆大欢喜。
2 软件架构师应该知道的 97 件事
选择正确的解决方案可以降低项目的压力,团队工作起来更开心,客户也更满
意。你会有更充裕的时间,既可以钻研现有技术,也可以利用空闲时间学****新
知识,甚至重拾向往已久的业余爱好。家人察觉你的变化后,也会感到欣慰。
把客户的长远需求摆在自己的短期利益之上,才能立于不败之地。
作者简介:
尼廷·博万卡 20 世纪 90 年代初曾先后就职于 Ingres 公司和 Sybase 公司。
他曾参与开发最早的网络数据库应用,那时的开发语言是 SybPerl 和
OraPerl,之后他又投身研究 Enterprise Java。他曾积极参与 New-EDI 项目
——一个基于 IETF 标准的因特网电子数据交换系统。1994 年以来,他一
直作为独立顾问和研究者关注企业数据集成和消息传递的研究。他目前的
兴趣包括研究数据库模式(schemas)用来实现企业应用中的大众分类方
法(folksonomy),以及将社交网络运用于企业应用时的底层数据库问题。
他是数据可移植性(Data Portability)策略小组的成员,负责起草有关用
户数据权利的最终用户许可协议。他撰写了多篇数据库方面的文章,发表
在和他的博客()上。他还拥有一项跨
越可信赖边界传递协同消息的专利。
业界专家集体智慧 3
简化根本复杂性,消除偶发复
杂性
Simplify plexity;
Diminish plexity
尼尔·福特(Neal Ford)

根本复杂性(plexity)指的是问题与生俱来的、无法避免的困难。
比如,协调全国的空中交通就是一个“天生的”复杂问题,必须实时跟踪每架
飞机的位置(包括飞行高度)、航速、航向和目的地,才能预防空中和地面上的
冲突。像天气骤变这样的情况会令航班计划全盘失效,航班时刻表必须适应不
断变化的环境才能避免乘客滞留。
与之相反,偶发复杂性(plexity)是人们解决根本复杂性的过程
中衍生的。目前陈旧的空中交管系统,就是一个偶发复杂性的例子。系统设计
的初衷是管理数以千计的飞机参与的交通活动,即解决根本复杂性,但是解决
方案本身带来了新的问题。事实上,目前正在服役的空中交管系统,其复杂臃
肿已经到了难以改善的地步。在全球多数地区,空中交管系统仍然在使用三十
多年前的技术。
许多软件框架和厂商提供的“解决方案”都表现出偶发复杂性的症状。解决特
定问题的框架很管用,但设计过度的框架增加的复杂性反而超过了它应该缓解
的复杂性。
4 软件架构师应该知道的 97 件事
开发人员痴迷于复杂的问题,好比飞蛾喜欢扑火。谁能拒绝迅速解决复杂问题
带来的快感?但是开发人员应该解决问题,而不是解谜取乐。在大型软件项目
中,关注根本复杂性,消除偶发复杂性,抽丝剥茧制订解决方案,才是真正的
挑战。
该怎么做呢?应该尽量选择源自实际项目的框架,警惕那些象牙塔里的产品;
分析方案中有多少代码直接用来解决业务问题,有多少只是用来实现用户与应
用之间的交互;谨慎使用软件厂商在幕后推动的方案,它们并非一无是处,但
往往包含偶发复杂性;要量体裁衣,为问题制订“合身”的解决方案。
架构师的责任在于解决问题的根本复杂性,同时避免引入偶发复杂性。
作者简介:
尼尔·福特是 ThoughtWorks 公司的软件架构师和文化基因探索者(meme
wrangler)。 ThoughtWorks 是一家全球性的 IT 咨询公司,专注于端到端的
软件开发与交付。除了开发软件,尼尔还编写教材,撰写杂志文章,制作