一位苦乐自知的软件架构师的自白：让软件真正地“灵活可塑”

软件行业，苦乐自知

今年是我从事软件开发的第17个年头。从非科班出生的业余计算机爱好者，到成为走过无数弯路的老码农，或者偶尔也被人称为架构师。回顾我成为架构师的道路，可能要追溯到最初的工作阶段，干过码农、做过美工、当过项目经理，这些经历让我幸运地在实践中体会了从酝酿诞生到后期维护的整个阶段，然而当时苦于没有经过系统的训练和学习，对整个软件工程和架构的认知是懵懂的。十余年前，我参加并通过了系统分析员的考试（当年软件架构师认证还没有从系统分析师中分离出来），然后又陆续作为“架构师”被某些大公司聘用（然而自认其实还不够格），逐渐地，在一些大型项目的历练和个人业余作品的开发种，才弥补了我技术上的短板。

回首十余年软件从业的道路，从开发到项目经理再到部门管理，然后回归开发，到最后成为架构师，期间的坎坷真实苦乐自知。而让我能在这个行业一直坚持下来，并且不断适应这个行业变化的，我认为最大的收获来自于同事和前辈的指导，其次就是不断的自我反省和教训总结。因为走弯路好比交学费，工作就是不断地在错误中前行，必须时刻警惕不要让自己犯下相同的错误—如果一次次掉到同样的坑里，是很难在这个行业的研发岗位上坚持下来的。

为此，我愿意分享我的经验和教训，或许有缘者能从中体会一二。

如何做好一个架构师

1. 关注用户行为动机和利益

软件工程的源头，在于用户需求，而用户需求恰恰是软件项目中最难的，也是很容易被大家忽视的点。架构师必需从源头来引导软件开发这条河流，不要让它流到沟里去。

让我首次明白业务分析的重要性，是在我工作不久的时候。当时，我负责某省厅档案系统的项目开发，第一次作为主力程序员，在走访了几个业务员后，很快便开发出了第一个版本，当时内心还是挺得意的。

开发完成后我便去给用户报告，刚见到用户，还没来得及把软件打开给对方看，用户表示上次谈的需求只是一点点，复杂的问题还没和我说呢，然后张嘴说出一大堆业务名词和术语，把我说得云里雾里，感觉好像完成的软件功能不到实际业务需求的三分之一。如此往复、修改下来，才粗略了解到用户业务的概况。这才发现实际要开发一款被用户接受的软件，并不如预期得那么容易。

然后真正的磨炼还在后面。当我终于第一次将自认为完整的功能上线拿给用户试用，得到的是“几乎没办法使用”的评价。用户一改过去积极配合的态度，产生了诸多抱怨。比如，多余的输入框，要求输入框有记忆功能（就是后来的“自动完成”功能，也就是希望将Excel表格的操作方式搬到软件上来，当时的Web开发技术几乎不能支持）等等，很多需求以当时的技术能力很难实现。

这简直没法干了，我几乎要放弃了，这个问题最终被上级领导反映给了负责建设这套系统的厅办公室主任（多年以后，我终于知道，他是“客户”而不是“用户”）。在主任安排下，次日我坐在用户办公室观察他的日常工作。原来用户上午要处理的文书案卷有一百多件，我们的档案系统不但需要用户逐个浏览所有待填写字段，还要求用户将档案扫描后录入系统（主任要求的），用户的工作量不但没有降低，反而大为增加！

这里有两个问题。第一、由于数量原因，录入效率要求非常高，但在设计开发中没有得到重视。第二、系统上线后反而加重工作负担，用户有了抗拒心理。但业务的框架是主任定的，这是用户“不愿意”说出口的原因。

很多时候用户诉求犹如冰山，访谈和书面的需求说明上能获得的只有冰山浮在水面上的部分，大量的潜在诉求隐藏在水面之下，不深入学习用户业务细节是无法真正掌握用户诉求。在分析用户需求时，需要关注用户的动机和出发点，而这往往是用户利益息息相关的，我们需要分析清楚这种动机和利益关系。

在知道了原因后问题就好办了，主任很快就根据系统上线后的工作负载情况，从另一个工作量大幅减少的岗位上安排人员来负责文档录入，同时我们也对软件交互进行了大幅改进。最后系统再次上线后，整个软件的实施就变得非常顺利了。

多年后，我终于知道分析业务全貌的工作叫“业务建模”，如果说反映冰山浮在水面上的部分是需求，那么“业务建模”就勾勒出整个冰山的全貌。构造业务模型是架构师的基本功之一，一个好的架构师一定会做“涉众利益分析”，将产品设计得符合用户真正的需要。

很多朋友可能认为，用户需求主要来自用户（代表）的口述或者访谈意见，其实这是个误解。在另一个省厅做无纸化办公的项目时，为了得到这些“隐含”的业务信息，在征得同意后，采取了以下方法：

观察关键岗位，记录操作人员的日常行为。

查阅了两年内所有文书档案材料（绝密除外）。在文书材料的手迹当中，我们看到了很多不在“明面上”的东西。比如过程中的周期性工作（例如一年才发生一次），这种用户在反馈中遗漏的事项。进一步地，我们还看到了矛盾、争论、政治因素等这些用户不会说出口的部分。

分析这些业务数据，并勾勒出了业务的全貌后，我发现来自于直接收集的“明面”需求-包括用户访谈和需求描述材料中的业务信息不到20%，大约80%以上的业务需求来自于各种观察和材料检索分析。这是一个稍稍令人吃惊的比例，但足以说明业务建模工作的重要。

2. 让软件真正地“灵活可塑”

上一节我们讲了业务建模，将业务模型化，不仅可以把需求做深入，更重要的是业务模型可以引导我们做出好的软件设计。

做产品也好，做项目也好，研发人员厌恶的事情会有很多—比如赶进度、调错、维护别人的代码等等。但是，最为深恶痛绝的事情，无疑就是变更需求。只有符合用户业务模型的设计，才能在频繁的需求变更下保持稳定。

就如上面提到的无纸化办公项目中，一样碰到了需求的复杂变化，以及用户的业务多变。

最终，我们丢掉了数百页的需求和流程描述；放弃了之前开发好的所有功能（这些功能曾被反复诟病不够灵活）；放弃了过去那种按局长、处长、科长等分别设置角色进行授权的权限模型—这些头衔仅仅只是人员的属性。人员的权限实际上是受任务决定的，这才是真实的业务模型（若干年后，才知道那叫TBAC权限模型，也就是基于任务的权限模型，早已作为理论被国外软件科学家提出）。

而基于不变的用户责任模型，我们抽象出了基本的职责行为模型，然后将可变的业务归纳到了一个配置层中。也就是说，不是直接去实现业务功能，也不假定用户具有什么职务就能干什么，而是将复杂的业务功能拆解成几个基本行为。然后用配置层将这些行为组合起来供用户使用，就像搭积木一样。

这样开发出来的软件，做到了原先根本不敢想象的事情—用户上午找我谈心的业务流程和想法，下午两点上班后，立刻就在系统中能够使用这个功能。这种敏捷和响应能力，堪比“飞机在飞行中更换发动机”，这让用户非常满意。

更为难得的是，数年后，包括我在内的几名开发骨干陆续离开了那家软件公司，这家软件公司也不复存在了。然而，这套没有人维护的系统一直被用户保留了下来，至今已连续工作了近15年，期间没有经过大的升级和开发。现在依然每天有数百人在操作和使用，累计运行数据也有了几十TB。

软件没有针对用户的“具体需求”来设计，而是通过抽象的模型来设计开发。能够十几年无需升级而满足各种业务变化，无疑是那套抽象了所有业务模型的配置层带来的。

然而并不是所有的项目和产品都能像这个项目一样完美收官。在项目过程中，我们还认识到要实现业务灵活性的重大代价。因此，不要让完美主义耽误了时机，毕竟天下武功，唯快不破，很多时候客户需要的是及时响应而不是完美无缺。

3. 非功能性的问题也对架构有着高要求

随着系统规模越来越大，单纯做好业务模型和业务设计，并不足以保证软件的成功。随着架构工作的深入，架构师需要一一或者说不得不更多考虑非功能性的设计要点。

2011年，我参加了某省移动通信公司BOSS系统升级和重构项目。所谓BOSS系统，是行内的一个叫法，正式名称是Business&Operation Support System，在通信行业，一般分为四个部分：计费及结算系统、营业与账务系统、客户服务系统和决策支持系统。

这样的一个系统，是由我当时所在的公司杭州、南京两个研发中心加上北京研发中心的部分专家，有数十个团队参与开发和测试，近百人在现场进行系统集成。我当时负责的是营业与账务系统和部分计费系统的核心框架设计。

我们对营帐系统的交易链路进行压力测试。测试的结果不容乐观，服务整体并发性能未达到客户要求的数据，接下来要推动整个系统的性能优化。这个任务的困难在于大型分布式系统关系错综复杂，整个营帐系统的链路是一条很长的集群，涉及到另外两个系统的调用，同时每个系统内部都有好多组件，彼此形成了复杂的调用关系。而大多数组件来自不同团队，我们团队提供的RPC框架和基础框架只覆盖了65%的组件，剩余来自其他省市研发团队的组件架构不明，设计也完全不了解。在这种情况下，我认为需要解决以下问题：

1. 搞清楚每个测试案例的调用链顺序。在核心调用链上，应该将非核心的系统剔除。

2. 造成整体链路性能不佳的短板在哪里？

3. 找到存在性能短板的组件后，如何发现性能瓶颈。

针对问题1，我们基于RPC框架输出结果的分析，初步完成了一个调用关系图，然后配合软件设计文档，编写流量转发代理工具补充完整了调用链路图。

问题2，我们在RPC框架基础上增加了分析模块，自动对每次吞吐的数据量进行记录，还用于分析响应时长排名、报文长度等Top10等，根据排名情况列出一大堆所谓“慢接口”，但是我们不能因为一个接口慢，就认为它有问题。我们针对数据库的访问研发了自己的ORM框架，解决了一部分慢性能问题。

问题3，我们发现慢的接口往往集中在几个组件上，这和这些组件的设计质量有一定关系。

这个故事告诉我们，大部分研发团队在项目之初对非功能性的特性考虑往往不多，架构师在设计技术架构时，需要成为软件质量底线的保障者，让软件具备足够的自我纠错能力，以及一致的可集成、可维护的能力。

走出成为架构师的关键道路

1. 追根，抽象，把握事物本质

在过去的经历中，促使我从普通的编程者向架构师转变的根本因素，我认为是一种试图追寻事物本质的好奇心。这种好奇心是促使人思考和训练思维的源泉。人类的大脑在记忆力和理解力上是有其局限的，因此人不得不通过抽象，屏蔽事务的无关要素和细节，才能把握事物的本质。

中国古代哲学中，有很多这一类思辨，比如—“时有风吹幡动。一僧曰风动，一僧曰幡动。议论不已。惠能进曰：非风动，非幡动，仁者心动。”对于进修禅心者来说，直指人心的思辨，毫无疑问抓住了问题的本质。因为在参照系为“人心和佛性”的禅学中，世界的本质已经“不在你的心外”（王阳明语）。参照系的不同，带来的结论也就不同。哲学中相对与绝对、运动与静止、唯心与唯物、存在与虚无都有很多对思维的训练，通过思辨，能提升个人的思维抽象能力，因为抽象是哲学思维的基本特征。

2. 不停的学习和传播知识

在技术架构中，各种架构方法可能是大家容易关注到的—面向对象、面向模式、自顶向下分解、自底向上分层等等，从冯诺依曼体系到通信协议、UML等有很多设计方法和架构理念可以学习。

但是在做业务分析和设计时，如何考虑业务模型，如何兼顾涉众利益？大家都知道人性是复杂的，但是在组织内部，人的行为和动机是有轨迹的，人类所表现出来的无外乎正常成年人的社会人格和动机，而这正是普通心理学和组织行为学的研究范围。所以做业务架构的伙伴要去学一些这方面的知识。其实老祖宗早就告诉过我们，“世事洞明皆学问，人情练达即文章”就是这个道理。

架构师无法“独善其身”，缺少了实现架构的研发和项目团队，架构就会成为空中楼阁。因此，成功的架构师只有让组织成功才能真正的成功。架构师要乐于将自己的知识、想法和同事、朋友分享。如果孤芳自赏，那就没有了用武之地。

3. 追求简约与平衡的架构之美

大多称为架构师的人，都有追求完美的偏好，但实际在项目和产品开发中，既没有机会，也没有必要实现完美的架构与软件。因为完美就意味着脱俗，脱俗就意味着无先例、无参照，这往往会带来巨大的风险和不可控因素。

KISS原则是架构师要注意遵循的一个原则，因为越复杂的东西就越精密，越精密的东西在工程中就越不可靠。尤其在分布式系统设计中，异常和故障的可能性太多了。将系统设计得丝丝入扣而没有任何预防措施，那么一旦出现任何意外，异常情况就会像滚雪球那样蔓延开来，直到整个系统奔溃。在二战中，德国的坦克大量使用交错式负重轮。这是一种非常复杂的机械构造，性能优良，稳定性好。然而就是生产复杂，维修繁琐，产量输给对手老大一截，而且容易出故障。据记载，虎式、豹式坦克的战损率和机械故障发生率几乎相等。种种因素下，性能强悍的虎式、豹式最终只能被淹没在廉价坦克T-34的海洋之中。

架构师最终需要站立在大地上，才能仰望天空。平衡好成熟技术和新技术之间的关系、平衡好硬编码和业务引擎之间的取舍、平衡好性能与资源占用之间的矛盾等等，这些都是架构师需要把握的。这种平衡往往来自于环境需求，而不应当是架构师的个人喜好。比如在预研性的项目中，可以适当采取更激进的技术策略，但是对于有紧迫上线时间要求的产品，就需要更保守和稳妥的解决方案。

所谓平衡，并不是平均，更不是平庸。而是在所处场景中，态度鲜明地取舍—在性能中取舍，在功能中取舍等等。这种存乎在心的取舍最终会形成架构师独特的审美，这种审美源自环境（或者场景）与架构的和谐。这种和谐之美体现在业务整体，而不是来自于某顶高精尖的局部构造—就像我们在山林中搭建的小木屋和在都市中搭建的混凝土大厦一样，如果交换了场所，那就失去了和谐之美。

回顾与总结

在软件行业工作，就是在多变的需求、紧凑的工期、古怪的bug中不断挣扎的过程，回首过往，十余年来很多同事在这样的颠簸中或转型管理、或转型售前、或离开了这个行业，这是非常遗憾的。对于我们很多人来说，在迈过所有这些坎坷后，就会发现软件开发工作是“踏遍青山人未老，风景这边独好”。

回首向来萧瑟处，也无风雨也无晴。当你真正体会了这个行业的酸甜苦辣之后，还有什么能让你放弃这个职业呢？

--是“枯燥的编码生活”吗？不，怎么会有人觉得编码枯燥呢？多年来，我内心一直以作为码农自豪，坚持每天写代码。最能体现软件从业人员“像上帝一样”编排一切的工作，无疑就是编码了。你从哪里还能得到创造一个世界那样的满足感？

--是“用户频繁的变更需求”吗？不，每个用户都是理性的体验者，他们追求的一直都是更好地完成业务，流水般变动的只是业务的形态，始终如一的是管理学、组织行为学和普通心理学作用下的业务本质。领会到这一点，你会从用户的微笑和感谢中找到前进的动力。

--是“繁重到不加班就完成不了的任务”吗？不，任何成就哪有不经过汗水和痛苦就能达到的呢？辛苦和汗水带来的不仅仅是疲劳，还有荣誉和满足感。

坚持走技术发展的道路，用技术手段解决客观世界的问题，然后在软件设计和编码的汪洋大海中寻找乐趣，这是所有软件技术人的最好归宿。最后，我希望有志于成为架构师的年轻人能在技术软件研发和架构的道路上坚持下去，直到体会到真正乐趣的时刻。