- 博客(8)
- 收藏
- 关注
RSS订阅翻译 97. 客户说的不是他们想要的
客户说的不是他们想要的我遇到的每一位客户，都会很快乐地告诉我他们需要什么，通常都十分详尽。但问题是客户总是不能告诉你整个真相，他们通常不撒谎，但他们是以客户的方式描述的，而不是开发者的方式。他们使用自己的术语和上下文，丢失重要的细节，作出你也像他们一样在公司工作了20年的假设。这是由很多客户一开始就不知道他们需要什么的事实促成的。有些可能知道“整体大概”，却几乎不能对细节作出有效的沟通
2014-05-31 15:19:03
1009
翻译 95. 为他人编写测试
为他人编写测试你已经在为自己的部分或者全部代码编写自动化测试了。恭喜你！你已经在编写代码之前编写测试了？更好！这样做已经让你成为先进软件工程实践的先行者了。但你写的是好的测试吗？如何分辨呢？一个简单的办法是问“我在为认证写测试？”如果答案是“为我自己，节省修正bug的力气和时间”，或者“为编译器，为了它们能够执行”，这样你很可能就不是在写最好的测试。你究竟应该为“谁”写测试呢？为了尝试
2014-05-19 14:42:31
578
翻译 94. 使用范例来编写小巧的函数
使用范例来编写小巧的函数我们都希望编写正确的代码，并且有确实的证据来证明代码是正确的，它可以帮助解决考虑函数“大小”的两个问题。不仅是实现一个函数的代码量意义上的，尽管那很有趣，更是我们的代码构建的数学上的功能的大小。例如，在围棋中有一个“叫吃”的状态，这个状态下棋手的子可能被对方吃掉：一颗子如果有两个或者更多多的空余连通（叫做“气”）则不是叫吃状态。计算一颗子有多少气可能很复杂，
2014-05-18 23:00:27
613
翻译 93. 就像要在要用一生去维护一般编写代码
就像要在要用一生去维护一般编写代码你可以问97个人每个程序员都应该知道什么和做什么，可能会听到97个不同的回答。这可能令人畏惧。所有的忠告都很好，所有的原则都很合理，所有的故事都很动听，但你该从哪开始呢？更重要的是，当你开始之后，如何保持你所学到的每一项最好的编码实践，并让之成为你编程中不可或缺的一部分？我想，答案在于你的思想，更直白地说，在于你的态度。如果你不在乎与你一同工作的开
2014-05-11 16:19:05
567
翻译 92. 当开发与测试精诚合作
当开发与测试精诚合作当测试人员和程序员开始精诚合作时，有些魔法就会发生了。花费在缺陷跟踪系统中将bug转来转去的时间更少了，浪费在弄清楚某个东西到底是bug还是新的特性中的时间更少了，用于开发好的软件来满足客户需求的时间更多了。即便在在编码开始之前，就已经有很多机会来开始合作了。测试人员可以使用他们的相关领域的语言和工具，比如Fit（Framework for Integrated
2014-05-10 11:05:47
723
翻译 91. WET稀释了性能瓶颈
WET稀释了性能瓶颈DRY原则（Don't Repeat Yourself）的重要性它将系统知识的每一部分都应该有单独表现的观点代码化。也就是说，知识应该包含在单独的实现中。DRY的对立面则是WET（Write Every Time）。如果我们的知识编码于不同的实现中，那代码则是WET的。当你考虑它们于某个性能问题的大量影响时，DRY与WET的性能实质就特别明显了。让我们从考虑 我
2014-05-03 19:24:34
607
翻译 90. 啰唆的的日志会打断你的睡眠
啰唆的的日志会打断你的睡眠当我遇到一个已经开发或者运营了一段时间的系统时，最开始真正的问题往往都是脏日志。你知道我说的是什么。每当正常流程中点击一个链接就会导致系统出现洪水泛滥般地消息。太多的日志可能和没有日志一样毫无作用。如果你的系统像我的一样，当你的工作结束时，其他某人的工作才刚刚开始。当系统开发完成，希望它能长时间地、成功地服务客户，如果你足够幸运的话。你如何知道系统在产品阶段是否出
2014-05-01 22:47:08
539
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人