工程原则

除非有真正的理由，否则就选那件久经考验的工具。新奇是一笔税，每一位未来的贡献者都得缴——包括未来的你自己。把兴奋留给真正要解决的问题。

代码被阅读的次数是编写次数的十倍。一行“魔法”就是未来的一个 bug——写出一目了然的版本，给变量起个好名字，把类型留着，然后继续往前走。

大批量的改动会藏住大 bug。每天交付的改动，就是每天都在接受检验的改动。把流水线搭好，让一行的修复在午饭前就能上线到生产环境。

测试向每一位读者说明代码应该如何运行。要写读起来像规格说明的测试，而不是对实现细节的断言。

每一个死分支、每一个没人用的辅助函数、每一层包着包装器的包装器——统统删掉。我经手过最健康的拉取请求，代码行数都是净减少的。

每一个架构决策都在塑造团队的工作方式。选择那些能让新人快速上手、让归属清清楚楚、让周五下午风平浪静的抽象。

如果你看不到它在运行，你就并不真正掌控它。日志、指标、链路追踪——从第一天起就接好，而不是在第一次事故之后才临时补上。

Stack Overflow 是起点，不是终点。真相藏在库的源码里——读得越多，你解决之后每一个问题的速度就越快。

我最敬佩的工程师总是忍不住去东戳戳、西探探。每天留出一段受保护的时间，去学一点项目并不严格需要的东西。

对一个不是你写的系统做渗透测试，教会你的关于自己代码的东西，比任何一次代码评审都多。周六用攻击者的思维，周一工程师的思维才会更敏锐。