学会识别错误，养成避免他们的习惯。
首先，我想说清楚一件事。如果你是一名初级开发，本文并不是想让你由于可能发生的错误而感到失落，而是想让你了解他们，教你发现他们的迹象，并提醒你避免他们。
我过去犯过许多错误并从每一错误中汲取教训。令人开心的是，现在我有了良好的编程习惯去避免他们。你也应该做到。
下面列出的错误并没有特定的顺序：
1.无计划的写代码
一般来说，写出高质量的书面内容并不简单。它需要你缜密的思考和深入的研究。高质量的程序里也是如此。
写出高质量的代码有以下过程：
思考、研究、计划、写出代码、验证他们、维护修改，你需要有好的习惯通过这些行为达到好的效果。
作为一名初级开发，我犯过最大的错误之一是没有经过思考和研究就开始敲代码。虽然它可能对于小型独立对应用可以很好的运行，但是对于更大些的应用来说，这样会有很大的负面影响。
就像在你说任何可能让你后悔的话语之前先思考一下，你也需要在写出让你后悔的代码之前思考。敲代码也是一种传递你思想的方式。
When angry, count to 10 before you speak. If very angry, a hundred.
— Thomas Jefferson.
下面是我的版本：
在检查代码时，重构一行之前数到10，如果代码没有测试，数到100。—Samer Buna
编程大部分是在阅读之前写的代码，研究它需要什么、它是怎么样去适用于当前的系统的和用小的可测试的增量规划去写代码。真正的代码行可能只占整个过程的10%。
不要把编程当作纯粹的写代码，编程是一种需要培养的具有逻辑基础的创造力。
2.在写之前想的过多
的确，在进入编码的状态前要去先思考是一件好事，但是想太多也会伤到你。喝很多的水让会让你中毒。
不要太过于追求有完美的计划。在编程的世界里它是不存在的。找到一个足够好的计划，你可以用它来开始。事实上，你的计划也会改变，它将强迫你了解某种结构使得你的代码更加清晰。过多的思考只会浪费你的时间。
我仅是在说计划一件小点的事情。一下把所有工程的计划做完应该是不合理的！这就是我们所说的瀑布式方法：它是一个系统的线性规划，有明确的步骤一步接一步去完成。你可以想象这种方法有多少规划。所以这样的规划不是我在这里谈论的。瀑布式方法对于大部分软件项目来说是行不通的。任何的复杂的计划只能通过灵活的适应现实去实现。
编程序是一种有响应的活动。你将在瀑布计划中添加你从未想到的特征，你会因为你在瀑布计划中从未考虑过的原因去移除某些特征。你需要调试错误并且适应变化，你需要去适应变化。
不管怎样，总是要计划接下来的一些特证。你要非常小心，因为太少的计划和太多的计划都会有损你的代码质量，代码质量并不是你可以去冒险的。
3.低估了代码质量的重要性
如果你只能专注于写代码的一方面，那就是可读性！不清晰的代码就是辣鸡，甚至是不能重用的。
绝不要低估了代码质量(可读)的重要性。查阅代码可以当作交流实践的一个方法。你作为程序员的主要工作是清晰的传达你正在处理的任何解决方案的实现。
即便是小事也很重要。例如，如果你的缩进、大写前后不一致，你应该很快丢失你的代码许可。
另一件小事是一行中代码太长。任何超过80个字母的东西都是难以阅读的。你可能会尝试把一些很长的条件判断放在同一行，为了保持if语句块的更加可见。不要那样做，绝不要超过了80个字母限制。
像这些简单的一些问题可以通过排版工具修复。在JavaScript中，我们有两个极好用的工具。ESLint和Prettier。帮自己一个忙，一直使用它们。
以下是关于代码质量的一些错误：
—在一个方法或者文件中写了很多很多行代码。你应该一直保持把很长的代码切分成小模块，这些小模块可以被单独测试与管理。我个人认为，任何超过10行的函数都过于长了，但这仅仅是我的经验规则。
—使用双重否定，请不要这样做。
—使用简短的、通俗的或者基于类型的变量名。给出变量的描述性和非模糊性的名字。
—对原始的字符串和数字进行硬编码而没有描述信息。如果你想要写依赖于固定的原始字符串或者数值的逻辑，把它定义成常量并且取个好认的常量名。
—使用方便的快捷方式和解决方案，避免在一个小问题上花费时间。不要绕着简单的问题转。正是现实。
—代码越长越好。其实，大多数情况下，越简短的代码越好。只有在更长代码有更好的可读性的时候才写长代码。例如，不要仅仅因为保持代码更简短去使用聪明的单线程和嵌套的三目运算。删除不必要的代码是你在任何项目中能做的最好的事情。
—条件判断的过度使用。大多数你认为需要条件判断的地方可以不用它来完成。考虑所有的备选方案，并专门选择处一个基于可读性的方案。相关：避免YODA条件和条件句中的赋值。
4.选择你的第一个解决方案(遇到问题的时找到答案就去试,试成功就完事了)
在我开始编程序的时候，我记得当我遇到一个问题时，找出一个解办法就立马去执行它。我并没有思考这个解决办法的复杂性和潜在的失败，我就使用了这个方案。
第一个解决办法可能当时是可行的，但是通常一个优秀的解决方案在你质疑了所有的方案后才能发现的。假如你没有想出一个问题的多个解决办法，这可能是你没有完全理解问题的标志。
作为一名专业的程序员你的工作不是找出一个解决办法，而是要找到最简单的办法来解决问题。我说的“简单”的意思是：解决方案必须能正常工作和有足够多的试错而且这个办法阅读、理解和维护起来很简单。
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies(缺陷).
——C.A.R. Hoare
5.不要放弃
我犯下的另一错误是我经常使用第一次找到的解决办法，即使我意识到它可能不是最简单的一个。这可能是与“不放弃”的心态有关。在大多数的活动中，这是一种很好的心态，但是它并不适合于写程序。事实上，在写程序的时候正确的心态是早点发现错误和会有很多的失败。
当你质疑你的解决办法时，你应该思考扔掉它，并且重新来考虑这个问题。不管你在这个问题上花了多长时间，这样做都是正确的。像git这样的代码管理工具可以帮助你拉取分支、然后在不同分支上尝试不同的解决方案。
6.不会谷歌搜索问题
有很多我浪费宝贵时间的情况，我本应该立即去搜索解决问题的办法的。除非你用了非常偏的技术，其他情况你应该先用谷歌搜索。你现在遇到的问题，也是其他人遇到过的问题，并且还有解决的办法。
有时候，谷歌会揭示你思考的问题真的不是一个问题，你需要做的不是修复它而是使用它。不要假设你知道任何事都需要选择一个解决方案。谷歌会让你大吃一惊。
然后，小心的使用谷歌。作为新手的另一个标志是在没有理解代码的情况下复制粘贴使用其他人的代码。这个代码可能解决了你的问题，但是你不应该使用你完全没有了解的代码行。
如果你像成为代码的开辟者，绝不要认为你知道你在做什么。
7.没有使用封装
这里不是说使用关于面向对象的例子。封装概念的使用总是有用的，不使用封装经常会导致维护系统更困难。
在一个应用程序中，一个特性应该只有一个处理它的地方。这通常是某个对象应做的。该对象应该只揭示应用程序的其他对象使用它所必需的东西。这不是保密，而是关于减少应用程序不同部分之间的依赖关系的概念。遵守这些规则允许您安全地对类、对象和函数的内部进行更改，而不必担心在更大范围内破坏事情。
逻辑和状态的单元概念应该有他们自己的类。我指的是一个蓝图模板。这可以是一个实际的类对象或函数对象。您还可以将其标识为模块或包。
在逻辑类中，独立的任务应该有它的方法。方法应该只做一件事并且做好这件事。累死的类应该使用相同的方法名称。
作为一名初级开发，我总是没有本能的创建一个新的类去表达一个单元概念并且我经常意识不到什么可以独立出来。如果你看到一个工具类被用作于许多不属于一类的东西，那就是新代码的标志。
在增加方法到一个类或者增加更多功能到一个方法之前，考虑并质疑一下你本能想做的。这里你需要时间去思考的。不要跳过这个或者你认为你做完这块后去检查。只有提前去思考才是正确的。
最伟大的想法就是使你的工程是高内聚低耦合的特性。这只是一个花哨的术语，意思是相关的代码在一个类里，和减少不同类之间的依赖。
8.未知的计划
你往往想不出你目前遇到的困难的解决办法。所有的IFS会突然出现在你写的每一行代码中。这是边缘测试的好办法，但它作为潜在需求的驱动程序是错误的。
你需要识别清楚你的IFS属于的以下两大类的哪一个。不编写你目前不需要的代码，不为未知的以后做计划。
你认为你可能在未来会有用到而写一个新特性是错误的，不要这样做。
总是保持写你目前需要的解决的问题最低量的代码，处理边缘情况，当然可以，但不要添加边缘特征。
9.没有使用正确的数据结构
在准备面试的时候，初级开发通常过于关注算法。识别出好的算法并且在被需要的地方使用它们是很好的事情。但是记住它们绝不会在你的编程才能上加分。
但是，记住各种数据结构的特点和缺点并使用在你的代码里，将会使你成为一名更好的开发者。
使用了不合适的数据结构是很明显的能看出来。在这里特指新手的代码。
本文的不是教你数据结构，我只在这里提出一些小例子：
——使用list列表代替映射map来管理记录
最常见的数据结构的错误是使用列表而不是映射来管理记录。是的，为了管理记录列表，你应该使用映射关系。
注意我在这里谈论的是一个记录列表，其中每个记录都有一个标识符，用来查找记录。使用标量值的列表是ok的。它是更好的选择尤其是如果你使用的重点是把值插在列表中的时候。
在JavaScript语言中，最常见的list结构是数组最常见的map结构是对象。
使用list套map来管理数据常常是错误的，虽然这一点对于大的收集来说是合适的，但我要说的是一直坚持下去。之所以如此重要，是因为当你使用标识符查找时，map比列表快很多。
——不使用栈结构
编写任何需要递归的代码时，使用简单递归函数总是诱人的。但是优化递归代码一般是困难的，尤其是单线程环境。
优化递归代码取决于你在递归函数中返回的什么。例如，优化返回参数是2个或者多个的递归函数结果比优化返回参数是单个的更难。
作为初级开发，我们倾向于忽略递归函数而使用另一种选择。你可以使用堆栈结构。将函数调用到堆栈中，并准备回调时弹出它们。
10.使用已有到辣鸡代码
看下面的混乱的房间：
你被要求往这个房间增加一个东西。因为它已经是大且混乱了，你可能会把这个东西随便放。你可以在几秒钟内完成你的任务。
不要这样做在混乱的代码情况下，不要让他变得更乱！当你在杂乱的代码上工作的时候，要总想着一点一点去使它清晰。
对于上副图，正确的事是清洁它，有序的放好东西，把你新加的放在合适的位置。比如，如果你加的东西需要安置在衣橱上，你需要清洁一下衣橱。这是完成你任务的正确的选择。
一下列举了一些错误的陋习，它们通常会让你的代码变得臃肿杂乱：
拷贝代码：如果你复制粘贴代码后在原代码基础上只改变了一行，很显然你的代码会变得臃肿。在上面的混乱的房间的例子中，它就像增加了另一把底座较低的椅子而不是投资买一个新的高低可调的。总是保持抽象的概念在你的脑海中并且在需要的时候使用它。
不实用配置文件：如果需要使用可能在不同环境或不同时间潜在不同的值，这个值应该配置到文件中；如果需要在代码中的多个位置使用值，这个值应该配置到文件中。当你传入新的值时问问自己这个值是否应该配置到文件中，答案大部分是肯定的。
使用不必要的条件语句和临时变量：每一个if语句是逻辑上的分支，需要至少进行双重测试。你应该避免条件限制而不牺牲可读性。主要问题是用分支逻辑来扩展函数，而不是引入另一高函数。每当你认为你需要一个if语句或一个新的函数变量时，你应该问问自己：是在正常水平修改我的代码还是应该在更高层次上思考问题？
11.写注释在很显然的方法上
我已经学会了尽量避免写注释的方法。大多数注释可以用代码中的更好命名元素替换。
仅仅使用更好认的函数和语法命名会使得大多数注释都不必要了。在写任何注释之前要经常想想怎么去掉不必要的注释。
然而，有时候你被逼迫进入只有写注释才能使的你的代码变得清晰的状态。这时候你应该组织你的注释来回答为什么这个代码需要写注释而不是这个代码做了什么。
如果你一定要加做了什么的注释来使得你的代码更清晰，请不要太显现的指出来。
不要添加不必要的注释，不要接受这样的代码。如果你必须处理很乱的代码，那就删除这些注释。最重要的是，教育那些编写注释的程序员他们是多么糟糕。如果雇佣来写不必要注释的程序员，让他们知道他们可能会因为这么做丢掉工作。yep……
12.不做单元测试
我要把这一点保持简单。如果你认为你是一个专业的程序员，这种思维让你有信心在没有测试的情况下编写代码，你在我的书中是个新手。
如果你在你的代码里不写测试，你可能在你的程序的其他地方手动测试。如果你构建了一个web应用，你将在每几行代码后就刷新并与应用交互，我就是这样的。你手动测试你的代码并没有任何错误，但是你应该手动编写出怎么样去自动测试它的代码。如果你与应用交互的测试成功了，你也应该回到你代码编辑里写一下交互的代码，以便下次向项目中添加更多的代码时自动执行完全相同的交互。
你是一个人类。你在每一次代码改动后会忘掉每次测试出的成功的验证结果，让电脑帮你记录一下！
如果你可以，在你编写他们猜测和设计你的验证结果以便满足他们。TDD(测试驱动开发)不仅仅只是花哨的炒作。它是积极影响你思考特性的方式，以及想出更好的设计。
TDD不适合每一个人，它并不能对每一个项目取得好的效果。但是你应该去使用它。
13.假定一切都是理想状态，那么代码都对了
看看下面的函数sumOddValues的实现，它真的一点错都没有吗？
上面的代码是不完整的。它只是对于一些例子是适用的，(通常断言测试的都是你想的普遍的测试)，但是它存在很多问题。让我来说明以下：
——问题1:没有处理空输入。如果没输入任何东西它会发生什么呢？现在你会看到一个error当你在运行它的时候：TypeError: Cannot read property 'reduce' of undefined.
这是一段 bad code，有以下两点原因：
作为使用你函数的人不应该让他关注你的函数的实现细节；
这个错误对使用你函数的人没有一点帮助。你的函数仅仅是执行它。然而，如果错误被更清晰的表达出来，使用者将会知道做了什么是不正确的。例如，你可以跑出自定义的异常信息像这样：TypeError: Cannot execute function for empty list。
你也可以替换一个error提示，设计你的函数忽略掉空输入，让他返回结果是0。无论如何，这都是必须做的。
——问题2:没有处理不合法的输入。
问题1和问题2都是一些边缘的问题。但是也要计划一些边缘的问题的处理，因为他们一旦发生是不容易辨认出来哪里出错了的。如果传入负数是什么结果
-13也是个奇数，但它是这个函数应有的参数吗？它应该抛出一个错误信息吗？在参数列表应该包含一个负数吗？或者它应该是忽略掉了负数吗像现在的结果一样？你可能意识到函数名应该被改为sumPositiveOddNumbers。
在这些例子中做决定是简单的。更重要的是，如果你没有写测试用例记录你的决定，未来维护你的函数的时候将没有一点线索：你忽略了负数有意的还是错误的？
——问题3:没有测试所有的合法的输入。忘掉边缘的例子，这个函数有一个合法的非常简单的例子缺造成它返回错误了：
上面的2被计算在了求和中，但它不应该求和的。
解决方式很简单，reduce接受第二个参数accumulator作为sum求和的初始值。如果这个参数没有提供，reduce将使用在集合中的第一个值作为accumulator初始值。这就是为什么第一个数被包含在sum求和中。
虽然你可能注意到了这个问题，并改正了或者在测试的时候，这个显示它的测试用例应该像其他测试用例一样被包含在测试中。
你意识到小测试而没有处理编写测试用例或者忽略了边缘的例子，这是新手的另一个标志。
14.代码中没有问题
除非你是位超级大牛，并且总是在独立开发。毋庸置疑的是在你的生活中你总会遇到一些愚蠢的代码。初学者意识不到它，会认为那是一段良好的代码因为它可以顺利运行和是代码库中的一部分。
糟糕的是，如果烂代码使用了烂的做法，初学者可能会尝试重复使用代码库中的其他地方的坏习惯，因为他们从他们认为是好代码的东西中学到了这个。
有些代码看起来很烂但是也有可能有特殊情况去逼迫程序员这样写。这个时候是不错的，可以让初学者知道这个状况以及为什么要这样写。
作为一个初学者，你应该假设任何你不理解的无注释代码都是一个坏代码的候选者。对它提出质疑，问问这个问题。
如果代码编写者已经隔了很久也忘掉它做了什么了，那就自己研究一下代码尝试去理解它做的每一件事。当你完全理解了这段代码后你才知道它是好代码还是烂的代码，不要在理解前就假定它的好坏。
15.沉迷于最佳实践
我认为“最佳实践”这个词实际上是不利的。这意味着没有进一步去研究必须了解的东西。去深入研究是有史以来最好的做法，不要质疑！
没有最佳实践。今天可能有比较好的实践和编程语言。
我们以前定义的最佳实践现在被标记为烂代码。
如果你投入足够的时间，你总是能找到更好的实践。不要担心是不是最佳实践，把注意力放在你能做的最好的事上。
不要由于你读到了某句话而做某事，或者你看到其他人在做，又或者因为别人说那是最佳的实践。这包括我在这篇文章中给出的所有建议。去质问任何事、挑战所有的理论、认清你所有的选择，只做有教育意义的决定。
16.痴迷于性能上
自Donald说过上面的话以来，编程就发生了很大的变化。我认为它在今天依然是宝贵的建议。
记住这个好的规则：如果不能用代码来测量可疑的性能问题，不要尝试去优化它。
如果在你执行代码前优化了，很可能是你过早的执行了代码。还有一个很大的优化的机会，所以你现在投入的时间是完全没有必要的。
当然，有一些很明显的可以优化的地方，你应该在添加新代码之前去保持思考。例如，Node.js中，你不能少了事件循环和阻止调用堆栈是非常重要的。这是一个早期就可以优化的例子，你应该时刻保持思考。问问你自己：我正在考虑的代码阻止调用堆栈了吗？
对任何现有的代码进行任何不明显的优化而不进行测量被认为是有害的，应该避免这样做。如果你想的话，你的表现可能会是一个新的意想不到的bug。
不要把时间浪费在没有测量的性能问题。
17.不注重用户体验
给应用程序添加一个功能最简单的方式是什么？从你自己的角度看，或者它如何适应当前的用户界面的角度看。正确吗？如果这个功能是从用户获取的某种类型的输入，那么将它附加到现有的窗体上，如果这个功能是在页面上添加一个链接 ，那就把它添加到已有到链接到嵌套菜单中。
不要成为这样到开发者！要成为专业到程序员是应该自己以用户到角度看功能。专业到程序员会想用户需要什么特殊到功能、他们会有怎样的行为。他们会思考这个功能怎么样可以让用户很简单的就找到并使用，而不是简单的把功能加到应用中现有的模块中，没有考虑这个功能是否简单适用。
18.没有选择正确适合的工具去编程
每个程序员都有他们自己喜爱的工具列表来帮助他们与编程相关的激活。一些工具是很好的，但也有烂的。但大多数工具是对于完成某件事情是极好用但，而不是对任何事情都有好都效果。
纯新手的标志是都判断是取决于这个工具都流行程度而不是这个工具对问题的适合程度。
关于这个论点，你可能不知道有什么“更好用”的工具更适合你的工作。在你目前的知识领域中，你可能认为某个你所知道的工具是最好用的。然而，当你和其他的观点比较后，你就觉着它不是最好用的了。你需要了解这个工具对你的价值，并且保持开放心里：去开始尝试使用新的工具。
有些程序员拒绝使用新兴的工具。他们觉着他们现在用的工具用起来很舒服，并且他们可能不在向学习新的工具了。我理解这样的想法，我之前也是这样，但这是个错误的观点。
你可以使用原始工具造一座房子，度过你的甜蜜时光，但你也可以投入一些时间和金钱到好的工具上面，这样你会更快的造出更好的房子。工具也在持续的发展，你需要得学习并使用他们。
19.不了解代码问题会造成数据问题
编程序一个重要的方面是经常要管理一些数据表单。该程序是添加新数据、删除旧数据、修改数据的接口。
即使是代码中最小的错误也会导致在管理数据中出现不可预知的问题。如果所有的数据验证都是用相同的有bug程序完成的话则更是如此。
初级开发可能不会立马联想到这点，当涉及到代码数据关系的时候。他们可能觉着不错，会继续在生产中使用一些bug代码，因为不能工作的特征xxx不是非常重要的。问题是，bug代码可能会不断引入数据完整性问题，这在一开始并不明显。
更糟糕的是，在不修复这些bug引起的小数据问题的情况下固定代码并运作他们只会积累更多的数据问题，将这些问题带入“不可恢复的级别”中。
像这样的情况下，你该怎样保护你的程序呢？你可以简单是使用多层数据完整性验证。不要指依赖于单一的用户界面。在前端、后端、网络通信和数据库上创建验证。如果这不是一个选项，那么至少必须使用数据库级约束。
你要了解数据库约束，在你添加一列和一个表的时候使用他们：
非空约束：意味着那一列不允许有空值。如果你的应用某个域一定有值，它应该在你的数据库中被定义非空约束。
唯一约束：意味着在整个表的这一列不能有重复的值出现。例如，它在user表中应用于username和email域是很合适的。
检查约束：是自定义的表达式接受的数据必须符合这个表达式。例如，你有一列需要百分号的值必须是0到100之间，你可以使用这个约束。
主键约束：意味着这一列值不能为空并且唯一。数据库的每个表都应该有主键约束去标识标中的记录。
外键约束：意味着这一列的值必须是另一个表的某一列值，通常是另一个表的主键。
还有一个对于新手有关数据库完整性的问题是缺乏对事务的了解。如果有多个需要改变相同数据的操作，他们就需要事务，必须封装在一个当这些修改操作的某一个操作失败时，能够执行回滚的事务中。
20.重新发明“轮子”
这是一个棘手的问题。在编程方面，一些基础是值得重新创造的。编程不是一个定义好的领域。很多东西都处在快速变化发展中，新的需求被引入的速度比任何一个团队所能处理的都快。
例如，你需要一个“轮子”基于每天的时间以不同的速度运转，而不是定制车轮，可能我们需要重新思考它。除非你真的需要一个没有在它的典型设计中使用的轮子，否则就不要重新发明它。就用这该死的轮子吧。
有时候去在许多可选项中去选择需要的品牌是一项挑战。在你买之前先做一些研究！帅气的软件大多数的他们是免费开源的，你可以看到他们的内部设计。你可以很容易的审视一下代码的内部设计质量。如果可以使用开源的。他们也很容易被替换。另外，更容易在内部支持他们。
然而，如果你需要一个轮子，不要买一辆全新的车，把你维护的汽车放在新轮子的顶部。不要只使用一个或者两个的整个库。最好的例子是JavaScript中的Load库。如果你只要将一个数组打乱，只需要倒入打乱的方法，不需要倒入整个Frut-Load库。
21.对待编码评审有错误的态度
初级开发者的标志还有是他们经常把代码评审看作是批评。他们不喜欢这样，甚至害怕被评审。
这样认为是不正确的。如果你这样觉着，那么你需要纠正对待评审的态度。每一个代码评审都被看为一次学习机会。拥抱评审并心存感激，在评审中学习。最重要的是，在评审官教你一些东西的时候对他表示感谢。
你永远是一个代码学习者。你需要接受评审。大部分代码评审将会教你一些你不知道对事情。把它们作为学习资源整理出来。
评审官也有错误的时候，需要你教他们。但是，如果从你的代码中看不到什么东西，那么这种情况可能需要修改代码。如果你需要教你到评审官一些东西，只要知道教学是最为程序员你可以做到最有价值到活动之一。
22.不实用代码控制
新手会低估好的代码版本控制系统的力量，我这里说的是Git。
源代码控制不仅仅是push你的代码改动，去让别人拥有和建立。它比这些还要强大很多。源代码管理历史清晰。代码将收到质疑，它的进展历史将会帮助解决一下棘手的问题。这就是为什么我们要关心提交信息的原因。他们是另一个交流你实现的渠道，并使用小的提交使用他们。这样会帮助你未来的代码维护者了解代码是如何达到现在的状态的。
经常提交并及早提交代码，为了保持一致，在你的主语行中使用现在进行时动词。详细说明你的信息，但要记住他们应该是总结。如果你需要很多行去说明，那可能是你的信息太长了，重新整理一下！
在你的提交信息中，不要包括任何不必要的东西。例如，不要列出新添加的文件，或者删除的文件在你的总结里。该列表存在于提交对象本身中，并且可以用一些Git命令参数轻松显示。它只不过是总结中的噪声。有些团队喜欢改变每个文件的摘要，我认为这样提交的太多了。
资源控制也是关于可发现性的。如果你遇到一个函数，开始质疑它的需求或设计，你可以找到提交该函数上下文的提交。这些提交甚至可以帮助你识别代码将bug引入程序。Git甚至在提交(BISECT命令)中提供二进制搜索来定位引入bug的提交。
源代码控制也可以以奇妙的方式使用，甚至在正式提交更改之前，使用诸如分期更改、选择性修补、重置、存储、修改、应用、扩散、反转等许多特性，可以在代码流中添加一些丰富的工具。了解、学习、使用、欣赏它们。
你对Git的特性了解越少，你就更是我书中的新手。
23.过度使用共享状态
这将不是函数是编程与其他范例的一个要点。这是另一片文章的主题。
事实上，共享状态是问题的源头，可能的话应该避免它。如果避免不了，共享状态应该保持到绝对最小的度。
作为一名初级开发我没有意识到我们定义的每个变量都代表一个共享的状态。它保存的数据可以被与该变量相同的范围内的所有元素更改。它的作用域越大，共享状态就的跨度越差。尝试小范围内包含的新状态，并确保它们不向上泄漏。
当多个资源需要在时间循环相同的状态下一起改变该状态时，会发生共享状态上一个很大的问题。竞争情况会发生。
有一件事：新手可能会尝试使用计时器作为共享状态竞争条件问题解决的方案，尤其是如果它们必须处理数据锁问题时。那是一个巨大的X号，不要这样做！注意这个地方，在代码审查中指出它，并且永远不要接受它。
24.对待错误有不正确的态度
发生错误其实是一件好事。它们使你进步。它们意味着你有一简单的后续变化，以取得更大的进步。
专业的程序员热爱错误。而新手就很讨厌它们。
如果看到这些奇妙的红色错误信息你就很烦扰，你需要改变这种状态。你需要把他们看作你的帮手，你要处理它们。利用它们来取得进步。
一些错误需要被改进为异常。异常是你需要去计划的使用者自定义的错误，一些错误需要被单独留下，它们需要崩溃应用程序并使其退出。
25.没有足够的休息
你是一个人类，并且你的大脑需要休息，你的身体也需要休息。你经常在编程中忘记休息。我把他看作又一个新手的标志。这不是你可以妥协的。在你的工作流程中整合一下东西强迫你休息。小憩一会，离开你的椅子，稍微走走，并想一下你下一步需要做什么。用新的视野回到代码中。
这是一个很长的职位，你需要休息。
原文链接：https://edgecoders.com/the-mistakes-i-made-as-a-beginner-programmer-ac8b3e54c312