大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
抛砖引玉——重构是必要的浪费
作者 Amr Elssamadisy 译者 李剑 发布于 2007年12月18日
重构是敏捷开发人员工具箱中的一项核心实践。按照重构的定义——修改内部结构（设计）而不影响外部行为——来讲，它并不能为客户创造可衡量的价值。在精益世界中，任何不能为客户创造价值的做法都是浪费，客户所能够感知到的只是行为/功能，而非结构。
但是精益定义了两种类型的浪费：“纯粹的浪费”和“必要的浪费”。“纯粹的浪费”指的是那种既不能给开发团队也不能给客户带来好处的做法。“必要的浪费”是指某些行为，即便它不能给客户创造价值，但也是在我们所知的范围内完成一项工作的最佳方式。重构就是典型的后者之一。
那又为什么要把一个有价值的做法称作“必要的浪费”呢？呃，这里的着眼点在于，它对于客户而言是没有价值的。所以我们应该把在这方面投入的 精力尽量减到最少，而且需要不断寻找更好的替代方案。可如果我们没有把它识别为一种浪费的话，我们就会把它理解为正确完成工作的唯一方式，不再寻找解决途 径——想一下“预先做大量的设计（Big Design Up Front）”吧。
如果看完了上面的话以后，你仍然赞同我的观点，那么接 下来就有一个问题等着你了：“那又怎么样？理解也好，不理解也罢，会有多大影响吗？”当开发人员把重构看作是必要的浪费时，他可能就会尽量减少重构，只重 构那些不再符合客户需求的代码。也即，如果你在编码的过程中发现了类中的某个方法有“坏味道”，但是它和你正在实现的需求并无联系，那就把它放到一边去。查看英文原文：Opinion: Refactoring is a Necessary Waste
译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。
浪费就是浪费
发表人
He Yiding
发表于
重构不能为客户创造价值？
发表人
zane dennis
发表于
同意，重构也在创造价值，Amr Elssamadisy 的一些论点是不对的。
发表人
Zhang Charlie
发表于
要注意度的问题
发表人
Yao Andy
发表于
作者是说no measurable customer value
发表人
B Necromancer
发表于
偶觉得还是挺有道理的
发表人
X 1073
发表于
-
浪费就是浪费，它的定义还需要多做说明吗？重构的直接目的并不是为了给客户创造价值，这已经很清楚了，那为什么还要以“对于客户而言是没有价值的”这样的标准来将重构归类为“浪费”呢？
实际上不止是重构，项目的任何实践都应该避免过度，在必要的前提下避免浪费。这不过是节约成本的需要，并不是什么新观点。 -
重构就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。那么软件的设计模式和架构更合理，扩展性和可维护性更高，显然就能够更快地响应客户的需求变化，对于客户的后期维护开发也有很大的价值，怎么能说不能为客户创造价值呢？
-
也就是怎么确定文中的“纯粹的浪费”和“必要的浪费”。
虽然下了定义，但是各个project中的情况是不一样的，还是要把握度的问题 -
如题
-
重构真的是不可衡量的？或者换个角度问：为什么作者认为可衡量客户价值才是客户价值？
-
因为开发者自身的问题导致代码中的坏味道，站在用户的角度他可没有义务为此付出代价，坏味道是开发者的责任，那用户当然有理由认为修正这些坏味道是浪费他的资源。但是软件开发中很多的不确定性致使开发者无法彻底避免这些坏味道，而且坏味道对系统的影响是显而易见的，修改他们是必须的。修改坏味道的花费自然就是“必要的浪费”了。
6 条回复
关注此讨论 回复