不知道你们身边有没有这样的同事，就是明明工作多年，职级却还是初、中级，想升高级就是没门。看看工作，不也还凑合着能用吗？加班改 bug 也任劳任怨了，凭啥就不给升职？
问题很有可能就出在代码没有写好。这样的程序员往往把注意力更多放在了业务逻辑的实现上，而忽略了代码本身的质量。虽说这不一定是主观的故意，因为工期紧、任务多，抢上线就成了头等大事。
但时间一长，低质量的代码会带来三重危害。第一是可维护性变差，代码条理不清，升级或修复都困难重重；第二是健壮性差，程序运行不稳定；第三是性能低下，资源管够却出现访问延迟等现象。
所以，程序能用，远远不能作为评判程序员水平的标准。要想跨过中级门槛晋升高级，程序员一定要花时间把代码写好。如果你不知道该怎么写好代码，那有一本书可以帮到你——《好代码，坏代码：软件工程师卓越之道》。
我们先来看一下什么算是好代码，再说怎么写吧。
好代码应该是什么样的关于好代码的标准是什么，业界对此确实也没有一个可衡量的标准，这也是编程质量难以评判的原因。每个人都有自己的观点，认为好代码应该是什么样的。我们不妨先从编写代码想要达到的目标说起。
《好代码，坏代码：软件工程师卓越之道》书中对编写代码提出了四个高层目标：
- 代码应该正常工作；
- 代码应该持续正常工作；
- 代码应该不断适应变化的需求；
- 代码不应该重复别人做过的工作。
以上四点，就是说明代码应该具备可用性、稳定性、可扩展性等特点。
你的代码达到这四个目标了吗？
如果你感觉自己离这四个目标还有差距，那么就可以继续学习书中提出的“代码六大支柱”，并且如何在实际工作中应用好它们。
这六大支柱分别是：
- 编写易于理解（可读）的代码；
- 避免意外；
- 编写难以误用的代码；
- 编写模块化的代码；
- 编写可重用、可推广的代码；
- 编写可测试的代码并适当测试。
做好代码的六大支柱，那简直就是六边形战士般的满格技能。要是花点时间学好了，那真是分分钟晋升高级程序员。《好代码，坏代码：软件工程师卓越之道》对每条支柱都有详细说明，照着练就行。
闲话少叙，我们先看头等重要的支柱，怎么写容易理解的代码。
代码是写给人看的对于什么样的代码是好理解的，这可能每个人都有自己主观的看法。但书中提出了一个观点，代码应该是“不言自明”的。这就意味着，如果我们只阅读代码文本，就能了解其设计意图，可算是达成目标了。
以此为出发点，我从书中提取了三个重要方面，我们一起来学习一下。
给变量和函数取个好名字
我看过五花八门的变量名称，从abc这样的到汉语拼音的形式都有，这些都是不合适的。因为编程语言的关键词都是英文，所以保持语言内容的一致性很重要。
还有的变量取名虽然遵循了英文规范，但用词却太过宽泛。例如大家最爱用的data，在代码里单看到这个词却无法提取更多信息，就会造成阅读时的思维脱节。
给变量和函数取名应当遵守一个原则，就是使用描述性的名称。这些名称中要包含特定的业务信息，做到一目了然，就算一个好名字了。
示例对比：data - studentData，GetData() - GetStudentData()。
总结：使用英文表意，使用描述性名称。
注释用好，事半功倍
坦白说，不少程序员就不爱写注释，他们的理由是：我的代码是自注释的。他们的误解在于，认为注释是用来说明低级功能的，例如就一条for语句还用得着说“此处循环100遍”吗？
正确理解代码的功能注释，应当是聚焦于高层概述，目的是让人从整体上可以快速领会思路。还有对于复杂的算法实现，也要有详细的说明，避免造成误解。
书中对于功能注释的高层概述示例：
平衡效率与可读性
有些程序员想要追求效率，就将多行代码做到只用一行代码写出来。这样做可能可以带来一些效率提升，但代码的可读性就变差了。以书中的一段代码为例：
代码确实很短，但要看出实现意图来，却很困难了。
程序员应当在代码的可读性与执行效率之间充分考量。如果是在资源极小的嵌入式平台上，那么效率优先是合理的。但如果是在性能强劲的服务端，且功能并不会频繁执行，那么就应当可读性优先。
上述代码，书中给出了一个改写的例子，大家看下虽然代码变长，但是不是更好理解了：
代码写得通俗易懂了，接下来就要学会偷懒，只造一次轮子就反复使用。
只造一次轮子高效的程序员，随着工作时间的增长，他们的代码写得比以前少，还保持了稳定性和健壮性。这是因为他们深刻理解了只造一次轮子的道理，也就是做好了代码的可重用与可推广工作。
可重用，就是对相同的问题，只需要使用已有的代码或库。例如对于网络通信编程，有经验的程序员都会使用第三方库，或者将自己经验积累起来的代码形成库，而不会每次都从套接字编程写起。
可推广，要求要高一些，它要能够对不同场景下的相似问题，使用同一套代码或库。C 的标准模板库 STL 就是可推广的典型代表。
道理都懂了，那怎么把我们的代码写好呢？
书中提出了许多有益的建议，我从中选取重要的方面进行说明。首先是要对系统建立清晰的抽象层次，从而编写出模块化的系统。这样就为代码封装为组件或库提供了前提条件。
书中使用了机器人玩具与毛线小猴玩具对比，形象地说明了模块化的系统在可维护与可扩展上的优势。
其次，要写出可重用性好的代码库，就要掌握一个原则：让调用者做决定，不要越俎代庖。这包括以下三个细节：
- 避免不必要的假设。
- 依赖注入共享状态，不要使用全局状态。
- 在较高层次代码中使用默认值。
最后，要使代码达到可推广的目标，就要借助于编程语言的泛型特性。好在当前的大多数主流语言都支持泛型，这样可以让参数类型与具体算法脱离，使得代码库更加通用。
到这一步，程序员的工作效率已经提上来了，接着就是做好代码质量的保障工作。
写好单元测试现在互联网公司的开发规范中，都会将编写单元测试作为基本要求。这项工作是对代码最基础功能单元的质量保证，这件事的重要性不言而喻，但还是会有程序员执行不到位。
原因就是编写单元测试会花费一定时间，程序员为了赶进度，就倾向于推迟或者干脆不写单元测试。这表面上看是节省了一些时间，但堆积的低质量代码，在后期调试与除错上付出的代价更大。
书中对于写好单元测试提出了五项要求：
- 准确检测破坏：代码被破坏时测试要失败，但不要报假警。
- 与实现细节无关：测试应当关注外部行为的一致性，而不是内部实现细节。
- 充分解释失败：出现失败，就一定要提供充分且有意义的信息。
- 易于理解的测试代码：测试代码也要做到“不言自明”。
- 便捷的运行：单元测试在开发过程中会频繁运行，应当避免难用或运行缓慢。
在为复杂的业务场景构造测试用例时，使用模拟对象与桩这两种方式，虽然可以将测试环境与生产环境隔离开，但会造成测试与真实业务之间的脱节。书中建议使用伪造对象方式，这样既能够保证测试与业务的一致，也将测试与实现细节解耦。
所以程序员一定要有正确认知，保证自己交付代码的质量。这样不仅高效完成工作，还收获老板的信任，晋级的这层窗户纸自然也就捅破了。
程序员们对于一些原则性的理念，都会抱以赞同的态度。例如代码是写给人看的，不是写给机器看的；不要重复造轮子；所有的功能代码都应该有对应的单元测试代码，等等其他。
但太宽泛的描述往往会让人在执行时不知所措，《好代码，坏代码：软件工程师卓越之道》就在理念与实践之间，架起了一座桥梁。这本书对于工作数年，认同一些基本理念，却难以再上一层楼的程序员来说，可以提供最直接的帮助。
我在看这本书的时候，经历了一个心路历程：先是看到坏代码示例——“我就是这么干的，惨了”，然后看到好代码示例——“这个办法妙啊，我怎么没想到”。
诚如书名所提示的，当程序员能够看到坏代码，并写成好代码，也就成就了一名软件工程师的卓越之道。当然，还有更重要的，就是晋级加薪一样不少。
#创作挑战赛#
,
