- 好代码VS烂代码
- 一些深层原则
- 深入学习设计模式的好处
- 如何评价代码质量的高低？
- 面向对象、设计原则、设计模式、编程规范、重构，包含哪些内容及这五者有何关系？
很多人写出烂代码的程序员往往会跟自己找借口——时间紧、任务重等，但是其实写烂代码和好代码花费的时间是差不多的。
一些深层原则- 大道至简：
思从深而行从简，其实包括写代码在内的任何事，如果感觉比较甚至越来越复杂、混乱、浆糊等。那很可能是没有深入思考、没有找到本质问题。 - 历史债与破窗效应
每个项目代码都存在或多或少的历史债，躺平的处理方式最终会导致破窗效应，而建设性的处理方式应该是：
1）、首先，尽最大努力保证产生的新代码是好代码。
2）、找到当前突破口，小步快跑进行代码优化重构。 - 代码编写与敏捷开发一样也需要有精益思维
讲求中庸之道，不要不设计，也不要过度设计，判断标准主要是聚焦当前和未来可预判的扩展点，保证有足够的灵活性和扩展性。
mvp，小步快跑的实现思想很重要。
- 应对面试中的设计模式相关问题
- 告别写被人吐槽的烂代码
- 提高复杂代码的设计和开发能力
具体来讲，包括：
1）、写出易扩展、易用、易维护的代码，其实并不容易，需要有意识的学习和可以练习。
2）、如何分层、分模块？应该怎么划分类？每个类应该放置哪些属性和方法？
3）、该用继承还是组合？该使用接口还是抽象类？怎样做到解耦、高内聚低耦合？
4）、该用单例模式还是静态方法？用工厂模式创建对象还是直接 new 出来？
5）、如何避免引入设计模式提高扩展性的同时带来的降低可读性问题？ - 让读源码、学框架事半功倍
- 为你的职场发展做铺垫
代码质量低还会导致线上 bug 频发，排查困难。整个团队都陷在成天修改无意义的低级 bug、在烂代码中添补丁的事情中。
主要的三个指标：
- 可维护性（maintainability）：
代码易维护的表现：在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码
代码不易维护的表现：修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。 - 可读性（readability）
代码的可读性应该是评价代码质量最重要的指标之一，我们在编写代码的时候，时刻要考虑到代码是否易读、易理解。 - 可扩展性（extensibility）
对修改关闭，对扩展开放
其实所谓的修改关闭，不是做到完完全全不修改已有代码，而是要将修改的地方控制在可控范围之内。
其他指标：
4. 灵活性（flexibility）
存在较多可复用的类、方法；方便灵活的扩展使用
5. 简洁性（simplicity）
尽量保持代码简单
思从深而行从简
在开发初期，除非特别必须，我们一定不要过度设计
6. 可复用性（reusability）
DRY（Don’t Repeat Yourself）
7. 可测试性（testability）
- 面向对象
四大特性：封装、抽象、继承、多态 - 设计原则
SOLID 原则 -SRP 单一职责原则
SOLID 原则 -OCP 开闭原则
SOLID 原则 -LSP 里式替换原则
SOLID 原则 -ISP 接口隔离原则
SOLID 原则 -DIP 依赖倒置原则
DRY 原则、KISS 原则、YAGNI 原则、LOD 法则 - 设计模式
1). 创建型
常用的有：单例模式、工厂模式（工厂方法和抽象工厂）、建造者模式。
不常用的有：原型模式。（java的浅深拷贝）
2). 结构型
常用的有：代理模式、桥接模式、装饰者模式、适配器模式。
不常用的有：门面模式、组合模式、享元模式。
3). 行为型
常用的有：观察者模式、模板模式、策略模式、职责链模式、迭代器模式、状态模式。
不常用的有：访问者模式、备忘录模式、命令模式、解释器模式、中介模式。 - 编程规范
编程规范主要解决的是代码的可读性问题，包括如何命名？如何写出良好的注释等。 - 代码重构
聚焦重构的目的（why）、对象（what）、时机（when）、方法（how）；
保证重构不出错的技术手段：单元测试和代码的可测试性；
两种不同规模的重构：大重构（大规模高层次）和小重构（小规模低层次）。 - 联系总结
1）、面向对象可以看成是基础
2）、设计原则主要是为了保障代码质量而提出来的代码编写需要保持的原则，设计原则相对偏理论和抽象。
3）、设计模式则是对于软件开发中经常遇到的一些设计问题，总结出来的一套解决方案或者设计思路。大部分设计模式要解决的都是代码的可扩展性问题。设计模式相对于设计原则来说，没有那么抽象，而且大部分都不难理解，代码实现也并不复杂。学习设计模式应该聚焦在某个场景下，该不该用这个设计模式，那就看能不能提高代码的可扩展性；
4）、要不要重构，那就看重代码是否存在可读、可维护问题等，特别要保持定期重构的心，以避免产生破窗效应。
