如何成为一个伟大的开发者(一)

jopen 10年前

        英文原文:How to be a great software developer

        作者简介: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 说的那样,注释是个麻烦的东西,一旦逻辑改变,注释也要改变。如果代码能好的反映自身逻辑,便不需要注释。

来自: 雷锋网