“如果你想在重要的事情上取得卓越的成就，那么就需要在小事情上培养良好的习惯。卓越不是一次例外，而是一种长期的态度。”——科林·鲍威尔(美国第一个黑人国务卿)
习惯的力量不容小觑，放之于开发人员亦如是。本文深入解析了可以永久改变开发者职业生涯的 14 种习惯，这些习惯将帮助你晋级成一名合格的高效能软件开发人员。
许多人都认为从一位高效的初级开发人员晋级到中级开发只是时间和经验的问题。但实际上，这两者的分界线非常不明显且很主观，文本也不打算搅和进“究竟如何定义中级开发人员”这一无休止的辩论。
说实话，我坚定地认为真正可以改变一个人的心态并帮助他们从初级开发人员晋级到中级或高级开发人员的只有习惯：
习惯是你开始有计划地做一件事情，直到你不再对它感到陌生，自然而然地形成的东西。
在专业和个人提升方面，形成与代码相关以及与工作相关的习惯至关重要。
习惯造就了我们。习惯是我们自己养成的，所以我们有责任尽可能地培养好习惯。如果能培养良好的与工作或学习相关的习惯，我们就能有效地战胜拖延症、倦怠、厌烦，以及偶尔的懈怠、冲动等阻碍我们的情况。
让我们来看一看日常习惯的清单，一旦掌握这些习惯，就能帮助你提升到下一个水平并取得卓有成效的进步：
编写 Small Methods
理想情况下，是都不要超过 20-30 行代码。这种习惯非常重要，它不仅能迫使你编写紧凑的代码，而且在模块化代码时也有助于你的分析思考。拥有大量缩进(大量 if、for、loop 等语句)的 big methods 简直就是一场噩梦。虽然编写 big methods 看起来既简单又省事，但是过不了多久你就很难搞清楚这段代码究竟在做什么了。
此外，big methods 还有一个弊端，那就是无法重用。编写这样的代码只是为了满足项目中的某个需求，很难在其他地方使用。
有意义的命名
方法和变量的命名都应该有意义。中级开发人员无法接受名为“x”、“xyz”或者“object”等的变量名。用英语单词命名变量的目的是为了赋予这些变量一定的意义。
与代码之间的沟通远比与文档或注释之间的沟通更为重要。
注释的目的是解释代码的“目的”，而不是为了解释“怎样”编写代码。
有意义的变量可以帮助你与那些阅读代码的人更好地沟通，而且还可以减少书写大量注释的必要性，变量和 methods 都是如此。此外，如果 methods 名过长，则可以考虑重构代码，简化 methods。一个干净利落的 methods 名总归比一个混乱的名称更方便使用。
在命名的时候，不要着急，先想一想你命名的组件是否太复杂，是否需要重构。
不要让过多的参数毁了你的 Methods
凡是拥有太多参数的 methods 都面临着重构的可能性。通常，编写这种 methods 会违反单一功能原则(Single Responsibility Principle，简称SRP)，这意味着 methods 中包含太多功能。一个高效简洁的 methods 只负责做好一个功能。正如 Robert C. Martin 所说，一个 methods 至多只能拥有 3 个参数。虽然并不一定要如此严格，但 methods 中所需参数的数量也确实和这个值差不多。
要抑制将一些 methods 的局部参数(local parameters)改成 class fields 的冲动。你应该考虑重构代码，让每个 methods 只负责很少的操作，或者干脆分解成两个单独的 methods。
“函数应该只有少量参数。好一个参数也没有，或者也可以有 1-3 个参数。超过 3 个参数就有问题了，应当极力避免。“——Robert C. Martin
避免在一个类中包含太多 Methods
与 methods 中的参数一样，类中的 methods 数量也很重要。拥有许多 methods 的大类通常表示一个组件拥有太多内容或包含太多功能。我们将这些组件称为上帝类(God Classes)，这个词是高耦合代码的反面教材。
如果一个类中拥有许多 methods，那么可以想一下，以后写代码时你可能需要经常打开该类并修改其行为。这可能违反了开放封闭原则(Open Closed Principle，简称 OCP)，即“软件实体(类、模块、功能等)应该易于扩展，但尽量避免修改。”
使用第三方库时，应该使用长期支持和稳定的版本
请时刻为下一个需要使用你的代码并重新编译项目的人考虑。使用长期支持版本的库、插件和框架，虽然可能无法提供新的酷炫功能，但是在将来如果需要重构或重新编译代码时，你就能体会到其中的好处了。
按下使用新好版本的工具的冲动，坚持使用安全、稳定的工具。将来有一天，你和你的同事都会感激这一选择!
学习掌握常见的设计模式
其实，大多数大项目都会用到一个或多个设计模式。设计模式会定义组件的功能描述、组件之间的关系以及抽象级别。你不需要了解或掌握所有的这些设计，但是知道基本的部分不仅对思考和设计有益，而且也有助于你在代码库中对其加以识别。
如果能够在代码库中识别这一设计模式，那么你就知道从哪里能找到特定的类和对象，当然也可以扩展这些代码，或添加更多功能。
如果设计模式能得以良好地实现，那么项目中的每个人都能在设计上达成共识，并通过代码更有效地进行沟通。
始终为下一个人考虑
无论是你自己还是其他同事，新员工还是其他公司的开发人员，总会有人负责扩展你的代码或添加更多功能。这一点很难掌握，因为大多数初级开发人员都习惯了大学时期自己做项目，所有代码都是一个人写，并没有其他人的参与。
然而，专业环境中的情况会有所不同。你要改动的项目代码是好多年前编写的，而且你的代码也必须为几年后出现的“下一个人”做好准备。所以，如果你准备编写一个临时的“hack”来实现某个功能，或者你在构建过程中添加一些东西却没有记录下来，又或者你省略了重构，那么你的这些行为都是在增加技术负债，将来必须有人来处理代偿。
每隔几个小时就停下来检查一下你的工作。在 README 文件添加所需的记录，删除你临时添加到项目中，实际上并不会使用的代码和文件。如果你无法确定某个架构或编程决策，那么请与其他更有经验的同事交流。这不仅会改善你编写的代码，而且还有助于你将来更好地处理此类情况，另外还可以习惯自尊受到伤害这一真实体验(当你不再是新手时，这种情况会不断发生)。
习惯于自尊受到伤害
开发人员是一种奇怪的“物种”——我们谈论只有我们能理解的事物，而且谈论的方式也让别人十分费解。在某些情况下，我们的工作会让客户或产品/项目经理感到不快，但这也在情理之中。某个功能可能没有正确实现，或者可能因为模糊不清的项目需求而争辩，这时我们的自尊会受到伤害：
这绝对不是我的错!我怎么能犯这样的错误?他们是白痴吗?他们恨我吗?为什么他们不理解重新实现一个功能有多艰难?
所有这些都是软件工程师普遍的想法，但是这些想法会带来不良的影响，让我们无法接受问题并坚持维护自己的自尊。很关键的一点是我们需要明白没有人针对你或你的程序。如果你们之间存在误会，那么就去解释清楚。如果出现了 bug，那么就记录下来，然后修复并测试。这才是务实专业的软件工程师该做的事情，大可不必觉得自尊受损。
你的工作不仅是成为优秀的分析师、程序员和技术人员，还要成为一名出色的专业人士。出色的软技能可以在你的技术实力碰壁的时候帮助你。
勇于承担代码清理工作
有一条著名的童子军规则：离开时请确保宿营地比你刚到时更加整洁。这实际上适用于我们日常生活的方方面面，软件开发也不例外。很多时候，我们需要扩展代码库的功能并添加新功能。我们设置好开发环境，从版本控制中提取代码并开始项目，却只看到一堆 TODO、未使用的 methods 和变量、硬编码的数字和字符串值以及未使用的依赖项。
既然我们已经参与了这个项目，所以这时我们应该坐下来考虑是否应该做一点清理工作。但是，另一方面，我们不确定我们的改动是否会破坏其他功能。如果我们重命名了代码其他部分所使用的一个 method(或者是其他项目中的依赖项)，该怎么办?确定项目所需的重构级别并不容易，然而单元测试和集成测试可以帮助我们找到代码中遭到破坏的地方，methods 的作用域亦是如此。我们在更改公共方法之前，必须确认我们是否需要相应地修改调用者(调用该方法的代码)。受保护的 methods 应该比较容易修改，我们只需要检查子类的显式实现。通常 Private methods(私有方法)的改动简单，因为它们的作用域被限制在自己的范围内。
除了 methods 的重命名和重构之外，一个负责任的开发人员还有其他工作需要做，例如删除已被注释或未使用的代码，或未使用的文件。大多数专业 IDE 都有工具可以让你检查是否有其他地方使用了某个方法。不要害怕删除被注释掉或过时的代码。这些代码只会增加项目的技术债务，而且我们还可以通过版本控制系统重新获取某个时间点的旧代码。
不要害怕参与编程之外的事情
软件工程师的本职工作是写代码。无论是分析用户故事(User Story)，写需求还是绘制数据库的概要图，我们的终目标都是编写良好强大的代码，有效地完成工作。然而，完成非技术性的任务并深入研究软技能的神奇世界也同样至关重要。与经理、测试人员和客户的沟通似乎是一项艰巨又麻烦的工作，但它也具有很大的价值。
培养你的软技能，更好地沟通和管理，一定会让你成为一个更出色的专业人士。因为你能够更好地传达用户故事，甚至不使用严格的技术语言(免得他们把我们当作外星人)也能解释清楚技术细节。
此外，能够与管理人员和客户进行更好的沟通还有助于你提高分析新的用户故事或估算完成新功能所需时间的效率。你可以提出更好的问题，所以能够更好地掌握客户的需求。
不幸的是，有些人认为软技能并不重要。然而，几乎所有与我交谈过这个问题的老板都不这样认为。我们的工作职责变化非常迅速，而软技能是为数不多的几个可以长期使用的技能之一。
记录一切
不论是添加/删除插件和第三方库，还是在代码中做假设，或者是在设置或构建过程中添加额外的步骤，甚至是使用特定版本的命令行工具时，如果没有正确的记录，那么你将面临巨大的痛苦。这个规则与第 7 条“始终为下一个人考虑”的规则紧密相关。你应该确保你不是唯一能够为开发设置项目或运行生产构建的开发人员。
实际上针对这一点有一个非常简单的规则：在完成项目处理后，将代码存储库克隆到另一台计算机上，并尝试按照说明文档进行设置。这个过程中肯定能发现缺少的说明部分，确保你能够构建健壮又专业的文档。
放松和健身的时间
对普通的开发人员来说，8 小时的睡眠和每日健身难能可贵。我们更加喜欢下班后休息、刷电视剧和玩电子游戏。健康的饮食和避免垃圾食品对我们来说更是难上加难。然而，健康的饮食和长期的锻炼确实会对你的工作情绪和表现产生巨大影响。
运动可以增加大脑的血液流量，这有助于提高你的意识，让你更好地应对下一个大项目。保持佳的身体健康状况有助于提高你整体的工作表现能力。锻炼不仅可以帮助你减轻体重，预防某些疾病，而且还可以改善心血管健康，让你的日常工作更加充满活力。
在运动时，你的大脑会释放血清素，帮助你保持愉悦的心情，改善你的心态，减轻你的工作压力。血清素是大脑中的神经递质，可以向身体发送刺激心情和情绪的信息。
除了锻炼，晚上睡个好觉可以为第二天带来好心情。繁重的工作，不规律的工作时间，学校和养育孩子的责任会夺走我们的睡眠。所有这些看似正常，却越来越耗时的现实往往会剥夺我们健康的睡眠时间和内心的平静，从而影响到我们在工作中的良好记忆和整体表现。
容光焕发(而不像少年时期那样通宵玩电子游戏后一脸憔悴)地出现在会议上，一定会让你更好地工作，而且还能给同事和客户留下好印象。
学会不要掺杂私人感情
这一条与第 8 条“习惯于自尊受到伤害”紧密相关。但前面那条更重要的是学习如何让你在感觉自尊受到伤害时坦然处之;当下这条规则是关于学习如何成为一名高效的专业人士，并避免在工作中掺杂私人感情。
虽然你很难接受，但是不断抱怨产品中错误的客户并是不讨厌你。虽然你的同事在审查你的代码时发现了一些设计缺陷和一些需要改进的技术负债问题，但这并不意味着他们认为你是一个坏人，也并非他们讨厌你或想打击你。学会接受别人的意见(即使你并不认同)，并做好工作和项目。
当然，这并不意味着你应该贬低自己的性格或接受每个人向你提出的建议，毫无疑问，你享有争辩的权利，但请时刻牢记要让你的争辩富有成效。你是为了争辩而争辩或者只是为了捍卫自己的自尊，还是说你真的提出了一些有助于改善状况的建议并取得双赢的局面?
提出富有成效的建议
初级与高级开发人员之间的巨大差距在于，后者拥有提供良好建议和实施有益的代码审查的能力。当别人征求你的意见，或你实施代码审查时，请避免从你的角度考虑问题，你应该注重大局和“共同的利益”。
优秀的软件工程师应该像优秀的超级英雄一样，在提供建议时应该采用直接且诚实的方式(当然不能粗鲁)。你看到了需要重构的代码?不要害怕大胆地说出来。如果别人征询你的专业意见，那就大方地说出你的专业意见。
这一点关键的部分在于，每当你想提出建议或指出某个缺陷或错误时，在内心默默地问自己：“我是否可以提出更好的建议?”没有建设性的建议并不比投诉强。请确保你的提议可以为当前富有成效的对话锦上添花，并时刻牢记注重大局。
作为一名高级软件工程师，你不仅需要关心自己的发展，还需要关心他人的进步。避免不断给自己建议和为他人提供富有成效的指导方针。这种做法会让你受益匪浅，因为你需要负责整个专业团队的成长。
总结
从初级开发人员晋级到中级开发人员无法一蹴而就。作为一名专业开发人员，职务提升和编程技术升级是一个培养良好习惯的问题。培养良好的个人习惯和职业习惯可以加速一个人成为有效的专业人士。我们需要长时间的不懈努力。你需要做的是尽可能地将这些习惯应用到你的日常生活中，开始逐步向真正的专业人士过渡!
