【研发效率】关于文档

研发过程中，文档很重要，但更重要的可能是「惯性思维」

开发到底要不要写文档（注释），要写多少文档，要怎么写文档，想必在大家工作的各个阶段都会有不同的体会，不同人也会有不同的意见。

我是支持多写文档的，但是文档也有个弊端，就是不容易做到实时更新，代码即文档这个说法很酷，但是实际操作下来，并没有想象中这么容易的，都要耗费时间去维护的。

另外就是不同的同学写文档的风格不一样，有人喜欢用富文本，有人喜欢用 Markdown，有人喜欢用 tab 有人喜欢用空格，有人经常不注意换行的行数和格式，有人写文档写的很随意，觉得写了就万事大吉了，而大多数人都对自己的文档很有信心，都觉得自己写的很满了，写的很好了，看不懂都是读者的问题…我觉得这时候大家要有点同理心，你去读读其他人写的文档，看看是不是都完全看懂了。因为文档更新不及时，或者一些其他原因，很多时候看其他人的文档，并不能让我从0到100，很多时候能到10就不错了。

所以这里我提一个说法，就是大家在重视文档的同时，不要忘记我们开发的「惯性」。能来腾讯工作的各位开发大佬，多少都有点开源社区的经验，我工作中会经常将这些开源社区的习惯带到工作里的。举个简单的例子，按「惯性思维」来说，我们的 Git 仓库是最好不要留太多分支，甚至不能让每个人都有创建分支的权限，控制一下分支的数量，第一可以减少 .git 的大小，第二可以不让其他同学看的眼花缭乱，有时候分支命名过于接近，很容易就采坑了。那么如果这个是共识，那就大家一起带到工作来，大家一起好好维护 Git 仓库的分支，merged 后的分支，记得删除，分支命名也不要过于随意。

工作时，尽量用所谓的「惯性思维」或者「大众思维」去工作，不要在工作和工程上制造太多潜规则，越多的潜规则，就需要越多的文档去解释和说明，久而久之，这些就会变成技术债，船大难掉头，如果一开始就注意到这些问题，也不至于到后面经常出去救火的名场面了。