牧心

云中的软件应用生命周期

郑柯 — Sun, 22 Nov 2009 14:40:00 +0800

Geva Perry是Heroku 、Twilio 、ScaleDB 、Sauce Labs 、GigaSpaces 、NEC等多家公司的咨询顾问，他的博客“Thinking Out Cloud” 着重谈论与云计算相关的问题。最近的一篇博客名为“云中的应用生命周期” ，Geva Perry在其中讲述了他对于云计算时代开发、部署、运维软件应用的思考。
在文章一开篇，Geva就提出：云计算正在对软件应用的生命周期产生深远的影响。

......从原型化、到开发、测试与QA、持续集成，直到按阶段部署、上线后的工作（包括监控和管理）；所有这些都可以在云中完成。
接下来，Geva按照应用生命周期的各个阶段介绍了相关服务及其提供商：开发阶段
Geva指出：几乎开发阶段的所有领域都有云服务支持了。以SaaS形式提供代码库、版本控制和缺陷跟踪服务的有：GitHub 、Beanstalk (Subversion-as-a-service)。IDE方面：有Mozilla Lab的Bespin 项目和HerokuGard

克服在公共会议上做演讲的障碍

郑柯 — Sun, 18 Oct 2009 16:37:00 +0800

在公共会议做演讲，需要克服两大障碍：如何从会议主办方获得许可、如何在会议上做好演讲。对于第一个障碍，Jim Holmes的博客文章“编写优秀的演讲摘要”给出了几点建议：让你的演讲内容与活动目标相符合避免过于宽泛的演讲标题非常重要，真的说明听众能从你的演讲中得到哪些收获给出讨论的实际例子展示该演讲以前获得的反馈编写简洁的摘要编写内容紧凑的摘要一审再审，让人复审第二个障碍，可以参考Kathy Sierra（她是Head First系列书籍的作者之一）的博客文章：如何在技术会议上演讲坚决不要等待邀请！坚决不要指望别人提出建议议题邀请！知道会议的主题选择好的标题从听众的角度思考不要害羞，不要充斥市场宣传之词真正的工作实践远胜过抽象的思考回答该问题：我的演讲如何才能让听众解决实际问题？花时间研究会议手册，阅读每个摘要提供引人注目的个人介绍以前的演讲经验会有所帮助实际参加会议提交多个议题不要放弃，不管怎

测试方法命名基本规则和state-based testing

郑柯 — Sat, 19 Sep 2009 00:49:00 +0800

在The Art of Unit Testing With Examples in .NET的第二章“A first unit test”中，提出了一些unit test应该注意的初步细节，比如测试方法命名的基本规则：待测试对象：Project , 例如：项目名为Logan 测试代码中的对应对象：创建项目名称为[ProjectUnderTest].Tests；上例对应项目名为：Logan.Tests 待测试对象：Class，例如：类名为LogAnalyzer 测试代码中的对应对象：对于每个class，至少创建一个对应class，命名为[ClassName]Tests；上例对应类名为：LogAnalyzerTests 待测试对象：Method，例如：期待名为IsValidLogFileName的方法，输入合法的文件名，希望返回true 测试代码中的对应对象：对于每个方法，创建至少一个测试方法，命名规则为[MethodName]_[StateUnderTest]_[ExpectedBehavior]. 上例对应方法名为：IsValidFileName_valideFile_R

为测试，保护独立性——用stub来打破对象之间的依赖关系

郑柯 — Sat, 19 Sep 2009 00:39:00 +0800

现在来看The Art of Unit Testing With Examples in .NET的第三章“Using Stubs to Break Dependencies” 作者使用了三种定义来指向测试中的伪造关系：fakes, stubs 和 mocks。 “除了间接层次过多这样的问题之外，没有哪种面向对象的问题是不能通过添加间接层次解决的。”然而，单元测试的诸多精妙之处就在于：如何找到正确的地方添加或使用间接层次，以测试目标代码。加入间接层次的三个步骤：找到待测试方法依赖的“接口”。这里的接口不单单是指面向对象中的接口，还包括与其他类协作需要调用的方法或类。如果“接口”与待测方法有“直接关系”（比如直接调用等等），就可以通过向接口加入间接层次，使得待测方法可以被测试。将交互接口的“潜在实现”用可以控制的东西替换。对于Seam（接缝）的定义： Seams are places in your code where you can plug in diffe

好的unit test具备哪些特点？

郑柯 — Wed, 02 Sep 2009 03:05:00 +0800

根据The Art of Unit Testing With Examples in .NET，好的unit test应该具备如下特点： It should be automated and repeatable. It should be easy to implement. Once it’s written, it should remain for future use. Anyone should be able to run it. It should run at the push of a button. It should run quickly. 如果这还不够，请回答下列问题，足以判断一个测试是否是好的unit test： Can I run and get results from a unit test I wrote two weeks or months or years ago? Can any member of my team run and get the results from

拾起单元测试，再次上路

郑柯 — Wed, 02 Sep 2009 02:56:00 +0800

开始看这本书：The Art of Unit Testing With Examples in .NET。选择它，两个原因：单元测试是保证代码质量的基石和安全网。该书篇幅短小精湛，而且非常实用。非常期待看到Chapter 8中的Tough Questions and Answers，其中有对如下问题的回答。 How much time will this add to the current process? Will my QA job be at risk because of this? How do we know this is actually working? Is there proof that unit testing helps? Why is the QA department still finding bugs? We have lots of code without tests: where do we start?

分离需求与GUI设计——保持项目节奏实践之七

郑柯 — Mon, 15 Jun 2009 17:17:00 +0800

我们希望系统解决的问题通过需求得以体现。GUI设计是要体现出GUI如何引导用户使用系统以解决他们的问题。很多项目都将GUI设计混同于需求的假面之下，这很让人讶异。如果你的项目总是陷于无尽的需求工作之中，看看问题是不是出在GUI设计上。 GUI是设计，不是需求凯伦，程序经理我在一家新公司工作时，试图拯救一个陷入“需求地狱”的项目。需求文档已经达到300多页，而且远未完成。阅读这些文档后，我找到了原因。所有的GUI设计都被记录在需求文档中。GUI设计没有放在项目的设计阶段，业务分析人员和GUI设计人员试图将所有的GUI需求都放在需求文档中。他们使用了功能强大的图形设计工具，并在需求文档中定义GUI。我向他们询问原因，他们看着我，说道：“这些是GUI需求。”我建议他们认真看看GUI设计，并且考虑这些设计是否应该跟希望系统解决的问题放在一起。GUI设计不应放在需求文档中。最终，他们同意采纳我的建议，我们也可以逃离需求地狱了。而且，由于我按照逐个功能重新组织了项目，GUI设计也就跟各个功能结合在一起了。我们定期检查整个GUI的一致性，但是这与需求无关，这属于设计。人们很

通过用例、用户故事、角色和场景来定义需求——保持项目节奏实践之六

郑柯 — Sat, 13 Jun 2009 20:15:00 +0800

要减少不必要的代码，有一个好方法：想想谁会使用系统，又该如何开发用户需要的系统。有很多项目都试图通过定义功能性和非功能性需求来确定需求。可是这些需求没有说明一个人如何使用系统，以及一个功能在何种场景下必须运行。需求收集的方法应该为项目团队提供上下文，这样才能深入理解需求。谁需要那个支票账户？克拉丽莎，资深经理我的项目团队陷入困境。他们实现了一堆只开发完一部分的功能，可是没有哪个能够真正运行。我召开了一个会议，以决定接下来该做什么。在会议上，我想知道：为了完成项目，哪些用户是他们的首要服务对象。他们看着我，脸上毫无表情。“你们看，我们是一家银行。我们希望年满18岁、将要进入大学的人们首先使用我们的服务。还有住在郊外的妈妈们，她们还有其他资产，75岁的老奶奶，以及年方15已经靠做家务挣得零花钱的孩子们。我们可以为他们提供不同的理财服务。如果他们走进来，我们希望他们成为我们的客户。对于这些不同类型的客户，我们真地想过要给他们提供什么样的产品么？” 他们以前太过专注于系统的内部功能，忽视了系统真正要为之服务的用户。我们把期望捕获的用户重新进行了排序，项目团队因此得以完

Google Translation Toolkit初测——初具雏形的翻译IDE

郑柯 — Wed, 10 Jun 2009 00:38:00 +0800

Google Translation Toolkit 是google刚刚发布的在线翻译平台，初步评测结果如下：说明：在settings里面有两个选择：第一种：让目的文档中填充它翻译的结果；第二种：在目的文档窗口中直接放置原文以下测试方式，选择第一种设置：已尝试如下三种方式： 1、提供英文页面urll，直接让其翻译，结果：翻译质量不行，而且格式乱掉，它自己加了很多span 2、将英文web页面另存到本地，再上传文件让其翻译，结果：同上； 3、提取html标签内容，另存为word文件，再上传，让其翻译结果：格式同样乱掉，它自己很“智能”地处理了一些标签，结果更乱了。。..-_-|||||.. 当setting中选择显示原文时，上述第一和第二种方式生成的文件同样含有n多span，无法使用。第三种方案翻译起来相对比较方便，但是如果要调整html标签的位置相信比较麻烦（要调整，是因为语序上的变化）， =============== 如果在环境中选择show toolkit，屏幕下方会有工具箱出现，目前看来，字典比较方便，但是解释比较简单

准备重构——保持项目节奏实践之五

郑柯 — Thu, 28 May 2009 20:51:00 +0800

重构是对代码的简化，无论是产品代码还是测试代码。重构不等于重新设计，只是简化而已。重构过的代码不会改变它的接口，只是更简单。我的代码不见了哈尔，初级开发人员我现在参与的项目是离开学校后的第二个。在第一个项目中，经理听了我的代码工作估算后说：“好，既然你还是个新人，咱们就再多加点儿时间吧，这样你可以把学到的经验应用到写好的代码中。”我觉得他这么做纯属多余，不过没关系，我还是加倍努力，在截止日期来临之时完成了手上的工作。接下来，我了解了整个系统真正的运转方式，就得修改已完成的工作了，不只耗费了所有额外的时间，而且还多用了一点点。让我感到惊讶的是：为了解决问题，我没有编写更多代码，而是简化了现有做法并去掉一些代码。我的代码不见了。现在这个项目，我使用了持续集成，而且一边开发一边重构。在开发时，简化并清洁代码，而不是改变设计，这让我对自己手上的工作和开发速度有了更清晰的认识。而且，我的代码仍然在继续消失。如果你曾经随项目进展计算过代码行数，要是项目采取顺序式生命周期，或是将集成和测试放在项目临近结束时进行，那就会看到一个S形曲线（见图9.1）。可以注意到，开始集成和测试后，