- 博客(97)
- 收藏
- 关注
RSS订阅翻译 97. 客户说的不是他们想要的
客户说的不是他们想要的我遇到的每一位客户，都会很快乐地告诉我他们需要什么，通常都十分详尽。但问题是客户总是不能告诉你整个真相，他们通常不撒谎，但他们是以客户的方式描述的，而不是开发者的方式。他们使用自己的术语和上下文，丢失重要的细节，作出你也像他们一样在公司工作了20年的假设。这是由很多客户一开始就不知道他们需要什么的事实促成的。有些可能知道“整体大概”，却几乎不能对细节作出有效的沟通
2014-05-31 15:19:03
972
翻译 95. 为他人编写测试
为他人编写测试你已经在为自己的部分或者全部代码编写自动化测试了。恭喜你！你已经在编写代码之前编写测试了？更好！这样做已经让你成为先进软件工程实践的先行者了。但你写的是好的测试吗？如何分辨呢？一个简单的办法是问“我在为认证写测试？”如果答案是“为我自己，节省修正bug的力气和时间”，或者“为编译器，为了它们能够执行”，这样你很可能就不是在写最好的测试。你究竟应该为“谁”写测试呢？为了尝试
2014-05-19 14:42:31
553
翻译 94. 使用范例来编写小巧的函数
使用范例来编写小巧的函数我们都希望编写正确的代码，并且有确实的证据来证明代码是正确的，它可以帮助解决考虑函数“大小”的两个问题。不仅是实现一个函数的代码量意义上的，尽管那很有趣，更是我们的代码构建的数学上的功能的大小。例如，在围棋中有一个“叫吃”的状态，这个状态下棋手的子可能被对方吃掉：一颗子如果有两个或者更多多的空余连通（叫做“气”）则不是叫吃状态。计算一颗子有多少气可能很复杂，
2014-05-18 23:00:27
598
翻译 93. 就像要在要用一生去维护一般编写代码
就像要在要用一生去维护一般编写代码你可以问97个人每个程序员都应该知道什么和做什么，可能会听到97个不同的回答。这可能令人畏惧。所有的忠告都很好，所有的原则都很合理，所有的故事都很动听，但你该从哪开始呢？更重要的是，当你开始之后，如何保持你所学到的每一项最好的编码实践，并让之成为你编程中不可或缺的一部分？我想，答案在于你的思想，更直白地说，在于你的态度。如果你不在乎与你一同工作的开
2014-05-11 16:19:05
558
翻译 92. 当开发与测试精诚合作
当开发与测试精诚合作当测试人员和程序员开始精诚合作时，有些魔法就会发生了。花费在缺陷跟踪系统中将bug转来转去的时间更少了，浪费在弄清楚某个东西到底是bug还是新的特性中的时间更少了，用于开发好的软件来满足客户需求的时间更多了。即便在在编码开始之前，就已经有很多机会来开始合作了。测试人员可以使用他们的相关领域的语言和工具，比如Fit（Framework for Integrated
2014-05-10 11:05:47
689
翻译 91. WET稀释了性能瓶颈
WET稀释了性能瓶颈DRY原则（Don't Repeat Yourself）的重要性它将系统知识的每一部分都应该有单独表现的观点代码化。也就是说，知识应该包含在单独的实现中。DRY的对立面则是WET（Write Every Time）。如果我们的知识编码于不同的实现中，那代码则是WET的。当你考虑它们于某个性能问题的大量影响时，DRY与WET的性能实质就特别明显了。让我们从考虑 我
2014-05-03 19:24:34
585
翻译 90. 啰唆的的日志会打断你的睡眠
啰唆的的日志会打断你的睡眠当我遇到一个已经开发或者运营了一段时间的系统时，最开始真正的问题往往都是脏日志。你知道我说的是什么。每当正常流程中点击一个链接就会导致系统出现洪水泛滥般地消息。太多的日志可能和没有日志一样毫无作用。如果你的系统像我的一样，当你的工作结束时，其他某人的工作才刚刚开始。当系统开发完成，希望它能长时间地、成功地服务客户，如果你足够幸运的话。你如何知道系统在产品阶段是否出
2014-05-01 22:47:08
524
翻译 89. 使用正确的数据结构与算法
使用正确的数据结构与算法 某个有着很多分办公室的银行抱怨他们给出纳员们买的新电脑都太慢了。这还是电子银行普及、ATM遍布之前。人们经常要去银行，电脑慢就造成了人们在银行里面排队。于是，银行威胁它的供应商要取消合同。 供应商派出了一个性能分析和调优的专家来调查延迟的原因，很快他就发现有一个特定的程序运行时几乎占用了全部的CPU。通过使用分析工具，他仔细检查了该程序
2014-02-27 15:22:43
785
翻译 88. Unix工具是你的朋友
Unix工具是你的朋友 如果我即将被流放到一座孤岛上，只能从IDE和Uinx工具箱中二选一，我会毫不犹豫地选择Unix工具箱。以下这些就是为什么应该精通Unix工具的理由。 首先，IDE以特定语言为目标，而Unix工具对于任何以文本形式表现的东西都能工作。现今的开发环境中，新语言和新表示法每年都如雨后春笋般出现，学习Unix的方式是一种有着重复回报的投资。
2014-02-26 16:51:01
646
翻译 87. 带着班图精神编程
带着班图精神编程 通常，我们在不与别人交流的状态下自己编写代码，代码反映了我们对问题的个人理解及解决方法。尽管我们可能是团队的一部分，但仍然会独自行事，很容易就忘记了自己独立编写出来的代码会被其他人执行、使用、扩展或者依赖。软件创建的社会方面很容易被忽视。创建软件是混合进入社会活动的技术活动。我们只需要多抬抬头就能意识到我们不并是在与世隔绝的状态下工作的，我们共同承担了为每个人，
2014-02-13 12:15:40
795
翻译 86. 两个错误的结果可以是正确（也会更难修复）
两个错误的结果可以是正确（也会更难修复） 代码从不说谎，但可能自相矛盾，有些矛盾可能会导致“这怎么可能正常工作？”的时刻。 在一次访谈中，阿波罗11号月球模块软件的主设计师，Allan Klumpp，透露说该软件的控制引擎包含一个可能导致着陆器不稳定的bug。但是，另一个bug补偿了第一个，而且软件在两个bug都没有发现和修正的情况下，在阿波罗11号和阿
2014-02-06 23:21:30
781
翻译 85. 两个头脑往往比一个更好
两个头脑往往比一个更好 编程需要深思，深思又需要独处。于是就有了程序员的呆板形象。 这种“独狼”的方法要让位于更合作性的方法了，后者我更会说它改进了质量、产出和程序员的工作满意度。这种方法让程序员们彼此之间更加近距离地合作，甚至是同非开发人员——业务和系统分析师、质量保证专业人员以及用户。 这对程序员来说意味着什么呢？作为专业技术的专家
2014-02-06 23:18:14
672
翻译 84. 在状态中思考
在状态中思考现实世界中的人们对和状态有一种奇怪的关系。今天早上我在本地一家商店停下来准备将咖啡因转换为代码。由于我喜欢的方式是喝拿铁，然而我又找不到牛奶了，于是向店员询问。“抱歉，我们超级没有牛奶了。”对于程序员来说，这是个奇怪的表述。你要么就是有牛奶，要么就是没有。没有牛奶是没有尺度衡量的。也许她是想告诉我他们可能几个星期都没有牛奶了，但结果是一样的：今天只能喝浓咖啡了。
2014-01-29 23:35:34
629
翻译 83. 测试是软件开发的工程严谨度
测试是软件开发的工程严谨度 当软件开发人员尝试向他们的家人、配偶或者其他不懂技术的人解释自己做什么时，喜欢用一些令人痛苦的比喻。我们经常尝试用桥梁建造或者其它的“硬”工程学科。然而，如果我们过度使用这些比喻，它们很快就就一沓糊涂了。结果是软件开发在很多很重要的方面与其它的“硬”工程学科并不相同。 与“硬”工程相比，软件开发对于桥梁建造者来说，就像是建一座桥，然后
2014-01-28 15:35:03
3564
翻译 82. 在睡觉时（或者周末）测试
在睡觉时（或者周末）测试 放松。我不是指海外那些研发中心，在周末加班或者是夜晚换班，而是想让你注意到我们有多少可以使用的计算能力。特别是，有多少我们可以控制来让自己的程序员生活更容易一些。你是不是一直感觉到在工作时间难以得到足够多的计算能力？如果是的话，你的测试服务器在工作时间之外在干什么？很可能的情况是，测试服务器在夜里和周末都是空闲的。你可以利用这一点。 你
2014-01-19 15:07:17
518
翻译 81. 精密地、具体地测试
精密地、具体地测试 测试代码单元所需的、基本的行为而不是测试特定实现的附加的行为是很重要的，但这不应该将其错误地用来作为含糊不清的测试的借口。测试既需要准确，又需要精密。 排序是一个测试很有说明性的例子。实现一个排序算法不是程序员的日常工作中所必需的，但这是一个很为人熟知的概念，而且大多数人知道结果是什么。然而这种漫不经心的熟悉，会让人更难看到若干假定。
2014-01-14 19:32:27
608
翻译 80. 测试所需行为，而不是附带行为
测试所需行为，而不是附带行为 通常在测试过程中易犯的一个错误是，假定实现方法与你想要测试的完全相同。乍一看这似乎更是美德而不是错误。然而，换种说法问题就更明显了：测试中一个常见的错误是将测试硬绑定到特定的实现方法，而这些实现方法只不过是附带的、与所需的功能无关。 当测试绑定到特定的实现时，对实现做出能兼容所需行为的修改可能导致测试不通过，产生误报。程序员一般是要
2014-01-11 10:55:18
535
翻译 79. 利用代码分析工具
利用代码分析工具 自从走上编程之路，测试的价值就深深地灌入软件开发人员的脑海中了。近年来，单元测试、测试驱动开发、敏捷方法的崛起见证了对在所有开发阶段进行测试的兴趣的激增。然而，测试只是改进代码质量的诸多方法中的一种。 穿越时间的迷雾，追溯到C语言还是新事物的年代，CPU时间和任何种类的存储都很昂贵。考虑到此，第一代的C语言编译器通过移除一些语法分析进行了代码的
2014-01-06 20:20:00
553
翻译 78. 后退一步，自动化，自动化，再自动化
后退一步，自动化，自动化，再自动化 我曾和一些程序员一起工作，他们被要求生成某个模块中代码的行数，于是将文件复制到一个文本处理器中并使用它的“行数统计”的功能。接下来的一周他们也是这样干的。再后面的一周还是这样干的。这很不好。 我曾经工作的项目有一个冗长的部署过程，包括代码签名以及将结果移动到服务器，需要点很多次的鼠标。有人将其自动化了，那个脚本在最终的测试中运
2014-01-05 19:26:26
525
翻译 77. 从说“是”开始
从说“是”开始 最近，我在一家超市到处找一种叫“毛豆”的东西，我只大概知道那是一种蔬菜。但我不确定我应该是蔬菜区、冷藏区还是罐头区找到它。最后我放弃了，找到一名超市的雇员帮我。她也不知道！ 那位雇员可以有很多种回答的方式。她可以让我因为不知道在哪里寻找而觉得很无知，或者告诉我一个大概可能的位置，或者干脆告诉我他们没有。但她却将此作为了一个找到答案并获得一名客户的
2014-01-02 22:51:02
506
翻译 76. 单一职责原则
单一职责原则 好的设计的一个最基本的原则就是： 把因相同原因变化的东西聚合到一起，把因不同原因变化的东西分离开来。 这个原则就是“单一职责原则”或者SRP。简短地说，即一个子系统、模块、类甚至是一个函数，就应该因多于一个的原则而变化。一个有着处理业务规则、报告和数据库的方法的类是经典的例子：public class Employee {
2014-01-01 17:17:32
520
翻译 75. 简单来自删减
简单来自删减 “重做......”，我的老板一边对我说一边用手指重重地按着删除键。我看着电脑屏幕，随着我的代码一行又一行地消失于虚无，心里一种再熟悉不过的不祥预感。 我的老板，Stefan，并不是总是直言不讳的人，但他看到不好的代码时，他是清楚的，并且他确切的知道对不好的代码应该做什么。 作为一个程序员学生，我带着充足的精力和热情达到了
2013-12-10 23:25:59
515
翻译 74. 性能调优的道路上遍布脏代码炸弹
性能调优的道路上遍布脏代码炸弹 通常，系统的性能调优需要你修改代码。当你需要修改代码的时候，每个过于复杂或者高耦合的代码块都是一个脏代码炸弹，随时会让你需要付出的努力变得失控。脏代码对你造成的第一个伤害就会是你的日程安排。如果能顺畅地前进，就很容易预测结束时间；遇到非预期的脏代码会让进行明智的预测变得非常困难。 考虑当你遇到一个执行热点的情况。通常的做法是减少底
2013-12-09 23:20:54
903
翻译 73. 抵制单件模式的诱惑
抵制单件模式的诱惑 单件模式解决了你的很多问题，知道你只需要一个单一的实例，你可以确定这个实例在使用前已经初始化了，它通过一个唯一的全局访问点让你的设计变得简单。有何理由不喜欢这个经典的设计模式呢？ 结果是，有很多理由。尽管很诱人，但经验显示大多数单件实际上的坏处比好处要多。不幸的是，这个额外的智慧并没有像它应该的那样广为传播，单件也继续让很多程序员感到充满了诱
2013-12-05 23:52:36
1338
翻译 72. 经常重新造轮子
经常重新造轮子 “用一些已有的东西就可以了，重新造轮子是很傻的...” 你否曾经听说过这句话或者类似的说法？肯定的！每个开发人员和学生都可能经常听到这样的论调。然而为什么呢？为什么重新造轮子这么不被赞同？因为，通常情况下，已有代码是管用的。它已经经过了一定的质量控制、严格测试，而且成功应用了。此外，投入重新创造的时间和精力的回报不太可能比使用已有的产品和代码库更
2013-12-03 18:13:04
661
翻译 71. 读懂人性
读懂人性 除了最小的项目开发以外，人们都要与其他人合作。除了最抽象的领域以外，人们都需要其他人写软件支持其目标。人和人一起编写软件，这是人与人的事。不幸的是，给程序员关于如何与他们为之工作、与之工作的人打交道的教导实在是太少了。幸运的是有一整个领域的研究可以提供帮助。 例如，Ludwig Wittgenstein在《哲学研究》（Philosophical Inv
2013-12-02 23:17:27
602
翻译 70. 阅读代码
阅读代码 我们程序是古怪的生灵。我们喜欢编写代码，但要阅读代码时，却唯恐避之不及。毕竟，写代码中的乐趣更多，而读代码则很艰难，有时候几乎是不可能的。阅读其它人的代码尤为困难，不只是因为其他人的代码不好，也可能是因为他们所想的解决问题的方法和你的完全不一样。但你想过吗，阅读其他人的代码可以改进你自己的？ 下次你阅读代码时，停一小会进行思考。代码是容易阅读还是难以阅
2013-12-01 12:12:50
482
翻译 69. 放下鼠标，离开键盘
放下鼠标，离开键盘 你已经专注于某个难缠的问题几个小时了，还没有找到解决方法。于是你起身，伸伸腿，或者捶一下自动售卖机，接着在回来的路上答案突然就清晰了明了了。 这个场景听起来熟悉不？有想过为什么会发生吗？奥秘在于当你编码时，大脑的逻辑性部分很活跃，而创造性部分则停止了，在逻辑部分中断之前不会产生任何东西。 这是一个亲身经历的例子：我在清理一些
2013-11-30 23:56:00
591
翻译 68. 把一切都置于版本控制之下
把一切都置于版本控制之下 把项目中的一切都放在版本控制之下。你需要的资源有：免费的工具，比如Subversion，Git，Mercurial和CVS；充足的磁盘空间；便宜又强大的服务器；无处不在的网络；甚至是项目主机服务。等安装了版本控制软件之后，为了将所有资源放入版本库，你所有需要做的就是在一个干净的、包含代码的目录中运行恰当的命令。而且只有两个基本的操作要学习：提交代码修改到
2013-11-29 20:16:54
597
翻译 67. 专业的程序员
专业的程序员 如何才能一位专业的程序员？ 专业程序员唯一的最重要的特质就是个人的责任感。专业的程序员对他们的职业、评估、计划、错误和技艺负责；专业的程序员不会把责任推给其他人。 如果你很专业，就会对你的职业负责。你会负责地阅读和学习，负责地与行业和技术同步更新。太多的程序员感觉是他们雇主的工作训练了他们。遗憾的是，这是大错特错。你觉得医生也是这样
2013-11-28 23:21:38
498
翻译 66. 防止错误
防止错误 错误消息是用户和系统其余部分之间最关键的交互，它们在用户和系统的交流接近崩溃时出现。 很容易认为错误是由于用户的不当输入造成的，但是人们是会犯一些可预测、系统的错误的。于是，“调试”用户和系统其余部分就和系统其它组件一样是可能的。 例如，假设你想要用户输入一个在某个允许的范围内的日期。与其让用户输入任何日期，不如提供一种只显示允许的日
2013-11-26 23:38:06
483
翻译 65. 优先使用领域特定类型而不是基础类型
优先使用领域特定类型而不是基础类型 1999年9月23日，价值3.276亿美元的火星气候探测者号在进入绕火星的轨道时失去了联系，就因为地球上的一个软件错误。这个错误后来被称为“公制单位混淆”。地球上的指挥站的软件使用的是“磅”，而飞行器使用的是“牛顿”，导致指挥站把飞行器的推进器的动力低估了4.5倍。 这是如果使用了更强大的领域特定类型的语言即可防止失败的例子之
2013-11-25 18:47:30
535
翻译 64. 结伴编程，感受心流
结伴编程，感受心流 设想一下，你完全投入了你正在做的事，专注它，奉献它，参与它，可能忘记了时间，可能感受到了欢乐。你这就是在检验心流。整个团队中的程序员们要同时达到并保持心流是很难的，因为有非常多的中断、交互和其它的分散注意力的事情可以轻易打破心流。 如果你已经实践过结伴编程，那么你很可能已经了解对结伴对心流的贡献了。如果还没有的话，我们想用自己的经历来
2013-11-24 20:17:39
1760
翻译 63. 掌握（并重构）构建
掌握（并重构）构建 对编码实践高标准严要求，却对构建脚本极其忽视的团队并不罕见，可能是认为构建脚本不重要，也可能是认为构建脚本太复杂了，需要狂热的发布工程才能完成。无法维护的、有着各种重复和错误的构建脚本会导致问题，正如很差的代码一样。 自律的、技术强大的开发人员把构建放在他们工作的第二位的一个理由是，构建脚本经常与源代码中所用的语言不同。另一个理由是构建脚本算
2013-11-20 18:38:41
673
翻译 62. 只有代码会告诉你真相
只有代码会告诉你真相 程序的终极语义由它的运行代码给出。如果它只有二进制的形式，那将非常难以阅读！然而，如果是你的程序、任何典型的商业软件开发、开源项目或者动态的解释型语言程序，都是有源代码的。看一下源代码，程序的意思就应该清楚明了了。要了解一个程序做了什么，源代码是你最终肯定应该看的。即便是最精确的需求文档也没有说明全部真相：它没有包含程序真正做什么的详细信息，只有需求分析中的
2013-11-16 18:23:53
820
翻译 61. 统一二进制
统一二进制 我见过几个在构建时重写部分代码来为每个目标环境生成定制的二进制文件的项目。这往往让事情变得比它本应该的要复杂，也引入了团队可能在每次安装时没有一致的版本的风险。至少它造成了多次的构建，每个副本都只有很少的差别，而且各自必须部署到正确的位置。这意味着增加了不必要的动作，也意味着有更多可能犯错的机会。 我曾经工作的一个团队里，每个属性的改变都必须提交做一个
2013-11-14 22:56:32
676
翻译 60. 奇闻异事：测试人员是你的朋友
奇闻异事：测试人员是你的朋友 不管他们自称是“质量保证”（Quality Assurance）还是“质量控制”（Quality Control），许多程序员称他们为“麻烦”。在我的经历中，程序员们经常与测试他们的软件的人有着对立的关系。“他们太挑剔了”、“他们什么都要求完美”是常有的抱怨。听起来很熟悉吧？ 不确定为什么，但是我对测试人员有不同的看法，可能是因为我第
2013-11-06 18:40:13
548
翻译 59. 错过多态的机会
错过多态的机会 多态（Polymorphism）是OO的一条主要的基础思想。这个词源来希腊语，意思是多种（poly）形态（morph）。在编程中，多态是指一个特定的对象类或者方法类的多种形态，但多态并不简单地是变化的实现。细心使用，多态可以创建出细小的本地化执行上下文，让我们无需if-then-else语法的代码块就能工作。要么是一个可以让我们直接做对事情的上下文，要么就是在那个
2013-11-05 18:37:58
480
翻译 58. 给未来的消息
给未来的消息 可能是因为其中的大多数都是聪明人，这些年来我教导过的和一起工作过的程序员们，似乎大多数都认为既然他们曾经研究的问题很难，那么答案对于每个人（可能即便是对于代码编写几个月后的自己）也应该一样难以理解和维护。 我记得和Joe的一件事。他是数据结构课程中的一名学生，找到我给我看了他写的东西。“Betcha猜不出这是做什么的。”他扬扬得意地说。
2013-11-02 13:59:23
557
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人