原文：What I Didn't Understand as a Junior Programmer
译者：杰微刊兼职翻译张万程
作者：Alex Naraghi
我还记得第一次接触百万行代码库的时候是在我实习期间，那是一个有十多年历史的老系统，使用多种语言编写，上千个单元测试，被分成多个工程和dll文件，编译一次需要一整晚。有些工程的构造过程十分复杂，需要额外的脚本，甚至代码控制系统还有自定义的钩子，用来阻止代码风格不规范的提交。那时我感觉阅读相关文档需要花费一周的时间。我的领导告诉我通常深入了解这些工程。需要一年的时间，但的是的实习只有3个月的时间。
天哪,我想,难道这就是程序员的毕经之路吗?，
那时候,我知道自己掌握了哪些知识。不客气地讲，我知道所有常用排序算法的算法复杂度。学校里的课程对我来说很简单，我已经和朋友发布了两款游戏。我掌握了面向对象的所有知识。
我不想写出拙劣的代码，尤其是挣钱的商业项目，不像简单的课堂作业。更糟糕地是你担心那些老鸟们会看穿你的愚蠢。知道你在漫无目标的乱写代码，你修改了无数次的代码被他们删掉90%。这样一直到你放弃，耸耸肩，做些疯狂的举动。如果你们有代码审查，他们会审阅，皱着眉头发表一些观点，但你的代码是如此之混乱像是在糊弄你的领导，他们不能在你荒谬的接口和混乱的方法中看到任何的设计模式。他们眉头紧皱，盯着屏幕，"这不是一个好的代码方式,我们需要做质量测试,如果有必要,我们需要回过头来重构这些代码"。真是糟糕至极。
这是恶梦般的体验，当然我可能有点夸张。但编程确实不容易.你呆在公司里，花费整天时间非常痛苦地与代码风格，编程范式，运行时，调试工具，接口，搜索，工作计划做斗争，他们不停地打断你的思路，令人发指的是你还要保证按时完成任务。
但是，最终你还是一一战胜了它们。
我经常问自己同一个问题： 哪些知识必须从经验中得来，必须从错误中学习。我无法回答这个问题，但我想和你讲一个我所经历的特殊战争。
在过去，阻碍我成为高级程序员的最重要原因是我不能在不了解运行状态的情况下解决问题,我所谓的运行状态是指所有运行时相关数据，通常和问题密切相关。
那段时间我记忆犹新，我做出了很多努力，花费了很多时间，漫无目的地调整各种变量，希望能够解决那些我还不了解的问题，更糟糕的是我还为此感到自豪。我知道，如果我做的调整足够多，问题会发生变化，可能不太明显，也可能一下子就把问题解决掉了。那时我最大的错误是数学相关问题，主要是界面和渲染工作。如果偏高，我会把"y - box.height / 2"调整为 "y - box.height / 4"。这可以解决数学问题吗？有时候也有可能，如果我打一个断点，我可能看到很多变量，但中间数据往往看起来都是枯燥乏味，没有什么用处的感觉，所以这些代码很快就成了黑盒子。
这种解决问题的方式明显太原始，是反人类的，是愚蠢的。但却被普遍使用，对于课堂作业，小项目，它非常凑效，因为它们复杂度低，是不需要后期维护，也没有用户使用的小型代码库。只要通过老师的单元测试，你就可以拿到A+。
开发人员在他们所不明白的哪些问题上不停地转圈子，所浪费的时间是惊人的.
现在我相信，通过这种瞎猫撞死耗子的方式，虽然貌似你把问题解决了，但实际上你并没有真正解决。经常被修改的代码最容易出问题，你只是碰巧解决了它。你不仅可以维护你自己写的代码，为了解决问题你可能还会去修改以前的老代码，因为你不了解运行状态。更糟糕的是，版本控制器中的日志可能会误导将来查看这段代码的程序员，因为他会基于你的实现方式来解决问题。这种影响还是双向的，我已经从亲身经验中对这类潜在问题有了深刻认识。
幸运的是在这条路上我学到了很多东西，关于如何改进，从这种调试中解脱出来，我有一些心得可以分享给你。 如果代码非常复杂，你可能需要开始重构，提高代码可读性（重构后要检查问题是否依然存在）。创建一些测试用例，要涵盖数据的转换，验证你的假设是否成立。如果数据可以可视化，并且数据呈几何级增长，或者使用了复杂的数据存储结构，要考虑用可视化的方式来展示，如果有大量的过程数据，请准备好纸和笔，自已动手追踪运行状态。向代码的作者获取帮助。如果你失去了耐心，出去散散步，呼吸一下新鲜空气。
我相信这种方式适用于任何代码，不管有多复杂。你可以追踪运行状态的数据。代码可能不是你的同事写的，可能像意大利面一样混乱，变量命名可能天马行空般随意。但是使用简化，可视化，逐步深入，校验等方法，再加上时间，你会获取到你需要的一切。
当然，好的编程理念和设计模式可以更容易理解运行状态。如果你采用我的建议，并开始运用，你很快就会写出健壮，易于维护的代码。后面我还会写更多同类主题的文章！
如果你不了解你写的代码，或者你正在调试的代码，不要找任何借口。编程没有捷径，只有脱离实际的幻想。现在，即便已经解决了问题，我仍然要深入代码的细节，以确保自己真正地理解代码。如果有必要，我还会对它进行重构，或者在注释里加上我通过分析学到的知识。只有这样，我才认为我解决了这个问题。
可能你想绕过对代码的理解，但是在真实的项目中，这个捷径会让你和公司付出更多的时间，丢失更多的用户，还有永无休止的维护工作。避免我曾经有过的还习惯，花时间学习复杂问题的分解，掌握调试工具的使用，写一些工具帮助你更舒服地工作。这样会还清你的技术债，不再做恶梦。
“所有bug的产生，都是因为代码没有按你的设想运行。”
我不得不佩服John Carmack，他的一篇文章让我的想法更加具体。
精彩内容推荐：
