什么是优秀的程序员思维

优秀的程序员思维应该是什么样的？
有没有发现我们身边总是有很多牛人。他们可能年纪轻轻，但不管是在技术研究方面，工作方面，又或者是生活中遇到问题，都可以得心应手，当然他们的发展速度也是异于常人，不用多时就已甩开我们半条街。

思维方式对于咱程序员来说是非常重要的，有种像软件开发中架构设计的感觉。架构搭好了，原则写清楚了，剩下的都是水到渠成之事！

1.灰度思维

灰度思维表明这个世界充满复杂性，大部分的人和事并不是非黑即白。

小孩子的思维才是典型的非黑即白思维。眼里要么是好人，要么是坏人。而现实中，我们知道：好人会做坏事，坏人也会做好事。每个人都不是纯粹的好人或者纯粹的坏人。

用灰度思维去思考，事情会有更多回旋的余地。

2.双赢思维

如果一个人揭发，另一个人沉默，则揭发者因立功立即释放，沉默者因不合作入狱五年。

由于两个囚徒彼此无法信任对方，因此倾向于互相揭发，而不是一起选择沉默。

大多数人从小接受的教育更倾向于竞争，而不是竞合，于是在相当一部分人眼里，人生就是一场竞争，游戏只有击败别人分出胜负，才能成就自己。这就容易导致习惯性的损人利己。但事实上，在生活中，双赢模式才是长期相互依赖环境中唯一可行的交往模式。

3.跨栏定律

你前面要跨的栏越高，你跳的就越高，换句话说，一个人遇到的困难越大，成就往往越大。

4.复盘思维

复盘，并不是要求我们真的每一次都将过去的事情做一遍，它更多的是表达思维上对事件的重视。

对过去的思维和行为进行回顾反思，从而发现问题吸取经验，最终实现能力的提升。

复盘的作用与磨刀类似，正所谓：磨刀不误砍柴工，工欲善其事必先利其器。

温故知新，有这些顶级的思维方式指导，咱后续的开发之路、生活之路一定会向身边的牛人更靠齐！！

5.分解问题的能力

优秀程序员通常会把复杂的问题或任务分解成更小的、更容易管理的部分。这种思维方式可以帮助他们更好地理解和解决问题。

6.逻辑思维

程序员需要具备强大的逻辑思维能力，以便理解问题、设计解决方案并编写代码。他们通常会使用逻辑推理、条件判断和循环结构等思维方式来编写程序。

7.抽象思维

程序员需要具备抽象思维的能力，以便将具体的问题转化为抽象的模型或概念。这种思维方式可以帮助他们更好地理解和解决问题，并编写出更简洁、更易于维护的代码。

8.算法思维

程序员需要具备算法思维的能力，以便设计出高效的解决方案。他们通常会使用各种算法和数据结构来解决问题，并不断优化代码以提高性能。

9.创新思维

优秀程序员通常具备创新思维，能够提出新颖的解决方案或改进现有方案。这种思维方式可以帮助他们在技术领域保持领先地位，并为公司的产品或服务带来更大的价值。

10.持续学习

优秀程序员通常具备持续学习的思维模式，他们不断学习新的技术、工具和编程语言，以保持竞争力和适应不断变化的市场需求。

总之， 优秀程序员的思维模式是多方面的，包括分解问题的能力、逻辑思维、抽象思维、算法思维、创新思维和持续学习等。这些思维模式可以帮助他们在技术领域取得更好的成就。

11.构思软件的目的

首先，您应该了解该软件的目的。事实上，所有软件都有一个目的：帮助人们。

无法设想软件用途的开发人员将编写糟糕的软件。什么是坏软件？一个对人们没有多大帮助的复杂系统。

当您做出有关软件的决策时，您应该始终牢记这一点：我们如何提供帮助？您甚至可以通过这种方式确定功能请求的优先级。

12.软件设计的目标

每个程序员都是设计师。

当软件难以创建或修改时，开发人员将大部分时间花在使事情“正常工作”上，而较少时间专注于帮助用户。软件的设计旨在使开发人员的工作尽可能轻松，以便他们可以专注于重要的事情。您将创建将帮助用户的软件，并且您的软件将在很长一段时间内继续帮助他们。

但是，如果您设计了一个糟糕的系统，则软件的生命周期将很短。这就把我们带到了软件设计最重要的目标

所以这里有两个关键点：你的设计应该对你来说很容易，对其他人有帮助。

13.误解）理解

不完全了解其工作的开发人员倾向于开发复杂的系统。它可能成为一个恶性循环：误解导致复杂性，从而导致进一步的误解，等等。

实际上，提高设计技能的最佳方法之一是确保您完全了解正在使用的系统和工具。

糟糕的开发人员不明白他们在做什么，而好的开发人员会。真的就是这么简单。

14.简单

编程是将复杂性简化为简单的行为。“糟糕的开发人员”只是未能降低复杂性的人。一个“好的开发人员”正在尽其所能使代码对其他程序员尽可能简单。

一个好的开发人员会创建易于理解的东西，以便很容易摆脱所有错误。现在，开发人员通常是聪明的人，他们都不喜欢被当作白痴对待。具有讽刺意味的是，这导致他们有时会创造有点复杂的东西。他们基本上是这样想的：“哦，其他开发人员会理解我在这里所做的一切。

我应该写一些难以理解的聪明代码，这样他们就可以认为我很聪明。由错误的心态引起的错误 - 不一定是由于缺乏编程技能。大多数编程失败都是因为这种心态而发生的。炫耀你很聪明对他们没有帮助。不熟悉您的代码的开发人员对此一无所知; 他们必须学习。

所以，你应该问这个问题：“我是希望人们理解这一点并快乐，还是希望他们感到困惑和沮丧？事实是，如果阅读您的代码的其他开发人员可以轻松理解它，则意味着您做得很好。

15.复杂性

许多软件故障的根源是复杂性。

您从一个简单的项目开始，可以在一个月内完成。然后你增加了复杂性，任务将花费长达三个月的时间。
然后，您开始添加满足其他目的的功能。事情变得非常复杂，因为您无缘无故地扩展了软件目的。这些任务将需要六个月的时间。但这还不是结束。
然后，您将每个功能的一部分都变得更加复杂，任务将需要九个月的时间。
然后，由于代码的复杂性，您开始引入许多新的错误。

当然，您开始修复它们，而不考虑这些修复将如何影响其他部分。最后，即使是很小的改变也变得困难。当错误修复开始引入新的错误时，您将进入最受欢迎的编程恐怖故事之一：从头开始重写代码。那么，你是怎么成为这个恐怖故事的受害者的呢？不，谁在乎。

最好问：你怎么能避免成为受害者？嗯，这很简单。

首先，您将确切地了解您的软件用途及其定义。
其次，在你编写的每一段代码中，你都会尽可能简单。
第三，当新功能或更改请求出现在讨论桌上时，您将根据您的软件目的对其进行评估并提出质疑。作为开发人员，您的第一个行为应该是抵制（不必要的）更改。

这将防止您将不必要的代码添加到软件中。当您确信此更改是必需的时，则可以实施它。有许多因素会增加复杂性，但这些因素是最受欢迎的。除了所有内容之外，您只应该遵循一条规则：你的主要目的是控制复杂性，而不是创造复杂性。

16.维护

维护是软件开发中最重要的事情之一。不幸的是，开发人员通常忽略了它的重要性。快速编码和快速运输看起来比代码维护更重要。这就是他们犯错误的地方——对未来代码维护的无知。

总会有一些更改的实施。您不仅必须实现它们，而且还必须随着时间的推移维护它们。作为开发人员，考虑将来维护更改是您的主要职责之一。

17.一致性

不一致的代码将更难理解。不要一直强迫开发人员在每次查看系统的新部分时重新学习系统的工作方式。

18.确定优先级

您如何做出有关软件的决策？
当你面对许多可能的方向时，你如何决定哪个选项是最好的？要关注什么以及应该实现哪些功能？

当您确定工作的优先级时，应遵循以下规则：
那些能给你带来很多价值并且需要很少努力的变化比那些带来很少价值并且需要很多努力的变化要好。

19.解决问题

第一步是理解。确切地知道所问的内容。大多数困难的问题都很难，因为你不理解它们。写下你的问题，并尝试向其他人解释。
第二步是规划。不要采取行动。把问题留到第二天解决。给你的大脑一些时间来分析问题和处理信息，但不要花太多时间在计划上。行动前三思而后行。
第三步是分化。不要试图解决一个大问题。

当你把问题作为一个整体来看时，它会吓到你。将其划分为较小的任务，并逐个解决每个子问题。一旦你解决了每个子问题，你就把这些点连接起来。

20.足够好就好了

无论是创建新项目还是向现有系统添加功能，开发人员都倾向于从一开始就详细规划所有内容。
他们希望第一个版本是完美的。他们不关注他们将要解决的问题以及他们的软件将如何帮助人们。
他们首先考虑他们能想到的每一个小细节。然后是假设和预测，然后是“假设”句子。
他们必须预测未来，因为他们现在被他们脑海中的项目想象力所吸引，
他们的项目必须像他们想象的那样完美。

实际上，他们不知道等待他们的是什么，以及追求完美会让他们付出多少代价。

21.预测

预测只是对未来将要发生的事情的预测。它可以是事实，基于某种客观数据，也可以基于假设。
当面对他们的代码将来会发生变化的事实时，一些开发人员试图通过设计一个通用的解决方案来解决问题，以至于（他们相信）它将适应未来可能的所有情况。– 代码简单

过于通用涉及大量不需要的代码。您无法预测未来，因此无论您的解决方案多么通用，它都不足以满足您将拥有的实际未来需求。最有可能的是，这个时候永远不会到来，你为解决未来问题而编写的代码会增加复杂性，使更改代码片段变得困难，最终它将成为可能破坏软件的负担。不要预测未来。

只做你现在需要的通用。

22.假设

假设是你接受为真或假设为真的，尽管你没有确凿的证据。

软件项目的一大杀手是假设。让我们看看假设如何扼杀软件项目。

开发人员知道他们必须开发一个系统来执行 X。然后他们认为系统将来会要求他们做Y，他们也实现了Y。他们编写数千行代码来设计Y。将来，开发人员意识到当前的需求与他们想象的完全不同。

但是现在，该软件具有不必要的代码，因此很难丢弃，因为一切都交织在一起。重构代码需要几个月的时间，现在他们考虑从头开始重写整个软件，这将导致他们损失数月。

为了避免像这个开发人员一样成为受害者，请遵循以下简单规则
代码应该基于你现在所知道的，而不是你认为将来会发生什么。 — 代码简单

23.停止重塑

例如，如果你发明了自己的垃圾收集器，而存在一个非常好的垃圾收集器，你将花费大量时间在垃圾收集器上工作，而你可以只在你的软件上工作。

只有当以下任何一项都成立时，才能重新发明轮子：

你需要一些尚不存在的东西
所有现有的“轮子”都是糟糕的技术或无法满足您的需求
现有的“轮子”没有得到适当的维护

24.阻力

作为开发人员，您对更改请求的第一反应应该是“NO”。

始终抵制添加更多代码、更多功能，直到您确信它们是必需的并且需要实现它们。因为不必要的更改会增加软件中的缺陷。

你怎么知道需要他们？

返回并记住您的软件用途。然后记住优先级部分中的简单等式。

25.自动化

不要把时间花在重复性任务上。设置它们并忘记它们。它们可以在您睡觉时工作。当你意识到自己一次又一次地做某事时，请记住这条规则：

如果可以自动化，请自动化。

26.代码测量

我看到开发人员根据代码行来衡量他们的软件质量。

他们认为更多的代码行意味着他们做得很好。该软件包含数十万行代码，这意味着他们使用的软件非常大。

这里弹出的问题是：它真的那么大，还是那里有什么问题？答案是，他们的设计很可能有问题。大多数简单的解决方案不需要大量代码。您可以使用一小堆代码实现简单性并解决问题。我并不是说更少的代码行总是更好。虽然你想避免使用更少的代码，但你很容易陷入一个陷阱，这将导致你编写其他人难以理解的聪明代码。你应该找到一个平衡点。

最佳代码是一小堆易于理解、易于阅读的代码。

27.生产力

您如何衡量您的生产力？

通过编写更多的代码行或扔掉数百行代码？！

您的主要目标应该是保持代码库尽可能小。问题不是“我怎样才能写更多的代码？”而是“我怎样才能删除更多的代码？”

“我最富有成效的日子之一就是扔掉 1000 行代码。”

28.测试

何时应向项目添加日志记录和错误处理？
您应该在很早的阶段添加日志记录。这将帮助您轻松找到问题并节省时间。

在测试代码时，我看到很多错误。我举个例子。有两个条件，一个简单的if-else块。开发人员向软件提供了输入，该软件将进入 if 块。他们对其进行了测试，并将代码提交到源代码管理。做！但是其他块呢？当软件交付到生产环境时，这会导致很多错误。当你测试你的代码时，你必须至少执行一次所有新行，你应该在整体之前开始测试部分。

当你有一个错误时，首先你应该重现它。您不应该猜测错误的来源并根据您的假设应用修复程序。最有可能的是，你会错的。在应用修复程序之前，您应该亲眼看到它。你应该是可靠的。

当团队中的其他开发人员看到您将新代码提交到源代码管理时，每个人都应该知道您的代码已经过测试并且可以正常工作。未经测试的代码是不起作用的代码。

29.（不足）估计

开发人员的估计很糟糕。

通常，他们低估而不是高估事物。他们低估了开发少量代码或功能所需的时间和精力。最后，这种低估会导致错过最后期限。

解决方案：将大事分解成小事。它越小，就越容易估计。你可能仍然会弄错，但与你估计一个大项目相比，你的错误要少得多。

一切都比您想象的要长。

30.逃避重写

我相信，当你接受那篇文章中提到的软件开发的基本原则时，你不会走到这一步。

但是，如果您以某种方式犯了这些错误并发现自己正在考虑重写代码，那么您应该知道以下主要事项：重写代码通常是开发人员的错觉，在大多数情况下不是解决方案。

为什么是错觉？好吧，因为阅读代码比编写代码更难。这就是为什么重用代码如此困难的原因。这就是为什么当我们阅读另一个开发人员的代码时，我们的潜意识会低声对我们说“扔掉它，重新开始”。

在许多情况下，您应该考虑从头开始重写代码，您可以在此处阅读它们。但是，这里有一个简单的建议给你：

重构应该是第一个选项。

31.文档和注释

关于注释的一个常见误解是开发人员添加注释来说明代码正在做什么。这是错误的。从阅读代码中应该可以明显看出这一点。如果它不明显，则意味着它不可读，应该变得更简单。

当您无法使代码更简单时，您应该添加注释来解释这种复杂性。

注释的真正目的是解释“为什么”你做了某事，而不是代码在做什么。如果你不解释这一点，其他程序员可能会感到困惑，当他们去改变你的代码时，他们可能会删除它的重要部分。– 代码简单

当新的开发人员加入您的团队时，他们将更容易理解整个软件。当开发人员对软件的其他部分一无所知时，他们很容易在自己的部分犯错误，这也会影响其他部分。

32.拣选技术（工具、库等）

首先，永远记住这个规则：不要依赖外部技术。

但是，当您必须这样做时，请尝试尽可能减少对它们的依赖。为什么？因为它们是复杂性的另一个常见来源。它们会扼杀你的积极发展，让一切变得更加困难。当你如此依赖外部技术时，你就不自由。

如果该技术存在重大错误怎么办？你必须等待开发人员修复这个错误，如果这项技术在你的项目中心，基本上你就被卡住了，你就无法前进。因此，为您的项目选择正确的技术如此重要的原因。

在开始使用某些技术之前，应考虑以下几个因素：

背后有积极的发展吗？
会继续维护吗？
切换有多容易？
社区对此有何评论？

33.自我发展

不断学习。尝试不同的编程语言和工具，阅读有关软件开发的书籍。

他们会给你另一个视角。每天的小改进都会对您的知识和技能产生真正的影响。保持开放的心态。不要痴迷于一种技术。使用所需的技术来解决特定问题。

不要参与不必要的讨论，比如Microsoft与Linux:)要知道每个具体问题都有其特定的解决方案。

34.不要成为英雄

很多时候，做一个戒烟者比做一个英雄更好。

不要执着。知道何时戒烟。不要犹豫，寻求帮助。

35.不要问问题...寻求帮助

当您有要实施的东西并且不确定解决方案时，不要问别人如何实现…至少不是立即。

相反，尝试你能想到的一切。你对一个概念或语言越不熟悉，这一点就越重要。当您自己想不出任何东西时，请搜索！找到答案并尝试一下。

修改这些答案，看看你是否能理解它们为什么有效，使它们适应你的代码。…但一定要寻求建议。当您尝试了所有方法后，最好是在有了可行的解决方案之后，现在是寻求建议的最佳时机。

请同行和高级开发人员来审查您的代码。

总的来说

优秀的程序员都具备创造者思维，看问题更偏向于接近事物的本质，与此同时，他们具备更强的学习能力和解决问题的能力。

不过可惜的是，由于种种原因，前端程序员容易陷入使用者思维，他们在自我成长的过程中，会走更多的弯路，更难以突破瓶颈，甚至会给人一种，前端程序员不像是程序员的感觉