OpenSocial规范、实现现状与展望
OpenSocial为构建跨多个网站的社交应用程序提供了一组通用 API。开发人员可以使用标准 JavaScript 和 HTML 创建应用程序，用以访问社交网络里的朋友并更新对应的Feeds。本文是对本次QClub活动内容的一个简短总结，希望对没有到现场参会的读者了解OpenSocial有所帮助，也希望能引起大家更多的讨论。
新闻
抛砖引玉——重构是必要的浪费
作者 Amr Elssamadisy译者 李剑 发布于 2007年12月18日 上午7时36分
重构是敏捷开发人员工具箱中的一项核心实践。按照重构的定义——修改内部结构（设计）而不影响外部行为——来讲，它并不能为客户创造可衡量的价值。在精益世界中，任何不能为客户创造价值的做法都是浪费，客户所能够感知到的只是行为/功能，而非结构。
但是精益定义了两种类型的浪费：“纯粹的浪费”和“必要的浪费”。“纯粹的浪费”指的是那种既不能给开发团队也不能给客户带来好处的做法。“必要的浪费”是指某些行为，即便它不能给客户创造价值，但也是在我们所知的范围内完成一项工作的最佳方式。重构就是典型的后者之一。
那又为什么要把一个有价值的做法称作“必要的浪费”呢？呃，这里的着眼点在于，它对于客户而言是没有价值的。所以我们应该把在这方面投入的 精力尽量减到最少，而且需要不断寻找更好的替代方案。可如果我们没有把它识别为一种浪费的话，我们就会把它理解为正确完成工作的唯一方式，不再寻找解决途 径——想一下“预先做大量的设计（Big Design Up Front）”吧。
如果看完了上面的话以后，你仍然赞同我的观点，那么接 下来就有一个问题等着你了：“那又怎么样？理解也好，不理解也罢，会有多大影响吗？”当开发人员把重构看作是必要的浪费时，他可能就会尽量减少重构，只重 构那些不再符合客户需求的代码。也即，如果你在编码的过程中发现了类中的某个方法有“坏味道”，但是它和你正在实现的需求并无联系，那就把它放到一边去。查看英文原文：Opinion: Refactoring is a Necessary Waste
相关厂商内容
浪费就是浪费
发表人
Yiding He
发表于
2007年12月18日 下午6时57分
重构不能为客户创造价值？
发表人
dennis zane
发表于
2007年12月18日 下午7时14分
同意，重构也在创造价值，Amr Elssamadisy 的一些论点是不对的。
发表人
Charlie Zhang（张恂）
发表于
2007年12月18日 下午8时20分
要注意度的问题
发表人
少远 姚
发表于
2007年12月18日 下午7时25分
作者是说no measurable customer value
发表人
Necromancer B
发表于
2007年12月21日 下午12时41分
偶觉得还是挺有道理的
发表人
1073 X
发表于
2007年12月26日 下午11时8分
-
浪费就是浪费，它的定义还需要多做说明吗？重构的直接目的并不是为了给客户创造价值，这已经很清楚了，那为什么还要以“对于客户而言是没有价值的”这样的标准来将重构归类为“浪费”呢？
实际上不止是重构，项目的任何实践都应该避免过度，在必要的前提下避免浪费。这不过是节约成本的需要，并不是什么新观点。 -
重构就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。那么软件的设计模式和架构更合理，扩展性和可维护性更高，显然就能够更快地响应客户的需求变化，对于客户的后期维护开发也有很大的价值，怎么能说不能为客户创造价值呢？
-
也就是怎么确定文中的“纯粹的浪费”和“必要的浪费”。
虽然下了定义，但是各个project中的情况是不一样的，还是要把握度的问题 -
如题
-
重构真的是不可衡量的？或者换个角度问：为什么作者认为可衡量客户价值才是客户价值？
-
因为开发者自身的问题导致代码中的坏味道，站在用户的角度他可没有义务为此付出代价，坏味道是开发者的责任，那用户当然有理由认为修正这些坏味道是浪费他的资源。但是软件开发中很多的不确定性致使开发者无法彻底避免这些坏味道，而且坏味道对系统的影响是显而易见的，修改他们是必须的。修改坏味道的花费自然就是“必要的浪费”了。
6 条回复
回复