接到一个紧急需求：大屏展示原来只有两个品牌数据，现在需要增加到三个品牌的数据。看似简单的需求，却在代码注释中引发了作者的思考。

这段代码经历了多少次的蹂躏，才会让作者的心潮有如此波澜？抑或，这到底提出了怎样一个需求，让作者需要通过这样的注释来宣泄心中怨气？

这个作者经历了什么样一个撕心裂肺的过程？但是可以肯定的是这一定是一个有想法的作者，不由得心中肃然起敬。

巴拉开代码修改记录，作者已经去别的地方高就了，要不是留了这些代码，实在想不起有这样的一个同事存在过；代码提交记录比较整洁，大部分代码是在5月29号提交，5月30大概是修复bug提交了小部分代码。如此看来，代码没有经历过什么苦难，这里的需求仅仅是每个品牌的门店按订单数量排序。

再细读作者留下的代码，只能说作者给自己设置了难度系数(这说法太含蓄了)，稍微有一点改动，便是牵一发而动全身，于是留了这样一个不太成熟且不太有价值的注释。

《代码整洁之道》一书开篇第一句话就是一个著名的论断：衡量代码质量的唯一有效标准：WTF/min。这一让人费解的缩写背后，是对代码质量的深刻思考。这引发了作者对于代码质量的思考。

如果作者阅读了《代码整洁之道》，他就会明白代码走向整洁的四原则：运行所有测试、不可重复、表达了程序员的意图、尽可能减少类和方法的数量。

如果作者阅读了《Clean Architecture》，他就会明白要面向抽象，而不是具体去编程。他就会面向品牌这个概念去编程，而不是面向具体的品牌1，品牌2去实现。

如此这般，我们当时践行了编码里的童子军规：当你离开营地时候，要让它比你来的时候更整洁干净。

最近两个月一直忙于面试，沟通了有近百人。大部分候选人都没有阅读书籍的习惯，甚至连技术书籍都不读。作者在面试中深感喜欢阅读技术书籍的人，应该都不会太差。

回家开篇的注释问题，想和大家一直分享下代码重构过程，如果不幸被作者看到，希望不要介怀。每个程序员都应该接专业眼光的检视，要遵循代码整洁的原则。

成为一名优秀的程序员！