我最近看了一本叫做《the 97 Things a Programmer Should Know》的书。书是一本好书。不过，下面我将我认为最值得我们了解的 20 件事情列举给大家：
1 . 应用函数式编程原则
引用透明性是一个非常可取的特性。这意味着，不论何时调用它，对于同一组参数它永远给出同样的结果，这使它跟那些与其他系统相互交织的东西比起来更易于使用。
2 . 从用户的角度看问题
你不是用户。不要把你的想法强加到用户头上，每个人的想法都不尽相同。花一个小时去观察用户的行为比你花上一天的时间去猜测他们想要什么要有用得多。
3 . 心口不一的客户。
在你决定客户需求之前，最好先和他们多讨论几次，重新确认问题。有时候，客户前后谈论的话题以及不同客户群体之间的想法是会有出入的。如果你想要成功，那么必须得在软件开发之前先好好解决差异问题。
在交流时不妨使用一些直观的辅助工具，例如白板、可视化模型等，有助于客户的理解和信息保存。
4 . 以 Why 开始
不要客户说什么就是什么，多问几个 Why。只有弄清楚需求背后的原因，才能发现新的可能。很多时候，我们可以通过对现有产品的改动来完成需求，大大减少工作量。
有时候，客户的想法与你对产品的看法可能达不成一致。那么反过来问自己“Why？”。这能让你更加明确自己的第一感觉是否对头。如果还是裁决不了，那么就需要其他主要决策者的参与。
5 . 努力并不一定都有回报
不要工作得太辛苦。减少工作量，增加工作效率，才能完成更多的工作。我可不是在忽悠你。做项目时，如果想减少工作量，那么势必得找到实现目标的高效途径。在提高了工作效率的同时还有助于积累经验。以后碰到这样的问题不就是三下五除二的事了。
6 . 大量刻意的训练
我们还可以训练自己从而提高执行任务的能力。这是一种技巧和技术，也意味着重复——意味着带着某种目的去执行任务。不断地重复 and 重复，一遍又一遍，直到你达到所需的能力级别。
译者注：我曾经学 asp 的时候重复写了几十遍数据库操作的代码，都会背了：）
7 . 做点所谓的“重复工作”
使用现有的代码与一步步设计自己的软件——测试、修复、改进——是完全不同的。这些旁人看来所谓的“重复工作”有助于你更深刻地熟悉并理解现有的各个组件是如何运作的。
大多数开发人员可能从来没有创建过核心的软件库，因此对它们的工作原理也不甚了解。其结果就是，一旦碰到这些种类的软件出现问题就会束手无策。了解表面永远是不够的，只有将里面隐含的工作原理挖出来，才能让你真正地在这一行业，独步武林。
8 . 不断学习
阅读。（译者注：订阅《快乐码农》程序员期刊）
参与邮件讨论。
获取并编写代码。
找一个导师。
了解你正在使用的框架和库。
犯了错误，需要修复 bug 或遇到问题时，弄清楚原因。
教人也是学习的一种好方法，可以教学相长。
参于用户组或本地会议。
加入或启动研究小组。
听讲座或在线观看会谈。
学习一门新的编程语言。
梳理出新的，可用于技术堆栈的想法和点子。
9 . 知道如何使用命令行工具。
由 grep 和 SED 提供的搜索和替换能力往往比 IDE 的功能更强大。
如，查找相同名称的类：
find . -name ‘*.rb’ see ’s/.*\///‘ sort uniq -c grep -v “^ *1” sort -r
10 . Unix 工具会是你的好伙伴。
Unix 工具是很简单的扩展工具。只需要谨记以下一些简单的规则即可：
程序只需要执行单一任务
读取标准输入文本行数据
显示结果为标准输出
影响工具的操作参数使用的也是命令行。
11 . 自动化，自动化，还是自动化。
掌握 shell 语言，如 bash 和 PowerShell，构建自动化系统是不可能一蹴而就的。如果需要网站交互，可以使用如 iMacros 或 Selenium 等工具。
一开始你没必要去学习所有的 bash 命令。当你需要的时候再去学也来得及。如果碰到你认为可以自动化的任务，那么尽可能地学习并使用工具来达到自动化的目的。自动化任务越早开始越好。
12 . 版本控制
给软件版本标记一个象征性的名称，以便于将来可以轻松找到所需的确切版本。也可以创建并行开发的分支：对于正在积极支持的发布版本，大多数项目有一个活跃的开发分支和一个或多个维护分支就行了。
13 . 放下鼠标，离开键盘。
碰到实在解决不了的问题时，不妨放下鼠标，离开键盘——可以听听音乐也可以出去散散步，休息会儿——让你的大脑也休息会儿。也许过一会儿你再看这个问题的时候，答案呼之欲出了呢。
14 . 错失采用多态的机会。
多态允许我们创建小型的本地化执行上下文，而不需要 if-else 模块。它可以让我们写出的代码更少更易于理解。
15 . 特定领域类型胜过原始类型
领域类型能使得代码既易于理解，又容易测试。
16 . 为必需行为测试，而不是偶发行为。
测试的一个常见缺点就是与实现细节焊死在一起，而这些细节都是偶然的，跟所要求的功能关系不大。
17 . 测试要准确、具体。
18 . API 设计的黄金法则。
只为你开发的 API 编写测试是不够的，你还需要为使用 API 的代码编写单元测试。
19 . 编写测试程序
一个优秀的测试程序可以当作开发文档来使用，因为它们已经描述了代码是如何工作的。对于每一个场景，测试程序必须做到：
1、将程序的上下文、运行起点或者必须满足的前提条件描述清楚。
2、写清楚程序是如何被调用的。
3、将程序运行的期望结果描述清楚。
当然不同的情况下这 3 个规则也会略有不同。其他程序员只要看了测试程序就可以判断软件会有哪些不同的行为，因此，每一个测试程序应该将程序的因果关系描述清楚。
20 . 采用单个二进制文件的发布规则
建立单个二进制文件可以确保发布流程中的每一个环节顺利地进行。把握每一个运行环境的详细信息，这意味着将这些信息记录到一个文件中，同时记录环境 信息的文件也需要版本控制。如果环境配置有变化，但是你又没有控制好版本的话，那么我们就很难知道系统环境哪里发生了变化。同时，这些环境配置信息必须和 代码分离，因为代码和配置的变化频率是不同的，当然变化的原因也是不一样的。