网路上有很多关于如何写好代码的文章。一个新入行的开发人员如何才能记住这些技巧？一篇名叫《Code Complete》的指导就是一份非常好的学习资料，可惜的是，它长达960页！

我认为，找到一种简单可行的框架是完全有可能的，这种框架可以用在任何语言中，让你写出高质量的代码。今天我将会讨论5个主要的概念。将这些概念时刻记在心里，写出好的代码不是什么太难的事情。

抛弃个人的怪习惯

假设你阅读了一篇文章，里面介绍的编程技巧让你受益匪浅。现在你想在工作中使用这些clever code，让你的同事大吃一惊。

然而问题是，人们只是想要修复bug，然后继续去做别的工作。你所使用的那些技巧很多时候只会让人们分心。当别人在消化你写的代码的时候，他们的“心理堆栈”会越来越高，进而很难获得任何进展。

如果你写的代码需要你向其他人进行解释，那就不要用这种写代码的方式。不要用“你自己的方式”去写代码。时刻遵循标准的写码方式，所有人都理解的方式。按照所有人的习惯去写代码，让你的代码易于理解。

对复杂代码进行拆分

复 杂的代码在很多时候，可以通过模块化处理而变得容易理解，有很多种方式都可以完成这个目标，不仅仅只有创建更多函数而已。将长条件的结果储存为一两个变 量，这就是一个对复杂代码进行模块化的好方法，而且无需发起函数调用。这种方法甚至还可以让你将它们组成更大的条件，或是在其他地方对其进行重复使用。

将 问题拆分的方法，应该注意要尽可能的将每一个部分独立处理，让其只影响局部状态，不要混入不相关的问题，还要尽可能的避免副作用。编程语言和库经常有着自 己的问题，规避这些问题可以帮你的代码管好自己的事情。单一职责原则（ Single Responsibility Principle）是另一个很好的例子，它说明了专注于局部代码可以带来优秀的设计。

我非常喜欢利用变量来划分逻辑。

TDD 在用好的时候有着自己的好处，除了这些好处之外，它还一直在要求人们使用那些此前并不流行的一些原则。无状态代码曾一度因为其速度慢以及需求程度不高而被 人们放弃（例如大多数老旧的C/C++代码），而现在所有人都在讨论纯函数。即使你不做TDD，也也应该学习它背后的驱动原则。不断学习新的知识，能让你 变成一位适应性极强的开发人员。

让你的计算机可以轻松对其进行处理

你的计算机和你所使用的工具也和你一样，在处理代码的时候也会遇到困难，这种困难的程度取决于多个因素：处理器的数量、突变的数量、以及代码的复杂程度。

我们先不讨论那些额外开发工具可以给你带来的好处。这些工具很有可能要求你使用领域特定语言，例如自定义模板，或是复杂且处于动态的数据架构，例如散列表。你的IDE总体来说并不善于处理这些东西，而且定位相关的代码也会变得更加困难。

你应该避免使用那些无法与你的IDE良好协作的语言扩充和库。他们对你的工作效率会产生巨大的影响，而且这种影响要远远大于它所给你带来的好处和便利。

另 一个让代码与IDE和平共处的方式，就是避免使用所谓的“magic code”。大多数语言都为你提供了写更加动态代码的方式。然而，过渡使用这些功能，将会产生不连贯、不成系统的代码库。通常情况下，那些只有人类才了解 其意思的功能，都会走上这条路，而且这通常是一条不归路，因为你的IDE无法理解代码，当你想要对其进行重构的时候，你会发现IDE的重构功能根本无法使 用。

 提高可读性

在工作过程中，你应该给自己制定一个方向：打造一个可预测的架构。在这个架构下，你的队友能 轻松找到他们需要的东西，这能够大大减少他们完成任务的所需要的时间。当你们确定了项目的整体架构之后，就要不断的让主要元素出现在最明显的位置上。你在 使用MVC？将模块、视图和控制器放在他们自己的文件夹内，而不是放在三个深埋底下或是散落在四处的三个文件夹里。

我之前讨论了模块化。但 是在这里，你不要过多的使用模块化，否则将会导致代码难以定位。你的IDE可能会帮你一些忙，但是很多时候IDE将会忽略库文件夹，因为里面有着太多不相 关的代码，而你将会备受折磨。这是一个双输的局面。试着使用更少的库，你要选择那些包含尽可能多的你所需要的东西的库。

 和工具的选择对于 新入行的开发人员来说也是一个巨大的挑战。我不久之前用EcmaScript 7开发了一个项目，但是之后我才意识到，我们的初级开发人员完全看不懂代码是什么意思。这给我们团队的工作效率造成了巨大的影响。我低估了这些工具对一个 刚开始编程的人有多么难以理解。不要使用那些现阶段对于大多数人来说还难以理解的工具，等待合适的时机。

我写的一些真实代码。初级开发人员还无法掌握这种新出现的技术。

 让代码容易消化

 读 到这里，我要给你一个好消息：下面这一条是最重要的技巧。在软件开发领域，众所周知选择好的名称是最重要的事情之一。而你无法通过开发工具来实现这个目 的，因为计算机无法理解解决方案背后的思考过程。你必须记录这个原因。先关和情景变量、函数名称就是一个不错的方法。能够表达目的的名字甚至可以让你不再 需要记录。

在名称前面使用前缀是一个很好的给名字添加含义的方式。这个方式曾经流行过一段时间，后来被人们慢慢抛弃，我认为它被抛弃的原因 在于人们的错误使用。前缀系统，例如匈牙利标志法，其诞生之初就是要添加含义，但是随着时间的推移，他们被人们错误的使用，最终我们只是用它来添加对象种 类信息。

最近Fluent interface一直在被滥用

最后还要说说降低圈复杂度的问题。它的意思是将条件分支的数量维持在尽可能低的范围。每一个额外的分支不仅会增加凹陷、对可读性造成破坏，更重要的是，它还会增加你要监控的东西的数量。

总结

 以上是5个简单而重要的概念，我的目标是让你的编程学习变得更简单，让你更合理的安排代码结构。