如何做个好的程序员:新年计划

　　我的同事朋友Chris Eargle写了一篇关于新年计划的有趣文章。他让我想到了，没有出现那场世界末日是我们多么大的幸运呀(还有其他我这45年中躲过的天灾)，于是，我也有了一些我自己的以程序员为主题的新年计划。

　　找到一名导师/成为一名导师

　　在你的职业生涯中，你能做的会给你带来最多麻烦的事就是成为屋里最聪明的人。我说的并不是你坚信自己你就是屋里最聪明的人。我的意思是你成为团队里真正的万事通。问题终结者。终极疑难解答者。

　　于是，这就有了另外一个问题：你有疑问了去问谁呢?

　　如果你的回答是“谷歌”，那你是不思进取。去到那些你认识的(或不认识的)最聪明的人中间去。参加你们的本地社团。去你们本地的编程活动中发言，去和其他的讲演者一起喝酒聊天。找那些你可以接触到的人，让他们成为你的导师。

　　找到一名导师

　　我在生活中有好几位导师。他们是我尊敬的人和能让我轻松问问题的人。有些人甚至非常的专业!没错，这些是我软件开发圈外的导师。

　　如何去请教你的导师?这取决于你。我是在有问题时找他们。我对他们说喝杯咖啡吧，找个地方坐下来，聊聊天。如果我们能同一个城市的某个研讨会上遇到，我会和他们一起出去喝酒吃饭。早些年，我很注重形式礼节，特别是我作为团队的消防队员的时候。如今，我已经不再有任何形式拘束了。更多的是随心所欲的求教。

　　成为一名导师

　　同样，我们也应该成为生活中的某些人的导师。如果你有孩子，你已经承担起了一名导师，父母，朋友，老师的职责。当然，对于一些同龄人的指导，我们需要去掉父母那部分的角色。对他们你是不能发号施令的。

　　如何让自己成为其他人的导师?当然，如果有人来请教你，那是最好了。这就有些名正言顺了。但你也可以在不声明“我是你的导师”的情况下成为某人的导师。看看是否有人在为一些事情愁眉不展，你可否帮助他们?对他们说喝杯咖啡吧(如果是九零后就喝红牛)。去跟他们一起吃饭。跟他们聊天。更重要的是，倾听。指导并不是宣扬你的智慧或你的经验。导师是要成为一个耳朵，一个肩膀，一个指点方向的手指——在他们需要的时候。

　　2010Feb08_0123.jpg/Jerome T/CC BY

　　KISS

　　“贝丝，你在呼唤我，但我只是想去底特律摇滚城市里每天没日没夜的摇滚”![歌曲KISS的歌词]。似乎这个社会在召唤你制定一个加入这种KISS大军，去吃喝玩乐，去体验生活的新年计划。但我在这里说的可不是这些。

　　我说的是Keep It Simple, Stupid!作为程序员，我们绝大部分时间都是花在了维护代码上，只有少部分的时间用来创造代码。事实也证明，维护代码要比写新代码要难的多。所以，按照这种逻辑，如果我们在创造代码时极尽所能写出最巧妙的代码，那么我们就没有足够更高的能力来维护它们了。

　　Blaise Pascal在他的第16封省府信件中说“这份信件很长，原因很简单，我没有时间使它更短”。抽出时间，重构你的代码，让它们更短小。让它们更容易阅读。尽所可能的在所有地方遵循SOLID原则。

　　如果你不能把它向一个9岁的小孩解释明白，这说明它太复杂了。公司雇你不是让你来表现脑瓜好使的，如果你写的代码没有任何人能接手维护，你不会因此而得到加薪或晋升。

　　Keep it simple, stupid (and short)/Jegi/CC BY

　　去读该死的手册(RTFM)

　　这是我的第一次圣诞节里不需要在平安夜里去做一些东西。在以前，我会做小脚踏车，布娃娃房子，布置厨房，以及所有类似的东西。当然，做这些东西都不需要参考手册，只是需要在孩子们上床睡觉后才能开始，而且第二天早上天蒙蒙亮就会被三个孩子跳上床来吵醒。噢，这些美好的回忆!

　　当然，所有的这些不眠之夜都有一个相同的主题。我知道我不需要读操作手册就能做这些。可工作中更常见的是，文档上的图表画的一团糟，文字是经过了三种不同语言翻译过来的，我对这些文档的质量的意见一致很大。我认为只要埋头去做，我能做出任何东西，所以为什么要读那些无聊的手册呢?这是不是好像是在说你上一个项目的需求文档?

　　不管你相信与否，人们通常大量的时间用在写需求上。他们并不是有意的要写这些东西来让我们困惑。需求很难写的面面俱到，让每个人都理解。但它们却是你的项目的基础，包含了大量的项目上的知识。所以说，读读它们吧。如果是先读它们，然后到它们的作者那里问一些问题，这是更好的做法了。用心听!聊一聊。每一次有感悟都要重读它们。再去聊一聊。

　　[127/365] Immersed/pasukaru76/CC BY

　　不要重复自己

　　一个朋友对我说“如果你写出一些代码，你应该把它做成一个方法。如果你写了它两次，你应该把它做成一个方法。如果你写了它三次，那你就别去编程了!”

　　我举双手赞成。如果你把自己的代码从一个项目拷贝到另一个里，你是在给自己未来的道路上挖坑。没错，你能记得修改手头上这个项目里的这段代码，但其它项目里的这段代码呢?假设你在调试bug，幸运的是你能清楚的知道如何纠正这段代码里的逻辑问题。但不幸的是，这段代码在其它项目里的拷贝却成了问题的根源。

　　像JustCode这样新式的重构工具能轻松的让代码片段变成方法，从而减少重复代码，提高程序的可维护性。

原文转自：http://www.aqee.net/developer-resolutions-for-2013/