最近重构代码，又赶上这个分享，实在太巧了，听完了就觉得刚写好的代码又要改了。
易于维护的代码
一、高内聚
内聚：一个模块只做一件事
1、功能单一
2、用数据描述事物
3、对象只修改可控数据
4、数据采集和适配要在外层
最开始重构的时候就犯了这个错误，把适配放在内层来进行。即使用函数封装分开了，看似符合在外层的要求，但非常别扭
这个需求是在某组件执行之前先找一下当前状态。
最开始的想法是执行的时候检查一遍，因为可能因为某些模块的不同状态导致参数不同，即要执行的不同。
后来发现这么写太别扭了，我在实例化这个组件的时候要适配很多规则，并且这不应该是组件来干的事儿。
于是，改成了每当某些模块的不同状态变化时就更新一下当前状态，使影响组件的关键状态随时都是最新的
然后执行这个组件的时候，只要获取这一状态就好。
虽然执行的代码次数其实是一样的，但写的时候逻辑就不那么纠结了，组件内部很干净。
二、低耦合
耦合：高正交性
1、定义标准数据格式。
2、建立对象间通信机制。
听完之后改的就是这个。
一直听说是 模块间用广播，组件间用自定义事件
我重构完的代码虽然可用，但基本上是句柄调用，并且组件间广播泛滥。
之前就因为广播使用不当出了好多bug
这次终于想通了，把纠结的通信和也没那么方便的句柄调用统统改成了自定义事件：
内部的组件不接受广播，只在controller里接受，并由controller找到对应的支付方式，执行对应的方法，内部组件的调用执行采用用自定义事件。
这样多种并列的支付方式可以各干各的，不会因为大家都注册了广播，结果一个变大家都变，虽然从效果上没差别（因为其他都隐藏了），但这是不科学的，需要写很多适配来达到切换时的和谐。
逻辑上一下子就清晰了很多呢。
3、系统之间时数据传递。
三、逻辑清晰
1、不过早的做逻辑的抽离封装。
2、避免过细分层。
3、拿不准就穷举。
4、协议的设计要明确。
四、易于阅读
1、80列。
2、注释what不注释how。
我一般都注释what & why 相当啰嗦
3、单条语句不要过于复杂。
4、文件名与命名空间对应。
5、不编写超大文件。
记于2013年10月17日 EOF
点击评论或查看评论。