一，关于程序员的价值观
对于一个程序员来说，是应该有价值观的，然而最朴素的基本价值观，就是要写好的代码。然后，要做到这一点不容易，
对些，我针对这些价值观有自己的一些看法：
（当然，在网上有关于价值观的内容一大片，各有视角，这里仅仅说说我的看法）
1，good software != quality code
2，软件开本 = 开发成本 + 维护成本
注意，尤其是维护成本，被很多程序员所忽视，认为我只在几天开发完了这个代码，这个软件的成本就并不高，这个观念万万要不得。 久而久之，这个观点慢慢地被产品，项目经理所学习到，也自然而然的认为，只在几天内开发完的功能，所投入的成本并不高。然而残酷的事实是，投入维护它的成本数倍于甚至数十倍于开发成本，扔下的往往是一个烂摊子，后续接手的开发人员也会苦不堪言。
有时候，我们程序员总感觉自己被产品催着，有忙不完的事，而背后的原因往往是程序员自己本身，因为在与产品沟通过程，总是会释放出这个很容易，那个也很简单的信号，而给产品造成错觉。
3，代码就是债务
同样的功能，写的代码越多，相应的测试、维护、升级等等成本也越高。 尤其是过度设计的危害，太过于高瞻远瞩，而忽略现实情况，结果可能恰得其反。
还有一个是不得不说的：关于设计和代码。我们期望的是设计与代码无限接近，但是，现实中，设计与代码往往是脱离的，甚至有时候看到设计，对代码的理解反而是一种误导。不仅无助于还原软件的真实面目，反而让软件蒙上神秘的色彩。
程序员之间沟通，最佳的语言就是代码，代码说了什么，就是软件实际运行的真实表达。
有一个观点我需要表达的是：代码写出来，除了要运行之外，就是为了给别人看的。而后者，有很多程序员会忽视，甚至都没有意识。 如果有程序员认为，写出来的代码，只要能运行，有高效率，有什么可动态扩展等等就可以了，至于别人能不能看得懂，那可就不关我的事了。事实上，这个观点很有害。如果只是说代码能执行等等这些观点来看的话，那么，什么格式化，变量命名规范等等都可以不要了，甚至换行都不是必须的。
二，关于代码的坏味道
关于这一点，不得不承认，代码很难做到一点坏味道也没有。
但我想表达的时，我们需要培养这种嗅觉。 如同一个摄影师，要想出好的作品，首先需要培养审美能力，否则，再好的器材，也出不了好作品。
培养了对坏味道的灵敏嗅觉，一旦在自己的代码中闻出了不好的味道，就会有强迫症一样逼迫自己去消除之。 （我们假定一个合格的程序员，有那么一点点代码洁癖，看到不好的代码总会坐立不安，在不需要别人的催促下能自己消除坏味道。）
代码中有哪些常见的坏味道，在互联网上能搜索出一大堆，在此，我只列举一些，有空无空看一眼，以培养自己嗅觉。
- 1，重复的代码
- 2，过长的函数 （函数的代码过长）
- 3，过大的类
- 4，过长参数列表
- 5，发散式变化
- 6，霰弹式变化
第5点和第6点有时感觉很接近，发散式变化主要是指软件在某个细节点需要增加相同的功能，如原来支持mysql，现在要增加对postgre数据库的支持，则要修改若干个函数。而霰弹式更强调细节，如代码中要增加或变化某个变量的，若干个类也需要做许多细小的修改。 发散式一般指一个class受多个变化影响，而霰弹式则指一个变化引起多个class要做修改。 但我觉得刻意去记清这个差异没有必要。理解它的本质就行：一个地方微小的变化，总会引起若干地方有关联的变化，如果有这种情况，就要警觉是否有坏味道在产生了。
- 7，依恋情结
函数对某个class的兴趣比自己的所在class兴趣还要高，这个比较难以理解，如，一个函数中，一大半的代码都在调用某一个类的方法，如取值等。
- 8，数据泥团
- 9，基本类型偏执
- 10，switch statement
这个没啥好说的，面向对象最好少用switch , 尽量用多态，不过，也要分情况，不要杀鸡用牛刀了。
- 11，平等继承体系
如： A extends SuperA , B extends SuperB , 如果有需要定义 AA extends SuperA时，总需要需要定义 BB extends SuperB 。 当然，这种也要会情况来对待，如果两边各代表一系列的继承关系，这个味道就不对了。
- 12，冗赘类
定义一些无用的类，或者考虑的某种变化根本不可能存在，而代码中却有大量相关的类实现定义等。总之就是想得太多，但实际不会出现。
- 13，夸夸其谈的未来性
在定义类时，总想着在未来的某一天会用到，而提链出一堆抽象类，接口等，而实际上，却无用处，甚至测单元测试也用不到。纯粹为了复杂而复杂。常见的情况就是，某些程序员总是无脑地定义抽象类，定义各种复杂的继承关系。
- 14，Temporary Field
类中的一部分属性，只有在特定的方法才有作用，而这些属性，往往又不对外暴露。常见的是把某些方法的临时变量，作为类的属性。
- 15，过度耦合的消息链
这个比较通俗的理解是： a调b，然后a调c, 然后又有b调c等等，可以改在 a调b， b调c。
- 16，Middle Man (中间转手人)
委托（delegation）的过度使用，而且这个委托人不干实事。
- 17，狎狔关系
两个class关系太过于亲密。这一点有点难以嗅到，不过，当发现用一个两个class类时，感觉用其中一个类时，又不得不花时间这个类的私有成员或者另外一个类的内容，两者很难分清它们之间的关系，往往会这种坏味道。这种情况下，相办法拆散它们，让他们关系明确一些。
- 18，Alternative Class with Different Interface (异曲同工的类)
两个函数做着同一件事，却有着不同的签名，请按照用途重新命名或者其它方法消除这种表达不一致的情况。
- 19，Incomplete Library Class (不完美的程序库类)
这一点我理解倒不像是一个坏味道，更新是在某些特殊场景下解决方法。
引入第三方的库不可能能满足所有需要，遇到这种情况，可以尝试引入外加函数或者引入本地扩展来解决这个问题。当然，这个是要分情况的，不能一概而论。
而如果要求第三方库完美，满足所有情况，这个就有点要求过度了。
- 20，Data Class (幼稚的数据类)
常见一些看上去像bean的java对象，它的属性，除了有get/set方法外，我们还发现这些属性居然是public的，有的属性是容器等等，这样的代码看上去像是无脑的代码，哪些属性能够public，容器对象应不应该这样暴露出来，都没有思考，只是知道这样可以修改这些属性的值而已，至于这样写，会造成什么危害，对模型的数据和行为定义是否准确完成没有考虑过。
- 21，Refused Bequest (被拒绝的遗赠)
这个坏味道有时并不那么强列，SubClass 继承了 SuperClass，但是又不支持SuperClass的接口，这个一般情况也就无所谓，当然，这么做有那么一点点别扭，但是，不要因此去随意改变模型间的继承关系，可以尝试用委托(Delegation)。
- 22，过多的注释
这一个的正确理解是：一个本身很简单的功能，因为实现的代码过于糟糕，而造成注释不得不随之变长，而使得内容难以理解。 因此，不要一看到这一点就惊呼，不是提倡代码要写注释么，注释要详细么，怎么这又说是坏味道了，注意，不是这样子的，要正确理解。
总结：以上的坏味道，有些是可能存在争议或者只在某个场景中才算，所以，对于这些场景应理解其本质所要反映问题的本质，区别情况对待。但是，这不妨碍对于这些坏味道的识别，却培养一个码农应具备最基础的嗅觉能力。
另外，对于出现了坏味道的代码，也不太可能一味地追求去消除它，毕竟追求极致是要付出时间成本的，而且有些时间会出现首鼠两端的情况，一定要权衡利弊。
三，一些所要了解的基本常识
- 1，圈复杂度
-
2，创建子程序的理由：
- 职责单一原则
- 封装变化
- 引入中间或者易懂的对象，使得代码更易懂
- 避免重复代码
- 简化复杂的布尔判断
-
提高可移值性
....
-
3，使用异常代替直接返回错误码
- 可以使错误处理从主路径中分离出来，使主流程清淅易懂
- 使用错误码返回易导致深层次嵌套
- if条件判断中，鼓励使用指令函数去替代复杂的判断表达式
这一点，会有使用异常会影响性能一说，但是，这里想表达的是，对于性能的追求，也需要分场景，在不分场景的情况下刻意追求性能，如异常所产生的性能对系统整体影响微乎其微，这种情况下，回避代码的可维护性而去追去所谓性能，实在是不提倡。
- 4，代码中，主体流与异常流要组织好，让代码突出主体流，更易于理解。
- 5，了解助手函数的好处，多用助手函数。
四，写高质量函数所要了解的
-
1，单一抽象层次原则
- 让一个方法中，所有操作处于相同的抽象层。
-
2，驯服深层嵌套
- 使用卫语句
- 重复检测条件中某一部分来简化嵌套
- 使用break
- if 转换为 if-then-else
- 嵌套if 转换为 case
- 嵌套的代码提取为子程序
- 3，函数设计原则： 短小
-
4，函数单一职责
- 函数名称或者代码块的业务目标是什么
- 函数的执行步骤，抽象层次是否相同
- 如果有足够的行数在解决不相关的子问题，提取之
- 每一行代码是否在为目标工作？如果不是，提取之
- 函数的语句有副作用吗？
-
5，函数的命名
- 动词或者动记词短语 ， 如： saveXXXXObject
- 符合命名规则 ，如bean的get,set方法等，
- 驼峰式命名
-
6，好的函数名称
- 描述代码块所干的事情，能反映出业务内容
- 避免使用无意义，模糊，表达不清的动词， 如： run , perform ,execute , processInput等
- 不要通过数字在区分不同子程序， 如 printUser , printUser1 ,printUser2 ，同样，使用顺序字母也不应使用。
- 避免重复，如 Document类， Document.print 即可， 而Document.printDocument则罗嗦。 而SystemUtil.printDocument则不是。
- 函数名称长短适宜。 （这一点，我认为，如果在迫不得已的情况下，长的比短的更合适）
- 能描述输出结果。 如 pen.currentColor
- 命名单词符合常规则习惯，不搞生避字等。
-
7，关于函数的参数
-
使用参数对象
- 如：queryObjectByDate(Date start, Date end) 改为： queryObjectByDate(DateRange dateRange)
- 解决数据泥团
- 以函数作为参数
-
保持对象完整
- 如果函数的参数，需要从某个对象取若干个属性作为一次调用，可以直接将些对象作为参数
- 过长的参数解决办法
- 分解成小函数
- 以函数作为参数
- 引入参数对象
- 变长参数
- 可选参数
-
关于参数的顺序
- 如果有函数使用了类似的参数，就应该让这些参数顺序一致
-
应避免以下情况
- 将参数作为临时变量
- 参数即作为输入，又作为输出 。 容器参数除外。
-
-
8，复杂的表达式应对办法
- 引入解释变量
- 分解表达式
- 引入布尔函数
- 表驱动法
-
9，关于循环
-
while , for 使用场景
- for：预先知道循环次数 ，简单场景
- while:预先不知，但是知道在什么条件下要跳出 ，复杂场景。如查有中途要跳出的情况，最好使用while
- 一个循环只做一件事情
- 用 {} 把循环括起来，就算循环体只有一句话
- 循环终止的条件一定要明显
- 不要随意修改for循环的下标，也不要滥用下标
- 嵌套的层次不要太多，避免超过3层
- 如查循环体内容过长，提取子函数吧。
-
-
10，关于常量
-
避免魔法值
- 别忘了final
- 使用类或者枚举类来替代类别码
-
-
11，关于变量
- 减少没有价值的临时变量
- 变量的用途单一，避免多用途
- 尽可能的减少中间结果。 解释变量除外。
- 变量的作用域尽可能地小，存活时间尽可能地短
- 临时变量不要远离它的业务代码
总的来说，变量应尽可能地轻量级
-
12，注释
理想情况：不需要注释，代码自解释
好代码 > 坏代码 + 好注释- 注释应该紧凑，精炼
- 避免使用不明确，含糊的表达
- 描述函数的行为要精确
- 说明参数、返回值的含义
- 配套有输入输出的例子
-
13，重复代码
- pull members/method up
- push members/method down
想一下，IntellijIdea工具中，Refactor菜单中的功能 ，你用过几个？
五，修改遗留下的代码
首先，请做到不伤害 -- 不要让它变得更糟
你是去治疗病人，而不是去伤害病人
关于重构
1，持续进行，而不在版本发布后才想起重构。
2，小步骤进行，不要尝试硬着陆
