如何成为一枚普通的程序猿，答案比较简单，那就是完成自己的工作。如何成为一个牛逼的程序猿，答案就难，这里列出8+8条成为牛逼程序猿的准则。

第一部分：有关代码

1：技术是用来让你获取解决方案的，但它本身并不是解决方案

我们对于特定的技术必须非常谨慎不要太疯狂，不是我们碰巧喜欢或者碰巧现在很流行，而是要考虑运行他们所带来的风险，要思考这个问题是不是就是那个钉子，而我们是不是碰巧拿着锤子，那么我们就要学习它。

2: 对代码而言，“聪明”是“清晰”的敌人

在写代码的时候，我们应努力保持书写的代码清晰易懂。

可以明确（Clear）表明自身意图的代码，永远要比那些晦涩的代码更有价值-无论那些晦涩的代码被构建得多么聪明（Clever）。

虽然情况并不总是这样，但一般来说，“聪明”是“清晰”的敌人。

一种经常出现的情况是，当我们写出一段“聪明”的代码时，这段代码并不是特别的“清晰”。

这条规则非常重要，尤其是当我们思考我们要做一些特别“聪明”的事情时。

有时候我们写出了“聪明”的代码，它们同时也是清晰的，但是其他情况也会时有发生。

3: 只在逼不得已的情况下才写代码

这条可能会有些争议，毕竟，作为程序员，我们的工作不就是写代码吗？

写代码的确是我们工作的一部分，但是，我们要尽可能努力的去用最少的代码来解决问题。

所谓“最少的代码”并不是说我们只能用一个字母的变量名或者其它方式来压缩我们的代码。“最少的代码”指的是我们应该只写为了实现功能而必不可少的代码。

我们常常添加一些“酷”的功能，来让代码“健壮”和“灵活”，让代码能够处理“所有”可能的使用情况。我们企图猜测那些可能会被用到的功能。总之，我们常常花费时间去解决一些头脑中臆想出来的可能的情况。

我们这么做，是错的。

不能否认，这些多余的代码能会带来些好处。然而，这些代码同样的会有很多危害。我们写得代码越多，就越有可能引入错误；我们写得代码越多，将来的维护工作就越繁杂。

好的软件工程师只写绝对需要的代码。

伟大的软件工程师会把没用的代码统统都删掉。

4: 注释是魔鬼

Bob Martin说：“你写的每个注释，都代表着你表达能力的欠缺”

这并不是说一点注释也不写，但通常我们可以通过一种更好的方式——命名来避免。

注释仅在命名不能有效表示变量或方法的意图时才真正需要。此时的注释表达了不能用代码表达的真实意图。

例如，注释能够告诉你在代码中某些奇怪的操作顺序并不是错误的，它是由于底层系统的某一bug而有意为之的。

但通常，注释不仅没有必要，有时它们还会"撒谎".

注释没有随着代码更新的倾向，而这是很危险的，因为它们会将你带入歧途。

你会查检每条注释和与之对应的代码，确保代码是在做注释说的事么？如果是的话，写注释还有什么用？如果不是，你怎么相信注释说的是对的？

真他妈麻烦，所以最好还是尽量别写注释了。

OK，喷子们，在下面的评论区里留下你们的“口水”吧，但我会无视你们的。

5: 永远要在你开始写代码前考虑好它是做什么的

这一条看上去显而易见，然而事实并非如此。

想想你有多少次并没有完全想好就坐下来写代码，而这段代码确实实现了你要做的功能？

比之我乐于承认这个思路的正确性，我行动了更多次，这是一条我需要经常去品读的规则。

练习测试驱动开发（Test Driven Development，TDD）在这里会有所帮助，因为你在写出代码前，必须逐字的了解它们会做些什么，但是这依然无法阻止你去做错的事情。因此，在构建一个特性或功能前，保证自己百分之百地理解需求，也是很重要的。

6: 在交付之前，测试你的代码

别把你的代码直接扔给QA，然后指望着所有人来浪费时间为你服务。

事实上，你自己认真的运行一下测试案例，是完成代码之前必不可少的一步。

这并不是说一定让你自己找到代码中所有的问题，但是你至少得把那些愚蠢得令人尴尬的错误找出来吧？

很多软件工程师都觉得测试代码是QA的工作。这个想法绝对是大错特错。保证代码的质量，是每个人的工作！

8: 写代码是件快乐的事

诚然，你最开始进入这个行业可能只是因为它待遇优厚。

我是说，为了良好的待遇找工作没有任何错误，但是医生或律师可能会是更好的选择。

你之所以成为了一名软件开发人员，是因为你爱写代码。因此，不要忘记你在做你所热爱的事情。

写代码有很多乐趣，我希望我能写更多的代码。

我这几天经常忙于写代码并试图让它占据我更多的时间，这也是我为什么如此清晰地记得它有多么的有趣。

也许你已经忘记了写代码的乐趣，也许是时候你应该再次记起写代码是多么的有趣了-通过开始一个边角的项目，或是仅仅改变你的心态，意识到你开始写了代码，并为之付出。（但愿如此）

第二部分：有关客户

1：客户在接触到产品之后，才会真正明白自己的需求

这是我在我的第一份工作上面学来的。只有当我们给客户展示产品的时候，他们才会意识到哪些是必须的。给出一个功能性原型设计远远比一张长长的文字表格要好。

2：成功源自于失败中的学习；失败则是因为容忍错误的横行

有很多程序员总是在辩解，说什么“程序这么难，犯错误很正常了，软件变得糟糕也在所难免了”。这种理由听得多了，于是，大家也逐渐接受了这些扯淡的 借口。但是我们作为程序员真的不应该让这些借口阻碍我们的进步，应该谨记，错误只能犯一次，要吸取教训。话说是程序员都会希望自己下一次就能一次性搞定代 码。但是没有人是完美的，不过至少我们是在朝着这个方向前进的路上。

3：唯一不变的是变化本身，这是谁都无法改变的法则

计划永远赶不上变化，以为明天的世界和今天一样，这种想法本身就是愚不可及的。尤其是在编程世界里，没什么是永恒的。人不能两次踏进同一条河里。

4：适合你的不一定适合他

在软件项目中我们可做的选择有很多。但是适合你和你当前情况的选择可能一点都不适用于其他人。我们经常能听到别人说自己又在干什么伟大的创举，但是如果他们说什么这是唯一的好方法时，我会对此嗤之以鼻。

5：不管黑猫白猫，能抓到老鼠就是好猫

只要你的软件能实现客户指定的功能，他们才不会关心需要解决哪些问题。用户永远不会对这些发生兴趣。如果发生意外情况，最好能坦诚说出来，但是你最好要能确保这种情况不会持久，因为你总给将最终的产品交给客户。

6：客户的意见决定质量

这是我在我的第一份工作上面学来的。只有当我们给客户展示产品的时候，他们才会意识到哪些是必须的。给出一个功能性原型设计远远比一张长长的文字表格要好。

7:对某方面的无知可能会让你一败涂地，因为你在这方面毫无经验。

即使到了今天我依旧在不断惊叹，有的同行竟然仍然没有收集足够的日志、崩溃报告和使用信息来掌控自己的软件。那些对这方面信息不屑一顾的家伙，大多 会高估产品的质量。因为如果你不采取措施和记录结果，浑浑噩噩地混日子，终将会导致你对当前情况一无所知，包括你的客户。我一直反复强调，详细而有用的日 志记录、程序崩溃跟踪、评论和意见，反正各种只要能让我尽快了解发生了什么问题的途径和方法，都是可行的。不过，我也知道有很多人认为“这种事和程序员有 一毛钱的关系吗？”。

8:永远不要太相信销售的话

有些销售总是把这两句话挂在嘴上：

“客户还是找愚蠢的好。”

“我的工作是欺骗客户，而你的工作则是支持我。”

认可了，你就错了，这样的销售还是换掉的好。

ok，都散了吧，赶紧回去看需求，写代码。