aoelover的专栏

关联的大数据属于数据库        如果你的应用程序需要处理一份很大的、持续的、关联的数据元素的集合，不要犹豫，将它存入一个关系数据库里。在过去，（RDBMS）关系数据库管理系统曾经昂贵、稀少、复杂且笨重；现在RDBMS已经很容易得到，很可能你正在使用的系统中就已经安装了一两个。有些功能强大的RDBMS，如MySQL和PostgreSQL，已经是开源软件了，于是得到时要花费的资金就不现进问题

结伴编程，感受心流        设想一下，你完全投入了你正在做的事，专注它，奉献它，参与它，可能忘记了时间，可能感受到了欢乐。你这就是在检验心流。整个团队中的程序员们要同时达到并保持心流是很难的，因为有非常多的中断、交互和其它的分散注意力的事情可以轻易打破心流。        如果你已经实践过结伴编程，那么你很可能已经了解对结伴对心流的贡献了。如果还没有的话，我们想用自己的经历来

优先使用领域特定类型而不是基础类型        1999年9月23日，价值3.276亿美元的火星气候探测者号在进入绕火星的轨道时失去了联系，就因为地球上的一个软件错误。这个错误后来被称为“公制单位混淆”。地球上的指挥站的软件使用的是“磅”，而飞行器使用的是“牛顿”，导致指挥站把飞行器的推进器的动力低估了4.5倍。        这是如果使用了更强大的领域特定类型的语言即可防止失败的例子之

防止错误        错误消息是用户和系统其余部分之间最关键的交互，它们在用户和系统的交流接近崩溃时出现。        很容易认为错误是由于用户的不当输入造成的，但是人们是会犯一些可预测、系统的错误的。于是，“调试”用户和系统其余部分就和系统其它组件一样是可能的。        例如，假设你想要用户输入一个在某个允许的范围内的日期。与其让用户输入任何日期，不如提供一种只显示允许的日

专业的程序员        如何才能一位专业的程序员？        专业程序员唯一的最重要的特质就是个人的责任感。专业的程序员对他们的职业、评估、计划、错误和技艺负责；专业的程序员不会把责任推给其他人。       如果你很专业，就会对你的职业负责。你会负责地阅读和学习，负责地与行业和技术同步更新。太多的程序员感觉是他们雇主的工作训练了他们。遗憾的是，这是大错特错。你觉得医生也是这样

统一二进制        我见过几个在构建时重写部分代码来为每个目标环境生成定制的二进制文件的项目。这往往让事情变得比它本应该的要复杂，也引入了团队可能在每次安装时没有一致的版本的风险。至少它造成了多次的构建，每个副本都只有很少的差别，而且各自必须部署到正确的位置。这意味着增加了不必要的动作，也意味着有更多可能犯错的机会。       我曾经工作的一个团队里，每个属性的改变都必须提交做一个

把一切都置于版本控制之下        把项目中的一切都放在版本控制之下。你需要的资源有：免费的工具，比如Subversion，Git，Mercurial和CVS；充足的磁盘空间；便宜又强大的服务器；无处不在的网络；甚至是项目主机服务。等安装了版本控制软件之后，为了将所有资源放入版本库，你所有需要做的就是在一个干净的、包含代码的目录中运行恰当的命令。而且只有两个基本的操作要学习：提交代码修改到

阅读代码        我们程序是古怪的生灵。我们喜欢编写代码，但要阅读代码时，却唯恐避之不及。毕竟，写代码中的乐趣更多，而读代码则很艰难，有时候几乎是不可能的。阅读其它人的代码尤为困难，不只是因为其他人的代码不好，也可能是因为他们所想的解决问题的方法和你的完全不一样。但你想过吗，阅读其他人的代码可以改进你自己的？        下次你阅读代码时，停一小会进行思考。代码是容易阅读还是难以阅

放下鼠标，离开键盘        你已经专注于某个难缠的问题几个小时了，还没有找到解决方法。于是你起身，伸伸腿，或者捶一下自动售卖机，接着在回来的路上答案突然就清晰了明了了。        这个场景听起来熟悉不？有想过为什么会发生吗？奥秘在于当你编码时，大脑的逻辑性部分很活跃，而创造性部分则停止了，在逻辑部分中断之前不会产生任何东西。        这是一个亲身经历的例子：我在清理一些

读懂人性        除了最小的项目开发以外，人们都要与其他人合作。除了最抽象的领域以外，人们都需要其他人写软件支持其目标。人和人一起编写软件，这是人与人的事。不幸的是，给程序员关于如何与他们为之工作、与之工作的人打交道的教导实在是太少了。幸运的是有一整个领域的研究可以提供帮助。        例如，Ludwig Wittgenstein在《哲学研究》（Philosophical Inv

性能调优的道路上遍布脏代码炸弹        通常，系统的性能调优需要你修改代码。当你需要修改代码的时候，每个过于复杂或者高耦合的代码块都是一个脏代码炸弹，随时会让你需要付出的努力变得失控。脏代码对你造成的第一个伤害就会是你的日程安排。如果能顺畅地前进，就很容易预测结束时间；遇到非预期的脏代码会让进行明智的预测变得非常困难。        考虑当你遇到一个执行热点的情况。通常的做法是减少底

掌握（并重构）构建        对编码实践高标准严要求，却对构建脚本极其忽视的团队并不罕见，可能是认为构建脚本不重要，也可能是认为构建脚本太复杂了，需要狂热的发布工程才能完成。无法维护的、有着各种重复和错误的构建脚本会导致问题，正如很差的代码一样。        自律的、技术强大的开发人员把构建放在他们工作的第二位的一个理由是，构建脚本经常与源代码中所用的语言不同。另一个理由是构建脚本算

奇闻异事：测试人员是你的朋友        不管他们自称是“质量保证”（Quality Assurance）还是“质量控制”（Quality Control），许多程序员称他们为“麻烦”。在我的经历中，程序员们经常与测试他们的软件的人有着对立的关系。“他们太挑剔了”、“他们什么都要求完美”是常有的抱怨。听起来很熟悉吧？       不确定为什么，但是我对测试人员有不同的看法，可能是因为我第

学会说“Hello, world”        Paul Lee，用户名leep，更为人所知的名字是Hoppy，他在我们这里是一位有名的编程问题专家。我需要他的帮助，于是我直到他的桌子旁边问，能不能帮我看一些代码。        当然，Hoppy说，坐吧。我小心翼翼不要等到他身后由空的可乐罐组成的金字塔。        什么代码？        这个文件中的这个函数，我说。 

让项目自己说话        你的项目可能已经有一个版本控制工具了，也许它连接到了一个通过自动化测试检查正确性的持续集成服务器。这很好。        你可以在持续集成服务器中包含一些静态代码分析工具进来，收集代码指标。这些指标提供代码某些方面的反馈以及随着时间推进时的进化状态。当使用代码指标时，总有一些红线是你不想逾越的。假设你以20%的测试覆盖率开始，并且不想低于15%。持续集成帮助你

让接口容易正确使用且难以错误使用        件开发中最常见的一项任务便是接口规范了。接口遍布于抽象的最高级（用户接口）、最低层（函数接口）以及中间的层次（类接口、库接口等）。不管你的工作是指定用户如何与系统交互，与开发人员指定API，或者是声明类的私有函数，接口设计都是工作的一个重要部分。如何做得好，你的接口用起来很舒服，而且会激发他人的产出；如果做得不好，你的接口会成为失败和错误之源。

链接器不是魔法程序        很令人沮丧地，许多程序员经常（在写这篇文章之前我刚刚遇到过）对编译型的语言中从源代码到静态的可执行程序的过程的看法是：        1. 编写源代码        2. 编译源代码，生成目标文件        3. 一些魔法发生        4. 运行可执行程序        第3步，当然就是链接了。为什么我说得这么夸张？我做技术支持已

长命的临时解决方案        为什么我们要创建临时解决方案？        典型原因是因为我们有一些紧急的问题要解决。可能是开发团队内部的，某些填补工具链中的沟壑的方法；也可能是外部的，终端用户可见的，例如对某个缺失功能的变通方法。        在大多数的系统和团队中，你都能发现一些在某种程序上与系统不协调的软件，这些是在什么时候就会改变的草稿，不遵守限制其它代码的标准和指导。免

让不可见的更可见        隐蔽性的很多方面都被正确地宣扬为要遵循的软件开发准则，我们有很多隐喻隐蔽性的术语，机制透明和信息隐藏。软件及其开发过程，引用道格拉斯·亚当斯的话，“基本看不见”：        · 源代码没有天生的表现，也没有天生的行为，而且也不用遵守物理定律。当将它载入一个编辑器时，我们就能看到它，但关上编辑器时，它就消失了。想它太多了以后，就像倒下了却没有听到的树，你开

消息传递让并发系统有更好的可扩展性        程序们在他们学习计算机的一开始就被教导：并发，特别是并行（并发的一个特殊子集），是非常困难的，只有少数很优秀的人才能正确处理，而且即使这些很优秀的人也可能会在上面犯错。对于线程、信号量、监视器以及线程安全地并发访问变量的困难，一直受到关注。        的确，这里有很多困难的问题，要解决起来很不容易。但问题的根源是什么呢？共享的存储。几乎

给未来的消息        可能是因为其中的大多数都是聪明人，这些年来我教导过的和一起工作过的程序员们，似乎大多数都认为既然他们曾经研究的问题很难，那么答案对于每个人（可能即便是对于代码编写几个月后的自己）也应该一样难以理解和维护。        我记得和Joe的一件事。他是数据结构课程中的一名学生，找到我给我看了他写的东西。“Betcha猜不出这是做什么的。”他扬扬得意地说。    

只有代码会告诉你真相        程序的终极语义由它的运行代码给出。如果它只有二进制的形式，那将非常难以阅读！然而，如果是你的程序、任何典型的商业软件开发、开源项目或者动态的解释型语言程序，都是有源代码的。看一下源代码，程序的意思就应该清楚明了了。要了解一个程序做了什么，源代码是你最终肯定应该看的。即便是最精确的需求文档也没有说明全部真相：它没有包含程序真正做什么的详细信息，只有需求分析中的

错过多态的机会        多态（Polymorphism）是OO的一条主要的基础思想。这个词源来希腊语，意思是多种（poly）形态（morph）。在编程中，多态是指一个特定的对象类或者方法类的多种形态，但多态并不简单地是变化的实现。细心使用，多态可以创建出细小的本地化执行上下文，让我们无需if-then-else语法的代码块就能工作。要么是一个可以让我们直接做对事情的上下文，要么就是在那个

简单来自删减        “重做......”，我的老板一边对我说一边用手指重重地按着删除键。我看着电脑屏幕，随着我的代码一行又一行地消失于虚无，心里一种再熟悉不过的不祥预感。        我的老板，Stefan，并不是总是直言不讳的人，但他看到不好的代码时，他是清楚的，并且他确切的知道对不好的代码应该做什么。        作为一个程序员学生，我带着充足的精力和热情达到了

经常重新造轮子        “用一些已有的东西就可以了，重新造轮子是很傻的...”        你否曾经听说过这句话或者类似的说法？肯定的！每个开发人员和学生都可能经常听到这样的论调。然而为什么呢？为什么重新造轮子这么不被赞同？因为，通常情况下，已有代码是管用的。它已经经过了一定的质量控制、严格测试，而且成功应用了。此外，投入重新创造的时间和精力的回报不太可能比使用已有的产品和代码库更

带着班图精神编程        通常，我们在不与别人交流的状态下自己编写代码，代码反映了我们对问题的个人理解及解决方法。尽管我们可能是团队的一部分，但仍然会独自行事，很容易就忘记了自己独立编写出来的代码会被其他人执行、使用、扩展或者依赖。软件创建的社会方面很容易被忽视。创建软件是混合进入社会活动的技术活动。我们只需要多抬抬头就能意识到我们不并是在与世隔绝的状态下工作的，我们共同承担了为每个人，

Unix工具是你的朋友        如果我即将被流放到一座孤岛上，只能从IDE和Uinx工具箱中二选一，我会毫不犹豫地选择Unix工具箱。以下这些就是为什么应该精通Unix工具的理由。        首先，IDE以特定语言为目标，而Unix工具对于任何以文本形式表现的东西都能工作。现今的开发环境中，新语言和新表示法每年都如雨后春笋般出现，学习Unix的方式是一种有着重复回报的投资。 

使用正确的数据结构与算法        某个有着很多分办公室的银行抱怨他们给出纳员们买的新电脑都太慢了。这还是电子银行普及、ATM遍布之前。人们经常要去银行，电脑慢就造成了人们在银行里面排队。于是，银行威胁它的供应商要取消合同。        供应商派出了一个性能分析和调优的专家来调查延迟的原因，很快他就发现有一个特定的程序运行时几乎占用了全部的CPU。通过使用分析工具，他仔细检查了该程序

啰唆的的日志会打断你的睡眠当我遇到一个已经开发或者运营了一段时间的系统时，最开始真正的问题往往都是脏日志。你知道我说的是什么。每当正常流程中点击一个链接就会导致系统出现洪水泛滥般地消息。太多的日志可能和没有日志一样毫无作用。如果你的系统像我的一样，当你的工作结束时，其他某人的工作才刚刚开始。当系统开发完成，希望它能长时间地、成功地服务客户，如果你足够幸运的话。你如何知道系统在产品阶段是否出

WET稀释了性能瓶颈DRY原则（Don't Repeat Yourself）的重要性它将系统知识的每一部分都应该有单独表现的观点代码化。也就是说，知识应该包含在单独的实现中。DRY的对立面则是WET（Write Every Time）。如果我们的知识编码于不同的实现中，那代码则是WET的。当你考虑它们于某个性能问题的大量影响时，DRY与WET的性能实质就特别明显了。让我们从考虑 我

当开发与测试精诚合作当测试人员和程序员开始精诚合作时，有些魔法就会发生了。花费在缺陷跟踪系统中将bug转来转去的时间更少了，浪费在弄清楚某个东西到底是bug还是新的特性中的时间更少了，用于开发好的软件来满足客户需求的时间更多了。即便在在编码开始之前，就已经有很多机会来开始合作了。测试人员可以使用他们的相关领域的语言和工具，比如Fit（Framework for Integrated

就像要在要用一生去维护一般编写代码你可以问97个人每个程序员都应该知道什么和做什么，可能会听到97个不同的回答。这可能令人畏惧。所有的忠告都很好，所有的原则都很合理，所有的故事都很动听，但你该从哪开始呢？更重要的是，当你开始之后，如何保持你所学到的每一项最好的编码实践，并让之成为你编程中不可或缺的一部分？我想，答案在于你的思想，更直白地说，在于你的态度。如果你不在乎与你一同工作的开

使用范例来编写小巧的函数我们都希望编写正确的代码，并且有确实的证据来证明代码是正确的，它可以帮助解决考虑函数“大小”的两个问题。不仅是实现一个函数的代码量意义上的，尽管那很有趣，更是我们的代码构建的数学上的功能的大小。例如，在围棋中有一个“叫吃”的状态，这个状态下棋手的子可能被对方吃掉：一颗子如果有两个或者更多多的空余连通（叫做“气”）则不是叫吃状态。计算一颗子有多少气可能很复杂，

为他人编写测试你已经在为自己的部分或者全部代码编写自动化测试了。恭喜你！你已经在编写代码之前编写测试了？更好！这样做已经让你成为先进软件工程实践的先行者了。但你写的是好的测试吗？如何分辨呢？一个简单的办法是问“我在为认证写测试？”如果答案是“为我自己，节省修正bug的力气和时间”，或者“为编译器，为了它们能够执行”，这样你很可能就不是在写最好的测试。你究竟应该为“谁”写测试呢？为了尝试

必须在乎你的代码

两个头脑往往比一个更好        编程需要深思，深思又需要独处。于是就有了程序员的呆板形象。        这种“独狼”的方法要让位于更合作性的方法了，后者我更会说它改进了质量、产出和程序员的工作满意度。这种方法让程序员们彼此之间更加近距离地合作，甚至是同非开发人员——业务和系统分析师、质量保证专业人员以及用户。        这对程序员来说意味着什么呢？作为专业技术的专家

两个错误的结果可以是正确（也会更难修复）        代码从不说谎，但可能自相矛盾，有些矛盾可能会导致“这怎么可能正常工作？”的时刻。        在一次访谈中，阿波罗11号月球模块软件的主设计师，Allan Klumpp，透露说该软件的控制引擎包含一个可能导致着陆器不稳定的bug。但是，另一个bug补偿了第一个，而且软件在两个bug都没有发现和修正的情况下，在阿波罗11号和阿

抵制单件模式的诱惑        单件模式解决了你的很多问题，知道你只需要一个单一的实例，你可以确定这个实例在使用前已经初始化了，它通过一个唯一的全局访问点让你的设计变得简单。有何理由不喜欢这个经典的设计模式呢？        结果是，有很多理由。尽管很诱人，但经验显示大多数单件实际上的坏处比好处要多。不幸的是，这个额外的智慧并没有像它应该的那样广为传播，单件也继续让很多程序员感到充满了诱

单一职责原则        好的设计的一个最基本的原则就是：        把因相同原因变化的东西聚合到一起，把因不同原因变化的东西分离开来。        这个原则就是“单一职责原则”或者SRP。简短地说，即一个子系统、模块、类甚至是一个函数，就应该因多于一个的原则而变化。一个有着处理业务规则、报告和数据库的方法的类是经典的例子：public class Employee {

从说“是”开始        最近，我在一家超市到处找一种叫“毛豆”的东西，我只大概知道那是一种蔬菜。但我不确定我应该是蔬菜区、冷藏区还是罐头区找到它。最后我放弃了，找到一名超市的雇员帮我。她也不知道！        那位雇员可以有很多种回答的方式。她可以让我因为不知道在哪里寻找而觉得很无知，或者告诉我一个大概可能的位置，或者干脆告诉我他们没有。但她却将此作为了一个找到答案并获得一名客户的