主页 > 最具权威 >如何成为一个杰出的开发者 >

如何成为一个杰出的开发者

如何成为一个杰出的开发者

作为一个开发者,最关心的不外乎提高自己的软体开发水準。那要从何做起呢?积累技术知识?死命嗑那些经典的算法问题?或者是稳固基础?

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

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

执行、完成任务然后迭代,才能实现软体开发「简单和高效」的目标。深植于我们脑海深处的关于创业的宗旨,就是先构建基础,然后迭代。软体开发亦是如此。先开发一个粗糙的版本,然后重构、修补错误、精简。要得到结果,你得老老实实去写程式!去执行!

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

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

要成为真正杰出的开发者,应该从实干做起,遵循以下準则。

规範的函数和变量命名

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

这样的函数命名方式完全不能传达出来函数的功能是什幺。而:

这样的函数命名方式,準确反映出了函数有且仅有什幺作用。

除了「转换文本到 HTML」之外,可能有开发者愿意实现其它功能,例如自动嵌入视频等,但通常这是不需要的。清晰规範的函数命名不仅能让人一眼看出它能做什幺,也能让人知道它不能做什幺。良好的命名规範可以提升程式可读性,让程式间关係更加清楚明白。不规範的命名,常常伴随着混乱的程式、BUG、糟糕的逻辑。

规範变量命名也同样重要,例如:

这样的命名方式很难让人读懂,即便读懂了,也很难保证完全了解的作者的意图。这个变量命名很糟糕,不能传达任何信息。而且「并且不(&& !)」这样的语句本来就非常晦涩难懂,更别说在语句后面还跟着一个名词了。如果有人要重构这段程式的话,恐怕需要先费尽脑子搞清楚原作者是在干什幺。如果将变量命名规範

化,情况会很不一样。

if
&& !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 和安装调试。如果你用一点时间来製作文档或者教程的话,将为团队省下更多的宝贵时间。

把握好测试的平衡

软体开发中的测试活动是强有力的工具,它能让你为产品发布做好準备。走过测试流程,新版本的发布对你来说应该是件信心满满的事,不会感到恐慌,新版本的发布也会进展的更快。经过的测试流程太少,有可能会出大乱子。当然,如果测试流程过头了,你会变得绑手绑脚。

至于进行多少量的测试,没有直接的答案。每个专案需要的测试总量和测试点都不同。在开发的过程中,我们应该下点功夫理解什幺部分是真正需要测试的,什幺时候测试才会产生价值。不要害怕进行测试,也不要害怕不进行测试,只要找到其中的平衡点就好。

让团队进步

你的存在,是让你的团队变得更好了?还是拖了团队的后腿?你的程式品质、文档和技术水平,是不是帮助周围的人有所提升?你有没有启发和

鼓舞队友,让他们变得更好?或者,你是那个 Bug 製造者,浪费时间争论无意义的架构问题,到最后没有实际产出的人?

一个杰出的开发者,应该影响他周围的人,让团队一起进步。

成果最重要

「你是谁并不重要,重要的是你做了什幺」,电影《蝙蝠侠》里这句台词很适合用在软体开发者身上。

作为一个开发者,你有多聪明,了解多少技术知识并不能衡量你的能力。你的简历上,会写你会什幺语言、在哪里上的大学、在哪家公司工作过等等,这些只能显示出你会什幺,能做什幺。但真正衡量你作为一个开发者的价值的是,你做了什幺,专案和团队因你而改变了什幺!

via peter nixey



上一篇: 下一篇: