Blog2: 编程偏执

English Version

我认为所有人都有自己的编程偏执，只要他写过足够多的代码。最近，我发现我的 coding 偏执对我造成了不小的影响。当然，这个影响不一定是负面的。在这篇博客里，我会探讨一下偏执和习惯的区别，并分享我自己的 coding 偏执。

首先，我们需要理解偏执和习惯的区别。这里有一些结合 coding 的定义：

习惯是我们几乎自动遵循的常规，使我们的工作流程更加顺畅。而偏执则更深层次、更强烈，它们反映了我们的个人怪癖和执着，比如对特定编码风格的坚持或对代码完美重构的需求。

"偏执"这个词并不是一个好词。在日常生活中，我们可能会遇到一些人为了一些看似小事而发疯。例如，有些人会因为我们不使用公筷或进门不换睡衣就失去冷静，变得歇斯底里。

在编程中，情况也很相似。程序员可能会对工作中的某个方面产生执念。例如，他们可能会花费大量时间确保每个变量名称都非常具有描述性，或者确保代码优化到最后一毫秒的性能。这些偏执有时看起来有点过头，甚至可能减慢整个项目的进度。

但事情是这样的——这些编程偏执也有积极的一面。它们经常推动我们编写更清晰、更高效和更可维护的代码。就像一把双刃剑：它既可以带来不必要的压力和时间消耗，也可以推动我们达到更高的工作质量标准。

让我分享一下我自己的编程偏执吧：

我特别喜欢重构代码。当我进入一个新的研究领域时，我通常会先找到大家用得最多的代码。但我不会直接在上面修改，而是花费大量时间重写它以符合我自己的编码风格。原始代码和我的风格实在太不同了，我无法直接使用。
在这个过程中，我可以更好地理解不同模块之间的相互作用。然而，这种偏执也带来了很大的风险。我在重构过程中非常容易引入 bug。轻微的bug可能只是运行时出错，这种情况我还能修复。但严重的问题是那些不会报错的隐性bug，比如导致模型性能低于baseline，或使后续改进完全失效。尽管有这些风险，我还是无法接受使用原始代码。
这就是我的偏执。我无法接受使用原始代码，因此花费大量时间重构以使其符合我的风格，即使这意味着要面对这些潜在的风险。

每个人都有自己的偏执，因为每个人都是独特的。我爱我的偏执，也希望你们也能拥抱自己的偏执。祝愿你们 coding 顺利！