[转] 应该为这样的代码感到惭愧

大学时专业是机械，工作后来才干了软件。所以对于软件我可以说是半路出家。但一路走来还真应该感谢几位导师以及他们的几句话，这些话让我在钻研 技术的同时也在不断思考。

1 可以理解的才是代码，无法理解的是垃圾

   这是我进入公司后印象深刻的第一句话，这句话也让我立刻意识到我之前写过的成千上万行曾经还让我自信满满的代码很可能就是垃圾，因为自从我写过后就不想再 去看。从那以后，我就开始为不制造垃圾而努力！

 

2 最难的是命名

   那时导师无论对设计还是代码都要求很严格。代码检查的时候会不时地提出一些命名问题。有的是词不达意，有的是牛头不对马嘴。对于命名问题，被指出后可以很 快有更改方表明对问题还是有比较深刻的认识，只是命名时没有太在意。如果很难给出更改方案，那很有可能有更深层次的问题，要么函数结构不合理，要么根本没 有理解问题域。有时命名不是单纯的名字问题，同时还和分析设计有密切联系。

 

3 对自己放松就是对他人苛刻

   无论是做设计还是写代码，很多时候都要和团队成员交流或者交付给他们使用。如果在这过程中不严格要求自己，凡事都差不多就行，到最后可能就会苦了团队成 员，这很有可能还是包括自己。试想下，如果经过一段时间后自己要重新面对以前做过的，是不是很有可能会掉进当初自己设下的陷阱呢？

 

4 分清事实和假设

   这是遇到问题的时候，导师教给我的一句话。我在一次连续一周的“抓虫”行动中对这句话的感受尤为深刻。开始的几天每天都在怀疑不同的东西，而且不断地改变 方向。这样下来感觉每天都很忙，但都没有进展和头绪。到了后来不得不改变策略，严格分清事实和假设并开始明确方向，随着更多的假设被证实，“虫虫”也就无 处藏身了。

 

5 这不是在设计，而是拼凑

   再后来加入了一个新的团队，遇到了新的导师。不过我还是用原来的方式努力设计编码。但每每我提交设计的时候，导师都会告诉我“这不是在设计，而是拼凑”。 开始确实感觉很受打击，而且有些不服气，“以前我都这样的，也没有人指出什么不是，为什么到你这里就这样啊。人和人差别咋就怎么大呢？”但随着一次次被否 定后一次次的修改，我开始感受到了不一样，看到了欣喜的变化。最后我不得不承认当初自己确实在拼凑，而且拼凑得理所当然。

 

6 程序员应该为这样的代码感到惭愧！

   这是一次代码检查中的事。那时为了满足公司的一个编码规约，我把很自然的逻辑反过来写，不仅代码多了，而且也更难理解。当被指出问题后，我理直气壮地说这 是编码规约规定的。这时导师就指出了“程序员应该为这样的代码感到惭愧！编码规约是死的，人是活的，认为对的就应该坚持和尝试”。会后我反思了下，其实写 代码的时候我就很矛盾，但一念之差我还是选择了编码规约。后来在遇到类似的情况，我就更有勇气听自己的心，至少尝试一下。否则感觉对不起这样一个职业。

 

上面的很多话都已经过去很久了，但每当想起总还感觉就在耳边。这也许是因为他们真正触到了我的心，并让我的大脑不断思考。