写代码，就应该像音乐家谱写曲子一样来思考

十多年前的我没有想到，一款产品竟能改变一个人的命运。
 
2000年，文曲星，一款教育类电子词典，推出了革命性的产品CC800：它支持VB语言编程，还能直接运行。高中的我，用这个小机器执行了自己的第一个程序，做出了第一款小游戏。仿佛一个孩子打开了潘多拉的魔盒，各种美妙的东西喷薄而出，从此我一头扎进代码的世界。
 
后来的我终于证明，玩出来的志向，果然经受得住考验。

软件小兵触通信
 
从文曲星的启蒙编程，到大学坚定选择计算机专业，再到2007年加入华为之时，我都信心满满，以为凭借对软件坚持多年的热爱，终于可以大展拳脚。没想到的是，来了通信产品的软件部门，刚开始就被浇了一盆冷水——什么是信号、什么是速率、什么是码？我连最基本的概念名词都搞不清。偏偏做通信产品，最需要的就是对业务的理解。刚到新部门的我，因为不懂通信，就这样突然变成了一个“软件白痴”。
 
6个月的实习期，我做好了恶啃天书的打算——第一周学专有名词，第二周了解代码框架和信令知识，第三周……第三周还没来，项目负责人找我说，刚好赶上版本开发，要不给你个特性做做？我心里打鼓：“这咋两周就开始真刀真枪上战场了！” 可是又挺兴奋，有种一入门就担当重任的感觉，于是一口答应下来。
 
整整一个月，我憋着一股劲：在有限业务理解的基础上，把自己的软件能力发挥到极致。最终的2500行代码，每一行都是我带着处女座般的洁癖打出来的，命名、格式、简洁度、可读性，都尽了当时最大的努力。当我交付到华为后的第一个作品，导师看完后拍了拍我的肩说，“干的不错！”短短四个字，让我幸福无比！后来得知，我做的这个叫做控制器的“铁东西”，原来是保障3G时代人们顺畅通话的重要部件之一。
 
成长的路上，不会一路鲜花
 
2010年，版本上网后爆发了复位问题，导致某地区出现大面积的网络瘫痪。最要命的是，复位信息显示，问题就出现在我们组的某行代码上。
 
客户火急火燎地打来电话，要求我们立即处理：“如果定位不出问题，我们马上投诉华为！”听到这个消息的我，脑袋嗡地一声，除了打击，更多的是羞愧——竟然是因为我们的代码导致了这么严重的问题！我们马上开始了没日没夜的攻关，复位问题就像一把剑悬在头顶。在第二次复位问题发生之前，我们终于定位出来了，确实是我们代码中的保护参数没有做好。
 
原因找出来了，但事情远远没有结束。这个问题是版本的大隐患，只要出现某种业务场景，就会触发复位，引起网络瘫痪。所以我们接下来要做的，是对所有已经升级过此版本的局点，提出版本修复的请求。
 
来华为几年，一直埋头做产品写代码，接收来自一线对产品的反馈，这是我第一次走上对客户解释自己错误的痛苦之路——为什么要修复？不修复会怎样？如何验证效果？我们也收到了一个又一个局点的质疑之声——你们华为的都是这样做事的吗？叫我们以后还怎么敢合作？
 
我很清楚，直面自己的错误需要勇气，挽回客户的信任更需要诚意和耐心。我和其他几个同事，给每个出现问题的局点打电话，一遍遍解释、道歉，再指导客户如何打补丁修复版本，并保证24小时服务，遇到任何问题都能在第一时间联络到我们……后来，好几个局点客户反馈，大意是，你们的东西出了问题，不过修复故障的小伙子还是蛮拼的。
 
得到了客户的理解，但这件事给我带来更多的是警醒——一个小小的保护没做好，事后竟要花1000倍的精力来弥补。质量真的是自尊心。从此以后，我渐渐有了反复检查数组保护的“强迫症”，因为我知道，一时贪图省事，后面必有大事。
 
做第一个吃螃蟹的人
 
2016年，软件行业有一个词火得如日中天：微服务架构。它的介绍宣称，与传统的单体式架构相比，微服务架构“小、独、轻、松“，能够极大降低人员的开发和维护成本。当我看到这句话，仿佛被一道闪电击中——过去几十年，几乎所有的通信产品使用的都是单体式架构。
 
如果把单体式架构比作过去的雕版印刷术，那微服务就是现代的活字印刷术。出版一本书，活字印刷可以很快把书印出来，而雕版印刷的每页书都需要雕刻；如果修改一个错别字，活字印刷替换那个字就可以了，而雕版印刷需要整版重新雕刻。所以，假如通信产品能实现微服务架构，这将是一次颠覆性的革新。
 
我意识到自己站在了一个风口上，第一次用文曲星写代码的那种感觉又回来了！恰逢团队刚刚开发出一款新的软件产品，我们决定就从它开始，尝试一场微服务化的架构改造。
 
30万行代码，是产品原来的架构形态。我们不到10人的小团队，需要做的就是在保证功能不变的前提下，将这30万行代码，重构成每个两三万行代码的多个服务。

 一解释就懂，一问又不知，一讨论就吵架
 
整理好思路框架后，我把每个任务标上难度和时间节点，以竞标的形式供大家选择，虽然很多人还没理解微服务是什么，竞标现场倒是挺热烈的。部门有个小伙子事后对我剖析了心路历程，“凭借手快，嗓门大，我抢了三个任务。抢完后又有点心虚，能不能做成资料中描述的高大上的样子，会不会对产品本来的性能造成影响，我都是在心里打问号的。”
 
在对微服务的理解并没有达到一定的高度，没有一致认知的情况下，团队成员彼此怀疑，甚至看不见希望，都是不可避免的。“感觉我们做这个东西没啥太大意义”，在项目初期，经常听到类似的声音。
 
一解释就懂，一问又不知，一讨论就吵架，这就是团队的初始常态。那一段时间，部门里闹哄哄的，有时候是两三个人，有时候是六七人，越说越激动，讨论出一个方案，然后跑来找我拿主意。
 
为了给每一个人补足信息量，建立起大家的信心，我作为总设计人员，一边不断查找文献，跟其他架构师们对齐观点；一边和开发人员一起看代码，把他们的反馈作为输入，矫正前进的方向。
 
在这期间，好几次当我们以为可以定稿了，突然有人又发现了一些不合理的地方，然后整个改造计划又需要重来一遍。每次都逼得项目经理跟我哭诉，“哥，你再调整任务我就不给你搞了。”但其实他也知道，架构改造一旦开始，走的是一条只能往前，不能后退的路。
 
整整三个月，我们终于完成了我司通讯类产品对微服务架构的首次尝试，2万行代码联调活动从56人/天降低到2人/天。“以前代码上库前，个人需要执行对所有代码的编译检查，现在只需要编译检查自己这一块的服务，不用等的感觉真好“，同事体验完微服务架构后，发出由衷的感慨。从等待到不等待，从战战兢兢到轻装上阵，微服务架构就这样风风火火地来了。
 
后来某天，大家正在埋头继续优化微服务，一个同事突然站起来，对另一个同事说，“啊，trans，你那个XXXX搞好了没？”顿时周围笑得人仰马翻，因为trans是我们一个微服务的名称。看来在这三个月里，每个人已经深深地打上了服务的标签。我清清楚楚地看到每一个人在这中间的转变和收获， “没有意义”这种质疑声，再也没有出现过。
 
当我获得了梦寐以求的金牌个人奖时，已经无心回顾历史，因为未来正迫不及待地向我而来。从庞大到小巧，从笨重到轻量，从连动到独立，微服务的好处，除了减少人员的开发维护成本，还是通信实现云化所需要的关键架构能力。微服务，即将成为点亮云图的那道光束。 

工程师，要像音乐家一样思考
 
有这样一首曲子，你可能不知道它的名字，但你一定听过它的调子——因为它无数次地被电影、音乐、游戏引用过，改编过，甚至乘着宇宙飞船上过太空，它就是《Canon in D》。
 
我曾经以为，这首红遍宇宙的卡农曲谱，会复杂到只有音乐家、演奏家才看得懂。但其实它简单得让人不敢相信——“小提琴全部拉奏完全相同旋律，前后仅3段不同的旋律，每段仅2小节的旋律供重复拉奏；大提琴从头到尾也仅有2小节，重复达28次之多。”不炫技、不卖弄、不断回旋往复，就是这么简单。但就是这样简单的曲目，却在心底的最深处留下了一颗种子，让你每次遇见它都会侧耳倾听。我们不是音乐家，我们只是工程师、设计师、架构师，但音乐家和工程师都有一个共同点：我们都是进行创造性活动的人。既然同是创造者，我们为什么不能将其他领域的思想引入到我们的工作中来呢？
 
最难的事情，其实就是把简单做好。我们工程师，也应该像音乐家谱写曲子一样来思考软件架构，追溯世界本质，回归设计之源，追求流传于世的惊天动地之作。

本文来自《华为人》