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