用 Safari 11+、Firefox 70+ 浏览效果最佳
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> 敏捷 > > 敏捷 >
在线/74 登录/0

程序员必读的敏捷开发建议

阅读数:2.0K
基本
引言


网络上流传了很多关于敏捷开发的具体建议,加起来可能超过上百条,有些内容很精彩,而有些说法比较片面,值得商榷。收集和整理这些至理名言是我的一项工作。

下面是我作为一名具有近 20 年编程经验的“编程达人”对这些建议的分析和评论,供大家参考、拍砖。

* 完整地做完第一件事后再开始第二件。软件开发的一个大问题就是同时做几件事情,这将不可避免地使得某些工作被废弃从而造成浪费。用厨房来比喻就是:“先上这道菜,再开始烧下一个。”

不一定。并行工作还是必要的,但是要有限度。


* 不要害怕做决定;不要害怕改变先前的决定。最大可能地延迟决策,直到必须做决定的时候。一旦有新的信息了,不要害怕改变先前的决定。

不错,这是敏捷精神所在。


* 度量、度量、度量。敏捷开发帮助处理了未来不确定性的问题。但是对于过去,应该没有不确定的事。

说得非常好!

想一想 NBA 梦之队的实时技术统计,就可以知道度量的最高境界了。


* 设计是为了人,而不是系统。太多的程序员偏离了设计的目的,而更关注技术本身。软件最终的成功取决于让人们有效合作并增加商业价值。

说得太好了!

提供业务价值的业务建模绝对重要。


* 过早地进行优化是万恶之源。仅仅基于对代码的静态理解就直觉地判断什么对整体性能最为重要,结论几乎总是错误的。相反,应该衡量整个系统的行为,随后来识别性能问题。

很好的建议!


* 决不过度强调功能的通用性。这也就是著名的“YAGNI——你不会需要它的(You Aren’t Going to Need It)。”

对!


* 不要用代码行数来度量代码。完成特定任务所需的代码行数,不同的程序员之间和编码风格之间差异很大。应该去统计功能用例的数目。

绝对正确!


* 软件是可塑的。不像实体制造业,软件可以很容易地获得显著改变。

不全对,虽然是很容易,但可能也是高成本的。


* 不要去发明新的语言。XML的出现引领了无休止的专门订制“脚本语言”的潮流,想来应该会让软件开发更加趋同。这种推理的缺陷在于,离开某个特定实施的环境,几乎从来都没能很好地精确定义操作行为。

片面。可以去发明新的语言,比如 DSL。

<帮助> <全部评论> 共 0 个主题 0 条评论 (AgileHints)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2020 张恂 版权所有. 沪ICP备15017521号-2