关于提高编程思维与工作效率的总结（持续更新）

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

关于编写程序

1. 接到新需求不要立马开始写，思考时间要多于总开发时间的30%，即个人的方案评审期
   就算定了一个很少的期限，没几天就deadline，还是不要马上去动程序。
   （1）一定要 拿着需求的流程图，对着基础的代码一行一行的模拟，尤其是每一条判断语句，每一个关键的语句执行，触发条件、执行后的效果、可不可以优化等等。然后对于一些关键的步骤，最好先写写demo，向产品需求一方展示下效果O不OK。
   （2）然后对于模拟代码时的一些疑问（就是需求提的一些不完善或者不够好的地方），整理出来并分别提供至少一个解决方案。
   个人认为，能做好这些事情，反而能提高效率，而不是 more delay和 more bugs。
2. 多读源码，能懂一行是一行
   读源码是自虐的行为，但是有很多行为能够帮助源码的阅读。
   （1）跟着大佬解析源码，就是大佬的blog/视频看到哪一步，你也跟着读到哪一步，一些晦涩的地方大佬们都会讲出来的
   （2）从小的轮子读，比如加起来只有 四五个类的那种 做一个简单操作的 小轮子，里面也有很多可以学习的地方，自己也跟着做就更好，丰富自己的blog或者github。
   （3）学习设计模式对阅读源码很有帮助。
   读源码的目的是为了达到 面向源码编程，打一个比方：同样是写一篇英文作文，别人是零散的单词和从句的东拼西凑，而你是直接带着一本字典，谁的理解更深不言而喻。
   （4）对源码既定的流程，先思考一下，多问自己几个问题，再去阅读源码，效率特高
3. 要有代码洁癖
   要养成code smell的习惯，致力编写优美的代码。如果还没有养成这个习惯，建议每天起来写代码之前，都读一下最下面的 code smell。
4. 代入产品的思维编程
   因为我是一名前端开发人员，所以做的程序是直接呈现给用户的，我们在自测时最直观的感想其实就是用户的感想。“开发程序的时候我是程序员，自测时我就是用户”。这是一种把产品思维代入的编程。它会帮助我们更追求一些代码细节的东西。
   比如我们会自己会为负责的模块写一套专门界面显示工具，我们任何的数据带到这个工具里面， 我们都能看到其最直观的工作流程，比起凭空想象的模拟数据工作方式，这更便于我们修改工作流程，这样做更直接而且有据可查，直接提升用户体验。（而且在debug时，这样的效率比打断点、打log更高！）
5. 开发、学习时关掉自己的手机。

关于改BUG

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

关于需求评审、多方交接

1. 开发的任何细节都要有文档依据：
   大部分情况下，开发初期的需求文档并不是最终版本，而是会随着开发做一些小更新（小更新是Ok允许的，如果说开发还在大更新需求的话就是双方的严重失误（比如说更改逻辑））
   这导致开发时的一些细节，会觉得：这个地方需求会没有考虑到，但是又不影响主流程，所以会自己发挥。
   但这其实很不严谨，任何的逻辑以及细节都要在 流程图里面过。所以一定要提出来。商讨出解决方案后第一时间更新到需求文档或者开发文档，这样可以保证出现问题时，锅绝对不在你身上。
   （突然想到一个表情包，程序员最讨厌的四个事情：1.写文档 2.别人不写文档 3.写注释 4.别人不写注释， 人间真实）
2. 如果在需求评审时，只是重点考虑到这个功能能不能实现，那其实这个评审会其实还是会给以后自己留坑。应该在之上，考虑到研发的新功能是否会影响已有的功能，如果影响到，影响的部分该怎么处理。这才是需求评审会时更该注意的一点。功能能不能做这个问题，只要你别来个根据手机环境来改变App主题颜色，那tmd肯定能做啊。

提醒自己的话

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(过多的注释)
    并不是不能写过多的注释，注释的对象是代码，但是代码糟糕所以才导致 注释写的篇幅过长