工程习惯、质量与团队 · 综合
命名、结构，以及可以再回来的代码
一句话： 代码被读的次数远多于被写的次数——所以一个准确的名字和一个可预测的结构，比任何巧妙都值钱。
命名
名字要用业务领域的语言说明「这个东西做什么」，而不是「它怎么实现的」。一个需要注释才能看懂的名字就是一个坏名字。
保持一致：整个系统里同一个概念用同一个词，包括数据库和界面。同一样东西有两个名字，是bug的长期来源。
结构
按业务领域组织，而不是按文件类型。一个包含所有与订单相关内容的「订单」目录，比按分层拆开的目录更容易导航。
守住边界：一个模块通过明确的接口访问另一个，而不是通过它的内部实现。在一个系统内部守住的边界，正是日后需要时能把它拆开的前提。
简单
偏好无聊的代码。在还没出现三个真实用例之前就造出来的抽象，几乎总是错的，而且删掉它比加上它更难。
深入一层
当代码难以测试时，这几乎总是「依赖和逻辑纠缠在一起」的信号。与其加更多mock，不如把依赖注入进去——测试会变简单，结构也会同时变好，而这是「设计需要修正」最可靠的信号之一。