牧心

关注敏捷、关注人

用户操作

[留言] [发消息] [加为好友]

订阅我的博客

[编辑]MagBryan的公告

[编辑]文章分类

[编辑]Web 2.0

[编辑]敏捷

存档

开始写BLOG

2009年11月22日

云中的软件应用生命周期

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阅读全文>

发表于 @ 2009年11月22日　14:40:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年10月18日

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

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

发表于 @ 2009年10月18日　16:37:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年09月19日

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

在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阅读全文>

发表于 @ 2009年09月19日　00:49:00 | 评论( loading... ) | 编辑| 举报| 收藏

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

现在来看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阅读全文>

发表于 @ 2009年09月19日　00:39:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年09月02日

好的unit test具备哪些特点？

根据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阅读全文>

发表于 @ 2009年09月02日　03:05:00 | 评论( loading... ) | 编辑| 举报| 收藏

拾起单元测试，再次上路

开始看这本书：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? 阅读全文>

发表于 @ 2009年09月02日　02:56:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月15日

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

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

发表于 @ 2009年06月15日　17:17:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月13日

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

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

发表于 @ 2009年06月13日　20:15:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月10日

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

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

发表于 @ 2009年06月10日　00:38:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月28日

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

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

发表于 @ 2009年05月28日　20:51:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月19日

多几只眼睛盯着产品——保持项目节奏实践之四

邀请团队成员相互复查工作。复查的形式并不重要，结对编程（pair programming）、伙伴复查（buddy review）、同行复查（peer review）、走查（walk-through）、正式代码检查（formal code inspection）都可以。复查能够为项目方方面面带来好处。项目经理要为团队提供多种方法。这些方法以特定顺序介绍：从最不正式到最正式。以我的经验来看，这也可以从最有效和易于保持的，到最没有效果和难以维系的。结对编程。先不要假定“这里没人愿意这么做”，要允许大家这么做。（而且可以提醒大家，他们已经完成过结对调试了。）我会问大家谁自愿进行结对。我建议他们在开始之前，先去阅读一些相关资源，比如［WK02］和［SH06b］，还有http://www.pairprogramming.com。不出意外的话，会有人愿意尝试结对的。相对独自工作来说，他们可以学到如何通过结对编程使工作变得更有效率。除了减少缺陷、加快开发速度外，结对编程还能带来很大的好处：有两个人完全熟悉并知道如何处理同一块代码。而且，如果人们经常切换不同的结对对象，他们就会深阅读全文>

发表于 @ 2009年05月19日　17:52:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月15日

按功能实现，而不是按架构——保持项目节奏实践之三

逐个功能进行实现和测试哈威、维贾、道、兰迪、肯和梅布尔，负责提醒功能的团队我是哈威，团队的头儿。我们的开发人员包括维贾、道、兰迪和肯，梅布尔是测试人员。我们在GUI、平台、硬件集成以及几个方面都有专家，而梅布尔无所不知。（背景中传来笑声。）刚开始的时候，我们试图先把架构开发出来，再制订规范，告诉大家我们在做什么。我们每个人各自负责一块，最后再放到一起。可是一切都没有按计划进行。因为即使我们有规范，在开发各自的组件时，我们总会改变些什么。梅布尔曾经听过有关按功能实现的说法，并告诉了我。我问大家是否愿意组建一个基于功能的团队。嗯，其实是基于功能集合的团队。我们开发所有的提醒功能，一次完成一个，从前端到后台。梅布尔会负责测试。开始时有点儿困难，不过习惯之后，我们添加功能的速度让人惊喜不已。我们不再是每个人开发很多代码然后再集成到一起，而是只添加每个提醒功能需要的代码，再进行测试。梅布尔保证我们不要出现系统级别上的问题，我们保证每个提醒功能不要出问题。我们的开发速度如此之快，不久就有新的功能需要开发了。现在，有些其他组也在尝试我们阅读全文>

发表于 @ 2009年05月15日　17:00:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月10日

为构建创建自动化冒烟测试——保持项目节奏实践之二

不管使用持续集成与否，都应该为构建产品创建自动化冒烟测试。冒烟测试仅仅是为了验证要构建的版本没有问题。你想添加多少回归测试都可以，我不拦着，但是使用冒烟测试，是要知道当前的构建版本是否对大家有用。有了自动化冒烟测试，项目团队就可以知道是不是有人破坏了当前构建版本。如果能尽早知道一个构建完成了，你就可以在其基础上做些自己想做的工作。要是必须依赖其他开发人员或是测试人员才能知道当前构建版本出了问题，那你就不能以最快的速度修复当前构建版本了。别让烟跑出去！梅瑞狄斯，资深测试人员作为测试人员，寻找问题是我的职责所在。而且，我也很擅长这个。我有一句座右铭：“别让烟跑出去。” 有一次，我加入了公司的一个新项目。开发人员以前从没有与专业测试人员一起工作过。我拿着一张有15个缺陷的列表，走到他们中一个人的面前，然后说：“你得说说这是怎么回事，要不我把这些问题提交到缺陷跟踪系统里面如何？”他们都惊呆了。我向他们说明，这些缺陷通过一个自动化冒烟测试都可以找出来。没有哪个缺陷需要靠我的专业知识和经验才能发现。我不想浪费时间找出这些易于发现的缺陷，而是要找出阅读全文>

发表于 @ 2009年05月10日　22:24:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月08日

持续集成——保持项目节奏实践之一

第9章保持项目节奏项目经理不但要用管理实践掌控项目，还可以欢迎团队改变自己的技术实践，从而获得更大收益。本章包含的一系列实践，能为项目带来很多好处。项目经理和团队要根据自身的实际情况，判断如何调整、使用这些实践，而不要强制推行。如果你认为它们有所裨益，不妨将其介绍给团队，并欢迎团队积极尝试。 9.1 在项目中使用持续集成开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。[1] 持续集成可以让开发人员马上得到所做工作的反馈。他们开始考虑将大任务拆分成更小的部分（这可以让他们以更快的步伐前进），还能尽早识别出项目的集成风险。持续集成让开发人员每天都能有所收获，帮助项目团队找到符合自己的节奏。开发人员只有在完成了某个功能的代码后才将其签入，这就是按阶段集成的方式。有些开发人员一周签入一次代码。有些更糟糕的项目，开发人员一到两个月才签入一次代码。按阶段集成会打断项目的节奏。构建时出现的问题，会中断设计和编写新功能代码的人们的思路。他们不得不记住很多小细节，而这些小细阅读全文>

发表于 @ 2009年05月08日　10:49:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月07日

掌控项目节奏，做到了如指掌

（图片来自：http://www.flickr.com/photos/cuppini/）节奏，无所不在。春夏秋冬，日升月落，这是大自然的节奏；日出而作日入而息，朝九晚五，这是人类社会的节奏。生活有了节奏，人体的各个构成部分、乃至各个细胞才能正常运作，以保证整体的健康。社会中有节奏，而不是朝令夕改，大家才能安居乐业。项目管理同样如此。《Manage It！》第8章“掌控项目”第1节就名为“掌控项目的节奏”。其中说到：节奏，每个项目生而有之。有些项目节奏混乱，进展缓慢。有些项目就像坐上了火箭，倏忽间，团队就完成了更多工作。所有的项目都有节奏，不过它会随时间而变。观察节奏是项目经理的职责，你还要看出来哪些实践是否能够帮助项目建立并维持合理的节奏，保证项目取得成功。项目的生命周期越接近于顺序式生命周期，项目的节奏就越有可能随阶段发生变化［Rot04a］。在早期阶段，项目看起来就像遭受了很多痛苦，项目经理也不知道需求何时冻结、设计何时稳定。有些项目会“神奇地”找到出口，在进入实施阶段后，节奏逐渐显现出来，而且日趋稳定，因为该做的决策已经做了，而且得到了实行。假定没阅读全文>

发表于 @ 2009年05月07日　10:59:00 | 评论( loading... ) | 编辑| 举报| 收藏

第1页，共5页