在此，先给出结论：代码须要注释。但是不是每行都须要注释，或者须要多少注释，我们会在接下来的文章中谈论这个问题。（文中的例子均为PHP代码）
首先，我们先谈论下代码即注释 的问题。我们先思考下，代码即注释的不雅观点是否精确。对付代码即注释，紧张有两个好处。 其一是在不写注释的情形下，避免了一定的事情量，这个事情量包含注释的编写，掩护以及注释规范的保持。在实际事情中，我们都碰着过注释和实际代码意图不一致的情形，这便是注释没有掩护好，为代码的掩护造成更多的包袱。 比如下面这个常常被用来被调侃的例子
<?php/ 获取来日诰日这个时候的韶光戳.// @return int 韶光戳./function getTomorrowTime(){ sleep(86400); return time();}复制代码
其二是代码即注释，能提高团队的代码命名、可读性等。对付一个有逼迫代码风格检讨、Code Review实行到位的团队来讲，推崇代码即注释，确实会强有力地推动代码的命名和可读性，提升编码能力。
从以上两点来讲，代码即注释的不雅观念是精确的，也确实能给团队带来收成。但是，在团队实践代码即注释，也是有前置条件的。
首先，团队必须是相对固定的，这里的相对固定是指团队成员不会常常性流动。一个团队要达到代码即注释的水平，是很难的，纵然你的团队是精英团队，每个人能力极强，但是大概率会有不同的技能背景，在认知上难免涌现差异，这里举几个例子：
当代码中，须要发送一个事宜时，有人喜好用dispatch，有人喜好用send。转换成布尔值，有人喜好 (bool) $var，有人则会用 !!$var参考以下代码片段<?phpfunction test() { if ($a > 0) { return 100 / $a; } return 0;}// vs function test() { return $a > 0 ? 100 / $a : 0;}
我们先不论谁好谁坏，这种不一致性是确实存在的。 要到达代码即注释，最主要的一点是你须要将团队成员的编码认知，基本拉到同一个水平，并且团队内部形成大家都认可的最佳实践。要做到这一点，须要团队永劫光的协作和磨合。 对付一个流动性大的团队，是无法做到这一点的，假设团队5个人，刚把大家的认知统一，结果走了3个人；补充的3个新人，还得重新去拉齐大家认知，职员再流动，再拉齐，永久达不到目标。以是对付流动性极高的团队，老诚笃实写注释是最好的选择。
其次，你得有拉齐团队认知的工具和文化。比如严格的Code Review，自动化的代码风格检讨等。一个Code Review 都做不好的团队，代码风格、逻辑实现千奇百怪，怎么能统一认知，怎么做到代码即注释呢。
总结一下，要在团队中实践代码即注释，首先得考虑团队的流动性、其次有没有干系工具和规范；对付一个新团队，纵然有条件，也要长期坚持不懈实行规范，建立文化，才能得以成功。
末了，在谈谈代码即注释还有一个弊端，在一些特定的场景下，代码中会包含一些隐蔽的逻辑，无法很好通过代码表达出来。对付不理解隐蔽逻辑的人来说，每每会缺点地利用该代码，造成Bug。
鉴于以上的缘故原由，加上海内这种为抢占市场快速产出而导致各处加班的环境，代码注释绝对是有必要的，至少试用于90%以上的团队。
代码注释写多少得当对付这个问题，我们方向于从三个情形考虑：
第一，你的团队是践行代码即注释的团队，并且做得还不错；对付这种情形，常规的代码注释可以省略，但是对付业务逻辑繁芜或者包含隐蔽逻辑的代码，这是须要注释的。
第二，你的团队有明确的注释规范；这种情形按团队规范来即可。
第三，你的团队没有良好代码的基因，不推崇代码即注释，也没有规范；这种情形下，团队卖力人须要评估，是制订一套注释规范，还是践行代码即注释。我们的建议一样平常都是先制订注释规范，由于注释规范实现相对付代码即注释，韶光和本钱都要小很多；注释规范落地后，再考虑代码即注释的问题。
末了，不管是写注释还是践行代码即注释，Code Review 都是担保代码质量(包括代码和注释本身)的主要工具。
