引用链接：
https://medium.com/swlh/40-tips-that-will-change-your-coding-skills-forever-bf9d6b936ccc
https://xiaolong.li/2019/11/24/A-Solid-Guide-to-SOLID-Principles-in-Java/
https://www.javazhiyin.com/33854.html
https://xdrush.github.io/2016/04/24/Java%E8%BF%9B%E9%98%B6%E4%B9%8BSOLID%E5%8E%9F%E5%88%99/
https://insights.thoughtworks.cn/what-is-solid-principle/
一、40条编程小技能
或许，通过以下 40 个小贴士，你可以提升自己的编程技能。
1. 将大块代码拆分成函数。
2. 下班的时候还有问题没解决，请关上电脑，明天再看。
3. YAGNI 原则（你不会需要它）：只写别人要求你写的功能。不要预测未来，只需要尽可能快地完成开发。只编码解决当前问题最必要的部分。
4. 你不需要什么都懂，也不需要了解所有框架。最棒的事情莫过于打好基础。在开始使用一个框架前先深入了解这门语言，学习基础的事项（如 SOLID 原则），或者如何写出干净的代码。
5. KISS 原则：KISS（保持简单和愚蠢）原则表明，大多数系统保持简洁而非复杂化，就可以运行得很好。尽管这很符合逻辑，但有时候却很难做到。
6. 不要想太多。
7. 如果你和一个问题或 bug 斗争了太长时间，先离开一会儿，等下再回来。通常，在离开办公室去往卫生间的路上，解决方案就会出现在脑海里。当你对客户或同事生气时，也建议你暂时离开去走走，如果你还想保住工作的话……
8. 学习写有用的测试，学着用 TDD（测试驱动开发）。TDD 是一种软件开发流程，它是对如下简短开发周期的重复：写测试；运行所有测试，查看新的测试是否运行；写代码；运行测试；重构代码；重复。
9. 先解决问题再写代码。不要在一筹莫展的时候开始编程。
10. 不要记代码，而是理解逻辑。
11. 如果你复制粘贴 Stack Overflow 中的解决方案，请确保自己首先理解它。学习用恰当的方式使用 Stack Overflow。
12. 想学习，先实践。创建示例，并使其运行，因为只通过阅读来学习远远不够。
13. 研究他人的代码，也时不时让别人研究你的代码。结对编程并进行代码 review 是不错的想法。
14. 不要重复造轮子。
15. 代码是最好的文档。
16. 了解如何搜索。你需要有经验，大量阅读，了解需要找什么。
17. 你写的代码以后会由自己或别人进行维护，因此写的时候想着读者，不要把自己当做最聪明的人。写代码要像写故事一样。
18. 用谷歌解决错误的最佳方式是复制粘贴。
19. 不要放弃，问题总能得到解决的。糟糕的时刻总会过去。
20. 好好休息。解决问题的最佳方式是先让大脑得到充分休息。
21. 学习使用软件设计模式。设计模式是软件设计常见问题的解决方案。每个模式就像一个蓝图，你可以依据它进行自定义，进而解决自己代码中的常见设计问题（记住，不要重复造轮子）。
22. 尽可能地使用集成工具和自动化方式。
23. 练习编码套路（code kata）：编码套路是一种编程练习，可以帮助程序员通过重复实践来提升技能。示例参见：https://codingdojo.org/kata/
24. 编程并达到接口水平，而不是实现水准。依赖注入是必要的，参见 SOLID 原则。
25. 重构——测试 - 重构。重构即对现有代码进行重建、改动，在不改变其内部行为的前提下提升内部结构。
26. 必要的时候寻求帮助，不要浪费时间。
27. 多实践，熟能生巧。
28. 尽管有时候注释可以帮到你，但不要在这上面花费太多注意力。注释可能是过时的。
29. 了解自己的开发环境，并建设足够强大的开发环境，如 IntelliJ。
30. 重用组件。
31. 在开发 web 应用时，思考移动端及其相关的电量和带宽限制。
32. 不要过早地优化或重构代码。尽快做出最小可行性产品比较重要。
33. 不要为了节约几分钟，而选择低效的捷径。每次写代码，都要竭尽全力。
34. 遵循文档标准。
35. 用户不是技术人才。开发 UI 时时刻想着这一点。
36. 经常使用 GitHub 或 bitbucket 等源代码控制系统，并频繁进行小的提交更新操作。
37. 使用 log 要比代码 debug 更好。将所有关键部分记录下来。
38. 写代码时要保持连贯性。如果你使用一种风格，请一以贯之。如果你和多人合作的话，请和整个团队使用同样的风格。
39. 不要停止学习，不止是学新语言或新框架，还要关注软件开发基础知识。
40. 最后，保持耐心，保持热爱。
二、SOLID原则
设计模式的六大原则有：
- Single Responsibility Principle：单一职责原则
- Open Closed Principle：开闭原则
- Liskov Substitution Principle：里氏替换原则
- Law of Demeter：迪米特法则
- Interface Segregation Principle：接口隔离原则
- Dependence Inversion Principle：依赖倒置原则
把这六个原则的首字母联合起来（两个 L 算做一个）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。下面我们来分别看一下这六大设计原则。
众所周知，Java 编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计，S.O.L.I.D 是面向对象设计和编程 ( OOD & OOP ) 中几个重要编码原则(Programming Priciple)的首字母缩写。
1. 单一职责原则（Single Responsibility Principle）
一个类应该只有一个发生变化的原因
There should never be more than one reason for a class to change.
引起一个类发生改变的原因有且只有一个。也就是说一个类只做一件事情或者一类事情，每个类的分工是明确的，只负责一个功能。如果出现一个类有多个负责功能，那么就应该考虑将这个类拆分成多个来实现。因为如果把多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，有可能影响到另一个功能。
应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！
2. 开闭原则（Open Closed Principle）
一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭
Software entities like classes, modules and functions should be open for extension but closed for modification
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。
(1)通过增加代码来扩展功能，而不是修改已经存在的代码。
(2)若客户模块和服务模块遵循同一个接口来设计，则客户模块可以不关心服务模块的类型，服务模块可以方便扩展服务(代码)。
(3)OCP支持替换的服务，而不用修改客户模块。
简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。
应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。
3. 里氏替换原则（Liskov Substitution Principle）
所有引用基类的地方必须能透明地使用其子类的对象
Functions that use use pointers or references to base classes must be able to use objects of derived classes without knowing it.
父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中凡是父类出现的地方，都可以用子类进行替换，并且程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。
应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的 protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的 public 方法供外界调用。
该原则由麻省理工学院的 Barbara Liskov 女士提出，她是美国第一位获取计算机博士学位的女性，曾经也获得过计算机图灵奖。
4. 迪米特法则（Law of Demeter）
只与你的直接朋友交谈，不跟“陌生人”说话
Talk only to your immediate friends and not to strangers
其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
5. 接口隔离原则（Interface Segregation Principle）
1、客户端不应该依赖它不需要的接口。
2、类间的依赖关系应该建立在最小的接口上。
Clients should not be forced to depend upon interfaces that they don`t use.
The dependency of one class to another one should depend on the smallest possible.
注：该原则中的接口，是一个泛泛而言的接口，不仅仅指Java中的接口，还包括其中的抽象类。
不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。
应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。
6. 依赖倒置原则（Dependence Inversion Principle）
1、上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2、抽象不应该依赖于细节，细节应该依赖于抽象。
High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。
应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。