作为一个开发多年的程序员,写过太多的代码,也阅读过太多的代码.就代码本身而言,更多的是在业务逻辑身上.本来从0到1的过程,就着PM的产品文档,是写的非常流畅的.当然,从0到1的时候,好多公司总会压榨RD的开发时间,大家在经过数轮的battle之后,写代码仿佛就成了火急火燎的事情.今天,咱不说代码架构的问题,咱就只说代码注释的问题.
相信大家从网上也读过太多类似的文章,到底代码需不需要添加注释,或者什么添加注释的代码又是一种什么样的水平?我找几个常见的案例,给大家稍微提上这么几句.
如何看待程序员不写注释？
“几个月前，我写的代码只有我和上帝知道”
“现在，只有上帝知道了”
“不写注释就是害人害己，别人看不懂，过几天连自己也看不懂”
“好的代码就是最好的注释，我的代码可读性很好，没必要写注释”
“只要有完善的文档，代码本身就是注释”
自己写代码时：“我自己写的代码还要写注释？” 看别人的代码时：“卧槽这人居然不写注释？”
好了,言归正传.咱们继续说说代码注释相关的问题.
写代码需要写注释吗?为什么我的代码明明很好阅读,却还要写注释?
开篇咱就讲过,现在的代码更多的是业务逻辑,既然有产品文档,那我何必又要写注释呢?就我本人而言,觉得写注释的原因有以下几个方面:
1.需求文档不可控,需求文档多是PM操刀.作为RD,我们主攻代码,我们的代码最好可以可靠(就好像PM写需求文档一 样,永远要保持简洁高效,阅读方便).
2.注释可以让代码阅读更方便.不管阅读代码的人水平高低,阅读文字总会比阅读代码来得更快.
3.需求迭代,功能版本调整频繁,代码展示混乱,阅读困难.
4.代码封装或冗余或繁琐,没有注释读起来难如登天.
5.功能不确定,PM需求中包含众多ABTest,代码逻辑多样,后期删减方便.
6.写代码不光写给自己看,更要写给别人看.好注释更能节约时间,减少bug.
7.项目逐渐庞大,好的注释可以精准定位,快速上手.
好的注释应该是什么样的?
我觉得,阅读方便准确永远是第一位的!
1.大模块的注释
当我们写需求的时候,开发前先要捋清逻辑,将功能写到类的开头
2.方法封装的注释
方法的作用,传入的参数,返回的类型,是否废弃,后续替代都要写明白.
3.TODO的注释
功能未完成,代码又舍不得删,利用好TODO,加好日期,定期排查.
4.及时删除的注释
需求下线,代码修改,代码经常review,做好删减补称.
马上就要讲完了,其实程序员写注释就像我们日常吃饭喝水一样.事情做得板板正正的,对自己对他人都是一种享受.可能很多小伙伴没有学习过专业的代码规范,推荐大家去系统的学习一下,这些资料网上一抓一大把,我就不一一介绍了.链接也不给大家放了.当大家慢慢写习惯之后,不写注释才是浑身别扭的事情呢.最后希望大家养成写注释的好习惯,成为一名优秀的程序员!
