Keith Swenson 最近编制了一份给敏捷软件开发的 26 条建议。Keith 提到他常常收集一些不同主题的至理名言，这份列表是这一系列至理名言的精华，肯定能很好地帮助到敏捷软件开发。
在他的博文中，有人评论说很多建议可能并不是专门针对敏捷的，而是面向如何更好的软件开发和设计。Keith 回应说对于有资历的敏捷实践者而言，那些建议可能听起来太平常了，但是还是有更多的受众对那些实践并不是太了解。他补充说：
我正和几个团队在日本一起工作，他们使用一种很严格的瀑布开发模式。对于这种团队来说，我提到的那些建议，可能有一半都“令人惊奇”，甚至可能被认为是很激进的意见。比如“先写测试再写代码”以及“没有必要就永远不要去实现”这些对他们来说就是很激进的概念。他们自豪于“全面”实现功能，甚至去杜撰客户并未提出的用例。结果当然就是代码过度，这是另一种浪费。他们有时候等 6 个月来完成测试。对于在严格的瀑布模式中进行实施的人们来说，测试只是一种“辅助”，正确工作的程序员不需要它。很惊奇哦？
Keith 提议的某些“不是非常常见” 的有趣建议有：
- 完整地做完第一件事后再开始第二件。软件开发的一个大问题就是同时做几件事情，这将不可避免地使得某些工作被废弃从而造成浪费。用厨房来比喻就是：“先上这道菜，再开始烧下一个。”
- 不要害怕做决定；不要害怕改变先前的决定。最大可能地延迟决策，直到必须做决定的时候。一旦有新的信息了，不要害怕改变先前的决定。
- 度量、度量、度量。敏捷开发帮助处理了未来不确定性的问题。但是对于过去，应该没有不确定的事。
- 设计是为了人，而不是系统。太多的程序员偏离了设计的目的，而更关注技术本身。软件最终的成功取决于让人们有效合作并增加商业价值。
- 过早地进行优化是万恶之源。仅仅基于对代码的静态理解就直觉地判断什么对整体性能最为重要，结论几乎总是错误的。相反，应该衡量整个系统的行为，随后来识别性能问题。
- 决不过度强调功能的通用性。这也就是著名的“YAGNI——你不会需要它的（You Aren’t Going to Need It）。”
- 不要用代码行数来度量代码。完成特定任务所需的代码行数，不同的程序员之间和编码风格之间差异很大。应该去统计功能用例的数目。
- 软件是可塑的。不像实体制造业，软件可以很容易地获得显著改变。
- 不要去发明新的语言。XML 的出现引领了无休止的专门订制“脚本语言”的潮流，想来应该会让软件开发更加趋同。这种推理的缺陷在于，离开某个特定实施的环境，几乎从来都没能很好地精确定义操作行为。
想获得更多的信息，请访问这份完整的建议清单。如果你觉得有什么重要的观点遗漏了，请留言。
暂无签名
最新发布
QCon 北京路宁专访：精益开发
2012 年 5 月 16 日
熊节谈精益在软件开发中的应用
2010 年 12 月 21 日
讨论：Scrum 回顾会议怎么开最有效？
2009 年 6 月 8 日
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
走向深度学习的美图社区推荐：从工具到算法
10 道实用 Java 面试题
云原生应用中的网络流量管理
评论