如何成为强大的程序员？

from: http://www.infoq.com/cn/news/2013/02/howto-strong-developer 

作者 侯伯薇 发布于 2013年2月8日 

Aaron Stannard是新创公司MarkedUp的CEO，他最近花费大量时间雇佣、评估很多不同的程序员，并和他们一起协作。在这个过程中他发现并总结了十种程序员无法意识到自己潜力的原因，意在让更多程序员发掘出自己的潜力，从而成为强大的程序员。

Aaron提到，他的公司中所使用的技术非常复杂，某些大型企业都很难掌握，所以对于想要加入团队的程序员来说，入门门槛非常高。因此，尽管他们非常仔细地雇佣新人，但还是很难找到足够天才的程序员。于是，他总结出十种阻碍程序员职业生涯发展的行为，并据此来帮助想要提升自身的平凡的程序员们。

1. 太害怕学不会新的工具、语言和框架

一般的程序员会墨守他们最喜欢的工具，而不希望学习新的，因为他们认为，离开了那些语言和工具，多年的经验就会付诸东流。而强大的程序员会拥抱那些挑战和机会，积极地学习新的工作方式。

2. 直到特性“完成”的时候才会提交。（但永远都不会完成！）

他在MarkedUp公司中把这种行为叫做“囤积提交（commit hoarding）”。有些程序员没有足够的信心来承受团队中其他成员的批评和审查，因此会把自己的工作藏起来，直到“完成”状态才提交。

这种开发者会损害团队中其他人员的生产力，因为团队看不到他每天的成果，而且他也不会在正常开发的过程中寻求帮助，这样就会造成很多“最后一分钟”的缺陷，从而让交付延迟。而强大的程序员会知道，代码并不是他们自己，因此会把代码经常自信地呈现在其他团队成员的眼前，获得批评和建议。

3. 只是“知其然”会很危险

在这里Aaron举了微软最近在C# 5.0中引入的async和await关键字为例，这两个关键字会让创建和管理异步调用变得很容易，但是也会造成上下文切换、对共享资源进行多线程访问的成本，仅仅对此有基本了解的程序员会盲目地使用这些特性，把所有I/O调用都封装成C#中的Task对象，这会创建出危险的、不可预测的而且非常难以测试的代码。

好的开发者不仅“知其然”，而且会了解为什么这么做以及应该在什么样的条件下使用。

4. 分析瘫痪（Analysis paralysis）

分析瘫痪是指在程序开发初期进行系统分析，常因为太过执着于控制所有可能的变化和意外，而造成大量时间的浪费，裹足不前。这是一种很经典的问题，会影响很多一般的程序员。它通常是由过度分析造成的，但是Aaron认为其根本原因在于不敢做出坏的决定。一般的程序员会担心犯错，只想一次成功。

而强大的程序员不会害怕，他们会编写很烂的代码，对其进行单元测试，如果认为无法达到目的，就会在45分钟之内把它抛弃。强大的程序员会积极地限制用来研究的时间，因为他们知道那是个陷阱——看起来是有效的，但经常都无效。

5. 没有对工具和开发过程投入

如果你想要成为天才程序员，那么就需要投入时间提升技能和知识，而将你和普通的代码工人区分开来的是快速编写出生产级别代码的能力。你可以同时拥有好的代码和速度，但是你需要先对你用于构建的过程投入。

一般的程序员不会对工具、过程和环境投入，只会使用大量的时间学习新的语言特性和API如何工作，但那并不会改变什么。

通常，你作为程序员所能够做出的最大改进并不是专注于你所编写的代码，而是优化你编写代码的过程。

6. 羞于请求帮助

一般的程序员羞于或者不想让人知道自己不懂，所以他们装作什么都知道，但这样就有可能提交某种非常可怕的代码到库中。说“我不知道怎么做。”没什么错，强大的程序员知道这一点，所以当被问题难住的时候就会请求帮助。

7. 不知道如何让其他程序员更容易使用你的代码

在所有技术团队中，工作很重要的一部分就是人员的并行（human parallelism），也就是多个人能够同时对同一代码库工作的能力。但是对于团队来说，能够异步工作也很重要，当你不在的时候我可以修改你的代码，反之亦然。

一般的开发者并不这么认为，他们会开始对一项任务编写代码，认为他们会永远拥有这段代码。而强大的开发者会知道技术债务的说法，从而试图通过设计代码来对其限制，让它尽可能可维护和自解释。

编写可读的代码需要程序员改变他们的看法——你的代码要比你在组织中存在的时间长。

8. 不知道如何阅读其他人的代码（或者不想读）

当一位一般程序员看到用他所不熟悉的语言或框架编写的代码库时，就想立刻重写，而不考虑业务价值或者推向市场的时间。而强大的程序员会接受这样的观点，重写所导致的业务成本通常是不可接受的，所以应该避免这种行为。他们会试图坐在计算机前，理解、学习然后修改现有的代码。

阅读代码要比编写代码还难，但是强大的程序员会投入时间来学习如何超越。

9. 不能从最终用户的角度编码（你考虑的范围太狭窄）

有句话说得好：作为程序员，你的工作不是解决技术问题，你之所以解决技术问题，是为了解决业务问题。

一般的程序员只会陷在技术问题之中，而不知道最初是为什么要解决这个问题。更严重的是，一般程序员无法从头开始创建出具有业务价值的东西。当被要求基于简单的用户设计新特性的时候，他们会死板地、照着字面对故事或者说明书做出解释，这样交付的产品用户根本无法使用。因为他们不会考虑相关的用例；不会考虑最终用户的体验；并且在做面向用户的内容时，设计都会很笨重。这导致他们无法编写业务应用，只能做产品。

好的程序员会从最终用户的角度来看他们的代码。我怎样才能让它更轻松地解决用户的问题呢？故事的文字内容之外有哪些方面会让这个特性给用户带来更多收益呢？

10. 无法判断任何编程任务的业务价值

这个问题和上一个是相关的，很多技术上很强的程序员之所以无法意识到自己的潜力，是因为他们不会停下来，从业务或者组织本身的角度去看一下他们的工作。

强大的程序员能够自我管理，对选择如何投入时间做出很好的业务决定，他们会问这样的问题：这是我现在应该做的最有价值的事情吗？我应该为之投入多少时间？离交付日期有两个星期，我现在能做什么，从而更容易满足那个日期呢？

一般的程序员不会，他们只会拿着说明书，然后盲目地实现，直到结束，不关心他们的工作和公司的业务目标有什么关系，以及对其他团队和业务组会产生什么样的影响。这样，他们就会在业务价值很低的技术任务上浪费大量开发时间。

Aaron在最后做出总结：如果你想要成为更好的程序员，那么就要从改变你看待代码以及编码的方式开始。你需要理解所编写的每行代码背后的业务成本；你需要从客户或者最终用户的角度来看待工作；你需要接受代码会比你在组织中存在的时间更长，所以要以其他开发者能够继承的方式来设计；最重要的，永远都不要害怕新的挑战，也不要害怕请求帮助，你无法独居一隅来提升工作效果，软件开发也是社会化的工作。

侯伯薇 是InfoQ中文站架构社区编辑，有多年对日和国内项目开发经验，目前关注企业中技术与实际业务之间的融合和协作。