zoukankan      html  css  js  c++  java
  • 从任正非公开信说起,谈代码规范的重要性!

    最近的1月2号,任正非发布了题为《全面提升软件工程能力与实践,打造可信的高质量产品》致全体员工信,这也是今年华为总裁办签发的2019年001号文件。在信中,任正非强调了高质量软件产品的关键特性,呼吁各软件工程师理解架构的核心要素、重视代码质量、遵循业界共识的标准和规范,并计划用5年时间投入20亿美元全面提升华为软件质量。

    任正非的公开信

    在我的印象中,关于某某公司宣布重金投入一个领域、一个产品的新闻有很多,比如某度和某米的all in;但华为这次却很不一样,20亿美元的投入点居然单纯是冲着软件质量去的。和前面的新闻比,华为这次的投入针对的不是增量而是存量。于是我们不禁要问:花一百多亿人民币的代价,甚至不惜影响现有的团队开发节奏,去做一件并不能带来短期直接收益的事情,华为值得吗?

    我想任正非是坚定地认为值得的,从他的公开信中就能够看出来:在信的开篇,任正非就告诉华为员工公司正处在一个新的起点,并明确把网络安全和隐私保护作为公司的最高纲领。也就是说,面对全面云化、智能化、软件定义一切等发展趋势,他意识到软件工程的可信度将在接下来的时间内变得尤为重要,做不好是可能连入场券都拿不到的!

    随着5G、深度物联网建设即将拉开序幕,数据在日后将变得异常丰富。华为作为数据采集的主要设备方、管理者,必然要肩负起维护数据安全的责任,若稍有不慎发生一定范围的系统故障、数据泄露等问题,带给公众和公司的冲击会是巨大的。

    因此,任正非的这个决定看似针对的是公司现有存量,实际出发点和十年前马云决定做云计算是一样的:不可不做,因为这就是未来!


    代码规范为何重要?

    写这篇文章,主要不是要聊任正非的这封信,而是想借此谈论一些关于软件质量的看法。包括我在内的大部分软件工程师在现阶段是无需过多考虑架构的,我们面临的最直接要求就是软件编写要遵循统一的代码规范,因此本文就围绕代码规范来讲。

    每一位参与过工程代码编写的软件工程师或许都会说:“代码规范很重要”!若要问为什么重要时,得到的答案大概会是:“代码规范就像是团队的共同语言,大家使用统一的语言交流会更加顺畅,避免额外的沟通成本”。如果进一步追问还有没有其它因素,很多工程师就无从说起了。

    事实上,软件团队开发遵循统一的代码规范的确能够大大提升整体代码的可读性,不过还有更为重要的一点是:代码规范实际是架构细节实现的一部分,设计工程架构时会有安全性、韧性、扩展性、可维护性等多个方面的考虑,软件规范的落实情况将很大程度上决定软件工程在这些方面上的表现。这也是为什么任总在公开信中会呼吁员工要深刻理解架构的核心要素。

    在软件开发中这样的情形是很常见的:

    • 程序崩溃了,没有任何提示信息,只能通过不断地重复尝试复现,慢慢定位问题点。

    • 有人针对自己维护部分代码做出修改并局部测试成功后上库,结果引发其它模块的功能问题。

    • 代码冗长且逻辑复杂,交接给他人维护造成噩梦般的体验,甚至连编写者本人都难以重新理解。

    • 工程代码有移植需要,发现裁剪困难,同一硬件平台的迁移甚至都要反复调试。

    ……

    你看,即使我们拥有了统一的命名风格、代码格式、严谨的注释,依然无助于以上这些问题的发生。形式上的统一固然是代码规范中必不可少的部分,但代码规范还应包括体现良好架构设计思想的一些原则,甚至更为重要。

    然而,现实的问题往往不是有没有书面的代码规范,而是有了代码规范后团队能否一以贯之。

    有太多的理由让软件工程师们放松对代码规范的遵守了:

    • 项目工期紧、领导催得厉害,这个时候抓代码规范分散太多时间,应该让路于基本功能的实现。

    • 接手的时候代码就没按照规范来,因此我再遵守也没意义。

    • 让代码能工作,才是专业开发者的头等大事,要分清主次。

    ……

    以上的种种理由看似有一定道理,仔细琢磨其实完全不是那么回事,是站不住脚的。

    比如最常见的第一点,因为赶进度,所以没那么多时间注意规范。实际情况是:

    (1)在项目的开发中,绝大部分的时间是消耗在 bug 调试而不是写代码上的;

    (2)在写代码的同时注意代码规范的维护,并不会牵扯太多时间;

    (3)写代码的时候更多时间是在读代码,读代码和写代码的时间比一般在 10:1 左右,而代码是否规范,将及大地影响阅读代码的效率。

    如果注意到这些事实,代码规范还应该让位于工程进度吗?

    对于第二点,仿佛是在说:在一个本来就很烂的代码上坚持我的代码规范是没有意义的事情。这就好比我们同他人交往,我们有必要因为别人没有礼貌,就允许自己变得跟他一样没有礼貌吗?

    对于第三点,今天编写的功能极有可能在下一版本中被修改,但代码的可读性却会对以后可能发生的修改行为产生深远影响。

    版本经理、领导可能站在他们的角度而更关心项目进度,这并不意味着软件工程师可以放松对代码规范的遵守,只给领导看到他们能够看到的。所有不符合既定规范下写出来的代码在往后的维护上带来问题的可能性是极大的,也许是以 bug 的形式体现;也许就是一团乱麻,让人望而生畏。这些不规范的问题不会随着时间的推移而自动消失,它们会转化成技术债务,是债总是要还的,而且还利滚利!今天不还,明天后天还是要还;自己不还,别人就要还得更多;当哪一天软件工程师疲于还债,离职或许就会发生了。

    很多团队往往因为赶工期而加班加点,却不太舍得多花些时间对大家的代码规范意识进行指导和培训。就像时间管理的四象限法则,人们总是花太多时间在「重要又紧急」和「紧急又不重要」的事情上,对于「重要不紧急」的事情往往视而不见。

    落实代码规范就是那个重要不紧急的事情,希望我们都能注意到它,从维护代码的恶性循环中走出来,把软件开发变成一件愉悦的事情。


    参考资料

    【1】《全面提升软件工程能力与实践,打造可信的高质量产品》——任正非公开信

    【2】《代码简洁之道》——Robert C. Martin.

    ·END·


    你可能还感兴趣:

    SIMD数据并行(一)——向量体系结构

    SIMD数据并行(二)——多媒体SIMD扩展指令集

    SIMD数据并行(三)——图形处理单元(GPU)

    SIMD数据并行(四)——三种结构的比较

    现代处理器与代码性能优化

    关于代码执行效率优化的一次内部分享

    欢迎来我的微信公众号做客:信号君

    专注于信号处理知识、高性能计算、现代处理器&计算机体系 

     

    技术成长 | 读书笔记 | 认知升级

    幸会~

  • 相关阅读:
    codeforces C. Fixing Typos 解题报告
    codeforces B. The Fibonacci Segment 解题报告
    codeforces B. Color the Fence 解题报告
    codeforces B. Petya and Staircases 解题报告
    codeforces A. Sereja and Bottles 解题报告
    codeforces B. Levko and Permutation 解题报告
    codeforces B.Fence 解题报告
    tmp
    API 设计 POSIX File API
    分布式跟踪的一个流行标准是OpenTracing API,该标准的一个流行实现是Jaeger项目。
  • 原文地址:https://www.cnblogs.com/ncdxlxk/p/10279569.html
Copyright © 2011-2022 走看看