低质量软件编程成本价格表
- - ITeye资讯频道注意：下面这个清单里描述的事情并不是你绝对不能做的，它只是用量化的方法来让你知道编程上的这些做法将会产生的负面代价. 这些费用是在代码审查时你将要付出的. 代码库中的程序编码风格一致虽然不是很重要，但值得你去遵守. 在提交代码的说明信息上偷懒. 请细读这篇 代码提交说明信息指导(英文). 大多数的局部变量都最好使用方法代替.
低质量软件编程成本价格表
标签：
质量
软件
编程
| 发表时间：2013-09-05 10:00 | 作者：
出处：http://www.iteye.com
注意：下面这个清单里描述的事情并不是你绝对不能做的，它只是用量化的方法来让你知道编程上的这些做法将会产生的负面代价。
这些费用是在代码审查时你将要付出的。
不遵守编码风格
费用： $0.02
代码库中的程序编码风格一致虽然不是很重要，但值得你去遵守。
在提交代码的说明信息上偷懒
费用： $0.50
这主要是为了以后的查找。请细读这篇 代码提交说明信息指导(英文)。
使用局部变量
费用： $1.00
大多数的局部变量都最好使用方法代替。注意：代码块参数除外。
多于一行的方法
费用： $1.50
对多于一行代码的方法要保持高度警惕。
超过5行的方法
费用： $3.00
一个方法应该只做一个事情。一个事情应该用不了5行代码就能完成。
很长的类
费用： $5.00
根据 童子军(Boy Scout)法则：尽量只留下你会用到的代码。当你遇到一个比较长的类时，花点功夫精简它们。
使用魔幻数字
费用： $7.00
在代码中你只可以使用两个数字：0和1。其它的都应该用具有名字的常量代替。
在条件判断中使用`||` 或 `&&`
费用： $7.00
当你发现有 `if foo && bar` 时，把它提取到一个方法里，用来说明`foo && bar` 究竟是什么意思。
使用 case 或 switch 语句
费用： $15
一个swith语句基本上不是只做一个事情。它通常还会牵涉到其它类。
传递布尔参数
费用： $15
依赖布尔参数的程序流转叫做控制耦合，这是一种完全不应该的高 耦合。
类名用Manager结尾
费用： $30
“Manager”是一个很含糊的词，传达不了任何意思。使用它，很有可能你的类承担了过多的责任。
过度使用附加支持
费用： $10/object created
尽量简化你测试时需要的附加支持工具。如果能用临时对象代替，就避免使用数据库。
测试中屏蔽某些功能
费用： $10/屏蔽的方法
如果你在测试Foo类，你就不应该屏蔽或短路Foo中的任何方法。你越想这样做，越说明你需要从Foo中把这些功能提炼出来放到其它地方。
在数据库中观察集成测试效果
费用： $20
集成测试应该通过UI来验证。不要去窥探数据库。
注释
费用： $200/行
一千个注释中顶多只有一条有合理存在的理由。其它的你应该改进代码，直到不需要注释。
注释中包含 TODO 或 FIXME
费用： $500/行
我不在意代码分支中存在不多的TODO注释，但绝对不要把它们合并的代码库中。“FIXME”实际上是“fu ck you”你的同事。
无意义的命名
费用： $50/代码审查者的疑惑
一定要努力努力好好给代码命名。当系统有变化时及时修改、改进你的命名。当发现有更好的名称时，不要等待，立即换掉。
静态方法或类方法
费用： $50/个
Ruby里的类方法具有 可变全局状态。想办法重构它们。
不必要的属性状态变化
费用： $100/变化
与其修改一个现有的记录，不如创建一个新的，或return一个。与其删除，不如做标记。Rich Hickey 对此 有一些你值得一读的思考。
一个类有多个职责
费用： $200/额外职责
一个类应该只有一个职责或目的。几乎没有人因为使得类太小而出错。鉴于此，你的类很可能太大。
重复的代码
费用： $500
编程中几乎没有任何原则你必须遵守的，但避免代码重复是个例外。代码复制给维护造成困难，严重影响代码质量。
重复的测试代码
费用： $500
测试代码并不是产品代码的次要附属物。它们的质量同等重要。更严重的：维护一个糟糕的测试套件代码可能会让你欲哭无泪。
未经测试的代码
费用： $1,000/行
未经测试的代码自诞生之时起就成了负担。这样做很不专业。
感谢Paul Graham先生的“On Lisp”，本文是受他的在某些函数上收税的想法而启发。
英文原文： How much should global variables cost? / 译： 外刊IT评论
感谢 WnouM 投递这篇资讯
资讯来源： 外刊IT评论
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
这些费用是在代码审查时你将要付出的。
不遵守编码风格
费用： $0.02
代码库中的程序编码风格一致虽然不是很重要，但值得你去遵守。
在提交代码的说明信息上偷懒
费用： $0.50
这主要是为了以后的查找。请细读这篇 代码提交说明信息指导(英文)。
使用局部变量
费用： $1.00
大多数的局部变量都最好使用方法代替。注意：代码块参数除外。
多于一行的方法
费用： $1.50
对多于一行代码的方法要保持高度警惕。
超过5行的方法
费用： $3.00
一个方法应该只做一个事情。一个事情应该用不了5行代码就能完成。
很长的类
费用： $5.00
根据 童子军(Boy Scout)法则：尽量只留下你会用到的代码。当你遇到一个比较长的类时，花点功夫精简它们。
使用魔幻数字
费用： $7.00
在代码中你只可以使用两个数字：0和1。其它的都应该用具有名字的常量代替。
在条件判断中使用`||` 或 `&&`
费用： $7.00
当你发现有 `if foo && bar` 时，把它提取到一个方法里，用来说明`foo && bar` 究竟是什么意思。
使用 case 或 switch 语句
费用： $15
一个swith语句基本上不是只做一个事情。它通常还会牵涉到其它类。
传递布尔参数
费用： $15
依赖布尔参数的程序流转叫做控制耦合，这是一种完全不应该的高 耦合。
类名用Manager结尾
费用： $30
“Manager”是一个很含糊的词，传达不了任何意思。使用它，很有可能你的类承担了过多的责任。
过度使用附加支持
费用： $10/object created
尽量简化你测试时需要的附加支持工具。如果能用临时对象代替，就避免使用数据库。
测试中屏蔽某些功能
费用： $10/屏蔽的方法
如果你在测试Foo类，你就不应该屏蔽或短路Foo中的任何方法。你越想这样做，越说明你需要从Foo中把这些功能提炼出来放到其它地方。
在数据库中观察集成测试效果
费用： $20
集成测试应该通过UI来验证。不要去窥探数据库。
注释
费用： $200/行
一千个注释中顶多只有一条有合理存在的理由。其它的你应该改进代码，直到不需要注释。
注释中包含 TODO 或 FIXME
费用： $500/行
我不在意代码分支中存在不多的TODO注释，但绝对不要把它们合并的代码库中。“FIXME”实际上是“fu ck you”你的同事。
无意义的命名
费用： $50/代码审查者的疑惑
一定要努力努力好好给代码命名。当系统有变化时及时修改、改进你的命名。当发现有更好的名称时，不要等待，立即换掉。
静态方法或类方法
费用： $50/个
Ruby里的类方法具有 可变全局状态。想办法重构它们。
不必要的属性状态变化
费用： $100/变化
与其修改一个现有的记录，不如创建一个新的，或return一个。与其删除，不如做标记。Rich Hickey 对此 有一些你值得一读的思考。
一个类有多个职责
费用： $200/额外职责
一个类应该只有一个职责或目的。几乎没有人因为使得类太小而出错。鉴于此，你的类很可能太大。
重复的代码
费用： $500
编程中几乎没有任何原则你必须遵守的，但避免代码重复是个例外。代码复制给维护造成困难，严重影响代码质量。
重复的测试代码
费用： $500
测试代码并不是产品代码的次要附属物。它们的质量同等重要。更严重的：维护一个糟糕的测试套件代码可能会让你欲哭无泪。
未经测试的代码
费用： $1,000/行
未经测试的代码自诞生之时起就成了负担。这样做很不专业。
感谢Paul Graham先生的“On Lisp”，本文是受他的在某些函数上收税的想法而启发。
英文原文： How much should global variables cost? / 译： 外刊IT评论
感谢 WnouM 投递这篇资讯
资讯来源： 外刊IT评论
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
相关 [质量 软件 编程] 推荐：
软件质量之道
- - CSDN博客系统运维推荐文章 我曾与一些资历非常高但毫无实际经验的人共事过，也曾与一些只有很少或根本没有资历但才华横溢的工程师一起工作过，我也曾经不得已跟一些并不想用心做事、也对学习新东西丝毫不感兴趣的人共事过. 如果说我们这个职业是一张纸，那么这些人就好比纸上的污点. 软件开发业的低劣性不能完全怪罪于那些无知的经理、狡猾的市场营销人员以及总是急不可耐的用户，实际上很大程度上要归咎于这个行业的某些从业人员，他们应该去从事一些即使玩忽职守也不会造成像软件业里这样大的危害的行当，而不应该混迹于这个聚集着人类想象力的最复杂的创造性的行业.
提高软件质量实践―― Facebook 篇
- - 博客 - 伯乐在线来源： Bill Liu 的博客. Facebook从04年的哈佛校园的学生项目在短短的7－8年的时间中快速增长为拥有10亿用户的世界上最大的社交网络，又一次见证了互联网创业成功的奇迹. 同时它的产品研发流程也成为了众多互联网产品公司的追逐对象. 今天我们来看一下facebook在产品质量控制方面的实践.
提高软件质量实践――Amazon篇
- - 博客 - 伯乐在线来源： Bill Liu 的博客（ @billliu_seattle）. 前几天回国转了一圈，做了两家企业质量管理培训，一次上海测试沙龙，和chinatest两次演讲. 回来后发现我的软件质量实践系列文章距离上一次发表已经有很长一段时间了. 我想还是先把它写完，再写别的文章吧. 那么今天我们看看互联网公司的另外一个大哥大是如何做质量控制的――Amazon..
软件构架设计--质量属性
- - 研发管理 - ITeye博客软件质量属性是影响软件架构设计的重要因素，常见的软件质量属性有：. 性能(Performance)：指的是系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数. 可用性(Avaliability)：是系统能够正常运行的时间比例 . 可靠性(Reliability)：可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维护软件系统功能特性的基本能力.
如何开发高质量软件？及软件测试观点
- - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员也许是因为我经常在twitter上鼓吹“代码质量来自code review和单元测试”，老赵的这篇文字 http://blog.zhaojie.me/2012/01/a-case-requirement-to-practice-unit-testing-or-tdd.html 也at我一下，抱歉的是最近欠债太多，正在着手完成答应侯伯薇的那篇关于appengine的文字.
高质量c/c++编程指南"读书笔记1
- - CSDN博客推荐文章一个strcpy函数的代码. (3) 算法复杂度分析(用于提供性能). 定义1：能长期稳定地编写出高质量程序的程序员称为编程老手. 定义2：能长期稳定地编写出高难度、高质量的程序与称为编程高手. 1.1 版权和版本的声明. 版权和版本的声明位于头文件和定义文件的开头，主要内容有：. (2) 文件名称、标识符、摘要.
[译稿]软件编程21法则
- Alan - cnBeta.COM任何一个有经验的程序员都知道，软件开发遵循着一些不成文的法则. 然而，如果你不遵循这些法则也并不意味着会受到惩罚；相反，有时你还会获得意外的好处. 下面的就是软件编程中的21条法则：.
如何提高你的软件质量?去找一个旧电脑吧.
- 疯癫二楞子 - 译言-电脑/网络/数码科技来源How to Improve the quality of your software: find an old computer. 你的用户将会很高兴因为你的东西在他们的烂机器上表现得很好(而那些潮用户也会很高兴.). 你的老板也会很高兴因为他收到了很少来自用户的抱怨.比如必修升级他们的硬件或者软件才能使用你的程序..
开源软件质量报告：连续两年高于行业平均值
- - 开源中国社区最新新闻开发测试服务提供商Coverity近日发布了一份开源软件质量报告——《 2012 Coverity Scan Open Source Report》. 该项研究始于2006年，最初由Coverity公司和美国国土安全部合作进行， 旨在研究开源软件的完整性，现在由Coverity公司负责进行. Coverity的扫描报告已经成为了一个衡量开源软件质量状态的被广泛接受的标准，在过去的7年时间，Coverity已经分析了300多个开源项目的超过8.5亿行代码，这些项目包括Linux、PHP、Apache等.