关于提高编程思维与工作效率的总结

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

工作提效

1. 时间管理大师
   利用番茄工作法或类似方法，提高工作专注度，并且需要非常刻意的去练习，虽然这些方法不能适应到所有的情况，但是它们对每天工作的内容的的细致规划、以及频繁总结，都对工作提效起着很好的指导意义。本质上如下：

do {规划目标 + 专注完成} while (true)

2. 目标导向而非职责导向
   ①：职责导向：作为团队中的一员，完成团队交予的任务，即完成自身职位所应该完成的任务。
   ②：目标导向：为了触达目标，除了完成自身任务，也要向上、下管理
   两种导向有根本的区别，目标导向更能推动项目进行，在平时工作中，仅仅是职责导向，会被动、盲目，且最终可能达不到目标，而目标导向，可以把60分的事情，做到90分
3. 交流与沟通
   没有高效的沟通方式，因为每个人因为其局限性，都有自己不同的想法，即使在评审、会议中讨论了问题，也会有人不理解，并且不敢发言。
   所以需要有足够的耐心，来与任何人讨论问题，在时间充足的情况下，面对面把事情聊的水落石出，才是“高效的交流”方式。

关于编写程序

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

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