写代码的时候应该想到的问题
代码好坏体现了个人以及公司对代码的准入标准, 标准越高, 对个人能力的提升也越大
这篇文章主要介绍自己在编写代码时想到的问题, 供大家交流参考
- 代码最终要给其它成员review, 所以commit时, 请把属于同一类的改动, 放到同一个commit下, 把不相关的改动, 放到别的commit下, 方便别人review 以及理解你的逻辑.
2.commit message 必须写到清清楚楚, 通常就三段
第一段: 简要介绍, 本次改动的类别, feat, style, doc, build ..., 以及简介
第二段: 介绍为啥要做这个改动
第三段: 请把你的需求单链接贴出来, 比如JIRA的链接
写清楚和详细的目的就是方便以后大家回滚代码或者review你的代码时, 保证准确.
3.push前, 请rebase master, 再push -f, 这样保证master是清晰的
以上是讲开发流程的, 下面说代码
写代码跟装修房子很多是相通的
1.明确职责
每个变量
a) 可见范围 - 你的变量是用来干嘛的, 需要公开, 私有，还是只给子类用?
b) 职责 - 你的变量名跟它的职责有关系吗？有的话，是对应的吗，命名是否合理, 这个变量是不是只跟一个功能有关?
c) 复用 - 你的变量应该是类级别的，还是实例级别的，应该被共享出来吗, 有没有其它库已经提供了类似变量，有必要定义这个变量吗？
每行代码
a) 你的这行代码是用来干嘛的, 是不是只做了一件事
b) 这行代码是否要在不同代码中共享
c) 有没有已经实现了类似功能的代码
每个函数
a) 职责 - 只做一件事
b) 复用 - 需要共享吗, 能用别人实现的东西吗?
c) 开闭 - 改动容易吗? 是不是开闭? hard code的代码能不能挪到配置文件里去?
d) 测试 - 容易写单元测试吗? 能不能测试
e) 异常 - 需要抛异常吗, 抛checked还是unchecked, 遇到异常需要处理吗, 是简单的记下log, 还是自己处理掉, 还是想封装下异常再抛, 还是啥都不管，让上一级帮我们处理? 为什么要这样做?
f) 日志 - 有需要打debug日志的地方吗? 有需要打error的地方吗? 日志级别, 日志格式, 日志的内容是不是有意义的? 你得保证维护的人看到日志就知道是啥意思
每个类
a) 是否职责单一
b) 是否可以复用, 是否复用别人
c) 是否开闭
d) 是否可测试, 容易测试
e) 异常处理的是否合理
f) 日志打的是否合理
每个package
每个project
