一位 20 年老程序员分享的 20 条编程经验火了：不要与工具作斗争等
展开全部
转载自it之家同名文章
一位 20 年老程序员分享的编程经验突然火了，在 Hacker News 上，一天之内就收获了 467 热度。
其实这篇帖子所包含的观点大都是编程圈子里较常见的概念，但是这些年来有的话题一直很具备争议性。对他的大多数经验，网友很赞同。比如：代码终究还是给人写的，注释是为了让未来的自己和其他同事能看懂
20 年浓缩成 20 条经验
1. 不要与工具作斗争
所谓工具，包括库、语言、平台等。尽可能多地使用原生的开发方式。这样可以保证程序或软件的数据都存在于本地，能够及时检索，保证程序或软件的合作速度和流畅度。不要被技术捆绑，也不要被问题捆绑。应该为工作选择合适的工具，而不是为了工具寻找合适的工作。
举个例子：编程实现在一个文件中找到给定单词出现的位置并统计出现次数。如果用 C++ 写的话需要 92 行代码，而使用 Python 的话只用 26 行代码就可以完成了。
由此可见，对于同一个问题，换一个工具也许可以简化编程，提高效率。
2. 写让人可以看懂的代码
程序员们不是为机器编写代码，而是为了同行们和未来的自己编写代码。写代码的终极目标往往是完成一个项目或给后来者作为参考。
3. 善于合作
任何重要且有价值的软件都是协作的结果，有效沟通和公开合作很重要。能用众智，则无畏于圣人矣。
4. 对各模块分而治之
编写相互联系却又彼此保持独立的单个模块。先分别测试每个部分，然后一起集成测试。既要保证测试接近实际，也要测试边缘实例。
6. 安全是分层的
分层安全是一种应用多种安全措施的实践，每一层都与前一层和下一层重叠，以创建一个安全控制网络，这些网络可以一起工作以保护技术系统。每一层都需要单独评估，但也需要与整体相关。
7. 代码也有生死
要认识到，每段代码都有一个生命周期，并且会最终失效。有时，一段代码甚至还没上线发布就被废弃了。程序员要学会放手，弄明白 4 类特征的区别，然后想清楚应该在哪些方面投入时间和精力：
核心：就像 汽车 的引擎。没有它，产品就没有意义。
必要之处：就像 汽车 的备用轮子。它很少被使用，但当需要时，它的功能决定了系统的成功。
附加值：就像 汽车 的杯座。有它很好，但产品没有它也完全可用。
独特卖点：人们应该购买你的产品而不是你的竞争对手的主要原因。
8. 保护好个人信息
程序员不要将个人身份信息附加到代码中，也不要把其他人的身份附加到他们的代码上。人是独立于他们的工作产出物之外的。不要把别对代码的批评当成是针对个人的，当然也在批评他人的代码时也要谨慎。
9. 尽量规避技术债务
技术债务是开发团队在设计或架构选型时，为了快速地解决问题，而采取的不规范的方案。偶尔的技术债务是可以接受的，但如果长期负债往往会快速地扼杀产品。
10. 可参考以下优先级
为解决方案做决定时，假设其他条件都是一样的，可以按照这个优先级：
安全性 > 可用性 (可访问性和用户体验) > 可维护性 > 简单性（开发人员体验 / DX）> 简短性（代码长度） > 性能
但是也不要盲目地遵循这个规则，还要考虑到产品的性质。例如，在设计 游戏 引擎时，性能是最重要的；但在创建银行应用程序时，安全性是最重要的因素。
11. 复制粘贴会带来 Bug
有时复制粘贴后，会出现 Bug，这个几乎无法避免。为了检查是否有问题，每次都需要搞明白复制过来的内容，并审核导入的内容。
12. 不要只为乐观场景写代码
还要写出好的错误提示，回答其为什么会发生，如何检测到它，以及如何解决它。
13. 尽量不要使用依赖库
若调用一个动态库 A 时，A 需要调用动态库 B，则 B 是 A 的依赖库。
尽量不要使用依赖库，除非导入、维护、处理边界情况时出现 Bug，或者当代码不满足需求时，重构的成本远远低于你拥有的代码。
14. 不要盲目跟风
可以去了解热炒的新技术，但不要被拽着走，要坚持自己对技术的品位。
15. 坚持学习
16. 最好的代码都有良好的注释
一些人认为，代码写的够好，就不用写注释了。但最优秀的的代码中往往都包含着良好的注释。这样，即使是没有经历过这段代码的调试、测验过程，且暂时不具备写出此代码能力的人都可以使用它。
可以说，未文档化的功能是不存在的功能，不存在的功能不该有代码。
17. 尽量避免重写、继承和隐藏信息
写纯函数 (Pure Function)。对于纯函数，相同输入总是会返回相同的输出，执行过程中不产生副作用，且不依赖于外部状态。它们更容易测试和推理。
在执行一个非纯函数时，除了得到函数的返回值以外，还在函数调用时产生了附加的影响，如：修改了全局变量的状态，修改了传入的参数等。
任何非纯函数都应该是类，任何具有不同函数的代码构造都应该具有不同的名称。
18. 弄清楚问题后再开始编程
面对一个问题，首先要弄清解决思路，再开始编程。在编程过程中还需要逐步经历“编码-测试-改进”周期，并不断深入 探索 ，直到完成。
19. 不要去解决不存在的问题
不要进行投机性编程。只有在确定代码将来会被扩展时，才去花功夫提高代码的扩展性。
因为当代码要被扩展时，有很大的可能性问题定义已经与代码初次编写时不同了。
20. 巧用社区、积极探讨
参考链接
[1]. https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c
[2]. https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22
一位 20 年老程序员分享的编程经验突然火了，在 Hacker News 上，一天之内就收获了 467 热度。
其实这篇帖子所包含的观点大都是编程圈子里较常见的概念，但是这些年来有的话题一直很具备争议性。对他的大多数经验，网友很赞同。比如：代码终究还是给人写的，注释是为了让未来的自己和其他同事能看懂
20 年浓缩成 20 条经验
1. 不要与工具作斗争
所谓工具，包括库、语言、平台等。尽可能多地使用原生的开发方式。这样可以保证程序或软件的数据都存在于本地，能够及时检索，保证程序或软件的合作速度和流畅度。不要被技术捆绑，也不要被问题捆绑。应该为工作选择合适的工具，而不是为了工具寻找合适的工作。
举个例子：编程实现在一个文件中找到给定单词出现的位置并统计出现次数。如果用 C++ 写的话需要 92 行代码，而使用 Python 的话只用 26 行代码就可以完成了。
由此可见，对于同一个问题，换一个工具也许可以简化编程，提高效率。
2. 写让人可以看懂的代码
程序员们不是为机器编写代码，而是为了同行们和未来的自己编写代码。写代码的终极目标往往是完成一个项目或给后来者作为参考。
3. 善于合作
任何重要且有价值的软件都是协作的结果，有效沟通和公开合作很重要。能用众智，则无畏于圣人矣。
4. 对各模块分而治之
编写相互联系却又彼此保持独立的单个模块。先分别测试每个部分，然后一起集成测试。既要保证测试接近实际，也要测试边缘实例。
6. 安全是分层的
分层安全是一种应用多种安全措施的实践，每一层都与前一层和下一层重叠，以创建一个安全控制网络，这些网络可以一起工作以保护技术系统。每一层都需要单独评估，但也需要与整体相关。
7. 代码也有生死
要认识到，每段代码都有一个生命周期，并且会最终失效。有时，一段代码甚至还没上线发布就被废弃了。程序员要学会放手，弄明白 4 类特征的区别，然后想清楚应该在哪些方面投入时间和精力：
核心：就像 汽车 的引擎。没有它，产品就没有意义。
必要之处：就像 汽车 的备用轮子。它很少被使用，但当需要时，它的功能决定了系统的成功。
附加值：就像 汽车 的杯座。有它很好，但产品没有它也完全可用。
独特卖点：人们应该购买你的产品而不是你的竞争对手的主要原因。
8. 保护好个人信息
程序员不要将个人身份信息附加到代码中，也不要把其他人的身份附加到他们的代码上。人是独立于他们的工作产出物之外的。不要把别对代码的批评当成是针对个人的，当然也在批评他人的代码时也要谨慎。
9. 尽量规避技术债务
技术债务是开发团队在设计或架构选型时，为了快速地解决问题，而采取的不规范的方案。偶尔的技术债务是可以接受的，但如果长期负债往往会快速地扼杀产品。
10. 可参考以下优先级
为解决方案做决定时，假设其他条件都是一样的，可以按照这个优先级：
安全性 > 可用性 (可访问性和用户体验) > 可维护性 > 简单性（开发人员体验 / DX）> 简短性（代码长度） > 性能
但是也不要盲目地遵循这个规则，还要考虑到产品的性质。例如，在设计 游戏 引擎时，性能是最重要的；但在创建银行应用程序时，安全性是最重要的因素。
11. 复制粘贴会带来 Bug
有时复制粘贴后，会出现 Bug，这个几乎无法避免。为了检查是否有问题，每次都需要搞明白复制过来的内容，并审核导入的内容。
12. 不要只为乐观场景写代码
还要写出好的错误提示，回答其为什么会发生，如何检测到它，以及如何解决它。
13. 尽量不要使用依赖库
若调用一个动态库 A 时，A 需要调用动态库 B，则 B 是 A 的依赖库。
尽量不要使用依赖库，除非导入、维护、处理边界情况时出现 Bug，或者当代码不满足需求时，重构的成本远远低于你拥有的代码。
14. 不要盲目跟风
可以去了解热炒的新技术，但不要被拽着走，要坚持自己对技术的品位。
15. 坚持学习
16. 最好的代码都有良好的注释
一些人认为，代码写的够好，就不用写注释了。但最优秀的的代码中往往都包含着良好的注释。这样，即使是没有经历过这段代码的调试、测验过程，且暂时不具备写出此代码能力的人都可以使用它。
可以说，未文档化的功能是不存在的功能，不存在的功能不该有代码。
17. 尽量避免重写、继承和隐藏信息
写纯函数 (Pure Function)。对于纯函数，相同输入总是会返回相同的输出，执行过程中不产生副作用，且不依赖于外部状态。它们更容易测试和推理。
在执行一个非纯函数时，除了得到函数的返回值以外，还在函数调用时产生了附加的影响，如：修改了全局变量的状态，修改了传入的参数等。
任何非纯函数都应该是类，任何具有不同函数的代码构造都应该具有不同的名称。
18. 弄清楚问题后再开始编程
面对一个问题，首先要弄清解决思路，再开始编程。在编程过程中还需要逐步经历“编码-测试-改进”周期，并不断深入 探索 ，直到完成。
19. 不要去解决不存在的问题
不要进行投机性编程。只有在确定代码将来会被扩展时，才去花功夫提高代码的扩展性。
因为当代码要被扩展时，有很大的可能性问题定义已经与代码初次编写时不同了。
20. 巧用社区、积极探讨
参考链接
[1]. https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c
[2]. https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
