返回顶部


            北京快乐8平台


行业新闻
当前位置:主页 > 北京快乐8平台 > 行业新闻 >

软硬件研发从软件工程的角度解读任正非的新年

  前两天被任正非的那封《全面提升软件工程能力与实践,打造可信的高质量产品》的公开信刷屏了,作为一个软件工程专业科班出身的软件开发从业者,自然是引起了我(@宝玉 xp)的好奇,仔细阅读之下确实让我大吃一惊,看似八股官方文,但细看之下是作者对于软件工程的理解确实非常深刻,各种专业术语信手拈来,比喻恰到好处

  二十年前的 IPD 变革,重构了我们的研发模式,实现了从依赖个人、偶然性推出成功产品,到制度化、持续地推出高质量产品的转变

  我们要转变观念,追求打造可信的高质量产品,不仅仅是功能、特性的高质量,也包括产品开发到交付过程的高质量

  我们各级管理者和全体员工都不得以进度、功能、特性等为理由来降低可信的要求,确保可信的要求在执行过程中不变形

  2018 年底程序员被裁的不少,很多程序员开始担忧起前景来,其实如果你能做到这下面要求的应该是不担心被裁的

  我们要从最基础的编码质量做起,视高质量代码为尊严和个人声誉。代码就像是高楼大厦的一砖一瓦,没有高质量的代码,可信的产品就是空中楼阁。我们要优化并遵循公司各种编程规范,遵从架构与设计原则,熟练使用各种编程库和 API,编写出简洁、规范、可读性强、健壮安全的代码

  可信了,架构设计的时候,别再天马行空,啥新酷用啥,啥流行用啥,一定要“可信导向”,架构设计目标先搞清楚

  在确保可信的前提下,要在性能、功能、扩展性等方面做好权衡;慎重地定义我们的模块与接口,真正做到高内聚与低耦合;我们要遵循权限和攻击面最小化等安全设计原则,科学设计模块之间的隔离与接口,提升安全性;低阶架构与设计要遵循高阶的架构与设计原则,在充分理解原有架构与设计的情况下,持续优化;我们要熟悉各种设计模式,重用公共成熟组件和服务,避免重复劳动

  我们要重构腐化的架构及不符合软件工程规范和质量要求的历史代码。我们知道,再好的架构,其生命力也是有限的。随着时间的推移、环境的变化以及新技术、新功能特性的引入,架构也会腐化。面对腐化了的架构,要毫不犹豫地去重构它。同时主动以可信设计原则为导向,去重构不符合软件工程规范和质量要求的历史代码,提升软件架构的生命力

  我们都知道,没有万能的架构,只有适合当时需求,当时技术条件和人员的架构,时间推移了很多架构就满足不了要求了,就需要重构了!作为 80 后,小时候其实生活挺艰苦的,那时候我们穿衣服都讲究的是:“新三年,旧三年,缝缝补补又三年”,架构也一样嘛,不满足需求我们先修修补补,真要重构挑战还是不小的,但是不去做它会一直成为发展的一个障碍,这封信也算是推了一把:“面对腐化了的架构,要毫不犹豫地去重构它。”,当然你重构,也不要忘记“可信”这个根本目标:“同时主动以可信设计原则为导向”

  “我们要遵循权限和攻击面最小化等安全设计原则,科学设计模块之间的隔离与接口,提升安全性”

  这些年开发界一直有些不好的风气,就是都认为自己的技术是最牛的,写后端的看不上前端的,用 angular 的看不上 vue,写 PHP 的认为自己的语言是全世界最好的,开发的还看不上测试的。但是信中这一句话不要忽视呀:“软件技术是我们打造产品的基本工具”,技术只是工具,只是我们用来打造产品的工具

  “我们要深入学习架构与设计、编码、测试、安全、可用性、性能、维护性、体验等技术,并科学运用这些技术。”,既然技术只是工具,那么我们就没必要给自己设置各种技术壁垒障碍。如果开发就只学编码,测试就只学测试,认为安全那应该是搞安全的事,这样的话是非常不利于团体协作的,每个人都在一个领域能有深入的钻研,同时对其他领域有一定了解,对个人,对团队是非常有利的一件事。这样也不需要 DevOps 这种为了兼顾开发、测试、运维三种角色而存在的工种

  我们要遵守过程的一致性。遵守适用的法律法规、遵循业界共识的标准、规范,确保规范到实现的一致性、代码到二进制的一致性。架构要符合架构原则,设计要遵循设计模式,代码要符合编程规范,最终做到需求与实现一致,达成各项对客户的承诺。我们只有脚踏实地做好每一步,才能真正打造出可信的高质量产品

  一致性,“脚踏实地做好每一步”,还是有希望做到,“真正打造出可信的高质量产品”

  为此,我们要改变行为习惯,追求精品。我们要开放透明、积极和勇于揭示问题并主动推动改进。软件开发是一种创造性和艺术性的工作,需要充分发挥我们的聪明才智和潜力。我们要改变只重视功能结果、不重视代码质量的行为习惯,要严格遵守软件工程规范;改变被动的修修补补;改变碎片化知识获取,主动去学习提升并贡献经验、代码,形成共享知识库。我们需要改变的行为和习惯还有很多,对绝大多数人来讲都将是一个痛苦的转变过程,会脱一层皮,但我相信大家能够迎接这种挑战

  只重视功能结果、不重视代码质量” 。“功能实现完了就完事了,质量那是 QA 的事”,这种坏习惯不改质量是很难有保障的

  不遵守软件工程规范” 。软件工程的各种规范不是约束,也不是摆设,而是实实在在为了团队整体更好的协作。对于定好的规范,要严格执行,不合理的规范,也要提出来一起改进

  被动的修修补补” 。为了能继续凑合,继续修修补补,而没有考虑重构改进,也是一个不好的习惯

  碎片化知识获取,不主动去学习提升” 。在现在的信息时代,碎片化的知识获取是容易的,但是像软件工程这种知识,仅仅通过碎片化的学习还是不够的,必须的主动的,系统的去学习,虽然这个过程会很辛苦,但是是非常有必要的

  不愿意贡献经验、代码,不去形成共享知识库” 。很多人不愿意去分享知识和经验,有的是因为太懒,有的是觉得没什么好处。但是分享本身就是一个学习和提升的最好手段!知识库这种事不仅是对别人,对自己也是一个特别好的过程。 想象下你新加入一个团队,如果这个团队有很好的知识库,你可以通过知识库很快的上手工作,同样的,如果你把你的经验写到知识库,后面的新人也可以受益你的贡献

  “软件工程”和“质量工程”需要依靠架构技术,而不是依靠 CMM 和 QA 管理流程。一切工程问题,首先要思考能否通过技术解决,当前技术无法解决的问题,暂时由管理手段代劳,同时不停止寻找技术手段

  我们将全面强化以 Committer 角色为核心的代码审核和提交机制,代码经过更加严格和系统的审核才能合入版本。为此我们将建立一支更高水平的 Committer 角色群体,负责软件架构的看护、代码的审核和提交,整体保障合入代码的高质量。我们要变革考核机制,要让架构设计好、代码写得好的人脱颖而出,对编程能力不满足要求的人给予帮助和培训。但任何人如果编写的代码长时间不能合入版本,将会被团队抛弃