代码简洁之道
简介
对于程序员来说，在整个项目中高效工作和不降低生产力是每个程序员应该努力追求的本质。生产力下降的一个症状正是糟糕的代码。通过编写干净的代码，你的读者朋友，包括你未来的自己都会感激地回顾你所做的努力。
本文档涵盖了一些不良代码的症状和它们可能的解决方案，以及对所提出的问题的良好做法。然而，请记住，有时程序员必须打破良好和最佳的做法。偶尔，另一个解决方案会更好，而且没有额外的伤害性影响。也可能是这样的情况，两个好的实践发生冲突，或者看似好的实践在特定的环境下没有意义。
所涉及的实践和解决方案主要是在面向对象的范式中受到好评，其中代码的可重用性和灵活的适应性是一些隐含的目标。我们可能也很容易忘记，软件代表着软产品或可塑造、可调整的产品。如果你写的代码不能灵活地改变，那么代码在某种程度上只是一个重新发明的硬件的实例。
症状
僵化
当代码变得难以改变和重构时，这通常表明代码架构是严格设计的。例如，在一个模块中的改变会导致其他几个模块中的改变泛滥。如果代码是紧密耦合的，这意味着模块和组件之间有很大的关联，这样就不可能在其他地方重复使用任何组件，通常会遇到这种情况。
脆弱性
当对一个模块的修改使其他完全不相关的模块突然中断。随后，生产力将成倍下降，因为该项目将发展成为一个必须找到所有bug的游戏，每改变一次代码，就会出现两个新bug。
不动性
当大部分的代码在没有重大重构的情况下不能被重用。含有大量重复代码片段的大型代码库并不罕见。说得更清楚一点，代码作者可能想到了重用他们现有的代码，然而由于他们的代码与它所包围的组件极其紧密地联系在一起，重用性根本不是一个选项。偶尔，不动声色的症状可能是紧密耦合的代码和僵化的结果。
粘性
当改变是在最没有抵抗力和不适合的地方进行的。通常情况下，当程序员试图找到一个解决方案时，他们会立即意识到解决一个问题的肮脏而又笨拙的方式。当程序员选择走一条肮脏而通常容易的道路时，粘度的症状就会出现。这可能是出于公平的原因，如最后期限和重新编译可能需要大量的时间，在这种情况下，程序员决定简单地运行一些脚本，而不是以更持久的方式解决问题。一旦到了最后期限，程序员应该强烈考虑以更恰当的方式重做他们的代码中被催促的部分。
解决方案
[正在进行的工作］
函数的基本规则
一个函数应该只做一件事，不要与单一责任原则相混淆。在阅读代码时，遇到大而讨厌的函数并不是一种罕见的经历。大函数的问题在于，它们对读者来说变得严重无礼。不礼貌的发生是因为读者原则上必须阅读整个函数才能理解它的实际作用。解决的办法是让函数只做一件事。当我们不能有意义地从现有函数中提取另一个函数时，我们通常会定义一件事。