借着今天公司有分享设计模式 简单记录下自己对“高”质量代码和设计模式的理解。
众所周知设计模式有六大核心的思想原则。引用一段百度百科的介绍 传送门
为什么要提倡“Design Pattern呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？面向对象有几个原则：单一职责原则 （Single Responsiblity Principle SRP）开闭原则（Open Closed Principle，OCP）、里氏代换原则（Liskov Substitution Principle，LSP）、依赖倒转原则（Dependency Inversion Principle，DIP）、接口隔离原则（Interface Segregation Principle，ISP）、合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）、最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则）。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。
其实说是为了代码复用，也可以说是为了写“好”代码，写“高”质量的代码。那么什么样的代码才能算是好的代码呢？那么我就简单的记录下此时自己的理解吧。
可阅读性高/理解成本低
代码虽说是写给机器运行的，但最终维护是人，也是需要给人看的。所以如果你的代码写的别人看不懂只有你自己可以懂（有些人自己过一会看也看不懂了～），那么这样的代码肯定也不是所谓的“好”代码。
往往好代码都有以下的几个特点。
- 包括代码自解释
- 合适的文档注释
- 分层合理
- 函数封装粒度合适
- ….
总结就是你写的代码，别人包括自己以后来看都能看得懂。
维护成本低
业务是不断发展的，随着需求不断变化你需要对你编写的代码进行不断的调整。在这个过程中，如果有牵一发而动全身的感觉的话 自然会改起来很痛苦。所以合理的分层和抽象能够降低维护成本，改只改变动的地方。整体的结构也是扩展而不是修改。
复用程度高
复制粘贴的代码 改一处就得把之前复制过的地方都改一次,每次这样玩也是风险很高的。漏了改啊 或者复制错了什么的。
健壮性
对于边界情况异常情况的处理需要去处理.毕竟线上环境千变万化。
性能好
其实这块对程序员的经验要求可能会高一些，也是常常被忽略的地方。需求是完成了 但是占用内存/CPU很高，造成界面卡顿也是要不得的。
其实对于代码质量的话题真的很大。建议大家看一些经典书籍，取百家之长。
这一篇有些像lanyuchongshu..
更新时间2019-4-21
后续会针对这个话题更深层次的探讨。
写在最后：
Better Late Than Never ，愿我们都能跨出自己的第一步。
站在巨人的肩膀上，感谢前辈们的文章。