干货 | 成为优秀程序员的十条技巧

这篇文章很对程序员来说很适用，在这里分享给你！

交流，编码，会玩，绝不松懈等。在本文中，我们就如何成为一名优秀的程序员提出了十条建议。

这是一个很有趣的问题，如果遵循一些我认为的一些常识和规则，无论你的才能如何，我认为人人都能成为优秀程序员。

实际上这些规则并不止适用于程序员，而是适用于任何专业人士。

其实并不是所有的东西都是那么严肃认真的，有些东西只是我的看法，你可能在有的经历上与我不同，不是所有的程序员的个性都符合我遇到的人物情况。

1、学习如何提问

一些提出问题的程序员类型有如下几种：

1）完美主义者

这种类型的程序员在问一些关于一些开源工具的问题。他们大多数已经通过代码进行了测试，发现了问题的真正原因。即使不是这样，完美主义者也会写出问题介绍、重现的步骤，潜在的建议解决方法。

其实，完美主义并没有问题，只有答案。

2）话匣子

这种类型的人不会问问题。他们公开自己的想法，并偶尔在这里或那里提出一个修辞问号。什么似乎是一个问题，实际上只是描述自己的思想流。如果你想给答案，他们可能已经自己找到答案，或者在邮件中提出了真正的问题。

或许，或者，也许，如果我们这样尝试…你知道吗？原来，这个需求是完全错误的，我用其他技术解决了这个问题。哦，我其实完全改变了库。呵呵，别再问问题了。

3）懒鬼

“这是源码”。怎么了？

“请帮我”…

4）经理

对于这种类型的人，时间就是金钱。要求问题必须简短，答案尽快给出。这种方法存在一些问题，因为通过简短的问题，可能不完整，并不简明扼要。很多时候重要细节没有披露，后期丢失细节的需求。

之后，经理会感到失望，因为答案不对，或者又产生了一个新问题。他会不断的发送信息，要求更快的答案，反复几次后，可能得1-2周的时间才出来真正的答案。

5）抱怨者

这种人从来不提问题，只会抱怨，直到问题消失为止。也许，如果不是它更好…等等诸多抱怨。

到目前为止，我们应该清晰的是，一个准备充分的问题：简洁、重点突出，又有足够的细节，将会产生更好的答案。如果我们都学会了如何提问题，那么很快就能得到你想要的。

2、学习如何避免提问

其实，很多情况下，最好尽量避免提问题。

也许你可以自己搞定？当然不总是。许多事情，我们根本不知道，通过咨询相关领域专家，你会发出错最快、最有效的成功之路。

在大多数情况下，尝试自己搞定有诸多好处。如下：

1）你学会用“坚强的方式”，这种坚持让我们使用的记忆方式更好，我们会牢记我们学到的东西。

2）让自己做的东西更有意义。

3）不制造“噪音”。上面喋喋不休的话匣子就是这样。除非你经常问问题的人他也经常回答你，而且有时候也会推迟回复答案。如果不这样，他们可能没法看透你的想法并尝试回答每个不完整的“问题”。这对任何人都没有帮助。

4）通过推迟一段时间再提问，你自己可以收集更多的信息，可以提供给可能回答问题人更多的内容。

这里，可以借鉴“完美主义者”，先花大量的时间探究细节，然后再回答这个问题。

5）通过培训来学习怎样提问题，你会更好的提问题。这需要一点时间。

3、不要离开打破的窗户

“当我们采取某些捷径在最短的时间内提供某些东西时，代码会反映我们如此粗心，开发者们（来自同一团队，未来团队，甚至是我们自己）将会得到严重的结论：我们对生成的代码给予足够的关注严重不足，我们的应用程序在一点一点地恶化，成为一个不可逆转的过程。”

这是来自Reddit上的一篇文章——名为“不要离开打破的窗户”的节选。

这篇文章的精髓是，对质量永不妥协，永远不要变成懒鬼，永远不要离开打破的窗户。

事实上，即使不是完美主义者，在修复破窗需要一段时间。在通常情况下，我们会立即将窗户打破。如果不这样，我们将引入一个没有人感到开心的情况。

不是我们的程序员，不是客户，不是我们的用户，不是我们的项目经理。这是态度上的事情，也是职业化的核心。

富兰克林说：在低价的甜头被遗忘后，长期以来质量差的苦头会仍然存在。

4、软件是确定性目标

在一个理想的世界里，软件中的一切都是“确定性的”。我们要编写没有副作用的纯函数。像String.contains()。无论你执行以下几次：

assertTrue(“abcde”.contains(“bc”));

结果总是相同的预期结果。宇宙及期全部状态对这个计算绝对没有影响，是确定的值。

我们也可以在我们的程序这样做。而不仅仅是在标准库中。需要我们尽可能经常性的编写无副作用的确定性模块。

这些不是我们选择什么技术的问题，确定性编程可以用任何语言完成 - 即使功能性语言有更多的工具可以通过更复杂的类型来防止意外的副作用。

比如下面的PL/SQL允许确定性。如果函数在索引中使用，则它是一个确定性需求。

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

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

所以再次说明，这是一个开发者的纪律问题。

如果你看到副作用的程序/方法/函数为“破窗户”。也许保持副作用更容易，希望最终可以将其删除。但这通常是一个谎言。

当非决定性因素突然袭击时，价格将在稍后支付。

5、期待例外事件

程序员应该始终遵守墨菲定律。一切都可以打破。作为软件工程师，我们知道它会被打破。因为我们的世界是不确定性的。我们正在实施的需求也是不确定的。

但是我们的实施是确定性的，直到它不再可能变化。

从我们做软件开发开始，我们将不可避免的进入非确定性的现实世界，那里一定会出现错误。所以，请瞄定它。

我们要期待例外与变化，以此来训练和改变自己用内心的悲观主义来预见各种事物。

当然，如何以简洁的方式编写悲观的代码是一回事。

如何区分那些可能会失败但不需要处理的事物与将要会失败并不需要处理的事物，需要一些刻意练习。

6、永远不默守成规，教条

我们学过的每件事都可能是错误的。包括（或可能，特别是）真正流行时这么说。

这里有一句话：

我认为我的职业生涯中至少有50%在促成或展开一场灾难或另一场灾难。

我们的专业其实充满虚伪，我们喜欢把自己当作数学家、科学家，认为只有最纯粹正确的想法才会持续下去。

这其实是个错误。我们的专业建立在数学的基础上，但除非你进入类别理论或关系代数这种世界。即使这样，我也怀疑所有东西的“正确性”，我们都处在实际业务需求的世界中。坦率地说，这些都是那么不完美。

我们来看一些最流行的编程语言，比如C、Java、SQL等，你认为这些语言与数学相似吗？如果是，我们来看Java泛型或SQL三值逻辑的分段都是错误的。这些语言都是由实用主义者创建的平台。

他们都在建立之前有一些非常酷的理论背景，但最终他们不得不完成这项工作。

对于建立在语言之上的所有东西也是如此：库，框架，设计模式，甚至架构。没有什么是对或错，一切都是针对某种情况设计的工具。

我们要在其上下文中思考该工具，切勿将此工具视为独立存在的理由。不是为了艺术的缘故，我们不是在做艺术 。

所以，我们不要质疑：

XML

JSON

功能编程

面向对象的编程

设计模式

微服务

三层体系结构

DDD

TDD

等等…

所有这些都是在一定背景下的好工具，但它们在逻辑并不是总成立。

通过保持好奇心并开箱即用，你将成为更好的程序员，并知道何时使用这些工具中的哪一个。

7、去做

真的，此时才能产生超过大多数人的杰出人物。

但是大多数程序员只是“好”，或者他们有潜力成为“好”的人。你怎么能成为一名优秀的程序员？

我们通过以下方式。

伟大的软件并不是一天写成的，而明星也不是我们这个时代唯一的英雄。我遇到过很多并不知名的优秀程序员，他们过着私人的悠闲生活，解决着小公司的问题。

优秀的程序员都有一个共同点：他们不断做，不断练习。他们每天都能把工作做得更好，更加好。

想把SQL中做得更好？做吧！尝试写一个SQL语句，在其中添加一些新功能。使用事务，分组集合，递归，分区外连接，MODEL、MATCH_RECOGNIZE子句。它不必每次都能够在生产环境上使用，但这种做法是值得的。

8、长期关注一个主题

在这里可能只有极少的“优秀”全堆栈开发人员。相比之下，大多数完整的堆栈开发人员在很多方面表现平庸。

当然，一个小团队可能只需要其中的一小部分角色，涵盖很多业务逻辑来快速启动开发一个新软件。但是，一切都会相当草率，并且“有点奏效”。或许这对于最小可行产品阶段来说已经足够了，但从长远来看，将会有更复杂的问题出现，即整个堆栈开发人员没有时间来正确分析（或预见）。

关注一个主题并且非常擅长。只要该专家的利基存在，专家就会始终处于需求之中，许多专业领域将超越我们所有人（比如人工智能或大数据）。

所以，请将一个最擅长的做好，并且据此做很好的事情，而不是很多事情都好。

9、把玩技术

虽然你应该关注一个主题，但你不应该忘记其它主题。您可能永远不会真正擅长所有的SQL，一次性扩展，高级别的性能，CSS，面向对象，需求工程，架构等。这不可能的。

我们应该掌握每一个技术的本质。你应该明白什么时候选择SQL是正确的选择，当低级别的性能调整很重要时。CSS是如何工作的，推荐算法等的优点。

我们应该花一些时间玩耍，投入这些一些概念和新技术，以便更好地理解它为什么重要，知道何时应用它们，然后或许找到合适的专家来实际执行。

通过对新的范例和技术的把玩，你会打开完全不同的思维方式，而且以后有机会在日常工作中使用到它。

10、保持简单和愚笨

爱因斯坦说：“一切都应该尽可能简单，但并不简单。”

没有人能够处理巨大的复杂性。不在软件中，不在生活的任何其他方面。复杂性是优秀软件的杀手，因此简单性是推动者。

这话说起来容易，但很难实施。简单是需要花费大量时间和实践来识别和生产的。

有很多规则可以遵循：

有一些简单的规则，比如函数和方法只有很少参数。并且不需要阅读任何文档，每个人都会立即明白这是什么，该方法只做一件事和一件事，也没有复杂的上下文/设置/其他参数可以传递给方法，也没有特例。

同样，在库中生成简单性比在业务逻辑中执行简单得多。我们需要通过练习、通过重构来完成。 和所有伟大的产品一样，简单性不是一天建成的。