哈Ha！
谈论
干净的代码没有尽头，但是Dave Nicoletta的下一篇文章非常隐喻，并且希望确实值得翻译。 正如作者在原始文章中预先警告读者一样，让它有点“启发性”。
阅读愉快。
多年来，在家里已经养成了坏习惯。 使用任何工具，我们都会忘记将其放到原处。 下次有人需要它时，他们不得不花更多的时间来寻找工具，而不是解决问题。 最可悲的是，即使是最后拿到那把乐器扔到任何地方的人也注定要进行完全相同的搜索。 事实证明，购买新设备要比寻找我们拥有的工具要快-我们可以肯定！ -周围某个地方。
因此，我们得到了四把飞利浦中号十字螺丝刀，三把带有平槽，一堆额外的钳子和扳手，适配器套。 更不用说令人印象深刻的笔，胶带绞线，电池和其他精美物品的收藏了。
一旦我们决定：那就足够了！ 为所有物品分配他们的位置，并使它们与我们的库存保持一致。 手工工具捐赠给慈善机构。 我们竭尽全力培养自律性，并在与他们合作后始终将工具放在他们自己的位置。 单位时间工作的质量和数量急剧上升。 压力，金钱浪费和情绪变坏的情况变得更少了。
在公司车库中下订单
如果在公司车库中工作的汽车修理工将工具丢到任何地方怎么办？ 他们花更多的时间在寻找工具上而不是实际工作。 细节将被放置在错误的位置，丢失，生锈，损坏，它们只会被盗。 供应成本将大大增加。
完成任务将需要更多时间，但是工作质量会下降。 当机械师必须使用生锈，磨损和破损的工具进行工作时，他很难正确地安装和固定零件。 此外，在车间安排乱七八糟的习惯将不可避免地影响工作质量。
客户将厌倦了无休止的岗位调动。 不久他们将去更可靠的车间。 不知何故没有你。 也许与软件开发和支持的类比已经很明显了。
下订单进行软件开发
让我们看一个具体的例子：增量重构。
这种表达使许多人感到困惑。 我不知道哪个词使他们感到困惑：“增量”或“重构”。
增量（逐步）重构与大规模重构根本不同。 在许多人看来，任何重构都必然是“大规模的”，必须由某人“授权”，因此，据说应该将工作拖出。 实际上，如果在工作过程中忽略重构，那么一切都会大大延迟。
包括我在内的大多数技术教练都很难解释这种情况下的区别。 不是因为根据定义这种差异很复杂，而是因为很难用语言表述。 但是，我认为在这种情况下，仔细考虑可用库存并监控供应的习惯是一个很好的类比。
逐步重构
进行逐步重构就像在工作台上即使在工作高峰时也要保持秩序。 用螺丝刀-放在适当的位置。 在执行每项新任务之前，我们都不会为此而举办研讨会。 关键在于完成工作的能力……如何完成开始的工作。 剥开末端。
逐步重构不需要花费很多额外的时间，也不需要别人的许可。 为此，如果需要赶时间，您需要请求权限不要清除代码。 实际上，不断保持代码干净的能力应被视为程序员的基本专业技能。 遗憾的是，如今，“干净的代码”需要宣传，有些程序员甚至反对带来这种纯洁。 逐步重构对于大规模架构重构绝对没有任何帮助，这确实需要仔细计划，为此要分配时间，金钱和人员。
侦察规则
在编程中，有一个所谓的“侦查规则”：保持代码至少与收到的代码一样干净。 这同样适用于在家中存放工作工具。 如果我们正在寻找钳子，但是请注意，一字螺丝刀意外地进入了十字槽，而十字螺丝刀却进入了槽中，则在此过程中，我们将其放置到位。 我们不需要官方批准即可执行此操作。
这就是逐步重构的工作方式。 在我们面前的是一段代码，我们需要向可用结构列表中添加一个新条件。 我们注意到该列表被实现为一个大型if / else块。 我们决定在添加条件时需要将其重新设计为开关或选择运算符。 可以争论：这真的比if / else块好得多吗？ 是的，您是对的：不多。 但是好一点。 下次当有人在您之后阅读此代码时，由于您已经提高了他的起始位置，因此他将能够更好地对其进行完善。 如果您以前曾经做过这样的事情，那么您可能会注意到，只要仔细阅读所有条件，您有时会发现重复的构造，然后是表达式的非最佳顺序。 也许您遇到了一些无法满足的条件，甚至遇到了一个逻辑“空洞”，整个控制序列将通过该“空洞”落入if / else块，而某些情况将根本无法处理。 只要从现在的技术支持服务中收到相应的票证，您就可以立即为您发现它而高兴，而不是在深夜。 在这样的时刻，人们绝对不希望理解这些混淆的代码。
也许我们将向应用程序添加一些新功能，并注意到我们编写的函数/方法与代码库中已经存在的另一个函数非常相似。 仅花费了几秒钟，即使没有别致的IDE中我们的服务提供的其他工具，我们也将摆脱这种重复。 您可以毫不犹豫地进行重构，因为我们已经习惯了自律，并保证已经编写了涵盖此案例的微型测试（单元测试）。 那么，手动重构并不可怕。 最后，提出至少一个为什么不这样做的理由？
“长期”通常不像看起来那样长
我经常从不同的人那里听说重构带来了“长期的”好处。 尽管从理论上讲，在现实世界中，您始终必须严格地交接作品。 但是，如果我们谈论通过小规模的逐步重构来保持代码的纯度，则“长期”将一直持续到其他人接触到代码库的那一刻。 直到下一次。
坏消息是事实恰恰相反。 如果您在工作时不清理代码，则代码很快就会恶化。 我们没有十年的“安全气囊”，可以让我们在问题开始之前无罪无息地积累婚姻。 我们需要进行的下一个更改将花费很长时间，这是我们无法接受的，代码回归的风险将增加，而对此没有适当关注的情况只会恶化。
如果我们只是为了满足客户的需求（他希望更快地完成产品）而进行黑客入侵，那么在确保不再进行快速更改之后，由于我们将代码带到了现阶段，我们将如何继续满足这些要求？混乱，并且不可能维持吗？
什么是快的，什么是慢的？
无论您安排多快，客户始终希望您更加努力。 减少发布时间的最有效方法是正确地做所有事情。 做好 始终无一例外地不断清洁末端。 偷工减料，以“加快”速度，实际上，我们只是放慢脚步，而不是暂时的“长远眼光”，而是现在和现在。
当客户要求您更快地工作时，这并不意味着他会让您不小心工作。 自然地，在他看来，他不应该在每次请求后提醒我们他对高质量感兴趣。 高品质是我们工作的组成部分之一。
作为工程师，我们自己选择是否将逐步重构视为我们专业活动的基本要素。 我们不问我们是否可以照常工作，就像外科医生不问会计师在手术前是否有时间洗手一样。 花费在操作上的时间正好等于操作成功所需的时间。 需要仔细切除患者的阑尾，出院后，该人可以恢复正常生活-没有伤口感染，腹部也没有棉塞。 如果一个人比必要的时间提前十分钟离开手术室，那只会变得更糟，然后开始出现并发症。
通常，在这种情况下，他们会嘲笑说“如果一切都根据科学来完成”，那么结果就会“太长”。 不，实际上，如果工作匆忙而没有适当的专业精神，则纠正结果所花费的时间“太长”。 从感染中恢复对患者及其家人来说确实是一个震惊，这将不可避免地影响他的工作。 第二种手术是一种更为严重的干预措施，其中必须从腹部切出一个被遗忘的棉塞，这仅是因为该人是第一次急着进行手术。
进行编程时，如果由于有人急着编写代码而不得不进行五次代码回归，那么您就无法谈论“节省时间”。 相反，更改的时间更长。 只有正确完成工作，才能“完成”工作。 如果团队在“草稿准备就绪”之后不得不花费数小时和数天来纠正错误，那么这将浪费时间，而这些时间本可以花在其他有用的工作上。 这是损失的利润。
这样的错误会产生类似波浪的后果，并导致时间和金钱的长期损失，有时甚至会损失客户。 工程师自己承担了更多的压力。 士气低落，人员流动率高。 因此，工作变得越来越艰难，道德和工作投入进一步降低。
技术债务作为隐喻
每当您谈到渐进式重构主题时，肯定会有人提醒您技术上的债务。 他们会说：“我们的截止日期如此之短，以至于必须偷工减料。” 他们会补充说，在这种情况下，团队会根据业务需求有意识地积累技术债务。
那些这样说的人不理解这个隐喻，也许根本就没有隐喻。
隐喻无意对所表征的事物进行完整而全面的描述。
隐喻通常有助于概述事物的某个方面。
人们倾向于用事物的隐喻代替事物，然后用隐喻来操作，就好像她和
所描述的是一回事。 不，这不是一回事。 重点。
此外，人们通常会在其原始语境之外广泛地解释隐喻。 因此，隐喻的含义变得模糊，并且变得越来越有用。
沃德·坎宁安（Ward Cunningham）提出了技术债务的隐喻，描述了金融行业中的客户互动。 他在此特定情况下寻找合适的隐喻，以强调机会的逐步实现如何帮助创建一个反馈循环，在此期间不断优化程序。 他的意思不是“为了创造快速发展的幻想而偷工减料”。
技术债务隐喻的原始概念意味着该代码必须保持整洁。 理解代码中遗留问题的人员会逐步寻求解决方案，并且代码将始终足够准确，以便可以对其进行逐步改进。 并不是因为某些技术原因可以证明为什么该代码为垃圾代码并需要不断进行更正。
为了快速移交工作而偷工减料不是技术债务的积累。 这是一个常见的hack。
谁负责？
为了实现快速交付，您需要在工作时摆脱问题。 这些问题之一是垃圾代码。 您可以通过学会自律来逐步摆脱这一障碍。 在这种情况下，您的工作方式无关紧要-根据“瀑布”模型还是根据“先遣队”。 每当我们触摸键盘时，我们自己就选择如何工作。
我总结一下。 如果您正确地工作（包括清理末端），那么它将只会对客户，赞助商，经理以及将来会支持我们的代码的人员（当然对我们自己）有利。