1.不要纠结于开发⼯具——不管是库、编程语⾔还是平台。尽可能使⽤原⽣的构件。不要歪曲 技术，也不要歪曲了问题本身。为要解决的问题选择合适的⼯具，否则你要为你所选择的⼯具重新安排你的⼯作。
2.你写的代码不是给机器看的，⽽是给你的同事和未来的你看的（除⾮你写的是⼀次性代码或汇编代码）。写代码的时候要考虑⼀下初级开发者，他们会把你的代码作为参考。
3.优秀的软件是协作开发的结果。⾼效沟通，进⾏开放式的协作。信任他⼈，并让他⼈也信任你。尊重他⼈胜过尊重代码。以身作则，把你的追随者变成领导者。
4.分⽽治之。为分离的关注点开发单独的低耦合模块。进⾏单独的模块测试和集成测试。尽可能按照实际情况测试，同时也要测试到各种边界情况。
5.不要把⾃⼰与代码捆绑在⼀起，要想办法让其他⼈也能修改你的代码或者添加新的功能，这样你才能更容易脱身去参与其他项⽬，或者去其他公司。不要捆绑⾃⼰，否则你很难成⻓。
6.安全性是分层的，每⼀层需要进⾏单独的评估，同时⼜与整体相关。⻛险是⼀个业务决策，与脆弱性和概率有直接的关系。每⼀个产品或组织都有不同的⻛险偏好（为了获得更 ⼤的收益，他们愿意承担⻛险）。通常这三个关注点之间存在相互冲突：⽤户体验、安全性和性能。
7.要意识到每⼀⾏代码都有其⽣命周期，它们最终都会死掉。有时候，⼀些代码会在发布之前就死掉，所以要学会放⼿。代码可以分为三种：⼀种是核⼼代码，就像汽⻋的引擎，没有了它，产品就毫⽆意义；⼀种是必要的代码，就像是汽⻋的备胎，平时⽤得少，但⼀旦需要，它决定了系统的成败；⼀种是增值的代码，就像汽⻋的杯托，如果有那是再好不过，但如果没有也不会影响产品。
8.不要把你的个⼈标识融⼊到代码⾥，⼈和代码应该是分离的。不要把其他⼈对代码的评价与你⾃身联系到⼀起，在评价他⼈的代码时也要⼗分谨慎。
9.技术债务就像快餐⼀样，偶尔⽋下⼀点技术债务是可接受的，但如果你习惯了这样，它会毁掉你的产品（⽽且是以让你措⼿不及的⽅式）。
10.在寻找解决⽅案时，请按照这样的优先级进⾏决策：安全性 > 可⽤性（可访问性和⽤户体 验）> 可维护性 > 简单性（开发者体验）> 简洁性（代码量）> 性能。但不能盲⽬照搬， ⽽是要根据产品的特点进⾏取舍。你积累的经验越多，就越是能够在这些因素之间做出权衡。例如，在设计游戏引擎时，性能享有最⾼的优先级，但在开发银⾏应⽤程序时，安全性则最为重要。
11.拷⻉粘贴是滋⽣bug的温床。对你所拷⻉或导⼊的东⻄加以审查，bug⼀般会藏身在复杂性中。依赖项复杂没有关系，但不能让它存在于代码中。
12.不要只顾着写正常的代码，处理异常的代码也要好好写。让⼈们明⽩为什么会发⽣异常、 如何检测到的以及怎样解决。对所有的系统输⼊（包括⽤户输⼊）进⾏验证：尽早失败， 并尽可能从错误中恢复。我们要假设⽤户⼿⾥握着⼀把枪：你努⼒让⽤户输⼊⼀些其他的东⻄，⽽不是让他们的⼦弹射在你的脑⻔上。
13.不要使⽤依赖项，除⾮使⽤它们的成本⽐你⾃⼰写代码的成本低很多。因为使⽤依赖项要导⼊、维护、处理bug，在必要的时候还要进⾏重构，这些都是成本。
14.远离“炒作驱动开发”，但你要去了解它们，做⼀些尝试。
15.⾛出舒适区，每天都要学习。把学到的东⻄分享出来。如果你以⼤师⾃居，就不是在学 习。接触更多的编程语⾔、技术、⽂化，保持⼀颗好奇⼼。
16.好代码不需要注释，⽽优秀的代码提供了良好的注释，可以让任何⼀个原先没有参与代码演进、试错和需求过程的⼈更容易阅读、修改它。
17.尽量避免使⽤重载、继承和隐式的智能特性。使⽤纯函数，它们更容易测试和诊断，否则的话就使⽤类。实现不同功能的函数要使⽤不同的名字。
18.在彻底了解问题之前不要急着写代码。花在倾听和了解问题上的时间通常⽐花在写代码上 的时间要多。在写代码之前要先了解问题域。问题就像迷宫⼀样，你要循序渐进，反复进 ⾏“编码 - 测试 - 改进”，直到把问题解决为⽌。
19.不要尝试去解决不存在的问题。不要进⾏投机性编程。只有在确定代码确实需要具备扩展 性之后才让代码具备可扩展性。通常情况下，当代码被扩展之后，你会发现问题会变得与 原先认为的不⼀样了。
20.⼤家⼀起开发软件会更加有趣。建⽴可持续发展的社区。倾听，激发灵感，学习，分享。
