前两天参加了公司组织的一个培训，主题是“如何写出好的代码” ，刚看到这个主题，第一反应是又不知道是哪个培训机构来忽悠钱的！老大安排了，就去听听呗。
说实在的，课程内容没有什么新鲜的东西，就是讲讲如何发现代码的坏味道，如何重构函数，如何修改遗留系统的代码。这些东西从本科到研究生到实习到正式工作，也不知道看过多少听过多少了，话说本科的课程设计也和代码重构相关，私底下重构和设计模式方面的书也没少看，感觉应该没啥好培训的，不过两天的课程听完，打心眼里觉得来对了，意犹未尽！
课程结束了，感觉需要把这两天课程的内容回顾总结一下，加深一下印象。
关于代码质量。这是一个永远萦绕在程序员心头的问题，特别是在敏捷团队，code quality更是一个时常听到的词语，静态扫描，单元测试，持续集成平台上永远少不了这些东西，感觉有了这些工具，能看到一些报告，就对代码质量有交代了。其实呢，发现实际根本不是那么回事，规则流程有了，工具平台有了，代码质量并没有提高，反而，因为维护UT占了大量的时间，代码写的更随意，更不规范了。培训老师说了一句话挺对的“代码重构是个良心活”，一段代码很烂，不重构能work，重构好了，没人知道，重构出了问题，反而会引来各种抱怨，谁去干这吃力不讨好的事儿，系统中没用的老代码都不想删，何况去动正在运行着的代码呢。所以说，要想提搞代码质量，靠程序员的良心是不太行得通的，特别是交付压力很大的情况下，就是有这个良心也只能昧着良心check in了。那怎么办，要靠manager，只有manager关注这块儿，才真的能触动代码质量的提升，不求manager去review代码，manager哪怕是盯一下静态扫描工具产生的报告，稍微找负责人谈谈话，代码质量就能上去，敏捷搞得manager们只看User Story完成的情况，只看能不能持续交付产品了，选择性忽略了代码质量。当然了，程序员也不是一点责任都没有，程序员写clean code是职业素养，是一种习惯，很多时候，我们从刚开始就没有能够养成这种良好的习惯，现在要改变也很困难，所以程序员要培养编程价值观，要改变对写代码的认识，养成好的习惯。
再说说敏捷开发，这个不知道从什么时候从外企传到私企，从大企业传到初创公司改变传统软件工程的模式，我觉得真心是鸡肋，至少在中国的公司中是不能充分发挥它的价值的。敏捷开发作为一种为迎合当今快速变化的市场的开发模式，面向的是市场，而软件工程是有工程过程规律的，既然是一项工程，就要按部就班的搞，就得有规划，就设计，有实现，有验收，还要有工匠精神，对细节的打磨，一个环节也不能少，不会因为用了敏捷，就能神奇的缩短时间，历史证明，多快好省是不可能的，偷工减料，还能又多又好么！那为啥外国公司要搞敏捷呢，依我看，是因为外国公司和咱国内情况不一样，美国公司啥个情况，就拿我们公司总部，在硅谷，据B1回来的同事说那儿的工作状态：每周最多上四天班，周一下午才来，周五下午不见了，四天里怎么工作呢，上午咖啡下午茶，吃完午饭打个盹，把大部分脏活累活外包到中国印度，自己留着核心的慢慢磨，或者做做创新。这个状态下，敏捷起来确实能提高效率，因为有大把的时间可以挤出来。而国内的，本来就处在满负荷运转了，再搞敏捷，需求不断改，UT，TA各个sprint都要跟上，还有功夫去关注代码质量么？中央为什么要提中国特色，情况不一样，发展阶段不一样，生拉硬套别人的不好使。
扯远了，拉回来。
关于代码的坏味道。什么是好的代码？没人说得清楚，但我们能指出什么是坏的代码，《重构---改善既有代码的设计》这本书开始讲的就是这个，比培训课程里讲得更好更全。只要没有坏味道的代码，就是好的代码，问题是如何闻出代码中的坏味道，有一些量化的规定，比如，函数长度不能超过50行，参数不能超过7个，嵌套不能多于3层，圈复杂度不能大于10，不能出现重复的代码等。有了这些明确的标准，只要会数数，就一定能发现代码中的坏味道。当然了，数学再好也未必就能数的出坏味道，还得有节操。
关于高质量函数。到底为什么要写函数？封装变化，单一职责，隐藏细节，避免重复代码，提高可移植性等，太多理由了，以至于程序员出于本能就会说“这个地方写个函数处理一下”。当然了，本能是一个从刻意到随意的过程，想写出高质量的函数，刚开始也要刻意为之。创建函数三原则：单一抽象层次原则，单一职责原则，函数短小原则。
- 单一抽象层次原则：让一个方法中的所有操作处于相同的抽象层。比如描述业务流程的public方法，可以罗列调用几个私有的分步方法，只显示流程大体步骤。这样把程序划分成几个处于同一层次的方法，自然的产生多个包含许多小方法的程序，每个方法只包含少量代码了。
- 单一职责原则：函数应该做一件事情，做好这件事，只做这件事。这个原则更多的是针对助手函数，对于描述业务流程的顶层方法，很难做到一函数一件事情。有时候总是喜欢命名一些函数actionAndaction，其实就是懒得去抽开，当然也有为了省掉一个循环，在一个循环里做了两件事情，对于循环，看数据集大小，如果分成两个循环并不会太影响性能，抽成两个函数，代码会更清晰。
- 函数短小原则：函数越短，越不会出现嵌套过深，功能复杂等情况。
函数10个一：
- 每个变量只用于单一用途。
- 每一行代码只表达一件事。
- 一个循环只做一件事。
- 每个函数语句应该遵守单一抽象层次原则。
- 代码组织的一次只做一件事情。
- 一种变化导致的修改应该仅仅修改一处。
- 圈复杂度小于一十。
- 函数第一原则短小。
- 单一职责。
- 写代码时要有一颗谦卑的心
关于修改系统遗留的代码。这是个头疼的问题，特别是大公司的程序员，很多人刚入职就是从维护老代码开始，原代码的作者早就离职了，有文档的不多，有用的注释也不多，只能靠自己理解，而当需要改代码的时候，就犯愁了，不敢动。很多时候，程序员就会选择往老代码里塞新代码：加个判断，多写个分支，顺着原来的代码结构完成新的功能。可是这很容易把老代码变的更糟，怎么保证不要让老代码变的更糟呢，要对老代码进行隔离，可以采用新生方法，新生类，外包装方法调用老代码，外覆盖类等方式，这些在《修改代码的艺术》里讲得很详细。要时时提醒自己，拒绝软件的退化。