在我参与过的项目当中，有些为数百万人供应做事，有些在发布之前就发布失落败。我做过咨询顾问，还创办过自己的公司。我在开源项目、闭源项目和内部开源项目上花了很多韶光，从微掌握器到移动运用、桌面运用，再到云做事和无做事器架构。
我把过去 20 年积累的一些最为主要的编程原则总结如下。
不要纠结于开拓工具——不管是库、编程措辞还是平台。尽可能利用原生的构件。不要歪曲技能，也不要歪曲了问题本身。为要办理的问题选择得当的工具，否则你要为你所选择的工具重新安排你的事情。你写的代码不是给机器看的，而是给你的同事和未来的你看的（除非你写的是一次性代码或汇编代码）。写代码的时候要考虑一下低级开拓者，他们会把你的代码作为参考。精良的软件是协作开拓的结果。高效沟通，进行开放式的协作。信赖他人，并让他人也信赖你。尊重他人赛过尊重代码。以身作则，把你的追随者变成领导者。分而治之。为分离的关注点开拓单独的低耦合模块。进行单独的模块测试和集成测试。尽可能按照实际情形测试，同时也要测试到各种边界情形。不要把自己与代码捆绑在一起，要想办法让其他人也能修正你的代码或者添加新的功能，这样你才能更随意马虎脱身去参与其他项目，或者去其他公司。不要捆绑自己，否则你很难发展。安全性是分层的，每一层须要进行单独的评估，同时又与整体干系。风险是一个业务决策，与薄弱性和概率有直接的关系。每一个产品或组织都有不同的风险偏好（为了得到更大的收益，他们乐意承担风险）。常日这三个关注点之间存在相互冲突：用户体验、安全性和性能。要意识到每一行代码都有其生命周期，它们终极都会去世掉。有时候，一些代码会在发布之前就去世掉，以是要学会放手。代码可以分为三种：一种是核心代码，就像汽车的引擎，没有了它，产品就毫无意义；一种是必要的代码，就像是汽车的备胎，平时用得少，但一旦须要，它决定了系统的成败；一种是增值的代码，就像汽车的杯托，如果有那是再好不过，但如果没有也不会影响产品。不要把你的个人标识融入到代码里，人和代码该当是分离的。不要把其他人对代码的评价与你自身联系到一起，在评价他人的代码时也要十分谨慎。技能债务就像快餐一样，偶尔欠下一点技能债务是可接管的，但如果你习气了这样，它会毁掉你的产品（而且因此让你措手不及的办法）。在探求办理方案时，请按照这样的优先级进行决策：安全性 > 可用性（可访问性和用户体验）> 可掩护性 > 大略性（开拓者体验）> 简洁性（代码量）> 性能。但不能盲目照搬，而是要根据产品的特点进行取舍。你积累的履历越多，就越是能够在这些成分之间做出权衡。例如，在设计游戏引擎时，性能享有最高的优先级，但在开拓银行运用程序时，安全性则最为主要。拷贝粘贴是滋长 bug 的温床。对你所拷贝或导入的东西加以审查，bug 一样平常会藏身在繁芜性中。依赖项繁芜没有关系，但不能让它存在于代码中。不要只顾着写正常的代码，处理非常的代码也要好好写。让人们明白为什么会发生非常、如何检测到的以及若何办理。对所有的系统输入（包括用户输入）进行验证：尽早失落败，并尽可能从缺点中规复。我们要假设用户手里握着一把枪：你努力让用户输入一些其他的东西，而不是让他们的子弹射在你的脑门上。不要利用依赖项，除非利用它们的本钱比你自己写代码的本钱低很多。由于利用依赖项要导入、掩护、处理 bug，在必要的时候还要进行重构，这些都是本钱。阔别“炒作驱动开拓”，但你要去理解它们，做一些考试测验。走出舒适区，每天都要学习。把学到的东西分享出来。如果你以大师自居，就不是在学习。打仗更多的编程措辞、技能、文化，保持一颗好奇心。好代码不须要注释，而精良的代码供应了良好的注释，可以让任何一个原来没有参与代码演进、试错和需求过程的人更随意马虎阅读、修正它。只管即便避免利用重载、继续和隐式的智能特性。利用纯函数，它们更随意马虎测试和诊断，否则的话就利用类。实现不同功能的函数要利用不同的名字。在彻底理解问题之前不要急着写代码。花在谛听和理解问题上的韶光常日比花在写代码上的韶光要多。在写代码之前要先理解问题域。问题就像迷宫一样，你要循规蹈矩，反复进行“编码 - 测试 - 改进”，直到把问题办理为止。不要考试测验去办理不存在的问题。不要进行投契性编程。只有在确定代码确实须要具备扩展性之后才让代码具备可扩展性。常日情形下，当代码被扩展之后，你会创造问题会变得与原来认为的不一样了。大家一起开拓软件会更加有趣。建立可持续发展的社区。谛听，引发灵感，学习，分享。我并不是软件开拓方面的威信，但这些都是我一起走来总结出来的原则。我相信，20 年后，这些原则会发生变革，会变得更加成熟。
