资讯频道 → 研发管理
阅读更多

11顶
6踩

研发管理

翻译新闻 商业项目中代码质量是否重要？

2012-09-27 16:07 by 副主编 wangguo 评论(41) 有19331人浏览
开发 代码质量 敏捷开发 项目流程
这是一篇比较老的文章，但是文中的这些问题在现在仍然普遍存在。代码质量的高低与商业产品的优劣是否有直接的影响？开发者Frank Sommers在文中给出了他的看法。文章内容如下。

在大多数商业项目中，代码质量并不被看重，因为大部分情况下，代码不是整个项目的最终产品，客户最终使用的是二进制文件，而不是源代码。相比代码质量，开发流程、进度和技能更能决定产品最终的质量。

在现实生活中，我几乎从来没有遇到一个对他所工作的代码完全满意的商业软件开发者。相反，我甚至认识到，开发者对其所工作的代码的满意度与代码给老板所创造的价值成反比关系。

我的一个朋友在世界上最大、最赚钱的数据库公司的核心服务器组件部门工作，他时常感叹庞大的代码库中那些丑陋的命名约定，对于开发者来说，很难在这些代码的基础上开始工作。但是，不可否认，就是这些丑陋的代码库为该公司创造了高达数十亿美元的收入。

不幸的是，开发者一边感叹着代码质量，一边还不得不继续做这项奇怪的、与众不同的工作。说这项工作与众不同，是因为用户不能从最终产品中直接看到你的付出。如果你是一个音乐家，你可以根据自己的喜好来塑造每一个音符和乐句，并直接呈现给听众。如果你是一个木匠，你的产出是实际的椅子或橱柜。

但是作为一名开发者，除了你工作的开发环境和开发团队外，你几乎没有留下什么东西。客户看到的是二进制文件，而不是你的源码。除非你的产品是开源的，或者包含源码文件，否则，除了开发团队的人外，几乎没人看到或者关心这些代码，而你每天在这些代码上花费了大量宝贵的时间。

大多数编译器也不关心代码的质量，比如，变量如何命名、方法是否简洁、对象模型是否清晰、甚至不管你使用了什么算法，编译器对这些都没有兴趣，无论代码是优雅还是丑陋，都能创建出效果相同的二进制文件。比如，当你阅读这篇文章时，你根本不会考虑当前页面源代码的质量。

当然，作为开发者，我们必须关心代码质量，因为我们每天要花费大部分的时间来与这些代码打交道。而且，作为一个合格的开发者，我们应该努力打造和维护一个高质量的代码库。

我们花费大量时间来打造更高质量的代码，我们通常会说现在所做的工作将会在一段时间后带来更多的商业利益，以此来体验我们所做的努力。但是，代码质量很少直接导致任何可衡量的商业投资回报。比如我那位在数据库公司工作的朋友的例子，他认为这些代码丑陋不堪、难以阅读，但是依然能够很好地创造利益。该公司专注的是产品的整体质量，而不是代码的质量。

总体产品的质量，不是通过改善单一活动的质量就能提升的。开发者测试、敏捷开发方法、QA（质量保证）、CI（持续集成），这些所有的流程保证了最终高质量的产出。代码质量只是其中的一小部分。商业软件公司往往会更专注于产生高质量产品的过程，因为这比起强调代码质量来说，能获得更好的回报。

通常来说，产品经理很清楚以上这些内容。但是对于开发者来说，必须日复一日地工作在他们认为“丑陋”的代码基础上。这意味着，开发者注定一直无法对他们所工作的代码的质量感到满意。

原文：The Code Quality Myth
11
顶
6
踩
评论 共 41 条 请登录后发表评论
41 楼 phlsbg 2012-10-07 11:31
magichorse 写道
低能的架构+二逼的需求+弱智的用户代表+无脑的码工 这就是现在多数项目的情况。
因为公关做的好，多数的项目都顺利完成了，不过没几个人愿意去维护那些项目的。

只有少说运营不错的公司能打破这个规律。
40 楼 FlyAway2 2012-10-07 11:23
magichorse 写道
低能的架构+二逼的需求+弱智的用户代表+无脑的码工 这就是现在多数项目的情况。
因为公关做的好，多数的项目都顺利完成了，不过没几个人愿意去维护那些项目的。


你总结的太对了，很多时候确实如此！ 说到底都有错，但又几乎没人愿意认错。
39 楼 magichorse 2012-10-06 22:00
低能的架构+二逼的需求+弱智的用户代表+无脑的码工 这就是现在多数项目的情况。
因为公关做的好，多数的项目都顺利完成了，不过没几个人愿意去维护那些项目的。
38 楼 ssrtwwm 2012-10-05 10:29
个人认为最重要的是架构，代码的重复编写、冗余，是因为每个编码者对架构的理解不一样，如果架构很清晰、很详细，局部代码的质量倒不是很重要，即使出现Bug也很容易修改，重构，如果架构不好，那么代码体积只会越来越大，也就导致了代码的质量低下。
37 楼 坏孩子 2012-10-04 22:26
所以，ibm的程序跑的很慢，体积很大
36 楼 进退取舍 2012-10-04 21:28
我们基本是改bug的程序员。那个写代码噢。很多公司的代码，都是bug改bug.
有的项目，改bug改了n年，还在改。可是很奇怪的是，居然也赚钱。出产品。
程序员都在为难程序员。
不过确实，一切丑陋的代码，都起源于架构。
35 楼 KimHo 2012-10-04 09:32
white_crucifix 写道
从宏观上来讲很多差的代码质量都是由于架构引起的，架构的不理想，不清晰，往往会导致不同的开发人员理解不同，创建相似的方法，大量重复的代码等等。但是反过来看，没有一个软件从一开始就能朝准方向勇往直前。
所以最好的办法是，定期对程序进行重构，整理
但是这又是影响经济效益的
所以这就是个悖论……无解

敏捷开发的核心思想：重构
马丁福勒一直建议要不断重构，质量才能上去的。
34 楼 KimHo 2012-10-04 09:31
魔力猫咪 写道
“维护难度大并不是问题，是由于甲方还会出维护成本来维护项目，如果质量超好，反而这些软件开发商挣不到这部分钱了”
这种单纯靠内外勾结，损公肥私的，居然不以为耻，反以为荣。

我是感到无奈+天朝特色
33 楼 jywjyw 2012-10-03 11:04
niva 写道
这就好比，一场球赛，高层领导和观众只关心进不进球，不关心是否控制场面；孰不知，没有好的中场球员，有再好的前锋也没用。高层领导和观众可以不知道这一点，但是作为球员或者教练的你，如果不知道这一点，就只有输球了。

严重同意,公司是不需要关注代码质量的, 但做为架构师或项目经理, 甚至程序员都不关注代码质量, 就太不职业了
32 楼 laolinshi 2012-09-29 12:30
唔系好人 写道
michael_hy 写道
grandboy 写道
相比代码质量，整体质量更重要，现实生活中的有很大项目是工期紧导致不得不暂时抓大放小，而有些所谓的“小”在一定时期之后已经不可能得到根本性的纠正了。更有一些项目，维护难度大并不是问题，是由于甲方还会出维护成本来维护项目，如果质量超好，反而这些软件开发商挣不到这部分钱了，尤其是那些关系特别强大的企业，关系错综复杂，各方利益纠葛，软件质量只是非常小的一部分因素决定是否继续合作。

是啊，质量都好了，都没有bug了，那还怎么以维护升级的名义收费呢。

根本就不可能没有bug存在！

人无完人，根本不可能写出perfect的代码。
31 楼 dianthus 2012-09-29 11:19
确实如此。
30 楼 white_crucifix 2012-09-29 11:16
魔力猫咪 写道
这里不少人都在强调整体质量而表示代码质量不重要。但是代码没质量你哪里来的整体质量？而且又折腾什么利益纠纷。
意思是不是开发商和建筑商使用劣质建材没关系，重要的是回扣！！！住户花钱买楼，出了质量问题更好，还可以赚一笔维修费。


理想是好的，现实是残酷的。
29 楼 魔力猫咪 2012-09-29 11:13
“维护难度大并不是问题，是由于甲方还会出维护成本来维护项目，如果质量超好，反而这些软件开发商挣不到这部分钱了”
这种单纯靠内外勾结，损公肥私的，居然不以为耻，反以为荣。
28 楼 魔力猫咪 2012-09-29 11:11
这里不少人都在强调整体质量而表示代码质量不重要。但是代码没质量你哪里来的整体质量？而且又折腾什么利益纠纷。
意思是不是开发商和建筑商使用劣质建材没关系，重要的是回扣！！！住户花钱买楼，出了质量问题更好，还可以赚一笔维修费。
27 楼 kanme818 2012-09-29 10:00
gdpglc 写道
重不重视代码质量，本质上是对产品的bug重不重试的问题，对产品后期维护重不重视的问题 。另外，文中提到“他时常感叹庞大的代码库中那些丑陋的命名约定”，这里提到丑陋的命名约定，我看到了 “丑陋” 同时也看到 “命名约定”。

重要的是 “命名约定”

“丑陋” 是一个审美问题。你能说文中这家公司没有代码质量管理吗？

代码质量的标准，不要拔高，也不要说它“没用”。这是在误导别人。

代码质量并不是只是指一些命名，更重要的是合理的设计方案。

另外：这老兄说的大有同感：

引用
相比代码质量，整体质量更重要，现实生活中的有很大项目是工期紧导致不得不暂时抓大放小，而有些所谓的“小”在一定时期之后已经不可能得到根本性的纠正了。更有一些项目，维护难度大并不是问题，是由于甲方还会出维护成本来维护项目，如果质量超好，反而这些软件开发商挣不到这部分钱了，尤其是那些关系特别强大的企业，关系错综复杂，各方利益纠葛，软件质量只是非常小的一部分因素决定是否继续合作。




是的，不要只盯着代码的质量，就像井底之蛙一样。跳出代码，你会发现一个软件一个系统牵涉的东西太多了，技术方面都只是一小部分，更多的是利益牵扯。
26 楼 gdpglc 2012-09-29 09:17
重不重视代码质量，本质上是对产品的bug重不重试的问题，对产品后期维护重不重视的问题 。另外，文中提到“他时常感叹庞大的代码库中那些丑陋的命名约定”，这里提到丑陋的命名约定，我看到了 “丑陋” 同时也看到 “命名约定”。

重要的是 “命名约定”

“丑陋” 是一个审美问题。你能说文中这家公司没有代码质量管理吗？

代码质量的标准，不要拔高，也不要说它“没用”。这是在误导别人。

代码质量并不是只是指一些命名，更重要的是合理的设计方案。

另外：这老兄说的大有同感：

引用
相比代码质量，整体质量更重要，现实生活中的有很大项目是工期紧导致不得不暂时抓大放小，而有些所谓的“小”在一定时期之后已经不可能得到根本性的纠正了。更有一些项目，维护难度大并不是问题，是由于甲方还会出维护成本来维护项目，如果质量超好，反而这些软件开发商挣不到这部分钱了，尤其是那些关系特别强大的企业，关系错综复杂，各方利益纠葛，软件质量只是非常小的一部分因素决定是否继续合作。


25 楼 gdpglc 2012-09-29 09:03
从代码中，可以轻易的发现bug，通过读代码发现的bug，是很难通过测试发现的。构思简单轻巧的代码，比笨拙的代码更容易写出来，因为简单产生bug的概率也必然小。

高质量代码的好处是看得见摸得着的。
24 楼 freezingsky 2012-09-28 20:44
铁道部刚过宣传片的事，又来个3亿元的网站标价，看来真是可怜了。。。
23 楼 mfkvfn 2012-09-28 15:58
lpp333 写道
https://dynamic.12306.cn/otsweb/js/common/school_suggest1.js?version=4.1 第69行这是哪个学校，这么牛X的出现在铁道部的网站上？


晕死。都放到网上的代码，里面还有大段被注释掉的代码，而且也不压缩一下。没听说过网站优化的吗。
怪不得响应很慢，流量都被浪费了。
22 楼 white_crucifix 2012-09-28 14:44
从宏观上来讲很多差的代码质量都是由于架构引起的，架构的不理想，不清晰，往往会导致不同的开发人员理解不同，创建相似的方法，大量重复的代码等等。但是反过来看，没有一个软件从一开始就能朝准方向勇往直前。
所以最好的办法是，定期对程序进行重构，整理
但是这又是影响经济效益的
所以这就是个悖论……无解

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • delphi 中 adoquery 带参数查询的奇怪问题

    str = select * from t1 a + left outer join t2 b on a.id=b.id+ left outer join t3 c on a.id=c.id+ where c.field like :v1 ;adoquery.sql.clear; adoquery.sql.add(str) ;adoquery.parameters.paramv

  • plsql中报错argument out of range_我们是怎么发现C++异常从堆栈追踪中消失的原因的...

    每当我的程序崩溃的时候，我都会用核心转储 (core dump) 文件来找出来崩溃发生的具体位置。（关于怎么产生和使用核心转储可以看我之前的文章。）一直以来我调程序的时候都是很开心的……直到我遇到了这个新的 bug。当我把它的核心转储文件载入到 GDB 之后，我很失望地发现所有的堆栈追踪 (stack trace) 都是关于系统库的，没有一行是关于我的代码的。太长不看：那就看看这个补丁就好了。让我...

  • （转载）ADOQuery参数传递

    ADOQuery参数传递 dbgrid1.DataSource := datasource1; datasource1.DataSet := adoquery1; Value := 1221; SQL := 'SELECT * FROM customer WHERE CustNo>:Number'; adoquery1.SQL.Clear; adoquery1.P...

  • delphi去掉字段前后的引号_delphi中SQL避免非法字符,单引号（）出错的三种方法...

    由于 ' (单引号)是SQL的标准字符符号，所以在SQL语句中间遇到 ' 时要做特殊处理。1. 使用 QuotedStr 函数QuotedStr的作用是使字符串包含单引号：在字符的前后加上( ')号，因为在DELPHI中字符赋值是需要引号的比如CommandText := CommandText + QuotedStr(Edit1.Text);Sql := 'select ... ...

  • Delphi开发学习二：使用ADOQuery控件对SQL数据库表进行操作

    在delphi学习一中，已经使用ADOConnection控件设置属性连接数据库SQL了。 在这里开始使用ADOQuery控件对SQL数据库表进行操作。 首先我们在SQL中创建数据库名为PERSONNELMG_SYS的数据库，然后在这个数据库里创建USER_TABLE表，用来存放用户账户信息。 USER_TABLE表的结构如下图所示： 该表有用户名（USER_NAME） 、用户密码（USE

  • Delphi ADOQuery 的一些操作

    Prepared用来确定ADOquery是否要准备好了再查询,如设为true,则系统会先编译后再运行,在多次重复使用某一查询的情况下能有效提升运行速度,但对于只执行一次的查询反面会导致速度下降(编译会消耗时间): adoquery.sql.text:='select * from table1' adoquery.prepared:=true; while condition do adoquery.open; end; ADOQuery.Prepared属性的True/False与ADOQuery.P.

  • 参数化SQL（Parameters）使用示例

    public partial class Form1 : Form { private string connString = "Data Source=.;DataBase=TestDB;UID=sa;PWD=lwm110"; SqlConnection conn; DataTable dt = new DataTable();...

  • ADOQuery 查询 删除 修改 插入

    //利用combobox组件查询数据库表procedure TForm1.Button1Click(Sender: TObject);beginADOQuery1.Close;ADOQuery1.SQL.Clear;ADOQuery1.SQL.Add('select * from '+trim(ComboBox2.Text));ADOQuery1.Active:=true;end； //查询记录...

  • ADO CreateParameter 方法

     The CreateParameter method creates and returns a Parameter object containing the specified properties like name, type, direction, size, and value. CreateParameter的作用是：创建或返回一个新的参数对象，它可以是类似于名称、类型、尺

  • CreateParameter参数说明

    CreateParameter参数说明（ASP） cmd.CreateParameter("参数名称",类型,方向,大小) Cmd.CreateParameter Name,Type,Direction,Size,Value 数据类型（Type)的值及其意义如下： 名称值          整数值                        功能 adDBTimeStamp  

  • FreeSql v0.5.x 功能介绍

    弱类型 之前在操作实体时，必须传统泛型参数，现在可以实现弱类型实体的操作。以 Repository 为例： var repos = fsql.GetGuidRepository<object>(); repos.AsType(typeof(AddUpdateInfo)); var item = new AddUpdateInfo(); repos.Insert(item); ite...

Global site tag (gtag.js) - Google Analytics