如何成为卓越程序员：意识、理解与责任
成为或成为一名卓越程序员有三个关键因素：意识、理解与责任。
关于“理解”这一主题，我已经谈了很多。事实上，我最近的一本书甚至就命名为《理解软件》。我特别多次指出，你对某事物的理解越深，你就越能做好它。
然而，除了理解之外，还有另外两个因素共同作用，使人成为优秀的软件开发人员。简而言之，如果你没有意识到一个问题，就谈不上理解。而如果你不采取行动解决问题（这始于承担责任），那么你就无法做任何事情。
不过，关于每一点都有很多需要了解的内容，而且当人们考虑如何成为更好的软件开发人员时，这些是关键点。因此，我想在这里更深入地探讨每一点。
意识
在某种程度上，这是理解的一种专门形式。“意识”本质上意味着你能够感知某物并知道它的存在。这有很多方式适用于编程。
让我们举一个最简单的例子：如果你没有意识到一个 bug，你就不可能修复它。
有时，人们利用这一点来逃避对问题采取行动。他们认为，如果他们不知道，就不必做任何事情。这可能是真的，也可能不是，但事实是，问题存在与否并不取决于你是否个人知道它。如果你的系统有一个影响数百万用户的 bug，那么你应该意识到它。否则，你的用户将会受苦。他们的痛苦并不会因为你不了解而变得合理——也就是说，仅仅因为你不知道，宇宙并不会突然变得没问题。
还有更微妙的意识形式。例如，有些人实际上并没有意识到代码复杂性。他们没有意识到他们刚刚编写的代码是复杂的。有时，他们甚至没有意识到复杂性是一个问题，或者没有意识到必须阅读他们刚刚编写的代码的其他程序员的观点。他们没有看到代码缺少注释，难以阅读，或者有其他解决问题的方法。所有这些都是程序员意识的方面。
作为程序员，提高意识的最简单方法是愿意走出去阅读超出你正常控制范围的代码。也就是说，也许在日常工作中，你处理的是编码视频的代码。但视频也来自某个地方——用户将其上传到你的系统中。如果你遇到视频如何进入编码器的问题，那么也许你应该选择去看看那段代码实际上是如何工作的。
这听起来很简单，但对许多人来说，在情感上可能相当困难，有时甚至包括我自己。很容易想，“那边的都是白痴，这很糟糕，我只能绕开它。”但如果你没有看过他们的代码，你怎么知道呢？也许你会学到一些对你有帮助的东西。
意识也可以是关于知道可以在代码中使用的库、框架或工具的存在。也许你对最新的 Web 开发库并不了解一切，但如果你是 Web 开发人员，你至少应该知道它们的存在。然后，当你需要决定使用哪个框架时，你知道该去看哪些。
总的来说，一个人可以通过愿意体验新的编程语言、新的设计模式、关于测试的想法、新的框架等来提高意识。我个人想知道关于编程的新系统和方法。当我听说一种新的语言风靡一时时，我会去至少阅读其网站的主页，有时甚至深入研究其文档。这样，我至少知道这个东西存在，如果需要，我可以了解更多。如果我不知道解决问题的不同方法，那么作为软件工程师，我拥有的工具就少得多。以这种方式提高意识，增加了我在面对困难情况时的选择。
这一切可能听起来过于简单，但非常真实：你可以通过提高对编程和程序的意识来提高作为程序员的能力。
理解
正如我在别处提到的：你对某事物的理解越好，你就越能做好它。
意识是第一步——你知道一个东西存在。之后，你想要理解它以便做好。让我用一个虚构的伪代码语言给你一个例子：
|
|
你认为这个程序是做什么的？看起来它清除了终端，然后打印了单词“Hello”。但老实说，我只是在猜测。我没有看过 clear_screen 或 write_hello 的文档或代码。如果我看代码，我会发现 clear_screen 实际上把整个屏幕变白，而 write_hello 用十五种不同的语言和颜色在屏幕上打印单词“HELLO”。但如果不实际查看一些东西来理解它，我永远不可能知道这一点。
这可能看起来像一个过于简化的例子，但这在编程中一直发生。现在我知道 clear_screen 是做什么的，我可以在其他地方使用它，而不必思考或花时间重写它。我可以编写一个做我打算做的事情的程序，而不是一个有 bug 的程序。我可以为它编写一个有意义的测试。所有这些加起来就是简单性、稳定性以及我们认为是“良好编程”的所有其他品质。而所有这些都源于理解。
还有其他形式的理解，我在几篇文章中已经讲了很多，尤其是《为什么程序员很烂》。这确实是决定程序员成败的关键点。还有其他有用的技能——快速打字、良好沟通、适当管理优先级，以及许多其他技能。但关键点是理解。没有它，你可能是世界上最快的程序员，但只编写糟糕、不可维护的系统。你可能是团队中最有魅力的人，但完全无法编写一行有效的代码。我不是说快速或有魅力是坏事——这些也是有用的技能——但没有理解，它们不会让你成为伟大的开发人员。
责任
我在第一本书出版后不久在 O’Reilly 博客上写的一篇文章中谈到了这一点，但我不确定有多少 codesimplicity.com 的读者读过那篇文章，尽管这实际上是关于成为伟大程序员的一个非常关键的点。
首先，我想澄清一些事情。这里的“责任”并不是指“为出错的事情承担责任”。那是责任的常见定义，但不是我使用的定义。在这种情况下，我所说的“责任”是指“愿意成为某事物的原因或控制者”。例如，如果我对我的房间负责，我愿意打扫它。这并不意味着我必须打扫它，只是我完全愿意。而且不仅仅是“哦，是的，我完全愿意打扫我的房间”这样的大公关声明，然后去躺在混乱中三个小时。不，我的意思是真正、实际地愿意。就像，你愿意吃你最喜欢的甜点吗？那就是愿意。我不是说你必须对每件事都像对你最喜欢的甜点一样兴奋，我只是说必须有实际的意愿。
那么这如何应用于编程呢？嗯，我经常遇到这个负面例子：
“我不想重构那段代码，因为我不拥有它。”
这很傻。你能编辑它吗？你能阅读源代码吗？你被允许向所有者发送更改吗？那么理论上你能够修复它。现在，这并不意味着你应该一直到处修复整个世界中的所有代码，因为有时在你的开发目标方面，这不是正确的时间权衡。但甚至这句话我也不愿说，因为人们经常用它作为不清理事物的借口：
“我不能花任何时间清理那个团队的代码，因为这会让我的项目花费更长时间。”或者，“嗯，清理我依赖的这段代码不是我团队目标的一部分。”
好吧，这些理论有两个缺陷。（相信我，它们真的是理论——不是事实。）
第一个是，通常，当你依赖糟糕、疯狂或复杂的代码时，正确地做某事需要更长时间。通常，重构然后编写你的功能实际上比尝试在一些混乱或可怕的库之上编写你的功能花费的时间更少，而这些库完全不符合你的需要。所以你通常不会为你的目标增加很多额外的时间。之所以看起来如此，是因为你没有考虑“完成”某件事和实际完成某件事之间的区别。
我所说的“实际完成”是什么意思？嗯，我的意思是它有效，不会一直充满 bug，你可以轻松维护它，它不会耗尽你作为开发人员的整个生命，你可以继续做其他有生产力的事情。
这样想这个问题。想象一下你正在建一堵墙，你从底部开始用一些劣质砖块。然后你在上面再放几层砖。但当你放到大约第四层砖时，底部的劣质砖开始破裂。然后你去用一些劣质木材修补劣质砖。你再加几层砖，现在墙开始倒塌。所以你用一些生锈的铁条支撑它，继续你的工作。如果你继续这样，你将花费整个生命仅仅维护这堵墙。它将成为你生活中的一个巨大问题。你可能最终会走开，留给别人这个可怕的灾难墙，他们现在必须维护它，但他们甚至不理解，因为它看起来像是一个疯狂混合的劣质建筑材料，没有理智的人会组合使用。老实说，这相当残酷。
当你在底层依赖中“黑客”或“修补”糟糕代码时，你正在以建墙的方式构建你的软件。这不太明显，因为程序没有巨大的物理结构可以倒在你的脸上。但尽管如此，相同的构建原则适用——当你通过在上面添加复杂性来解决底层复杂性时，你增加了系统的复杂性。当你解决底层复杂性时，你减少了系统的复杂性。
我想指出，最初是谁让事情变得复杂并不重要。“别人做的”这一事实并没有改变上述任何规则。现在谁拥有复杂性也不重要。如果你绕过它黑客，你会使系统更复杂。如果你修复它，你会使系统更简单。你正在做出选择——你有这种力量，你可以负责。是的，有时这涉及让别人修复它。但根据我的经验，更常见的是你愿意自己做出改变。
当然，也许你知道所有这些。但你仍然可能想，“哦，好吧，我可以只让这一小块这次稍微复杂一点，因为这只是我正在做的这一件事。”你知道，有时，你可能是对的，特别是如果你有某种合法的紧急情况，你必须黑客某物只是很短的时间。但更常见的是，你实际上是在为一个巨大的破碎墙混乱做出贡献，这将成为你和每个人维护的噩梦。正是这些小小的复杂性，这些不负责任的小选择，最终累积成没有人想处理的巨大破碎混乱。
所以当我以这种方式说“责任”时，我很大一部分意思是“愿意改变你正常范围之外的事物”。它不必是无限的范围。你可以在某处划一条线，说：“超出这一点，真的是别人的问题。”例如，在我的项目中，我经常划一条线，说：“好吧，我不会对完全来自公司外部的代码做太多工作，因为这不是我时间的高效使用。”但我有时甚至到了提交编程语言错误或向开发工具发送补丁的程度，当我认为它们导致复杂性或让我的生活更困难时。我的意思是，我实际上成为了 Bugzilla 的主要架构师，因为我认为它有很多需要修复的地方。我不是说每个人都应该走那么远。但我是说，通过接受项目范围之外的一些代码的责任，你会成为更好的程序员。而且你把这个范围扩展得越广，你就会成为越好的程序员。
哦，顺便说一下，我说上面的理论有两个缺陷。第二个是你实际上属于一个群体，即使那个群体只是人类。你不是唯一的人。为别人的代码做贡献是可以的。我们实际上都在同一个团队中。
如果你为公司工作，当你遇到这些问题时修复它们，你就是在帮助整个公司。如果你只是世界上的一个个体开发人员，当你修复一些广泛使用的库、一些流行工具或网络上某处的糟糕示例代码时，你正在为每个其他程序员让世界变得更好一点。老实说，这让你成为更好的程序员。这就是我在这里说的全部重点。我认识的最好的程序员是那些最愿意承担广泛责任的人，无论他们必须接触哪段代码或必须与哪个团队交谈来完成工作。我告诉你这些是因为它会帮助你。
顺便说一下，作为库或 API 的消费者，通常你处于重构它的最佳位置，因为你比作者更了解应该如何消费该库或 API。至少，提交一个错误说明你遇到了什么问题。否则作者怎么会知道有问题？你可能只是期望他们神奇地知道，但相信我，他们经常不知道。你的经验对他们可能非常宝贵，谁知道呢！
总结
总的来说，如果你想成为更好的程序员，要问自己的是你应该提高意识、理解还是责任，然后专注于这一点一段时间。如果你不确定，从意识开始，然后进入理解，最后承担更多责任。反过来做非常困难——你无法轻松地为你不理解的事情承担责任（这会非常混乱，你也不会很擅长），而不可能理解你没有意识到的事情。所以意识、理解，然后是责任是正确的顺序。
如果是意识你应该提高，只需阅读一些新代码，找一个新的编程博客，四处看看书名，与其他程序员谈谈最新技术——任何只是帮助你更意识到问题、解决方案、知识、模式、人、组织、原则或任何其他对你的工作有帮助的东西。
如果是理解你想专注于，那么阅读更多文档，花更多时间理解每个函数如何工作，向你的程序员同事问更多问题，在字典中查一些单词，阅读一些关于你正在使用的技术的文章，或读一本书——任何达到对与你的工作相关的某些知识的完全和充分理解的方法。
最后，责任主要通过决定承担更多来实现。当问题来到你面前时，决定解决它而不是推迟它。当团队外部有困难时，决定帮助解决它而不是成为问题的一部分。还有一种特殊类型的责任——当别人有问题要解决时，愿意帮助他们，或者，如果他们应该自己解决，愿意让他们自己解决。责任不仅仅意味着你必须做所有事情。它也可以意味着愿意帮助别人完成事情。
做上述事情甚至不难——只要你以简单、单独的步骤去做。你不必一夜之间意识到整个宇宙。你不必明天就理解每个程序中的每个单词。你不必因为读了这篇博客文章就愿意改变存在的每一件软件。从小事开始。然后继续下一件事，再下一件事，再下一件事，随着时间的推移，你会成为你想要的那样好的程序员。
享受吧。
-马克斯