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

桂林seo / 随笔杂谈 / 时间:2017-11-25 19:27

十多年前的我没有想到,一款产品竟能改变一个人的命运。

2000年,文曲星,一款教育类电子词典,推出了革命性的产品CC800:它支持VB语言编程,还能直接运行。高中的我,用这个小机器执行了自己的第一个程序,做出了第一款小游戏。仿佛一个孩子打开了潘多拉的魔盒,各种美妙的东西喷薄而出,从此我一头扎进代码的世界。

后来的我终于证明,玩出来的志向,果然经受得住考验。

1

软件小兵触通信

从文曲星的启蒙编程,到大学坚定选择计算机专业,再到2007年加入华为之时,我都信心满满,以为凭借对软件坚持多年的热爱,终于可以大展拳脚。没想到的是,来了通信产品的软件部门,刚开始就被浇了一盆冷水——什么是信号、什么是速率、什么是码?我连最基本的概念名词都搞不清。偏偏做通信产品,最需要的就是对业务的理解。刚到新部门的我,因为不懂通信,就这样突然变成了一个“软件白痴”。

6个月的实习期,我做好了恶啃天书的打算——第一周学专有名词,第二周了解代码框架和信令知识,第三周……第三周还没来,项目负责人找我说,刚好赶上版本开发,要不给你个特性做做?我心里打鼓:“这咋两周就开始真刀真枪上战场了!” 可是又挺兴奋,有种一入门就担当重任的感觉,于是一口答应下来。

整整一个月,我憋着一股劲:在有限业务理解的基础上,把自己的软件能力发挥到极致。最终的2500行代码,每一行都是我带着处女座般的洁癖打出来的,命名、格式、简洁度、可读性,都尽了当时最大的努力。当我交付到华为后的第一个作品,导师看完后拍了拍我的肩说,“干的不错!”短短四个字,让我幸福无比!后来得知,我做的这个叫做控制器的“铁东西”,原来是保障3G时代人们顺畅通话的重要部件之一。

2

成长的路上,不会一路鲜花

2010年,版本上网后爆发了复位问题,导致某地区出现大面积的网络瘫痪。最要命的是,复位信息显示,问题就出现在我们组的某行代码上。

客户火急火燎地打来电话,要求我们立即处理:“如果定位不出问题,我们马上投诉华为!”听到这个消息的我,脑袋嗡地一声,除了打击,更多的是羞愧——竟然是因为我们的代码导致了这么严重的问题!我们马上开始了没日没夜的攻关,复位问题就像一把剑悬在头顶。在第二次复位问题发生之前,我们终于定位出来了,确实是我们代码中的保护参数没有做好。

原因找出来了,但事情远远没有结束。这个问题是版本的大隐患,只要出现某种业务场景,就会触发复位,引起网络瘫痪。所以我们接下来要做的,是对所有已经升级过此版本的局点,提出版本修复的请求。

来华为几年,一直埋头做产品写代码,接收来自一线对产品的反馈,这是我第一次走上对客户解释自己错误的痛苦之路——为什么要修复?不修复会怎样?如何验证效果?我们也收到了一个又一个局点的质疑之声——你们华为的都是这样做事的吗?叫我们以后还怎么敢合作?

我很清楚,直面自己的错误需要勇气,挽回客户的信任更需要诚意和耐心。我和其他几个同事,给每个出现问题的局点打电话,一遍遍解释、道歉,再指导客户如何打补丁修复版本,并保证24小时服务,遇到任何问题都能在第一时间联络到我们……后来,好几个局点客户反馈,大意是,你们的东西出了问题,不过修复故障的小伙子还是蛮拼的。

得到了客户的理解,但这件事给我带来更多的是警醒——一个小小的保护没做好,事后竟要花1000倍的精力来弥补。质量真的是自尊心。从此以后,我渐渐有了反复检查数组保护的“强迫症”,因为我知道,一时贪图省事,后面必有大事。

3

做第一个吃螃蟹的人

2016年,软件行业有一个词火得如日中天:微服务架构。它的介绍宣称,与传统的单体式架构相比,微服务架构“小、独、轻、松“,能够极大降低人员的开发和维护成本。当我看到这句话,仿佛被一道闪电击中——过去几十年,几乎所有的通信产品使用的都是单体式架构。

如果把单体式架构比作过去的雕版印刷术,那微服务就是现代的活字印刷术。出版一本书,活字印刷可以很快把书印出来,而雕版印刷的每页书都需要雕刻;如果修改一个错别字,活字印刷替换那个字就可以了,而雕版印刷需要整版重新雕刻。所以,假如通信产品能实现微服务架构,这将是一次颠覆性的革新。

我意识到自己站在了一个风口上,第一次用文曲星写代码的那种感觉又回来了!恰逢团队刚刚开发出一款新的软件产品,我们决定就从它开始,尝试一场微服务化的架构改造。

30万行代码,是产品原来的架构形态。我们不到10人的小团队,需要做的就是在保证功能不变的前提下,将这30万行代码,重构成每个两三万行代码的多个服务。

4

一解释就懂,一问又不知,一讨论就吵架

整理好思路框架后,我把每个任务标上难度和时间节点,以竞标的形式供大家选择,虽然很多人还没理解微服务是什么,竞标现场倒是挺热烈的。部门有个小伙子事后对我剖析了心路历程,“凭借手快,嗓门大,我抢了三个任务。抢完后又有点心虚,能不能做成资料中描述的高大上的样子,会不会对产品本来的性能造成影响,我都是在心里打问号的。”

在对微服务的理解并没有达到一定的高度,没有一致认知的情况下,团队成员彼此怀疑,甚至看不见希望,都是不可避免的。“感觉我们做这个东西没啥太大意义”,在项目初期,经常听到类似的声音。

一解释就懂,一问又不知,一讨论就吵架,这就是团队的初始常态。那一段时间,部门里闹哄哄的,有时候是两三个人,有时候是六七人,越说越激动,讨论出一个方案,然后跑来找我拿主意。

为了给每一个人补足信息量,建立起大家的信心,我作为总设计人员,一边不断查找文献,跟其他架构师们对齐观点;一边和开发人员一起看代码,把他们的反馈作为输入,矫正前进的方向。

在这期间,好几次当我们以为可以定稿了,突然有人又发现了一些不合理的地方,然后整个改造计划又需要重来一遍。每次都逼得项目经理跟我哭诉,“哥,你再调整任务我就不给你搞了。”但其实他也知道,架构改造一旦开始,走的是一条只能往前,不能后退的路。

整整三个月,我们终于完成了我司通讯类产品对微服务架构的首次尝试,2万行代码联调活动从56人/天降低到2人/天。“以前代码上库前,个人需要执行对所有代码的编译检查,现在只需要编译检查自己这一块的服务,不用等的感觉真好“,同事体验完微服务架构后,发出由衷的感慨。从等待到不等待,从战战兢兢到轻装上阵,微服务架构就这样风风火火地来了。

后来某天,大家正在埋头继续优化微服务,一个同事突然站起来,对另一个同事说,“啊,trans,你那个XXXX搞好了没?”顿时周围笑得人仰马翻,因为trans是我们一个微服务的名称。看来在这三个月里,每个人已经深深地打上了服务的标签。我清清楚楚地看到每一个人在这中间的转变和收获, “没有意义”这种质疑声,再也没有出现过。

当我获得了梦寐以求的金牌个人奖时,已经无心回顾历史,因为未来正迫不及待地向我而来。从庞大到小巧,从笨重到轻量,从连动到独立,微服务的好处,除了减少人员的开发维护成本,还是通信实现云化所需要的关键架构能力。微服务,即将成为点亮云图的那道光束。

5

工程师,要像音乐家一样思考

有这样一首曲子,你可能不知道它的名字,但你一定听过它的调子——因为它无数次地被电影、音乐、游戏引用过,改编过,甚至乘着宇宙飞船上过太空,它就是《Canon in D》。

我曾经以为,这首红遍宇宙的卡农曲谱,会复杂到只有音乐家、演奏家才看得懂。但其实它简单得让人不敢相信——“小提琴全部拉奏完全相同旋律,前后仅3段不同的旋律,每段仅2小节的旋律供重复拉奏;大提琴从头到尾也仅有2小节,重复达28次之多。”不炫技、不卖弄、不断回旋往复,就是这么简单。但就是这样简单的曲目,却在心底的最深处留下了一颗种子,让你每次遇见它都会侧耳倾听。我们不是音乐家,我们只是工程师、设计师、架构师,但音乐家和工程师都有一个共同点:我们都是进行创造性活动的人。既然同是创造者,我们为什么不能将其他领域的思想引入到我们的工作中来呢?

最难的事情,其实就是把简单做好。我们工程师,也应该像音乐家谱写曲子一样来思考软件架构,追溯世界本质,回归设计之源,追求流传于世的惊天动地之作。

 


桂林SEO半杯酒博客文章,转载请注明原文网址摘自 http://www.mna5.com/suibizatan/560.html,谢谢配合!

微信扫一扫,关注我们
1
3