写了十几年代码，我为什么还没有被拿去“祭天”？
|
不过，经过几个月的摸索、实践后，我渐渐地明白，Committer机制应该是一种文化上的变革，牵引大家提升自己的软件能力。Committer的职责很多，作为代码提交前的最后一道关卡，这是在当前人员能力不足阶段有效果，但是最终应该被弱化的一项实践。参与编码前的软件设计、持续做好架构看护和技术债务清理，让大家都有更大的机会写出更好的代码，我认为这是Committer更大的价值。 随着个人和组织的软件工程能力提升，自动化测试防护网和变更防护墙建设完善之后，前面提到的“一行代码引起的惨案”，是可以避免的。 4、“变更防护墙”够不够可靠? 对于大部分老员工，特别是无线2G/3G/4G等部门的老员工来说，一提到变更控制，都会如临大敌。版本升级后，KPI变差是绝对不允许的，严重时可能面临版本回退、客户投诉和上报事故。而KPI变好，除了要向客户解释，还有可能面临商务风险，客户会觉得之前吃亏了。现实世界对我们就是这么苛刻，谁让我们是影响世界的通信软件工程师呢，他们这是爱之深、责之切啊! 我们开发一个版本，动辄涉及几十万代码的新增、修改或重构。要想不引入变更问题，除了做好设计、结对编码、代码检视和测试之外，我认为最关键的就是完善的自动化防护网。在3G时，我带着两个同事将IT测试工程从只有几百个用例扩充到上万个用例。全方位的场景覆盖、严密的信元有效性检查、完善的用例失败判决机制、无死角的资源泄漏检查等手段，让变更错误无所遁形，给3G留下了一道变更防护墙。 开发过程中补充IT和PC-ST测试用例，不是为了提升代码覆盖率，而是为了自动化防护。而要能达成自动化防护的前提，是每个用例都具备完善的有效性检查，否则防护网就是形同虚设。几年前，我跟一个同事开玩笑：“我会故意将某行代码改错，看看你补充的用例是否能检查出来。”让我意外的是，在交付紧张的情况下，他仍然多花了半天时间完善用例有效性检查，并请我故意改错代码来做试验。当然，最终的结果是，他准备得很充分，我没能发现问题。多么有自我追求的一个程序员! 5、保持对于新兴技术的好奇心 说起程序员的追求，我还想起了2016年参与的一个产品云化项目，我负责弹性伸缩特性的方案设计。在此之前，我一直在投入嵌入式软件开发，虽然期间产品也换了好几代的硬件，经历了产品与平台解耦、制式间解耦、软件与硬件解耦等过程，但是对于服务化、微服务化、云化等概念，我却基本处于懵懂的状态。 不懂怎么办，只能是“站在巨人肩膀上，为我所用”。兄弟产品线不是已经做了吗，那就找他们做同行协助;友商不是有路标和规划了吗，那就在他们的有限材料中寻找可借鉴的地方;互联网的亚马逊云、阿里云不是有非常成熟的方案了吗，那就下载他们的产品手册和用户指南……那段时间感觉自己就像是入了魔一样，疯狂地学习分布式软件相关技术，疯狂地吸收各方面的能量为我所用，最终给出了一个令自己和项目满意的设计方案。 这也让我充分意识到自己之前把眼光局限于所在产品、系统、子系统的不足。作为一个程序员，除了要提升自己的基础软件能力，我们也要始终保持对于新兴技术的好奇心，孜孜不倦的追求，不断拓宽自己的视野。而这方面的能力和诉求，在5G时代更是如此。 当前我们华为5G面临的网络安全问题，虽然有着很大的政治因素，但也从侧面反映了5G的战略意义。超高速率、超大连接数、超高可靠低时延，对我们在软件处理时延、可靠性、安全、韧性等方面的能力都提出了更高的要求。同时，5G承载的垂直行业应用、接口开放和硬件“白盒化”等趋势，也必将对我们当前的知识和技术体系，提出更大的挑战。 公司计划用五年的时间，全面提升软件工程能力，对我们是考验，也是机会。统一编程规范、整洁代码、整洁优雅的架构，不同的人有不同的追求，需要我们有持之以恒、水滴石穿的决心。五年或者十年后，当我们回首时，会发现自己曾经的付出是值得的。正如，清代著名学者王国维提出的读书三境界之第三境：“众里寻她千百度，蓦然回首，那人却在灯火阑珊处。” 也许我们绝大多数人终其一生也无法成为Linus、张小龙这样的大神。然而，我们能够做一个有修养的程序员，并参与到改变世界的华为5G产品开发中来，在人类的通信史中留下自己的优秀代码，幸哉。 【编辑推荐】
点赞 0 （编辑：三明站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
