良好的开发规范

随着系统复杂性的增加，系统中任何单个行为主体的自有模型的准确性都会迅速降低。

—Woods Theorem

我就直说了吧，我永远不会有一个完整的GitHub心智模型。它太庞大了，有太多的逻辑路径，坦率地说，花费过多的时间学习代码的所有部分，并不能使我的工作做得更好。而且，它可能明天就又变了。

因此，当我必须收集足够的上下文信息以实现下一个特性或Bug修复时，我会依赖于代码中已有构件的准确性，这些构件是在我之前从事这些工作的人留下的。

我花了很多时间来研究代码：运行git blame，查看过去的提交、有关问题，以及任何有助于我理解为什么某行代码这样写的信息。如果我看到一个难以理解的改动，提交信息是“WIP”，这就会变成效率杀手。

良好的软件开发规范意味着需要额外花一些时间来记录当前的上下文信息，这可能表现在：

·描述性的提交信息

○ 至少，做到每个提交信息都包含一个动词。有些团队甚至更进一步，要求每次提交都可以跟踪到问题编号。务必选择适合你的团队认知投资水平的方法；

·遵循语言和框架约定、可以表明意图的类名和方法名；

·单元测试带有有用的描述信息，使用符合实际的变量名和数据，而不是“foo”和“bar”这样的变量；

·在问题跟踪系统中就相关特性反复沟通，而不是在Slack DM和其他地方。今后，入职不满6个月的团队新成员将无法访问这些地方。

最后，良好的开发规范事关同理心。工件越整洁，团队成员就可以越快地了解上下文，花在上下文切换和探查上的认知精力也就越少。此外，这其实对未来的你自己也是有好处的。道德哲学的一个分支认为，未来的你是一个有道德权利主张的不同实体，我想说：推广这些开发规范后续一定会得到回报，特别是在凌晨3点有人因为你写的一行代码给你打电话时！