这篇blog将一直持续的更新着。（10.23）

关于编写程序

1. 接到新需求不要立马开始写，思考时间要多于总开发时间的30%
   就算定了一个很少的期限，没几天就deadline，还是不要马上去动程序。
   （1）一定要 拿着需求的流程图，对着基础的代码一行一行的模拟，尤其是每一条判断语句，每一个关键的语句执行，触发条件、执行后的效果、可不可以优化等等。然后对于一些关键的步骤，最好先写写demo，向需求一方展示下效果O不OK。
   （2）然后对于模拟代码时的一些疑问（就是需求提的一些不完善或者不够好的地方），整理出来并分别提供至少一个解决方案。
   个人认为，能做好这些事情，反而能提高效率，而不是 more delay和 more bugs。
2. 多读源码，能懂一行是一行
   读源码是自虐的行为，但是有很多行为能够帮助源码的阅读。
   （1）跟着大佬解析源码，就是大佬的blog/视频看到哪一步，你也跟着读到哪一步，一些晦涩的地方大佬们都会讲出来的
   （2）从小的轮子读，比如加起来只有 四五个类的那种 做一个简单操作的 小轮子，里面也有很多可以学习的地方，自己也跟着做就更好，丰富自己的blog或者github。
   （3）学习设计模式对阅读源码很有帮助。
   读源码的目的是为了达到 面向源码编程，打一个比方：同样是写一篇英文作文，别人是零散的单词和从句的东拼西凑，而你是直接带着一本字典，谁的理解更深不言而喻。
3. 要有代码洁癖
   要养成code smell的习惯，致力编写优美的代码。如果还没有养成这个习惯，建议每天起来写代码之前，都读一下最下面的 code smell。

关于改BUG

1. 改bug有三种境界：
   第一种：错了哪里就改哪里。 这种对于开发效率是最低的。
   第二种：错了哪里，就把整个模块 这份代码可能出错的地方 检察一遍有没别的错误。 这个开发效率稍微好一点。
   第三种：错了哪里，基于第二种找出原因后，思考一开始为什么这么设计并记录下来，保证之后不再这个地方犯错。这样的思考对自己提高开发效率是最有帮助的。
2. 要做到阶段性的review代码，然后优化
   改bug的唯一目的是增强程序的健壮性。所以优化也是改Bug的一种。
   项目的收工并不代表之后不做这份代码了。做完后要找时间review一下代码，对 代码结构/用户反馈/或者自己的单元测试结果进行分析。自己主动的去优化。

提醒自己的话

1. 总是写自己会的代码，错误肯定会少，但是同时学到的东西也不会很多。
2. 如果自己不去努力的解决问题，那么自己也会成为团队里的问题。

Code Smell（代码坏味道）

1. Duplicated Code(重复的代码)
2. Long Method(过长方法)
3. Large Class(过大的类)
4. Long Parameter List(过长參数列)
5. Divergent Change(发散式修改)
   一旦须要改动，我们希望可以找到系统的某一点，仅仅在该处做改动。
6. Shotgun Surgery(霰弹式改动)
   假设须要改动的代码散布四处。你不但非常难找到它们。也非常easy忘记某个重要的改动。
7. Feature Envy(依恋情结)
   最根本的原则是：将总是一起变化的东西放在一块儿。［数据］和[引用这些数据]的行为总是一起变化的。
8. Data Clumps(数据泥团)
   这些[总是绑在一起出现的数据]真应该放进属于它们自己的对象中。
9. Primitive Obsession(基本类型偏执)
   大多数编程环境都有两种数据：结构类型让你将数据组织成有意义的形式；基本类型则是构成结构型的积木块。
10. Switch Statements(switch惊悚现身)
    面向对象程序的一个最明显特征就是：少用switch(或case)语句。
11. Parallel Inheritance Hierarchies(平等继承体系)
    在这样的情况下。每当你为某个class添加一个subclass，必须也为其它已实现的兄弟class对应添加一个subclass。
12. Lazy Class(冗赘类)
    假设一个class的所得不值其身份。它就应该消失。
13. Speculative Generality(夸夸其谈未来性)
    当有人说“噢，我想我们总有一天须要做这事”并因而企图以各式各样的挂勾和特殊情况来处理一些非必要的事情，这样的坏味道就出现了。
14. Temporary Field(令人迷惑的临时字段)
    在变量未被使用的情况下推測当初其设置目的，会让你发疯。
15. Message Chains(过度耦合的消息链)
    实际代码中你看到的可能是一长串getThis()或一长串暂时变量。採取这样的方式，意味客户将与查找过程中的航行结构紧密耦合。
16. Middle Man(中间转手人)
    你或许会看到某个class接口有一半的方法都托付给其他class，这样就可能是过度运用。
17. Inappropriate Intimacy(狎昵关系)
    继承往往造成过度亲热，由于subclass对superclass的了解总是超过superclass的主观愿望。假设你认为该让这个孩子独自生活了，请运用Replace Inheritance with Delegation让它离开继承体系。
18. Alternative Classes with Different Interfaces(异曲同工的类)
    假设两个方法做同一件事，却有着不同的签名式。
19. Incomplete Library Class(不完美的程序类库)
20. Data Class(纯稚的数据类)
    它们拥有一些字段，以及用于訪问这些字段的方法，除此之外一无长物。
21. Refused Bequest(被拒绝的遗赠)
    Subclasses应该继承superclass的方法和数据。但假设它们不想或不须要继承，又该怎么办呢？它们得到全部礼物。却仅仅从中挑选几样来玩！按传统说法，这就意味继承体系设计错误。
22. Comments(过多的注释)
    并不是不能写过多的注释，注释的对象是代码，但是代码糟糕所以才导致 注释写的篇幅过长