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