[转]高效能程序员的七个习惯

内容转自：http://tchen.me/posts/2014-03-05-highly-effective-programmer.html

 

昨天收到一个读者留言，问做为程序员，有什么学习和工做上的好习惯能够借鉴？想了想，干脆附庸风雅一下，总结个『高效能程序员的七个习惯』吧。Disclaimer：一家之言，可不信，但不可全信。

拥抱unix哲学

每一个程序员入门的第一堂和第二堂课应该是和unix哲学相关的内容，简言之就是：作一件事，作好它。具体点：

• 小便是美。
• 让程序只作好一件事。
• 尽量早地建立原型。
• 可移植性比效率更重要。
• 数据应该保存为文本文件。
• 尽量地榨取软件的所有价值。
• 使用shell脚原本提升效率和可移植性。
• 避免使用可定制性低下的用户界面。
• 全部程序都是数据的过滤器。

再具体一些（TL;DR）：

In [1]: import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

选一个样板，follow之

每一个NBA新秀都有本身的样板，咱们也总习惯称某足球新星为『小罗』，『小小罗』。样板为你提供了可模仿可追赶的对象，同时也让你审视本身究竟想成为何样的程序员。个人样板是Greg Pass和Werner Vogels，虽然我这辈子可能也达不到他们的高度，可这并不妨碍向着我心目中的明星一步步靠近。

写代码，而不是调代码

写软件最糟糕的体验恐怕是边写边调，写一点，运行一下，再写一点。是不少程序员都会这么干。缘由有二：1. 不熟悉相关的代码（类库），须要边写边运行保证代码的正确。2. 现代编程语言的REPL(Read-Evaluate-Print-Loop，就是语言的shell)能力滋长了这一行为。

写系统软件的人不多这么作。他们手头糟糕的工具让边写边调的行为成为效率杀手 —— 若是稍稍改动，编译就要花去几分钟，甚至更长的时间，你还会这么干么？因此他们每每是写完一个模块，再编译调试。（由此看来，高效的工具备时候是把双刃剑啊）

我以为写代码就跟写文章同样，构思好，有了大纲，就应该行云流水同样写下去，一鼓作气，而后回过头来再调整语句，修改错别字。若是写完一段，就要回溯检查以前写的内容，效率很低，思惟也会被打散。

靠边写边调作出来的代码还每每质量不高。虽然局部通过了雕琢，但总体上不那么协调，看着老是别扭。这就比如雕刻，拿着一块石头，你先是精修了鼻子，而后再一点一点刻画面部。等修到耳朵的时候，鼻子可能过大或太小，即使再精美，它也得不到赞扬。

聪明地调试

软件总会出问题。遇到问题，不少程序员就会用IDE在各类可能的地方加断点调试，若是没有IDE，那么各类print/log手段一齐抛出，有枣没枣打一杆子再说。

优秀的程序员会在撰写代码的时候就考虑到调试问题，在系统关键的节点上注入各类等级的调试信息，而后在须要的时候打开相应的调试级别，顺藤摸瓜，避免了不靠谱的臆测。这是调试之『道』。

不少问题打开调试开关后就原形毕露，但有时候靠调试信息找到了初步缘由，进一步定位问题还须要具体的工具，也就是调试之『术』，如上文所述之断点调试。有些时候，遇到靠相似gdb（如python的pdb）的工具没法解决的问题时（如性能问题），你还须要更多的调试工具作runtime profiling，如systemtap。

使用标记语言来写文档，而非word/power point

不要使用只能使用特定软件才能打开的工具写文档，如word/page或者power point/keynote。要使用『放之四海而皆可用』的工具。

java的市场口号是：『一次编写，处处运行』，对于文档，你也须要这样的工具。Markdown(md) / Restructured Text(rst)（以及任何编辑语言，甚至是jade）就是这样的工具。经过使用一种特定的文本格式，你的文档能够被编译成几乎任意格式（html，rtf，latex，pdf，epub，...），真正达到了『一次编写，处处运行』。最重要的是，因为逻辑层（文章自己）和表现层（各类格式，字体，行距等）分离，一样的文档，换个模板，就有彻底不同的形象。

除非必须，我如今全部的文档都是md或者rst格式。

一切皆项目

程序员的全部产出应该项目制。软件自没必要说，文档和各类碎片思想也要根据相关性组织成项目。举一些我本身的例子：

• 个人博客是一个名叫jobs的github项目
• 个人微信文章所有放在craftsman这个项目中
• 我学习某种知识的过程（好比说golang）会放在一个或若干个项目中
• 我工做上每一个项目的各类产出（包括会议纪要）会按照项目对应生成git repo

项目制的好处是具有可回溯性。每一个项目我能够用git来管理，这样，几乎在任何一台设备上我均可以看到我以前的工做。想一想你三年前写的某个文档，你还能找到它么？你还能找回你的修改历史么？

项目制的另外一大好处是能够在其之上使能工具。好比说你看到的这些微信文章，我随时能够

make publish YEAR=2014

来生成包含了2014年我所写文章的pdf。

心态开放，敢于尝试

在程序员社区里，语言之争，系统之争，软件思想之争几乎是常态。python vs ruby，go vs java vs erlang vs rust，scala vs cljure，OOP vs FP，iOS vs Android。其实无论黑猫白猫，抓到老鼠的就是好猫，facebook还用php呢。程序员应该用开放的心态去包容新的技术，新的思想，敢于尝试，而不是当即否认。这个世界最悲哀的是，手里有把锤子，看什么都是钉子（或者说，眼里就只能看见钉子）。

我接触mac时间不过三年。可这三年时间，我从对mac不屑，到深深热爱，最终成为mac的一个重度用户。不少东西用过才知道，不尝试不接触我可能永远活在本身下意识构筑的无形之墙的另外一边。

最近的两年里我学习了erlang，golang，scala，还看了一点点clojure和rust。目前我热衷于golang开发，但并不妨碍我继续拥抱python和nodejs。每一个程序员要在不一样的层级上有一门主力语言，好比说我：

• 系统级（realtime）：C （可能之后会是rust）
• 系统应用级（realtime）：erlang（养成中）
• 系统应用级（非realtime）：golang（养成中）
• 应用级：python
• Web后端：python，nodejs，golang
• Web前端：javascript
• 设备端：Android Java（暂无计划）

这个列表你没必要参考，我只是想用此来讲明心态越开放，你看到的世界就越大。

---

若是你对本文感兴趣，欢迎订阅公众号『程序人生』（搜索微信号 programmer_life）。天天一篇原汁原味的文章，早8点与您相会。

若是你还意犹未尽，戳下面的连接（来自智库百科）回顾一下 高效能人士的七个习惯吧。