如何成为一个伟大的开发者（转载）

做者简介：Peter Nixey，Ruby on Rails程序员，前计算机视觉学者、企业家，Clickpass公司CEO，YC孵化器的企业规划导师，Brojure公司CTO。

做为一个开发者，最关心的不外乎提升本身的软件开发水平。那要从何作起呢？积累技术知识（好比Node或者No-SQL）？死磕那些经典的算法问题（好比气泡排序或者网址缩短）？或者是打牢基础？

做为一个程序员你的价值不是由你知道什么来衡量的，而是由你能作出什么来衡量的。二者看起来类似，但有着天壤之别。你的价值在于如何将项目不断向前推动，并带领团队一块儿进步。15年的开发生涯中，我从未须要去实现一个气泡排序算法或是网址缩短程序。我要作的是花成千上万个小时来编写和重构帐户管理工具、邮件系统，编辑套件、测试套件，整理业务逻辑，部署脚本、JS层，进行架构分析以及文档管理等等。这些才是真正有意义的东西，完成了这些咱们才能迈上新台阶。

开发这些组件，就像搭建项目的一砖一瓦，须要花费几百上千小时的努力来琢磨。它们组成了复杂的系统，但它们自己却保持简单。软件之美就是“简单”。这些年的经验让我悟出的道理是，把时间花在编码和重构上，这比纯粹靠“才华”和空想更能实现目标。

执行、完成任务而后迭代，才能实现软件开发“简单和高效”的目标。深植于咱们脑海深处的关于创业的宗旨，就是先构建基础，而后迭代。软件开发亦是如此。先开发一个粗糙的版本，而后重构、修补错误、精简。要获得结果，你得老老实实去写代码！去执行！

一些聪明的懒人，老是炫耀本身的才华，让同龄人为之惊叹。但一个公司这样作是不能成功的，伟大的产品不会靠吹嘘而来。公司要依靠的是那些起早贪黑、团结协做、踏实编码的人。吹嘘容易，实干不易，且行且珍惜。

业界一直存在这样的误解：一个商业公司要完成伟大的产品，须要靠那些小圈子的名人怪咖。可在现实生活中，这样恃才傲物的一小部分人虽然在感兴趣的方面有着惊人的才华，但与团队相处很不融洽，工做起来也很不沉稳。他们不只没有实际成果，自觉得是的优越感还会影响团队的氛围。他们总认为本身天赋异禀，想干才干，爱干才干，但他们影响了团队，还会扭曲其余人的价值观。

要成为真正伟大的开发者，应该从实干作起，遵循如下准则。

规范的函数和变量命名

难以置信，在编程中这是如此简单却又如此重要的法则。清晰的函数命名，经常伴随着清晰的逻辑实现。例如：

def process_text string
…
end

这样的函数命名方式彻底不能传达出来函数的功能是什么。而：

def safe_convert_to_html string
……
end

这样的函数命名方式，准确反映出了函数有且仅有什么做用。

除了“转换文本到HTML”以外，可能有开发者愿意实现其它功能，例如自动嵌入视频等，但一般这是不须要的。清晰规范的函数命名不只能让人一眼看出它能作什么，也能让人知道它不能作什么。良好的命名规范能够提高代码可读性，让代码间关系更加清楚明白。不规范的命名，经常伴随着混乱的代码、BUG、糟糕的逻辑。

规范变量命名也一样重要，例如：

if (u2.made < 10.minutes.ago)
&& !u2.tkn
……

这样的命名方式很难让人读懂，即使读懂了，也很难保证彻底了解的做者的意图。这个变量命名很糟糕，不能传达任何信息。并且“而且不（&& !)”这样的语句原本就很是晦涩难懂，更别说在语句后面还跟着一个名词了。若是有人要重构这段代码的话，恐怕须要先费尽脑子搞清楚原做者是在干什么。若是将变量命名规范化，状况会很不同。

if (new_user.created_at < 10.minutes.ago)
&& !new_user.invitation_token

……

固然，变量命名太过多此一举也不行。例如咱们将这段代码，进一步注释成这样：

user_is_recently_created = user.created_at < 10.minutes.ago
invitation_is_unsent = !user.invitation_token

if user_is_recently_created
&& invitation_is_unsent
…

user_recently_created，这个变量命名实在是浪费时间来解释显而易见的东西。

就像DHH说的那样，注释是个麻烦的东西，一旦逻辑改变，注释也要改变。若是代码能好的反映自身逻辑，便不须要注释。

 

积累——先求深，再求广

程序员在开发过程当中，经常会遇到各类各样的问题，但不多是彻底陌生、其它团队也没有遇到过的。在Stack Overflow上最吸引眼球的提问，大多曾在其它地方出现过。

多数时候，程序员所用的编程语言自己就自带了解决方案。笔者曾经调用一个封装好的内建函数，将一段60行代码重构到1行。

重复造车轮般的过程去实现那些编程语言内建的函数不只浪费时间，也意味着程序的代码将更冗长，还可能引入bug，须要更多的单元测试和注释文档。

好好打牢本身的基础吧！若是你是一个ruby程序员，就好好学习Ruby丰富的数组方法；若是是Node开发者，就好好去理解node.js的架构；若是是Angular程序员，就去理解其内核背后的逻辑。在动手实现以前，先仔细查阅文档。记住，咱们都站在巨人的肩膀上。把时间花去学习那些顶尖程序员的思路和方法，要正确的多。

培养对代码的嗅觉

不少程序员水平不错可是遇到了平台期，问题经常出在他们不知道如何提高本身。这也许是技术生涯里可以遇到的最糟糕的事情了。要想知道如何提高本身，首先得知道须要在哪方面有所提高。一个优秀的象棋手，老是会花时间研究其余优秀棋手的路数，对于一个优秀的程序员来讲，也是如此。

要想提高本身，最好的办法莫过于培养对代码的嗅觉。哪怕不能清楚地说出缘由，也能察觉到一段代码的问题在哪里。什么是代码嗅觉？好比读到一段很难懂的代码，会察觉到哪里有问题。面对一个很基础的功能，你会以为语言自己应该有函数封装。要培养对代码的嗅觉，须要培养对代码的审美水平。代码之美，简单优雅！

在开发的过程当中，应该力图将代码写的简单优雅。若是只能用复杂丑陋的方法实现，那起码要逻辑清晰。没有对优雅和糟糕代码的嗅觉，技术水平将难以提高。

提高代码可读性

Joel Spolsky曾经说过，Stack Exchange不只造福那些提问者，也造福那些看到提问的阅读者。为何？由于许多人遇到的问题都是类似的，这些类似的问题均可以参考这个解决方案进行处理，效用便最大化了。

程序员写代码时也应采用相似的策略。也许代码仅由你本身写，且只写了一次，但它会被不少人阅读、修改。因此，在写代码的时候，除了完成任务之外，还应力图不给后来人形成麻烦。在开发过程当中，除了有良好的命名规范，还须要用严格的单元测试来保证代码足够耐用，经得起考验。种因得果，设想一下，一年以后在彻底没有耐心，时间又紧迫的状况下，让你来读如今写下的代码，你理解那种心情吧！

重视产品的生命周期成本

新手开发者们热衷探索和折腾。他们热爱那些最新最闪亮的技术，无论是No-SQL数据库仍是高并发的移动服务器，老是巴不得把全部新工具新特性所有使用起来，但这每每给后来的开发者留下一堆烂摊子。

功能和架构的选择会影响到建于其上的一切。潜在的抽象泄露风险，引起的后果将不堪设想。除非你有足够的理由，不然千万不要使用那些尚处于测试中的功能。全部主要项目的开发，都应该当心翼翼。若是非要尝试这些新特性，最好在那些辅助项目上尝试，这样保险得多。为了未来不把大量的时间都用来弥补前期捅的娄子，要谨慎使用新特性。

理解技术负债

技术负债是指那些混乱糟糕，但还能工做的代码。好比一个本应该用面向服务的架构，却单独开发了的APP；或者一个重构后只须要十分之一执行时间的Cron任务脚本。

技术负载不只会累加，还会带来复合效应。爱因斯坦说过，“世界上最强大的力量是复利”。类比到软件开发上，技术负载的复合效应也最具备毁灭性。多数开发者遭遇过这样的项目：哪怕是一点轻微改变，都不得不花费几个月的时间。这种状况下，你会失去保持代码整洁优雅的兴趣和耐心，只求不要把整个服务弄崩掉。

技术负债还有一个特色是：你不须要偿还。当开发的一个功能最后发现是错误的、不工做的，你会直接放弃它，同时也放弃全部的优化、测试及重构。因此，若是不是真正须要的话，那就不要去开发。将效用最大化，忽略错误。

技术负债，就像一个蛙跳游戏。最初的代码都只是尝试，只要能实现目标快速推动就好。这让咱们有足够的时间来提出解决方案，足够的空间来创建基础设施。产品的生命周期越长，投入在基础设施上的时间就越长。有了稳固可靠的基础设施架构，才能支撑起一个高质量的产品。

总结并分享所完成的工做

无论用什么样的风格来注释文档，无论是用邮件仍是Wiki，必定要花时间记录开发流程以及所用到的资料，并分享给其余团队成员。他们和你同样，也会遇到各类安装和调试的问题。软件开发中，最使人头疼的事情就是花费大量的时间来解决bug和安装调试。若是你用一点时间来制做文档或者教程的话，将为团队省下更多的宝贵时间。