IT思维

作为一个开发者，如何能够突破自身的约束，来完成一个伟大的创举，至少需要一个伟大的产品来证明自己。

原文作者 Peter Nixey 为 Ruby on Rails 开发者，前计算机视觉学者、企业家，Clickpass 公司 CEO，YC 孵化器的企业规划导师，新创公司 Brojure CTO。以下文字以作者第一人称撰写。

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

作为一个程式设计师，你的价值不是由你知道什么来衡量的，而是由你能做出什么来衡量的。

两者看起来相似，但有着天壤之别。你的价值在于如何将项目不断向前推进，并带领团队一起进步。15 年的开发生涯中，我从未需要去实现一个气泡排序算法或是网址缩短程序。

我要做的是花成千上万个小时来编写和重构账户管理工具、邮件系统，编辑套件、测试套件，整理业务逻辑，部署脚本、JS 层，进行架构分析以及文档管理等等。这些才是真正有意义的东西，完成了这些我们才能迈上新台阶。

开发这些组件，就像搭建项目的一砖一瓦，需要花费几百上千小时的努力来琢磨。它们组成了复杂的系统，但它们本身却保持简单。软体之美就是「简单」。

伟大的产品不会靠吹嘘而来，公司要依靠的是那些踏实 Coding 的人
这些年的经验让我悟出的道理是，把时间花在编码和重构上，这比纯粹靠「才华」和空想更能实现目标。

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

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

业界一直存在这样的误解：一个商业公司要完成伟大的产品，需要靠那些小圈子的名人怪咖。

可在现实生活中，这样恃才傲物的一小部分人虽然在感兴趣的方面有着惊人的才华，但与团队相处很不融洽，工作起来也很不沉稳。他们不仅没有实际成果，自以为是的优越感还会影响团队的氛围。他们总认为自己天赋异禀，想干才干，爱干才干，但他们影响了团队，还会扭曲其他人的价值观。

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

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

def process_text string
…
end

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

def safe_convert_to_html string
……
end

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

除了「转换文本到 HTML」之外，可能有开发者愿意实现其它功能，例如自动嵌入视频等，但通常这是不需要的。

清晰规范的函数命名不仅能让人一眼看出它能做什么，也能让人知道它不能做什么。良好的命名规范可以提升 Code 可读性，让 Code 间关系更加清楚明白。不规范的命名，常常伴随着混乱的代码、BUG、糟糕的逻辑。

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

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

这样的命名方式很难让人读懂，即便读懂了，也很难保证完全了解的作者的意图。

这个变量命名很糟糕，不能传达任何讯息。而且「并且不（&& !)」这样的语句本来就非常晦涩难懂，更别说在语句后面还跟着一个名词了。如果有人要重构这段 Code 的话，恐怕需要先费尽脑子搞清楚原作者是在干什么。如果将变量命名规范​​化，情况会很不一样。

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

……

当然，变量命名太过画蛇添足也不行。例如我们将这段 Code，进一步註释成这样：

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 说的那样，註释是个麻烦的东西，一旦逻辑改变，註释也要改变。如果 Code 能好的反映自身逻辑，便不需要註释。

积累 —— 先求深，再求广
程式设计师在开发过程中，常常会遇到各种各样的问题，但很少是完全陌生、其它团队也没有遇到过的。在 Stack Overflow 上最吸引目光的提问，大多曾在其它地方出现过。

多数时候，开发者所用的程式语言本身就自带了解决方案。笔者曾经调用一个封装好的内建函数，将一段 60 行 Code 重构到 1 行。

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

好好打牢自己的基础吧！如果你是一个 Ruby 程序员，就好好学习 Ruby 丰富的数组方法；如果是 Node 开发者，就好好去理解 node.js 的架构；如果是 Angular 程式设计师，就去理解其内核背后的逻辑。

在动手实现之前，先仔细查阅文档。记住，我们都站在巨人的肩膀上。把时间花去学习那些顶尖程式设计师的思路和方法，要正确的多。

培养对 Code 的嗅觉
很多程式设计水平不错但是遇到了平台期，问题常常出在他们不知道如何提升自己。这也许是技术生涯里能够遇到的最糟糕的事情了。要想知道如何提升自己，首先得知道需要在哪方面有所提升。一个优秀的象棋手，总是会花时间研究其他优秀棋手的路数，对于一个优秀的程式设计来说，也是如此。

要想提升自己，最好的办法莫过于培养对 Code 的嗅觉。哪怕不能清楚地说出原因，也能察觉到一段 Code 的问题在哪里。什么是 Code 嗅觉？

比如读到一段很难懂的 Code ，会察觉到哪里有问题。面对一个很基础的功能，你会觉得语言本身应该有函数封装。要培养对 Code 的嗅觉，需要培养对 Code 的审美水平。 Code 之美，简单优雅！

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

提升 Code 可读性
Joel Spolsky 曾经说过，Stack Exchange 不仅造福那些提问者，也造福那些看到提问的阅读者。为什么？因为许多人遇到的问题都是相似的，这些相似的问题都可以参考这个解决方案进行处理，效用便最大化了。

程式设计师 写 Code 时也应採用类似的策略。

也许 Code 仅由你自己，且只写了一次，但它会被很多人阅读、修改。所以，在写 Code 的时候，除了完成任务以外，还应力图不给后来人造成麻烦。在开发过程中，除了有良好的命名规范，还需要用严格的单元测试来保证 Code 足够耐用，经得起考验。

种因得果，设想一下，一年之后在完全没有耐心，时间又紧迫的情况下，让你来读现在写下的 Code，你理解那种心情吧！

重视产品的生命週期成本

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

功能和架构的选择会影响到建于其上的一切。

潜在的抽象洩露风险，引发的后果将不堪设想。除非你有足够的理由，否则千万不要使用那些尚处于测试中的功能。所有主要项目的开发，都应该小心翼翼。如果非要尝试这些新特性，最好在那些辅助项目上尝试，这样保险得多。为了将来不把大量的时间都用来弥补前期捅的娄子，要谨慎使用新特性。

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

技术负载不仅会累加，还会带来复合效应。

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

技术负债还有一个特点是：你不需要偿还。当开发的一个功能最后发现是错误的、不工作的，你会直接放弃它，同时也放弃所有的优化、测试及重构。所以，如果不是真正需要的话，那就不要去开发。将效用最大化，忽略错误。

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

总结并分享所完成的工作
不管用什么样的风格来註释文档，不管是用邮件还是 Wiki，一定要花时间记录开发流程以及所用到的资料，并分享给其他团队成员。他们和你一样，也会遇到各种安装和调试的​​问题。

软体开发中，最令人头疼的事情就是花费大量的时间来解决 bug 和安装调试。如果你用一点时间来制作文档或者教程的话，将为团队省下更多的宝贵时间。

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

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

让团队进步
你的存在，是让你的团队变得更好了？还是拖了团队的后腿？你的 Coding 质量、文档和技术水平，是不是帮助周围的人有所提升？你有没有启发和​​鼓舞队友，让他们变得更好？或者，你是那个 Bug 制造者，浪费时间争论无意义的架构问题，到最后没有实际产出的人？

一个伟大的开发者，应该影响他周围的人，让团队一起进步。

成果最重要
「你是谁并不重要，重要的是你做了什么」，电影《蝙蝠侠》里这句台词能很好的用在软体开发者身上。

作为一个开发者，你有多聪明，了解多少技术知识并不能衡量你的能力。你的简歷上，会写你会什么语言、在哪里上的大学、在哪家公司工作过等等，这些只能显示出你会什么，能做什么。

但是真正意义上能够说明自身价值的，是你能让你和你的团队能改变什么！

【 本文资料参考自TechOrange ，由IT思维整编发布，所有转载请注明作者和来源。 】