很多书会讲什么是好代码，如《代码简洁之道》，《代码之丑》，《代码精进之路》，记录一下自己在项目实践和学习过程中的感悟
google代码review文档
How to do a code review
对待代码优化的态度
如果你是想长久的维护一个系统，那么代码就必须要优化，或者说要用高标准严格要求他，一旦不好的代码积累，后期就要拿出成倍的经理，也承担成倍的风险去修复
对于新代码，最高要求
对外老代码，每次功能点内的进行优化，不要做超出功能点的内容，任何优化必然有风险，一定要体现为一个功能点，在实际开发的后续阶段进行跟踪
一、什么是好代码
参考《代码精进之路》，我觉得是“经济”这个概念去衡量是我最认可的。代码归根到底是一个工具，那么它主要的目的就是用合适的“代价”去获得效益。而不是单纯的无限去优化，去重构。
“经济”是根据实际情况来的，如果你是一个人的独立开发者，可能任何文档都是无意义的，但当我们在公司作为团队开发较大项目时，文档注释能帮助提升整体的经济性。
即便具体环境千差万别，我还是有一些例子，可以和你一起分享：
代码写得又快又好，是“经济”的；代码写得快，但是错误多，不是一个“经济”的行为。
代码跑得又快又好，是“经济”的；代码跑得快，但是安全问题突出，不是一个“经济”的行为。
代码写得精简易懂，是“经济”的；代码写得精简，但是没人看得懂，不是一个“经济”的行为。
二、如何写出好代码
各种各样的书都会教你什么是好代码，有很多的原则和细节，但要记住，代码的规范也是随着编程语言在进步的，可能过去因为语言特性的好代码也是会过时的。
那么如何了解什么是好代码？
1.多看各种书
2.多看各种开源高星项目
3.最推荐的，使用各种工具如spotBugs，阿里P3C，等扫描自己的一个工程，改一遍，这样起码能避免大部分坏味道，也能保持团队的统一
三、一些广泛认可的原则
命名
命名有很多原则，如合理使用英文，动名词，但最基本是要做到达意
如果一个方法里有方法名无法包含的逻辑，那么你应该考虑拆分方法
关于中文，很多业务由于复杂性及业务特殊性，无法找到恰当的英文，那么建议此类业务专有名词，统一使用中文拼音
如果有个方法你无法合适的命名，大概率是你的方法设计不合理注释
终极的目标，代码结构赏心悦目，一目了然。什么文档注释都不要，但现实情况很难达到。
因而注释是必须的，但切记不可滥用，如果一个变量，一个简单的方法你都要注释，说明你的代码结构有问题，需要优化
- 如何设计一个良好的接口----保持接口的简单直观
通常我们的接口设计时通过多年的工作经验和直觉去设计的，但还是有一些基本的原则可以参考
1.从真实问题开始，把大问题逐层分解为“相互独立，完全穷尽”的小问题；
这其实是一个原子服务的概念，但到底要分到多细，一般我们认为分到已有服务或者无法再分的情况。在实践中，我觉得从数据维度考虑也可以，如果是查询服务，可以将单一维度的或者密切关联的数据查询作为一个服务。而修改，则必须是“最小化”的
2.问题的分解过程，对应的就是软件的接口以及接口之间的联系
从问题和需求开始分析，这是为了有一条主线辅助分析，将问题的分解过程中，自然而然就出来了各个层级接口的框架
