修改代码的艺术
今天所写的每一行代码都可能会成为明天的历史包袱
个人意见
可以在代码的复用性上做考量，尽量使得代码量减少
修改代码最核心的还是基于原有需求拓展新业务
修改任何代码都有两种策略
避开原有逻辑，新开一份逻辑，注意要完全避开
理解原有逻辑之后，在业务里做融合
子主题 4
原则
做完是第一位，做完了再花点心思来做优化
一次修改只针对一个需求，即使能够做到同时修改两个，也尽量不要那么做
可能一个需要上，另外一个不需要
出错误的时候无法定位是哪个需求的问题
所有的改动都是在预期以内的，除了通知测试与客户之外，也要自己留下记录
唯一真正好的注释是你想办法不去写的注释
思考
重复的代码到底有没有必要修改
当你热情地消除代码中的重复时，就会惊讶地发现，设计会自己浮现出来。
消除重复是锤炼设计的强大手段，它不仅能让设计变得更灵活，还能令代码修改更快更容易。
对侵入性的理解
注释
使用恰当的注释
没必要注释的地方写注释会破坏我们对代码的专注
一个逻辑里里程碑式的逻辑不仅要抽取，也要说明
注释要从更高层次的逻辑出发，而不是就事论事
如果有必要注释，请注释意图（why），而不要去注释实现（how)，大家都会看代码
统一标记--团队的任何成员都能轻松上手
TODO 待处理的问题
FIXME 已知有问题的代码
HACK 不得不采用的粗糙的解决方案
没必要写注释的地方
逻辑很简单，或者很简短
git做了很多工作，重复的不要做，比如注明代码修改的时间
html页面的注释
子主题 4
案例
常量要加注释
精选一个例子做输入输出
注释掉的代码--我个人觉得还是有保留的必要，关键是要说明改动的原因
警示性的注释也是很有必要的
子主题 4
命名
官方名称
设计模式，学术名称
力求使用更加准确的名称
比如downLoad/fetch替换get
具体而不是空泛
长名称远比短而让人费解好，具体来说写长名称的方法有
带上作用域
带上功能
使用官方定义的，常见的名称，如listener，intercept，constant
使用自己的理解
fetchGood，fetchGoodList，downloadReport
带上重要的细节，比如单位ms
注意：到底要不要具体取决于功能，功能越抽象，名称越短
注意，函数可能存在的副作用应尽可能在名称中表现出来
方法
别返回null
别传入null
函数的功能尽可能专一
如果即使专一，代码量依旧很庞大，说明对业务的拆分粒度有问题
单个函数的长度在200以内都比较合理，太长会给看的人比较大的压力
公共函数调用私有函数
参数
理想的方法应该是零参数？
异常
对异常的处理要看需求
因为页面是会有规定的返回，所以在最后一步的异常抛出可以使用固定格式的异常
总的来说，异常一定要在业务处理的过程中，留下足够多的异常日志信息来帮助定位问题
并发
分离并发相关代码与其它代码
严格限制对可能被共享的数据的访问
避免使用一个共享对象的多个同步方法
保持同步区域微小，尽可能少设计临界区
单元测试
测试的目的是达到稳定的结果
测试的覆盖率问题
通常来说，越全面的覆盖率，需要花的时间越多，后10%的覆盖率所花的时间>前90%
平心而论，测试代码写得不好，那就会花大量时间反复写测试代码，不好的测试代码自己都不会去看一眼
代码结构
单个代码块的长度不要超过200，尽量将长逻辑抽出来，思路会更清晰 关系密切的代码要放在一起 变量尽量在使用处附近 巧妙使用三元减少代码量
