开发实践思考（六）
本篇接上一篇《开发实践思考（五）》，继续汇总日常总结点，每篇10个。
1. 奥卡姆剃刀原则
如无必要，勿增实体。如果一个现象，可以通过两种方法来解释，有简单的解释，也有复杂的解释，那么，选择简单易理解为好
2. 最小知识原则
每个模块只需要了解与当前模块紧密联系的模块接口，去掉无关紧要的依赖。它为设计带来两个好处：
- 更好的信息隐藏
- 更少的信息过载
3. 技术方案讨论
就某个问题，提出具体解决方案时，有以下几点注意：
- 方案个数要适合，1个太少，4个太多，最佳候选方案个数为2~3个。
- 列举出每个方案的优缺点以及适用场景，简要描述清楚
- 列举上述方案后，由上级来做最后的决定
- 一旦领导选定方案，那么需要通知全组人员，就该问题的解决方案达成共识，在后续落地中，小细节可以调整，但大方向不能偏
4. 对封装的进一步理解
封装，笔者认为当做聚合来理解更好，把数据和对数据的操作聚合到一起，把类型和对类型的转换聚合到一起，只对外暴露必要的数据。
当遇到重复逻辑时，可将操作中的变化部分抽离出来，当做参数传入，内部实现通用处理。聚合业务处理逻辑，通过将数据与处理数据的逻辑隔离开，使之更具有通用性。
5. 技术不是万能的
经过长期的开发工作，明白 "技术不是万能的"，这一客观事实。
笔者自己拒绝别人的能力还是不够，通过平时工作中细心观察周围同事，学习到如下方法，在此总结下：
总体思想：话不能说死，不要贸然给出承诺，凡事三思而后行。
- 这个需求能否实现，我要看下代码才知道。
- 这个需求不合理，我觉的对用户没价值。如果要上，请和领导再讨论下。
- 这个需求和之前的XX实现有冲突，如果这样做，那之前的XX流程就不再成立，你有考虑到这点吗？
- 这个需求改动涉及面太大了，不建议全部做。如果要上，要先限定范围，按重要性进行优先级排序，先做最重要的部分，其他的往后放。
6. 枚举变量命名
枚举变量的类型定义和内部成员定义使用相同的前缀说明，方便阅读和检查，以下载状态检测为例子：
enum DOWNLOAD_TASK_STATUS
{
DOWNLOAD_TASK_STATUS_NOEXIST = 0, // 下载任务不存在
DOWNLOAD_TASK_STATUS_STOP = 1, // 未开始或已停止
DOWNLOAD_TASK_STATUS_DOING = 2, // 正在下载
DOWNLOAD_TASK_STATUS_PAUSE = 3, // 暂停
DOWNLOAD_TASK_STATUS_FINISH = 4, // 已完成
DOWNLOAD_TASK_STATUS_WAITING = 5, // 等待
}
7. 期权业务知识
对于期权策略的编写，看了网上的众多介绍，介绍的书单很全很专业，但这些对工作上是否有帮助呢？
仔细想了下，受限于时间、业务范围以及知识结构，期权等衍生品涉及的知识太多，贸然通过各种书籍的识去打基础，一来耗时太久，二来目标不明确，估计效果不佳。
参照之前的学习方法，问题驱动型学习，先看代码，看到不同的知识点或者名词，再去查相关资料，查找过程收敛于该知识点即可，不要被旺盛的好奇心扰乱了自己的视线。搞明白一个知识点，好过囫囵吞枣看众多知识点，结果一团乱麻。
在搞清楚若干个知识点后，尝试寻找各个知识点的内在逻辑关系，通过思维导图等方式将其连接成线，最后结合立体的、完备的知识体系。这事儿快不得、急不得。
对于入门学习来说，知识是螺旋上升的，一下子学太多很容易遭受知识洪水而感早早放弃。
8. 只做必要的事
在自己能力范围以及能力边界上，只做必要的事。如果某项功能或者工作做了额外的事情，那么要从结果上尝试分离，职责内的和职责外，职责内的自己负责，职责外的要告知相关人员知晓变动以及可能的影响。
9. 状态的明确性
在代码的世界中，一切都要有明确定义，不应该存在模糊地带。例如，一个对象，要么已经初始化，要么未初始化，不应该存在初始化一半或者初始化1/3的情况，这种中间态是未定义的，一旦程序进入到这种状态，会发生意想不到的错误。
10. 偷懒心态
如果找到某种可行的方法，感觉心理上有种抗拒尽其他解决方法的思想。特别是在某个问题上困扰很久，之后找到某个方法可以解决，这种感觉就在黑暗的枯井中抓到了一根救命绳，抓到后就使劲往上爬，不会在寻找有没有其他逃生的通道。
这是一种偷懒心态。我们要承认这种心态是客观存在的，找到的某个方法，在没有和其他有效方法进行对比的前提下，是不能够认为是最佳方案。要多想想有没有其他可行的方案，找到几种方案后进行对比，根据具体情况选择最佳方案。这样，即使最终选择的方案就是最初找到的，我们也可以拍拍胸脯地说，用这个方案，而不是最初只找到这个方案时那种孤注一掷、小心翼翼的感觉。
眼光要高些，凡事多想几个方案，没坏处。
