【IT168 评论】我读过好多“成为更优秀开发者的方法”的文章，它们大部分似乎写于10年前。但大部分仍然很明智，因此我在这篇文章中提取出我认为的最好的10条途径。你可以随时看看。
我们开始吧。
读他人的代码 —— Scott Hanselmann
读他人的代码，并从中学习。你会适时得到提升，因为你容易学到其他开发者是如何处理问题的。结对编程是提升自我的最好途径。你从另外一个开发者那里读代码，实时地看到他/她的思维过程。反之亦然。你们可以挑战彼此的观点，共同进步。
找人读你的代码
在希腊神话里，那喀索斯(Narcissus)爱上他自己在水中的倒影。他无法抗拒不去看它。作为程序员，我们也有这样的症状，在他之后有了个名字叫自恋(Narcissism)。
当你写的代码时，会很容易爱上你的“艺术品”。但是一段代码只有当别人能读懂你干的啥时才算接近完美。
通过经常做代码评审来让他人读你的代码。你每次都能学到一两件事情，尤其在你最后发现那个方法名意义不大时。
写新的代码时先修bug —— Joel Spolsky
我肯定你遇到过这种情况。你发现了一个bug，然后说：“我过会再修，我先把这些特性搞定。”或者你看到一个单元测试没通过，但是你怕麻烦去找出没通过的原因，所以你会把这条测试注释掉抑或规避它。
来帮自己一个忙，养成早期修bug的习惯。bug只会随着时间的推移堆积成山，给你招致更多的技术债务。
学习一门新技术 —— Ryan Farley
你处于快节奏的世界。你的技术如同冰箱里的米饭一样容易变质。作为一个开发者，学习一门新技术有助于你立于刀锋上，并受到欢迎。
大量“市民”正在学习如何写代码。这并不奇怪，因为你现在正拥有这个世界上最高薪的工作。做一个极客再酷不过了。
如果你是iOS开发者，学一些Web框架，或者反过来。这样你知道如何写一个服务器端的简单例子。
保持简单
在编程里你总是可以找到一个更加精巧的方法去实现一个任务。有的人得意于他们的代码有多么令人惊叹，那样也还OK。但是保持简单，你愿意吗?这关系到前面提到的一点，让别人读你的代码。
如果他们几分钟之内无法理解，那么你是在给自己添乱(坦白地说还有那个必须维护那块代码的人)。
把你的实现发布到博客里 —— Bill Simser
在任何事情上要提高的最好途径就是教(jiāo)授。如果你能使别人理解一个概念，那意味着你掌握它了，而不只是说说。
写一篇博客，解释一下你解决手边的问题的过程。
顺便说一下，这也是一份很好的简历。如果你要找工作，你可以给你潜在的雇主一系列你的博客，这样你便有了优势。
贡献开源项目 ——Eran Kampf
就是说要么自己做一个开源项目，要么为已有的项目做贡献。这有助于你学会如何跟一群开发者协作。做很多独立的项目会尤其有帮助。
从志趣相投的开发者那里学习可以加分，并且拜托，回报开源社区不是很酷的事情吗?
修复问题，不要逃避问题 ——Danny Barbol
有一天我在和朋友谈话。她是一个会计。她说当她还有0.69美分的账合不上时会很沮丧。她花了数个小时做几百万美元的账目，到最后仅仅是因为有人在某个地方把0.96美分换成了0.69美分，结果导致他们合不上账。
作为开发者，我们经常遇到同样的事情。“一行”bug可以毁掉整个演示。有诱惑力的是不去真正的研究为什么它不去做它应该做的，而是把它绕过去。你说：“在这里添上a+5，然后就好了。”
不，找出原因，然后修正，否则绕过去的将会回过给你招来麻烦。
把代码覆盖率提高1%
有时候测试驱动开发显得很枯燥。一定要在写代码前先写好一行行测试代码?是啊，我们要诚实地说确实不总那么好玩。你想要马上开始好玩的部分。
我完全同意测试驱动开发思想，但是有时候你只是刚好有一大堆未测试的代码摆在面前。也许你从他人那里继承了一段糟糕的代码，或者你犯了错误，然后忘了加单元测试。
不要难过，不要悔恨。不管你信不信，许多项目都有相同的问题，不论他们愿不愿意承不承认。你要做的就是把单元测试一个个地加上。
像作家/作者的难产一样，盯着一张白纸看。多产的大牛说克服它的最好办法是在那张白纸(或者如今的电脑屏幕?)上开始动笔。
不要去想那24,000行未测试的代码。把它们分解成块，然后添加测试代码。今天覆盖400行，明天再覆盖400行。也许永远不会覆盖到所有的24,000行，但是一个月后未测试的代码就少了8000行。
你的基础代码变得更好了。
每小时离开办公桌休息一次
这是本文章里最重要的一条。尽管和编程没有直接关系。至少每个小时站起来舒展身子，你的身体会为此感谢你。
不要马拉松式的编程，几个小时地粘在椅子上直到最后。就算你有那种900美元的人体工程学的椅子也不要。(顺便说一下，如果有第11条，那将会是“弄一把好椅子”)
你应该不想编程挣的所有的钱，没来得及花，就去花在看病上了，是吧?
