“板凳”十年不会冷

举报
技术火炬手 发表于 2020/02/25 14:07:38 2020/02/25
【摘要】 软件更像是工艺品,而不是工业制品;软件工程师更像是工匠而不是流水线工人。所以软件工程师需要的是工匠精神,有时也需要一点独具匠心。

“板凳”十年不会冷

贺炜

“板凳要坐十年冷”,这是公司倡导的一种文化,尤其是在研发体系,它强调的是要耐得住寂寞,精益求精,踏踏实实把产品做好的一种精神。据说,这条标语常年挂在新员工培训的大教室里,好多人理解“板凳”都是冷的,即便坐十年也是。

而我的经历和体会却是,再冷的“板凳”坚持坐总能把它坐热,而已经坐热的“板凳”,如果总是翘起屁股去张望,也会变凉。因此,一旦找到适合自己的“板凳”,就坚持坐下去。

灯的颜色不一致,让我产生了敬畏感

1994年大学毕业,应聘去了广东江门一家银行的电脑部,那时候计算机专业还是很吃香的,银行给的综合待遇也不错,工作很轻松,唯一的问题是没怎么有挑战、有难度的事可干,时常觉得很无聊。1997年年中,一起入职的校友不知怎么联系到了华为,当时都不知道华为是个什么公司,一起面试的几个人都通过了,免不了俗,说实话最吸引我们的还是华为给的工资一下子较之前翻了三倍。

入职后,我到了传输业务部做网管,那时候还没有IPD流程,软件开发过程是很民间、很随意的。当时产品也还没有开卖,和网管一起的里程碑时间点就是一个试验局,俄罗斯的一个客户要来华为进行厂验。为了把一个粗糙的半成品赶在客户到来之前能够示人,我们几个人结结实实在公司睡了几天,状态好的时候我一个通宵就能完成一个模块的开发。但是我内心排斥这种疲劳作战的方式,从那之后我再也没有熬过通宵。

这个网管系统是很初级的,就是实现一个网元级的基本管理,不复杂。客户来现场体验后认为做的还可以。按现在的说法,客户的这个肯定,我们就算过了TR5点了,大家都很高兴。但客户的一个专家指出的一个小问题,让我觉得有些汗颜。他说设备上这个灯是黄色的,可网管上你的这个界面上怎么是绿色的呢?我解释说我理解设备没有故障就是应该绿色的。这位专家反驳道:“你这样理解不对,网管要反映设备的真实状态,如果设备状态指示灯变成黄色的,你应该很快同步过来,这样我的维护人员才能根据这个警示状态去检查设备到底有没有故障,而不是非得指示灯红了才采取动作,到那时候故障应该已经产生了。”

我很受启发,这就跟写代码一样,我应该重视一段代码运行过程的状态是要可控的,也就是说要用确定性的过程来确保确定性的结果。而不是说非得等程序的状态机跑飞了或程序挂死了再去查找原因,救火灭火的成本都很高,也很耗精力。随后,我就这个问题专门进行了整改。

这是我职业生涯里第一次面对客户,客户指出的这个小问题却让我产生了一种敬畏之心,这个敬畏不是说害怕犯错,而是对代码怎样实现需求这件事要有敬畏之心,实现的过程和呈现的结果要表里如一,不能含糊不清。哪怕错了就是错了,改过来就好;不够好就是不够好,改进就是。我要为我输出的每一行代码负责任,这样一个原则貌似也吻合了我们现在强调的过程可信。

唯一一次换“板凳”,让我差点怀疑人生

写代码二十多年,常有人问我,公司平台这么大,为什么不考虑试试其他岗位,换换赛道人生是不是会多一些可能?

我的答案很简单,适合自己的才是最好的。我能长久沉浸在编码世界,是因为写代码对于我来说是一件非常有趣的事,这里面的乐趣常常让我无法自拔。就如同作家来了灵感,写文章停不下来一样,编码,对我就是如此一般奇妙的存在。

实际在2000年前后,我也伴随着南京研究所的创立,被提拔为干部,当研究部的经理做管理岗位一年多。之后又响应研发去支援市场的号召,到上海代表处当了一名光网络的产品经理,那半年多对我来说简直是“如坐针毡”,完全不适应。感觉自己无论在性格还是技能上都把握不了这个岗位,不懂市场的销售运作方式。当时想着往回退,又不太敢开口,感觉不光彩,进退维谷之间都产生了辞职离开公司的想法。原来研发的主管得知我的情况后就给我打电话说,要不行就回研发吧。

这一段与代码分离的日子,反而让我更加看清了自己的内心:我发现比起和人打交道,自己好像更擅长和代码做朋友。于是当有机会回到编程岗位,我毫不犹豫地回来了。就这样,兜兜转转我又坐回了熟悉的小“板凳”——Coding和架构设计,从此就再没挪过屁股。

网络版配置器,让我酣畅淋漓了一把

这些年,参与和支持了公司很多重量级的项目,有对内的、也有产品化走向市场的,有成功的、也有不了了之的。现在回忆起来,当初参与网络版配置器的整改印象很深刻,感觉支持这个项目把当时所学酣畅淋漓地发挥了一把。

公司业务繁杂,从客户需求到最终产品到现场的链条很长,早期各体系的IT系统建设也不成熟,相互间的衔接不够顺畅,“发正确的货”一度成为公司上下追求的重要目标之一。这其中,一线产品经理用的销售工具——配置器(Unistar),就是很关键的环节,它要从源头上确保客户的需求转化成各产品线销售的具体模块及配套辅料等。

2008年前后,无线产品线找到中软的领导求助,说当时在用的单机版配置器越来越难以支撑海量发货对齐套准确性的要求了,简直是焦头烂额,请中软务必尽快派人解燃眉之急。

中软领导对这个事情非常重视,知道对公司很重要,就把包含我在内的几个骨干召集起来:“你们几个过去一定把这个事情搞定!”言外之意,中软的名声可不要被我们几个搞砸了。

我们去一看,无线已经决定把配置器从单机版改成网络版了,就是C-S(客户端-服务器)模式,虽然用了新技术,但是架构却很乱,怎么也搭不起来。配置器这个玩意儿虽然感觉很小,但是前前后后、里里外外涉及的东西还挺多。就拿其最核心的配置算法来说吧,一个基站根据需求配几个什么制式的主控板、基带板、哪个模块的RRU?配套几根光纤,配套光模块的速率是多少等等。这些规则一条一条顺下来感觉很简单,但是面对全球那么多纷繁复杂的场景,一套完整地适应各种需求的配置规则算法维护起来就不那么简单了。

最早的单机版都是各产品线的PDE(产品数据工程师)通过Excel里面的宏来维护配置规则和算法,宏有两个问题:一个是很难维护,另外一个是有些逻辑它很难表达。后来就改成了Python来描述和维护,就是用脚本,但是配置算法用这个通用语言描述起来很吃力,再就是容易犯错误,有时候会莫名其妙的跑偏。这次我给他们用上了DSL(领域专用语言),在公司也属首创,相当于给PDE开发了一个专用的语言和配套的IDE(集成开发环境,Unistar Studio)来描述、设置和测试配置算法,有了这个之后,缩短一半以上的规则配置时间,而且即便是产品线的MO都可以很轻松、很清晰地描述并维护配置逻辑。通过DSL来解决这个问题得益于我从网上得来的想法,只不过根据实际需要将概念进行抽象和落地,后来还在部门讲了好几堂关于DSL的课。

除此之外,我还给这个配置器重新写了一个底层框架,包括Server端的框架也重新写了。支撑这个项目,相当于把配置器的前端呈现和后端server的框架都重新搭了,还把其关键的配置算法用了专有技术搞定,相当于救治一个危重病人,能用的重器都给用上了,自然也不轻松,在百草园攻关住了好几个月。

好在我们几个算是不辱使命吧,帮助网络版的配置器按时上线,没给中软掉链子。

基础软件开发,让我很有成就感

中软基础软件项目很多,我有幸多次深度参与其中。

编译器内核项目原型版本初测,时常出现丢帧、卡顿等现象,内存管理的瓶颈较为突出。项目团队经过对Beta用户的大量数据采集,对系统内存分配、释放行为和时机进行大数据解析,将瓶颈锁定在GC(垃圾回收)停顿时长这个突出问题上。长期和代码打交道的我,喜欢研究各种编程语言的实现技术,对GC算法也有所研究。考虑内存管理的复杂度及项目商用诉求对工程能力和经验的要求,项目组找到我,希望我能跟他们一起攻克这个难题。

贡献代码上万行,涉及编译器前端、后端、运行时,GC最大停顿时间由开始的分钟级降到毫秒级,产品上市表现稳定,我很自豪有这个机会从一个编译器的“User”,摇身一变,成了“Provider”!

还有一次印象比较深刻的“小确幸”,要从大家可能都听过的“画一条线一万美元”这个故事说起:福特公司厂房的电机出故障了,万般无奈之下请来了著名的物理学家、电机专家斯坦门茨。斯坦门茨检查完用粉笔在电机外壳画了一条线,让工作人员在记号处把里面的线圈减少16圈后问题就解决了。事后斯坦门茨要1万美元的酬金,并给出理由:画一条线,1美元,知道在哪儿画线,9999美元。

无独有偶,公司一个重量级产品到了阶段性里程碑之后,邀请了产品线专家、客户侧的专家,和中软的专家一起帮他们检视代码以进行质量加固。我一共提了几十条检视意见,其中有一条最有价值,它是一个隐藏的bug,我写了一行内存屏障的底层代码,告诉项目组说,假设我们的产品相当于砌了一面“墙”,如果没有这行代码,意味着最底下的一层“砖”是不稳固的。我把我写的测试用例给他们看,测出了好多莫名其妙的并发场景的问题。迎着兄弟们钦佩的目光,当时真的成就感爆棚。虽都是职责所在,但在帮助项目把问题解决的那一刻,除了如释重负之外,也感到一点点自豪。

我说这两件小事并不想吹嘘什么,是觉得做技术,过程中需要有深扎到底的信心和决心,只有扎下去,才能在这个领域有所建树,时间久了才能融会贯通,处理跨领域、更复杂的问题。另一方面是要细心,小小的疏忽很可能造成灾难, 无论是自己写代码、还是去检视别人的代码、还是被指派解决疑难问题,我始终坚持细节藏魔鬼,大胆怀疑,小心求证。

不当“码农”的秘密,让我把“板凳”坐穿

“板凳要坐十年冷,文章不写半句空”,写代码也是一样,我很庆幸让自己大部分时间处于Coding的状态,就像此刻我作为中软极客组成员又投入在公司新的重要项目中一样。

image.png

回到编码本身,我始终认为软件更像是工艺品,而不是工业制品;软件工程师更像是工匠而不是流水线工人。所以软件工程师需要的是工匠精神,有时也需要一点独具匠心。

  我觉得每一个程序员都是在创作,就如写文章没有固定的句式,编码可以有自己的创作发挥,需要你去排兵布阵。我们平时经常说,研发有设计与编码,其实我觉得编写代码本身就是一种设计,架构设计与编写代码都属于设计。我们经常把写代码的软件工程和建筑工程相比,大家总觉得架构设计才是设计,编写程序的是就是在简单地码砖,其实并不是。比如贝聿铭设计的作品,他可能只设计整体的大框架,里面的细节结构设计还是要他人继续设计,这样的人也是真正的设计师。

所以,程序员给自己的定位是很重要的。平日里大家经常自嘲自己是“码农”,二十多年的编码生涯告诉我,不再当“码农”的秘诀,首先就是要摆正自己的心态,我们也是设计师!每一个小的函数,每个小代码块,都是一个设计,要把他的功能实现,都可以有自己设计的小巧思在里面。因为所谓的设计有很多种,你要选最合适的那个。软件设计里面有一句话:没有最好的,只有最合适的。我们作为写代码的设计师,经常面临有很多选择,但我们的标准只有一个,那就是选择最合适的,然后打造出可信的软件!

  回顾这些年,激励我把写代码这条“板凳”坚持做下去的,还是老板讲话中的一段话“你终于会享受到这种默默无闻的无私奉献的快乐。当你回首往事,不因虚度年华而悔恨,也不因碌碌无为而羞耻。你可以自豪地对儿孙说,我参与的平台,数十年了还在全世界运转……不要在乎别人说三道四,自己激励自己,才能实现人生的伟大。”

1582610831521875.gif

本文为《华为人》版权所有,未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。