编码混乱是技术上的债务吗?
2012-10-26 15:21
204 查看
“技术债务(technical debt)”这个词是由Ward Cunningham 发明的,用来描述为了在最后期限前实现某个项目任务而让开发团队做某种技术上的妥协。
这里有两篇博客文章,Uncle Bob 和 Martin Fowler 分别在里面描述了几乎所有项目都可能会遇到的各种技术债务。
在 A Mess is not a Technical Debt[/u] 这篇博客里, Uncle Bob 评论说,做出妥协是实现有最后期限目标的必要的手段。但是他区分妥协与否的方法只是纯粹从代码的粗心与否来考虑:
编码混乱并不是一种债务。编码混乱就是编码混乱。技术债务的产生是由现实的工程约束造成的。这是有风险的,但却是值得去做的。而程序员让编码混乱的行为永远是不理智的,它永远都是因为懒惰和不专业造成的,而且将来你也永远还不清这种债务。混乱永远都是一种错误 …
你承担的技术债务越多,你就应该越发自律。你应该做更多的测试,更多的结对编程,更多的重构。技术债务并不是你制造代码混乱的通行证。技术债务实际上是要求你更清晰的代码 … 当你决定去欠下技术债务的时候,你最好能确保你的代码保持清晰易懂。保持系统的清晰易懂是你将来偿还债务的唯一途径 …
在 Technical Debt Quadrant[/u] 这篇博客里, Martin Fowler 认为编码混乱就是一种技术债务,是程序员在不经意间犯下的错误。Martin Fowler 接着描述了四种类型的技术债务:故意的/大意的,故意的/谨慎的,非故意的/大意的,以及非故意的/谨慎的:
做这些区分的目的不在于判断它是否是债务,而是判断是思虑过的还是粗心的 …
不仅仅谨慎产生的债务和大意产生的债务有区别,考虑过的债务和非有意的债务更要有区别。谨慎思考过的债务的例子就是”故意的债务“,因为团队已经知道他们将会欠下债务,他们会考虑是提前发布一个不成熟的版本会得的利益多还是放弃这次发布产生的代价大。一个团队如果没有反复思考他们的设计,那他们就会欠下粗心大意产生的债务,他们甚至没有意识到自己已经陷入了无法自拔的债务泥潭里。
注意到,有一种特殊的债务既是既是大意的又是思考过的:
经常会有这种情况出现,一个项目你干了一年后才明白你实际应该采用何种的设计架构。也许我们应该这样计划项目:花一年的时间去开发它,然后扔掉重建,但没人会认同这种做法。除了此时你会明白什么的设计才是你应该采取的设计外,你还要明白,这就是一个非有意产生的债务。
你是否也认为混乱的编码、快速但质量低下的程序实现是某种形式上的技术债务呢?或者,你认为这些只是由于技术水平低下造成的,完全可以避免,即使是在有最后期限的情况下?
本文转自HTML5中国网站:http://www.html5cn.org/article-3896-1.html
这里有两篇博客文章,Uncle Bob 和 Martin Fowler 分别在里面描述了几乎所有项目都可能会遇到的各种技术债务。
在 A Mess is not a Technical Debt[/u] 这篇博客里, Uncle Bob 评论说,做出妥协是实现有最后期限目标的必要的手段。但是他区分妥协与否的方法只是纯粹从代码的粗心与否来考虑:
编码混乱并不是一种债务。编码混乱就是编码混乱。技术债务的产生是由现实的工程约束造成的。这是有风险的,但却是值得去做的。而程序员让编码混乱的行为永远是不理智的,它永远都是因为懒惰和不专业造成的,而且将来你也永远还不清这种债务。混乱永远都是一种错误 …
你承担的技术债务越多,你就应该越发自律。你应该做更多的测试,更多的结对编程,更多的重构。技术债务并不是你制造代码混乱的通行证。技术债务实际上是要求你更清晰的代码 … 当你决定去欠下技术债务的时候,你最好能确保你的代码保持清晰易懂。保持系统的清晰易懂是你将来偿还债务的唯一途径 …
在 Technical Debt Quadrant[/u] 这篇博客里, Martin Fowler 认为编码混乱就是一种技术债务,是程序员在不经意间犯下的错误。Martin Fowler 接着描述了四种类型的技术债务:故意的/大意的,故意的/谨慎的,非故意的/大意的,以及非故意的/谨慎的:
做这些区分的目的不在于判断它是否是债务,而是判断是思虑过的还是粗心的 …
不仅仅谨慎产生的债务和大意产生的债务有区别,考虑过的债务和非有意的债务更要有区别。谨慎思考过的债务的例子就是”故意的债务“,因为团队已经知道他们将会欠下债务,他们会考虑是提前发布一个不成熟的版本会得的利益多还是放弃这次发布产生的代价大。一个团队如果没有反复思考他们的设计,那他们就会欠下粗心大意产生的债务,他们甚至没有意识到自己已经陷入了无法自拔的债务泥潭里。
注意到,有一种特殊的债务既是既是大意的又是思考过的:
经常会有这种情况出现,一个项目你干了一年后才明白你实际应该采用何种的设计架构。也许我们应该这样计划项目:花一年的时间去开发它,然后扔掉重建,但没人会认同这种做法。除了此时你会明白什么的设计才是你应该采取的设计外,你还要明白,这就是一个非有意产生的债务。
你是否也认为混乱的编码、快速但质量低下的程序实现是某种形式上的技术债务呢?或者,你认为这些只是由于技术水平低下造成的,完全可以避免,即使是在有最后期限的情况下?
本文转自HTML5中国网站:http://www.html5cn.org/article-3896-1.html
相关文章推荐
- 编码混乱是技术上的债务吗?
- FLASH 编码和推送技术,轻松搭建跨平台网络视频监控系统
- 打造高质效的技术团队 —— 混乱篇
- Avro技术应用_8. 使用 Sqoop 加载数据的时候使用 Avro 格式进行编码 -- 带完善
- VoIP技术(2)--语音编码算法-1
- 针对login部分编码混乱原因的分析
- 不要让其他人的技术债务影响到你
- 编码之道:是谁制造了混乱
- 基于Intel®IPP的MPEG-2编码技术研究及实现
- 减少HTTP请求之将图片转成二进制并生成Base64编码,可以在网页中通过url查看图片(大型网站优化技术)
- 雄迈H.265+编码技术, 独领安防视频编码技术风潮
- MPEG-2压缩编码技术原理应用
- 一起谈.NET技术,VS2010测试功能之旅:编码的UI测试(2)-操作动作的录制原理(下)
- 音视频编解码技术之视频编码基本概念介绍
- 技术债务终于还得差不多了
- 程序员应知——技术债务
- [图文]MPEG-2压缩编码技术原理应用(三)
- 所有程序必须掌握的字符集和编码技术
- XP中重构和技术债务(XP编程学习)
- 英文半字节压缩编码技术