我最近在接受采访时被问到我对如何成为优秀程序员的看法。这是一个有趣的问题，我认为无论我们的才能如何，如果我们遵循一些规则——我相信——应该是常识，我们都可以成为伟大的程序员。事实上，这些规则并不仅适用于程序员，也适用于任何专业人士。

当然，以下要点并不都是完全正儿八经的，有些事情只是我的看法，你的情况可能会有所不同，所以如果出现矛盾的话，不要耿耿于怀。

1.    学习如何提问

基本上是这些类型的程序员提问：

l  完美主义者：特别是在询问关于某些开源工具的问题时，他们可能已经通过代码调试并找到了问题的真正原因。但是即使没有，完美主义者也会讲明白这个问题，重现步骤，建议可能行得通的解决方法，或者甚至是，建议可能行得通的修复途径。事实上，完美主义者没有问题。只有答案。

l  话匣子：这个人实际上没有问问题。相反，他们表明他们的想法，有时会到处放置浮夸的问号。对于问题，他们给出的是他们的思路流程，如果你揣着答案等的话，他们要么自己找到了答案，要么在多封电子邮件之后才问出真正的问题。“哦，对了，我发现这个需求是完全错误的，我用一些其他的技术解决了这个问题。实际上，我完全改变了库。”呵呵。只希望他们别再问问题了。

l  懒鬼：代码在这。我不知道哪里出错了？请帮帮我。

l  经理：对于这种类型的人，时间就是金钱。问题必须简短，答案尽快。讽刺的是，因为保持问题简短（意即：不完整，不简洁），大多数情况下，会丢失很多重要的细节，然后为了解答问题，程序员只能请求更多细节。所以，经理（自然会失望，因为他得到的并非是一个答案而是一个新的问题）会再次发送一个短的讯息，并且更紧急地要求答案。循环往复。最后可能需要1-2周的时间才能解答。

l  抱怨者：这类人不问问题。他们一直一直抱怨，直到问题消失。如果情况没有变好，那就有了更多的理由抱怨。

到目前为止，应该清楚的是，一个准备充分的问题（简洁，简单，简短，但有足够的细节）将产生更好的答案。如果你确切知道对于该问题你需要学习什么，那么更有可能得偿所愿。

2.    学习如何避免提出问题

实际上，最好尽量避免提问。或许你可以自己弄清楚呢？当然情况并不总是如此。许多事情你根本无法知道，通过询问领域专家，有助于找到抵达成功最快和最有效的途径。但是，经常自己去尝试解决问题有很多好处：

l  通过这种艰辛的方法学到的东西能够更好地保存到记忆中——我们将牢牢记住所学到东西。

l  自己去寻找答案更有价值。

l  你不会制造“噪音”。还记得前面所说的“话匣子”吗？除非你询问的人有责任回答问题（从而推迟他们的工作），否则他们可能会在不了解你的思维过程的情况下，来尝试回答每一个不完整的“问题”。这对任何人都没有帮助。

l  通过推迟问问题（至少一段时间），你可以收集更多的相关信息，然后提供给可能能够回答问题的人。想想“完美主义者”，他们花更多时间寻找细节，然后解答问题。

l  通过训练你可以更擅于提问。这需要时间。

3.    不要遗留破碎的windows

最近有一篇非常有趣的文章，是关于不要留下破碎windows的。文章的本质是永远不要妥协于质量。永远不要成为逃兵。永远不要遗留破碎的windows。以下引用自这篇文章：

其实，这并非意味着要成为一个完美主义者。有时，修复破碎windows是可以推迟的。但是，通常情况下，对于允许windows被打破和保持打破状态，没有人会觉得开心。我们程序员不开心，我们的客户不开心，我们的用户不开心，我们的项目经理也不开心。这是一种态度，是作为专业人士的核心内容。Benjamin Franklin怎么看呢？

一切都是如此。“低价”是我们用一种草率的方式来实现某些东西而获得的快速胜利。

4.    软件应该是确定性的。这是要瞄准的目标！

在理想化世界中，软件中的一切都是“确定性的”。我们都是函数式程序员，编写无副作用的纯函数。如String.contains()。无论执行以下操作多少次：

assertTrue("abcde".contains("bc"));

结果总是相同的，都是预期的结果。哪怕宇宙爆炸对这一计算也没有影响。这是确定性的。

我们也可以在我们自己的程序中，而不仅仅是在标准库中做到这一目标。我们可以尝试尽可能多地编写无副作用的确定性模块。这真的与我们选择什么技术无关。确定性编程可以用任何语言完成——即使函数语言有更多工具也可以通过更复杂的类型系统来防止意外的副作用。但是我所示的例子是一个Java示例。对象方向允许确定性。对的，像PL / SQL这样的程序语言允许确定性。如果要在索引中使用函数，那么需要请求确定性的函数：

CREATE INDEX upper_first_name ON customer (upper (first_name));

-- Deterministic function here: -----------^^^^^^^^^^^^^^^^^^

这又是一个规则问题。有副作用的过程/方法/“函数”是为“破窗户”。有副作用也许会更容易维护，当然希望最终可以消灭副作用。但这通常是自己骗自己。当将来的某一天意外突现的时候，就是你付出昂贵代价的时候。别不相信，说曹操曹操就到。

5.    接受意料之外的事情

程序员始终应该遵守墨菲定律。一切都可能被打破。并且它即将被打破。作为软件工程师，我们应该谨记它是会破掉的。因为我们的世界是不确定的，所以我们正在实现的业务需求也是不确定的。我们只有在终于能够确定的时候，才能实现技巧#4（确定论）。否则，我们将不可避免地进入不确定论的世界（也就是“现实世界”），即一个将会出错的世界。所以，要以此为基础。接受意料之外的事情。训练你内心的洪荒之力，从积极的角度预见各种麻烦。

当然，如何以简洁的方式写代码来预见各种麻烦就是另一个故事了。如何从那些可能会失败的东西（因此不需要处理）中辨别那些将会失败的东西（因此需要处理），还是需要通过一些实践滴。

6.    不要货物崇拜。不要教条主义。始终具体情况具体对待。

所有教给你的内容都存在潜在的错误。即使是那些流行语。引用一句很不错的话：

我们的职业充满了虚假。我们喜欢把自己当作数学家，坚持最纯粹的思想，认为它们一定是正确的。

那是一条歧路。我们的职业构建在数学的基础之上，但除非你进入范畴论或关系代数的时髦世界（即便你真的进入，我也怀疑一切是否是“正确的”），否则你就得面对现实世界务实的业务需求。好吧，坦率地说，这离完美还有十万八千里。让我们来看看一些最流行的编程语言：

l  C

l  Java

l  SQL

你真的觉得这些语言一点都不像数学吗？行，不如我们先来讨论段错误，Java泛型和SQL三值逻辑。这些语言是由实用主义者建立的平台。所有这些都有一些非常酷的理论背景，但最终，还是有了这些工具。

对于建立在语言之上的所有东西也是如此：库，框架，设计模式，甚至架构。没有什么是对的或是错的。一切都是为某些上下文设计的工具。想想在其上下文中的工具。永远不要把这个工具当成一个独立的理由。我们不是“为艺术而艺术”。

所以，不要质疑：

l  XML

l  JSON

l  功能编程

l  面向对象编程

l  设计模式

l  微服务

l  三层架构

l  DDD

l  TDD

l  实际上：*DD

l  不胜枚举

所有这些都是某些给定上下文的好工具，但并不总是如此，要学会具体情况具体对待。保持好奇心，开发创造力，知道何时才需要使用这些工具，你将成为一个更优秀的程序员。

7.    就是干

这是真理。

但大多数程序员只达到“好”的级别，或是有潜力达到“好”的程度。那么怎么才能成为一名好的程序员呢？伟大的软件不是一天可以写成的，受欢迎的人并非我们这个时代唯一的英雄。我遇到过许多默默无闻但伟大的程序员，他们孜孜不倦地攻克软件难题，解决了许多小公司隐蔽的问题。

伟大的程序员都有一个共同点：遇到问题就是干。练习，实践。每天都致力于工作与学习，然后变得越来越优秀。

想要更擅长SQL？那就干吧！每天都尝试用一些新功能编写一个SQL语句。使用window functions。分组。递归。分区的外连接。MODEL和/或MATCH_RECOGNIZE子句。不需要每次都交付生产，但这些都是有价值的。

8.    专注于一个主题（从长远来看）

可能只有很少一部分“优秀的”全栈开发人员独领风骚。事实上，大多数全栈开发人员都将位于中间水平。当然，一个小团队可能只需要几个全栈开发人员，就可以涵盖很多业务逻辑，快速推出一个新的软件。但是，软件将非常笨拙，“马马虎虎能工作”。也许这对于只要可行即可的产品阶段来说就已足够，但从长远来看，会导致全栈开发人员将没有时间来正确分析（或预见！）更复杂的问题。

主要专注一个主题，并真正擅长这个方面。真金不怕火来炼，只要你有本事，那么走到哪里都需要。所以，致力于你的职业生涯，做一些真正好的东西，而不是“差不多就行”。

9.    涉猎广泛

虽然你应该主要关注一个主题，但不应该完全遗忘其他方面。你永远不能马上真正擅长SQL、扩大、扩展、低级性能、CSS、面向对象、需求工程、架构等等的所有内容（见技巧#8）。这是不可能的。

但你至少应该理解每一个的本质。你需要明白何时SQL是正确选择（何时不是）。何时低级别性能的调整很重要（何时不是）。CSS原则上如何工作。面向对象、FP优点等等。

你应该花一些时间涉猎这些（以及更多）概念和技术，以便更好地了解它们的重要性。知道何时应用它们，然后再找专家来实际执行工作。

涉猎新的范式和技术，有助于你用全然不同的思维方式思考，可能你会在以后的日常工作中不自觉地以某种方式用到它们。

10.保持简单

爱因斯坦曾说：

“Everything should be made as simple as possible, but no simpler.”

没有人能够处理巨大的复杂性。在软件中不能，在生活的任何其他方面也不能。复杂性是好软件的杀手，因此简单性是推动者。容易明白。难以实施。你需要大量时间和实践才能识别和生产出简单。当然，你可以遵循许多规则来实现简单化。

最简单的规则之一就是使用只有少量参数的方法/函数。让我们来看看吧。前面提到的String.contains()方法就是如此。我们可以写”abcde”.contains(“bcd”)，不阅读任何文档，每个人都能立即了解这做什么以及为什么。该方法做了一件事情，并且只做这一件。没有复杂的上下文/设置/其他传递给该方法的参数。没有“特殊情况”，也没有任何警告。

同样，在库中简化比在业务逻辑中要简单得多。那么我们能实现吗？也许吧。通过实践。通过重构。但像伟大的软件一样，简单性也不是一天可以搞定的。

（高级技巧：应用康威定律。在一个业务超级复杂的环境中编写又好又简单的软件是完全不可能的。要么你选择复杂性和丑陋，要么你最好摆脱那个业务）。