在我心目中，好代码必需求契合以下四条规范

  1. 正确
  2. 易懂
  3. 易改
  4. 高效

而烂代码，只要一个衡量规范，那便是你在阅读或修正代码时骂的脏话的程度与次数

1. 正确

这是最根本的要求，代码当然是满意需求，运转起来正确无误，这一点并不那么简略做到，尤其是运转环境比较杂乱，各种异常情况较多的时候。

好代码要考虑周到，各种逻辑流程和意外情况的处理要八面玲珑, 单元和模块测验要掩盖异常逻辑和边界。

关于服务质量 SLA 要考虑周全, 简略说起来便是满意用户的七大根本需求

  1. 功用性，2. 安稳性，3. 牢靠性，4. 功用，5. 可维护性，6. 可移植性，7. 灵活性

一般正确性首要着重功用性完成正确无误，可是安稳牢靠，快速灵活也是不可或缺的

咱们的代码既要防错，也要容错，满足的健壮，不易出错，不怕出错，网络崩了，电源断了，磁盘满了等异常情况，都要有相应的应对办法。

2. 易懂

  • 好代码必须是看起来很舒畅，很洁净，简略理解

象一篇好文章，不罗嗦，简略懂，有头有尾。

各个层次，模块及函数分工清晰，各司其职, 望文知义，代码无需注释即可自我描绘。

接口即契约，要满足简略，易懂易用， 窄接口好过宽接口。

其实只要契合代码规范，命名简略易懂，代码就没那么丑。

拜见 Google 的代码风格攻略

有空翻翻“重构”那本书中的臭味介绍, 能够提高品味。

有一些根本软件开发的普适准则，能恪守尽量恪守。

KISS: Keep It Simple and Straight

坚持简略和直接, 恰当躲藏杂乱性

或许

KISS: Keep It Simple and Stupid 坚持简略, 象傻瓜相同, 不要让别人多加考虑

软件接口或 API 的规划要让人一看就明白, 一看就知道作者的目的和主意, 怎么运用它, 有什么成果和可能的异常及副作用. 看过很多代码， 踩过许多坑， 大多是作者或许我自己运用了出乎意料的完成， 不做好必要的笼统和封装， 杂乱的判别和算法到处都是

DRY: Don’t Repeat Yourself

别重复你自己, 如有重复代码, 请笼统或重用，切勿将重复的代码散落在多处，否则修正代码时就知道有多痛苦了

SRP: Single Responsibility Principle

单一职责准则: 就一类而言, 应该仅有一个引起它改动的原因，就一个函数来说，它应该只做好一件事，贪多嚼不烂。

也有一个别称 DOTADIW – Do One Thing and Do It Well 就做一件事并做好它

OCP: Open Close Principle

“software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

一个软件实体如类、模块和函数应当对扩展开放，对修正关闭。即软件实体应尽量在不修正原有代码的情况下进行扩展。

咱们能够在原有的类中增加字段或办法进行扩展，或许给函数增加新的参数(C 可赋予一个默认值, Java 干脆重载一个新函数)，以及扩展出一个新的子类。

而关于已经露出出去的API 以及接口, 类及公有函数，尽量不要修正它们，因为你需求压服你的客户（其他运用这块代码的模块）做相应的修正，而你往往并不清楚有多少客户在运用它。

LSP: Liskov Substitution Principle

LSP替换基类准则: 子类型应该能够替换掉它们的基类型，或许说父类型具有子类型的全部共性，子类型具有父类型的全部特征。

ISP: Interface Segregation Principle

ISP接口阻隔准则: 不应该强迫客户依靠于它们不用的办法, 接口归于客户, 不归于它所在的类层次结构，接口是生产者与顾客之间的契约，应该精炼精约，生产者只经过接口提供服务，而顾客也只经过接口来调用服务。

DIP: Dependency Inversion Principle

DIP依靠倒置准则: 笼统不应该依靠于细节, 细节应该依靠于笼统。

咱们要依靠于高层接口，而不是依靠于底层完成，接口是不会轻易改动的，而完成能够修正和替换
时下常用的插件机制，依靠注入办法都遵循这一准则

— 上述 5 个准则常被统称为 SOLID 准则

3. 易改

好代码要易于测验和修正， 恰当的笼统，封装和模块化有利于后期的修正和重构。

封装好杂乱性，区分隔常常改动与根本不变的代码, 恰当抽取易变参数作为装备。
为未来的改动规划有限的灵活性，无需多改就能很简略的扩展新功用。

仍是书里那句话，高内聚，低耦合。将依靠倒置，做好笼统，封装和模块化，代码就不难改。

例如最常用的 MVC 模式，为什么咱们要分成模型，视图和控制器三块，原因之一就在于分隔易变的与不易变的，分隔不会在一起改动的部分，减小每次修正的规模。

假如某个方面的功用需求修正，最好是改个装备， 其次是扩展个类或函数， 或许传个不同参数，最差的便是改多个地方，要做多个判别， 还要做霰弹式的修正。

好代码要易于观测和调试，也便是说日志和衡量数据要完备，能够分级，分模块进行日志和衡量数据的调整与剖析，自带衡量 API, 调试 API 及控制台为佳

好代码还要与时俱进，自我蜕变，写代码时要将不变的与易变的分隔，技能再怎么变，人性不会变，挣钱的事务改动也不会太大。一般来说，要封装好事务逻辑，核心事务不会大变，即使推到重写也要理解和参照老系统的事务流程。

人会变老，代码也会，新事务，新技能，新架构，新框架层出不穷，要大胆试验，当心引进，逐渐演进，不用抱残守缺，也不要盲目激动，把握住变与不变的平衡，常常变的地方应该尽量少，且尽量方便修正。

引述一下，Python 之禅，虽然说的是Python, 其实适用于多数编程语言

英文 中文
Beautiful is better than ugly. 美比丑好 
Explicit is better than implicit.    | 显着比隐晦好
Simple is better than complex.       | 简略比杂乱好
Complex is better than complicated.  | 杂乱比难明好
Flat is better than nested.			 | 扁平比嵌套好
Sparse is better than dense.         | 稀少比稠密好
Readability counts.                  | 可读性很重要
Special cases aren't special enough to break the rules.  | 特例也不要打破这个准则
Although practicality beats purity.                      | 虽然实践会损坏纯洁性
Errors should never pass silently.                       | 过错仍是不能让其悄然滑过
Unless explicitly silenced.                              | 除非你清晰声明不用理会它
In the face of ambiguity, refuse the temptation to guess. | 别让人来猜测不确定的可能性
There should be one-- and preferably only one --obvious way to do it. | 应该有一个且只要一个比较好的显着的办法来干事
Although that way may not be obvious at first unless you're Dutch. | 虽然那个办法可能并非一开始就清楚明了
Now is better than never. | 现在就做比永久不做好
Although never is often better than right now. | 虽然永久不做常常比立刻就动手做好
If the implementation is hard to explain, it's a bad idea. | 假如完成很难解释清楚, 那它不是一个好主意
If the implementation is easy to explain, it may be a good idea. | 假如完成很简略说清楚, 那它是个好主意
Namespaces are one honking great idea – let's do more of those! | 命名空间是个绝妙点子, 让咱们那样做得更多

4. 高效

好的代码应该充分利用可用的资源，功用达标，没有无谓的浪费和等待。
运用合适的算法和数据结构，对 CPU, 内存，网络等资源的运用有控制。

在关键算法，关键途径上要做算法杂乱度剖析，运用大 O 剖析法以及Amdahl加快定律等进行定性和定量剖析，再结合功用衡量数据进行调优。

咱们不光要给事务数据拟定 KPI, 也要给功用数据拟定 KPI, 例如通常用的到 UPS – Usage, Performance 和 Saturation, 经过观测，衡量和剖析这些 KPI 再做有的放矢的调优。

压力测验（stress testing）和功用剖析(performance profiling)是必不可少的办法。
一般来说，高效率要在规划，完成和测验多方面都要做有针对性的考虑，经过衡量驱动，想清楚代码上线怎么生成和收集衡量数据，怎么经过衡量进行调优。

参考资料

  • Agile Software Development, Principles, Patterns, and PracticesbyRobert C. Martin
  • Clean codebyRobert C. Martin
  • Refactoring: Improving the Design of Existing CodeMartin Fowler

本作品选用 [常识同享署名-非商业性运用-制止演绎 4.0 国际许可协议](http://creativecommons.org/licenses/by-nc-nd/4.0/)进行许可。