少编码多思考：代码越多 问题越多

学习语言而不是框架

我喜欢PHP、Python和JavaScript，喜欢用他们作些东西。但我却不是Symfony、Django、jQuery开发人员。

我认为这有很大的区别。一我的颇有可能成为一名jQuery程序员而非JavaScript，也有可能成为Django程序员而不是Python。在实际应用中，的确存在许多有价值且很是实用的工具和框架，但若是我仅知道如何使用一个框架，我想表达的观点是在工做上只使用合适的工具其实会给任务带来一些限制，你能够查看一下，看看你用的工具，看看你用的框架。以个人经验来看，一些复杂的全栈（full-stack）框架并非很是合适的工具，尤为在灵活性和性能方面都不是太好。

集中精力学习一门语言会让程序员变的更加灵活。全栈式复杂框架能够帮助我快速的构建某个产品，但当我须要一个不属于框架范围内的解决方案时，它反而会变成一种伤害。我常常会采用“plug和pray”方法进行开发，当我发现某个库或插件能够知足需求时，我就会把它们应用到产品里。这样可能会使应用程序快速推出，但在之后的道路上会留下不少障碍。

此外，学习全栈框架和学习新语言同样复杂。它们一般都有复杂的体系结构和术语，而且有些部分并不适用于其余框架和工具上。固然框架也有许多好处，但前提是你必需要懂这门语言，而后才能理解其真正的工做原理，因此我宁愿花时间学习更多关于语言自己的东西，而且把所学的技能应用到其余语言或者库上。

构建小模块

有些小型的单元代码是很好很讨程序员们喜欢的，由于越小越容易理解且很难把它弄的很糟，因此限制编写冗长复杂的代码是很是重要的。

因此有目的的构建一些小模块——尽量的接近需求目标。它们应该是独立的块，单纯地解决某方面问题，可是把它们结合起来时，就能够解决许多大型的、复杂的问题。

像这些简单的模块代码修复起bug来也会很是容易。由于这些单独的块通俗易懂，一看就会知道其用途。若是模块是自我包含的，那么测试起来会更加简单。

代码越少越好

套用Biggie Smalls的一句话：“代码越多，问题也就越多”。

谁都喜欢管理少的代码。估计你们都有过这样的体会，当审查一个功能模块的代码时，若是代码不少很乱，第一印象确定很差，相反，若是该模块代码简洁明了，你会很是愉悦。更通俗点讲就是代码越多，管理起来也就越困难：搜索代码库的时间会变长、查看文件导航也须要较长的时间、跟踪执行也会变的困难等。

你是否发现，代码审查、还有你使用的工具，很大程度上都是用来减小代码量的。那些庞大的库和长代码彷佛会溢出人们的大脑缓冲区。当我在追踪一段较长的源码或执行跳跃好几个源文件的功能时，我会感到很苦恼。这就是为何我会喜欢给语法进行着色的编辑器，而且保持一致的空格对我也很是有帮助。

除了喜欢管理较少的代码外，我还支持开发者们尽可能简化代码。程序员要为应用程序所使用的代码，不只仅是本身编写的部分负责——甚至是这些应用里的每行代码。这也就意味着要替这些应用里出现的bug或者安全漏洞负责。

你会在程序中使用本身不理解的代码吗？这并不表示我从不使用他人的代码——坦白说，世上有许多优秀的程序员，可是在应用他人代码的时候，你必须理解代码，由于应用程序里的每行代码都很重要。在编码时千万不要忘记思考，编写最少代码的背后应该是多思考，这样就不会给本身带来没必要要的麻烦。

编写简单、有用可读的代码

编写容易理解的代码，少编码多思考，这样完成一个功能就会很快，生产力就会获得提升。

固然，我也但愿代码是可验证的。而且我一直认为简单、模块化的代码是更容易被测试。

代码应具有的另外一特征就是可读。代码应简洁明了，语义清楚。在编写代码时，我会思考其余程序员在第一眼看到它的时候会花多长时间来理解。或者一两个月后我本身能一目了然吗？正如你们熟知的那句编程谚语：任何一个傻瓜都会写出可以让机器理解的代码，只有好的程序员才能写出人类能够理解的代码。当我试图发现它们工做原理的时间越少，作的事情就会越多。

可是不多有人能坚持这些规则，若是我说是，那么我确定是在撒谎。有时候我也会很懒惰，甚至因为时间限制，我会编写一些复杂的、难以理解的代码或者使用没有审查的库来实现某个功能。想要在短时间内编写简单、清晰的代码会很困难——它须要更多的纪律和不断的技术评估。特别是那种对时间敏感的项目，实行起来将会更难。

可是，当你花时间和精力去作的时候，你会发现功夫不负有心人——不只仅对本身有帮助，还会给其余团队成员带来不少益处。