20年老码农分享20条编程经验你pick哪些？

　　

　　任何重要且有价值的软件都是协作的结果，有效沟通和公开合作很重要。能用众智★◆◆★■★，则无畏于圣人矣。

　　任何非纯函数都应该是类★◆，任何具有不同函数的代码构造都应该具有不同的名称。

　　一个程序员不要成为那位唯一明白某段代码的人。可以对自己的原创代码进行优化■◆■★，以便人们找到修复Bug的方式◆■★，和向代码添加功能的方法■★★。

　　一些人认为，代码写的够好■★■◆◆◆，就不用写注释了。但最优秀的的代码中往往都包含着良好的注释。这样，即使是没有经历过这段代码的调试、测验过程，且暂时不具备写出此代码能力的人都可以使用它。

　　这个问题看来不会有确定的答案了★◆，不过这篇经验分享整体上还有更多有价值的观点◆★★★。

　　要认识到，每段代码都有一个生命周期■★★◆■★，并且会最终失效★★◆★。有时◆■，一段代码甚至还没上线发布就被废弃了。

　　本文为澎湃号作者或机构在澎湃新闻上传并发布，仅代表该作者或机构观点■■◆，不代表澎湃新闻的观点或立场◆★■■■，澎湃新闻仅提供信息发布平台。申请澎湃号请用电脑访问。

　　合作完成一个程序或软件往往更有趣■■★。许多程序员包括技术大牛们都会在一些专业论坛（如Github■■★★◆、Stackoverflow等）上分享自己的原创代码，供他人参考◆■★■★、提建议以及修复Bug◆■◆◆■。

　　职业生涯上从研究员、架构师一直干到过CTO★◆■★◆，另外也当过技术产品经理，技术指导◆★，老师等角色■■◆★★◆，可谓经验丰富■■。

　　不要被技术捆绑，也不要被问题捆绑。应该为工作选择合适的工具，而不是为了工具寻找合适的工作■★◆◆★。

　　安全性 可用性(可访问性和用户体验) 可维护性 简单性（开发人员体验/DX） 简短性（代码长度） 性能

　　技术债务是开发团队在设计或架构选型时★◆■，为了快速地解决问题，而采取的不规范的方案。偶尔的技术债务是可以接受的◆■★，但如果长期负债往往会快速地扼杀产品◆★■。

　　还要写出好的错误提示，回答其为什么会发生，如何检测到它，以及如何解决它。

　　不要进行投机性编程★★。只有在确定代码将来会被扩展时★■，才去花功夫提高代码的扩展性◆★◆■★■。

　　有时复制粘贴后，会出现Bug，这个几乎无法避免。为了检查是否有问题，每次都需要搞明白复制过来的内容，并审核导入的内容★■◆。

　　因为当我把一个问题分解成可编码的组件时，我学到了很多◆◆■■◆；在实际实现这些部分的过程中，我经常发现边缘情况或未定义的情况；现实情况下，真正的问题是什么★■★★◆■，通常在开始并不清楚★■■■★◆。

　　程序员要学会放手，弄明白4类特征的区别◆■，然后想清楚应该在哪些方面投入时间和精力：

　　必要之处：就像汽车的备用轮子。它很少被使用，但当需要时，它的功能决定了系统的成功。

　　程序员们不是为机器编写代码，而是为了同行们和未来的自己编写代码■■■。写代码的终极目标往往是完成一个项目或给后来者作为参考★★◆★。

　　分层安全是一种应用多种安全措施的实践，每一层都与前一层和下一层重叠，以创建一个安全控制网络，这些网络可以一起工作以保护技术系统。每一层都需要单独评估，但也需要与整体相关。

　　因为当代码要被扩展时★★■◆◆，有很大的可能性问题定义已经与代码初次编写时不同了。

　　编写相互联系却又彼此保持独立的单个模块★◆★★■◆。先分别测试每个部分，然后一起集成测试。既要保证测试接近实际★★，也要测试边缘实例★★◆★◆★。

　　程序员不要将个人身份信息附加到代码中■★★■◆，也不要把其他人的身份附加到他们的代码上◆■★。

　　面对一个问题，首先要弄清解决思路■■★◆◆■，再开始编程■◆■★。在编程过程中还需要逐步经历 ◆■◆■“编码-测试-改进◆■■★■★” 周期★◆■◆■，并不断深入探索，直到完成。

　　在执行一个非纯函数时，除了得到函数的返回值以外，还在函数调用时产生了附加的影响◆★，如：修改了全局变量的状态◆★★，修改了传入的参数等。

　　人是独立于他们的工作产出物之外的。不要把别对代码的批评当成是针对个人的，当然也在批评他人的代码时也要谨慎■■■。

　　但是也不要盲目地遵循这个规则，还要考虑到产品的性质。例如，在设计游戏引擎时，性能是最重要的；但在创建银行应用程序时★★，安全性是最重要的因素◆■◆。

　　对他的大多数经验★◆★■◆◆，网友很赞同★★★■◆。比如★■：代码终究还是给人写的◆◆★，注释是为了让未来的自己和其他同事能看懂。

　　尽可能多地使用原生的开发方式。这样可以保证程序或软件的数据都存在于本地，能够及时检索，保证程序或软件的合作速度和流畅度。

　　不过针对有的观点，大家各执己见■◆。最为突出的是下面这条，网友们对此讨论了60多楼◆★◆■◆★：

　　尽量不要使用依赖库，除非导入、维护◆■■★◆、处理边界情况时出现Bug★◆， 或者当代码不满足需求时，重构的成本远远低于你拥有的代码。

　　写纯函数(Pure Function)。对于纯函数◆★■★◆◆，相同输入总是会返回相同的输出★■■◆，执行过程中不产生副作用，且不依赖于外部状态■◆■★。它们更容易测试和推理。

　　风险是一种商业决策◆★■■■◆，与脆弱性和概率有直接关系。每个产品或组织都有不同的风险偏好，通常这三个关注点会相互冲突：用户体验、安全性和性能★◆■★■。

　　大体上同意，但我发现要真正完全理解一个问题，还是至少要先写一个解决方案。

　　但也有一些网友认为：对于小型的◆■★■■、偏算法的问题，先在纸上或脑海中过一遍，比上来就写代码有效率的多。

　　其实这篇帖子所包含的观点大都是编程圈子里较常见的概念■★★◆◆◆，但是这些年来有的话题一直很具备争议性。

　　一位20年老程序员分享的编程经验突然火了★■，在Hacker News上，一天之内就收获了467热度。