成为优秀程序员的三大关键要素：意识、理解与责任
作者：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