BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

给成功敏捷开发的26条建议

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 金毅 关注 0 他的粉丝 发布于 2009年11月9日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

Keith Swenson最近编制了一份给敏捷软件开发的26条建议。Keith提到他常常收集一些不同主题的至理名言,这份列表是这一系列至理名言的精华,肯定能很好地帮助到敏捷软件开发。

在他的博文中,有人评论说很多建议可能并不是专门针对敏捷的,而是面向如何更好的软件开发和设计。Keith回应说对于有资历的敏捷实践者而言,那些建议可能听起来太平常了,但是还是有更多的受众对那些实践并不是太了解。他补充说:  

我正和几个团队在日本一起工作,他们使用一种很严格的瀑布开发模式。对于这种团队来说,我提到的那些建议,可能有一半都“令人惊奇”,甚至可能被认为是很激进的意见。比如“先写测试再写代码”以及“没有必要就永远不要去实现”这些对他们来说就是很激进的概念。他们自豪于“全面”实现功能,甚至去杜撰客户并未提出的用例。结果当然就是代码过度,这是另一种浪费。他们有时候等6个月来完成测试。对于在严格的瀑布模式中进行实施的人们来说,测试只是一种“辅助”,正确工作的程序员不需要它。很惊奇哦?  

Keith提议的某些“不是非常常见” 的有趣建议有:  

  • 完整地做完第一件事后再开始第二件。软件开发的一个大问题就是同时做几件事情,这将不可避免地使得某些工作被废弃从而造成浪费。用厨房来比喻就是:“先上这道菜,再开始烧下一个。”
  • 不要害怕做决定;不要害怕改变先前的决定。最大可能地延迟决策,直到必须做决定的时候。一旦有新的信息了,不要害怕改变先前的决定。
  • 度量、度量、度量。敏捷开发帮助处理了未来不确定性的问题。但是对于过去,应该没有不确定的事。
  • 设计是为了人,而不是系统。太多的程序员偏离了设计的目的,而更关注技术本身。软件最终的成功取决于让人们有效合作并增加商业价值。 
  • 过早地进行优化是万恶之源。仅仅基于对代码的静态理解就直觉地判断什么对整体性能最为重要,结论几乎总是错误的。相反,应该衡量整个系统的行为,随后来识别性能问题。
  • 决不过度强调功能的通用性。这也就是著名的“YAGNI——你不会需要它的(You Aren’t Going to Need It)。”
  • 不要用代码行数来度量代码。完成特定任务所需的代码行数,不同的程序员之间和编码风格之间差异很大。应该去统计功能用例的数目。
  • 软件是可塑的。不像实体制造业,软件可以很容易地获得显著改变。
  • 不要去发明新的语言。XML的出现引领了无休止的专门订制“脚本语言”的潮流,想来应该会让软件开发更加趋同。这种推理的缺陷在于,离开某个特定实施的环境,几乎从来都没能很好地精确定义操作行为。

想获得更多的信息,请访问这份完整的建议清单。如果你觉得有什么重要的观点遗漏了,请留言。

查看英文原文:26 Hints for Successful Agile Development

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

过早地进行优化是万恶之源 by rao apple

过早地进行优化是万恶之源,maybe is right!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT