写点什么

20 年老程序员告诉你的 20 条编码原则

2020 年 3 月 22 日

20年老程序员告诉你的20条编码原则

我从 1999 年就开始了编程生涯,到今年已经有 20 多年了。我先是从 Basic 开始,很快转到了 Pascal 和 C 语言,然后又学习了面向对象编程语言 Delphi 和 C++。2006 年,我开始使用 Java,2011 年开始使用 JavaScript。我参与过各个行业的软件开发,从机器人、金融科技、医疗到媒体和通信。我还担任过研究员、CTO、TPM(技术产品经理)、老师、系统架构师和技术负责人,但不管怎样,我一直都在编程。


在我参与过的项目当中,有些为数百万人提供服务,有些在发布之前就宣告失败。我做过咨询顾问,还创办过自己的公司。我在开源项目、闭源项目和内部开源项目上花了很多时间,从微控制器到移动应用、桌面应用,再到云服务和无服务器架构。


我把过去 20 年积累的一些最为重要的编程原则总结如下。


  1. 不要纠结于开发工具——不管是库、编程语言还是平台。尽可能使用原生的构件。不要歪曲技术,也不要歪曲了问题本身。为要解决的问题选择合适的工具,否则你要为你所选择的工具重新安排你的工作。

  2. 你写的代码不是给机器看的,而是给你的同事和未来的你看的(除非你写的是一次性代码或汇编代码)。写代码的时候要考虑一下初级开发者,他们会把你的代码作为参考。

  3. 优秀的软件是协作开发的结果。高效沟通,进行开放式的协作。信任他人,并让他人也信任你。尊重他人胜过尊重代码。以身作则,把你的追随者变成领导者。

  4. 分而治之。为分离的关注点开发单独的低耦合模块。进行单独的模块测试和集成测试。尽可能按照实际情况测试,同时也要测试到各种边界情况。

  5. 不要把自己与代码捆绑在一起,要想办法让其他人也能修改你的代码或者添加新的功能,这样你才能更容易脱身去参与其他项目,或者去其他公司。不要捆绑自己,否则你很难成长。

  6. 安全性是分层的,每一层需要进行单独的评估,同时又与整体相关。风险是一个业务决策,与脆弱性和概率有直接的关系。每一个产品或组织都有不同的风险偏好(为了获得更大的收益,他们愿意承担风险)。通常这三个关注点之间存在相互冲突:用户体验、安全性和性能。

  7. 要意识到每一行代码都有其生命周期,它们最终都会死掉。有时候,一些代码会在发布之前就死掉,所以要学会放手。代码可以分为三种:一种是核心代码,就像汽车的引擎,没有了它,产品就毫无意义;一种是必要的代码,就像是汽车的备胎,平时用得少,但一旦需要,它决定了系统的成败;一种是增值的代码,就像汽车的杯托,如果有那是再好不过,但如果没有也不会影响产品。

  8. 不要把你的个人标识融入到代码里,人和代码应该是分离的。不要把其他人对代码的评价与你自身联系到一起,在评价他人的代码时也要十分谨慎。

  9. 技术债务就像快餐一样,偶尔欠下一点技术债务是可接受的,但如果你习惯了这样,它会毁掉你的产品(而且是以让你措手不及的方式)。

  10. 在寻找解决方案时,请按照这样的优先级进行决策:安全性>可用性(可访问性和用户体验)>可维护性>简单性(开发者体验)>简洁性(代码量)>性能。但不能盲目照搬,而是要根据产品的特点进行取舍。你积累的经验越多,就越是能够在这些因素之间做出权衡。例如,在设计游戏引擎时,性能享有最高的优先级,但在开发银行应用程序时,安全性则最为重要。

  11. 拷贝粘贴是滋生 bug 的温床。对你所拷贝或导入的东西加以审查,bug 一般会藏身在复杂性中。依赖项复杂没有关系,但不能让它存在于代码中。

  12. 不要只顾着写正常的代码,处理异常的代码也要好好写。让人们明白为什么会发生异常、如何检测到的以及怎样解决。对所有的系统输入(包括用户输入)进行验证:尽早失败,并尽可能从错误中恢复。我们要假设用户手里握着一把枪:你努力让用户输入一些其他的东西,而不是让他们的子弹射在你的脑门上。

  13. 不要使用依赖项,除非使用它们的成本比你自己写代码的成本低很多。因为使用依赖项要导入、维护、处理 bug,在必要的时候还要进行重构,这些都是成本。

  14. 远离“炒作驱动开发”,但你要去了解它们,做一些尝试。

  15. 走出舒适区,每天都要学习。把学到的东西分享出来。如果你以大师自居,就不是在学习。接触更多的编程语言、技术、文化,保持一颗好奇心。

  16. 好代码不需要注释,而优秀的代码提供了良好的注释,可以让任何一个原先没有参与代码演进、试错和需求过程的人更容易阅读、修改它。

  17. 尽量避免使用重载、继承和隐式的智能特性。使用纯函数,它们更容易测试和诊断,否则的话就使用类。实现不同功能的函数要使用不同的名字。

  18. 在彻底了解问题之前不要急着写代码。花在倾听和了解问题上的时间通常比花在写代码上的时间要多。在写代码之前要先了解问题域。问题就像迷宫一样,你要循序渐进,反复进行“编码 - 测试 - 改进”,直到把问题解决为止。

  19. 不要尝试去解决不存在的问题。不要进行投机性编程。只有在确定代码确实需要具备扩展性之后才让代码具备可扩展性。通常情况下,当代码被扩展之后,你会发现问题会变得与原先认为的不一样了。

  20. 大家一起开发软件会更加有趣。建立可持续发展的社区。倾听,激发灵感,学习,分享。


我并不是软件开发方面的权威,但这些都是我一路走来总结出来的原则。我相信,20 年后,这些原则会发生变化,会变得更加成熟。


英文原文


My guiding principles after 20 years of programming


2020 年 3 月 22 日 08:549302
用户头像
小智 InfoQ 主编

发布了 398 篇内容, 共 309.0 次阅读, 收获喜欢 1724 次。

关注

评论 9 条评论

发布
用户头像
香港IT經理完全不會編程, 更加推廣"編程沒用說", "PM不需要編程說"等等邪說
2020 年 03 月 31 日 19:35
回复
用户头像
尽量避免使用重载、继承和隐式的智能特性. 这个也要分场合的吧,合理的设计,加上规范的命名,我觉得有时候也能帮助我们事半功倍的 。
2020 年 03 月 30 日 15:19
回复
我认为都没有问题。其实就是阶段性观点,有点小成的人到了看山不是山的境界,但总会到最后一个看山还是山的境界,返璞归真。最后看开了,别搞什么花里胡哨的东西,哈哈。
2020 年 03 月 31 日 11:21
回复
用户头像
都是大实话,赞!
2020 年 03 月 29 日 00:23
回复
用户头像
受用
2020 年 03 月 28 日 21:01
回复
用户头像
受用。
2020 年 03 月 27 日 00:00
回复
用户头像
身有体会
2020 年 03 月 26 日 13:33
回复
用户头像
真的很不错
2020 年 03 月 25 日 15:22
回复
用户头像
受益匪浅。
2020 年 03 月 23 日 08:42
回复
没有更多了
发现更多内容

【第十周】模块分解

云龙

架构1期 第十周作业

haha

架構師訓練營 week10 作業

ilake

动态规划解决爬楼梯算法,彻底搞懂AppStore证书体系、彻底搞懂控制反转IoC,依赖注入DIP, John 易筋 ARTS 打卡 Week 28

John(易筋)

ARTS 打卡计划 动态规划解决爬楼梯 AppStore证书体系 控制反转IOC 依赖注入DIP

极客时间架构师培训 1 期 - 第 10 周作业

Kaven

Week 10 作業

Christy LAW

架构师训练营 - 第十周总结

一个节点

极客大学架构师训练营

Python进阶——什么是迭代器?

Kaito

Python

极客时间架构师训练营 1 期 - 第 10 周总结

Kaven

架构师训练营第六周作业2

韩儿

模块拆分第十周作业「架构师训练营第 1 期」

天天向善

南海将打造“区块链+”金融科技产业高地

CECBC区块链专委会

区块链 金融

【第九周】性能优化(三)

云龙

区块链将如何改变住房市场

CECBC区块链专委会

区块链 住房记录

微服务手册:API接口9个生命节点,构建全生命周期管理

互联网应用架构

微服务 APi设计 API网关

第10周 作业1

Yangjing

极客大学架构师训练营

架构师训练营第 1 期 - 第 10 周学习总结

Anyou Liu

极客大学架构师训练营

架构师训练营第六周作业1

韩儿

架構師訓練營第 1 期 - 第 10 周總結

Panda

架構師訓練營第 1 期

深入掌握底层源码常见的 CAS 原子编程

源码兴趣圈

架构 CAS

第10周 作业2

Yangjing

极客大学架构师训练营

第五周作业

Jack

架构师训练营第 1 期 -- 第十周学习总结

发酵的死神

极客大学架构师训练营

Week 10 學習總結

Christy LAW

架构师训练营第 1 周学习总结

Binary

【第九周】课后作业

云龙

架构师训练营第十周作业

听夜雨

极客大学架构师训练营

架构师训练营 - 第十周作业

一个节点

极客大学架构师训练营

第六周作业

Jack

架构师训练营第十周总结

听夜雨

极客大学架构师训练营

架構師訓練營 week10 總結

ilake

20年老程序员告诉你的20条编码原则-InfoQ