“祖尔谈软件”——过时的悲叹？

不知道什么时候（大概是从几个台湾人翻译了他的weblogs开始吧），“祖尔谈软件”似乎受到了越来越多程序员的青睐。不过，说实话，我很反感这位祖尔的论调。看看这段话吧：

“不管怎么说，我不认为Extreme Programming是在鼓吹零设计的理念。他们只是说：“不要作任何无必要的设计”，这没有什么错嘛。但人们听到的并不是这样。大多数程序员是在找不用设计的借口，所以他们像飞蛾扑火般投向“不用设计” 这个馊主意。这是一种奇怪的，让你事倍功半的懒惰方式。我懒得先在纸上把这个功能给设计好了，所以我就先写程序，然后发现不对，我就去改，结果反倒花更多的时间。或者，更经常发生的是，我先写些程序，发现它不对，但是没时间改了，结果我的产品质量低劣，而且我还是要找出些借口，说明它为什么“一定要那样“。那只不过是马虎潦草，缺乏职业精神。”

yuck，这位XP的批评者真的知道XP是在干什么吗？他批评的不是XP，只是他心里想批评的东西而已。不过我不想再多说什么，Cameron Purdy对他的评价更加恰当：这是一个停留在C++年代的程序员。也许，他只是（不巧地、不幸地）在Java或者C#里遗传了C++的语意，并发出了一些过时的悲叹。

————————

Poor sod ..

JoelOnSoftware used to be a really good read. Lately, it's been JoelOnJoel, and throw in some of that 1990s programming stuff just to sound technical. Take today's post as an example:

... I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:

They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn't reveal potential bugs.

They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.

A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be.

I'm speechless. (Well, that's not very likely. What I mean is that this guy is waxing clueless.) Let me start by saying that I like his rationale: Unknowns can lead to bugs, and by making everything known, bugs can be eliminated. I mean, come on, who doesn't want to exterminate entire families of bugs? I've coded reams of C++ code that did exactly Joel suggests, and he's right, being extra-anal with immediate error handling and well designed unambiguous return values does improve the quality of code. In C++.

Of course, maybe Joel is still coding in C++. Obviously, he's not coding in Java, which he likes to talk about in the article. The thing is, in Java, which is what most new projects are being built in (or it's cousin C# for Windows shops), using return values as he describes is an anathema. Reading his blog, I feel like how I did back when C programmers were trying to tell me how to build COM applications in C++ .. in fact, his code examples look like they are straight out of a "How to Code Windows NT 3.1 applications in C" book and would even make good examples for "Writing Solid Code" -- if it hadn't already been written 10 years ago, that is.

I wouldn't have had a problem with what he wrote, if he could have stopped with "C/C++", but he somehow assumes that since Java (also C#) generally shares the C/C++ syntax, that it must suffer from the same weaknesses. Java was designed from the ground up around good exception handling; it's not a glue-on long-jump afterthought. With these modern languages, exceptions are generally exceptional, which is to say that just about any line of code can theoretically throw an exception (I use the term "exception" in the loose sense that includes an "error" in Java), and the behavior of exceptions is very well defined and fairly logical.

Even catching all possible exceptions where they occur in Java is basically impossible .. by design. It reflects reality, instead of (as in C++) the assembly code that the source code generates. Furthermore, in Java, if you will purposefully throw something, you get to declare that exception as a checked exception, largely mitigating one of Joel's other concerns. (In C#, there are no checked exceptions, but you can still write comments saying what your code throws, which is a reasonable trade-off for being able to build Windows Forms in COBOL.)

So do yourself a favor: If you're coding in Java or C#, ignore his advice. The 90s are over and have been for a couple years. I don't like to have to explain OO to C coders (they still say "What's the big deal? I can do all that with structs and function pointers!") and I don't want to explain modern exception handling to people polluting their code with reams of brittle "if" statements under some delusion that they are actually handling exceptional conditions.

“祖尔谈软件”——过时的悲叹？相关推荐

Joel on Software 祖尔谈软件:行进中开火 (转)
Joel on Software 祖尔谈软件:行进中开火 (转)[@more@] 行进中开火作者: Joel Spolsky 译: Siyan Li 李思延编辑: Paul May 梅普華 200 ...
Joel on Software 祖尔谈软件:行进中开火 shadowkiss
为什么80%的码农都做不了架构师?>>> http://chinese.joelonsoftware.com/Articles/FireAndMotion.html Fire ...
Joel on Software 祖尔谈软件:行进中开火
行进中开火作者: Joel Spolsky 译: Siyan Li 李思延编辑: Paul May 梅普華 2002年1月6日时不时,总有一阵儿,我什么事也干不了. 我也去办公厅,东瞄瞄,西看看 ...
[转载]与大学生谈软件外包
作者:崔启亮, 原始出处:软件质量研究网www.sqstudy.org 目前已经进驻上海的知名全球服务外包企业包括埃森哲.优利.NCS.博朗.爱特优科等目录: [0] - 为什么要对大学生谈软件外包 ...
浅谈软件性能测试中关键指标的监控与分析（转）
浅谈软件性能测试中关键指标的监控与分析一.软件性能测试需要监控哪些关键指标? 软件性能测试的目的主要有以下三点: Ø 评价系统当前性能,判断系统是否满足预期的性能需求. Ø 寻找软件系统可能存在 ...
「软件项目管理」一文浅谈软件项目风险计划
一文浅谈软件项目风险计划序言一.风险基本概念 1. 风险的定义及特性 2. 风险三要素 3. 风险图示 3. 风险类型 (1)预测角度 (2)范围角度二.风险管理过程三.风险识别 1. 定义 ...
对话：与印度第一大IT教育培训公司CEO谈软件
对话:与印度第一大IT教育培训公司CEO谈软件印度软件业的蓬勃兴起,是这几年来最为中国软件人津津乐道的话题.人们既兴奋,又多少有些紧张地注视着印度.印度软件业的崛起,已经是一个既成事实.中国软件业, ...
浅谈软件开发工具CASE在软件项目开发中发挥的作用认识
浅谈软件开发工具CASE在软件项目开发中发挥的作用认识内容摘要:阐述了CASE工具作为一种开发环境在软件项目开发中所起到的开发及管理作用.CASE工具实际上是把原先由手工完成的开发过程转变为以自动 ...
java学习方法-浅谈软件开发的神速进步
中国人大都喜欢用武侠小说来比较软件开发,但是在实战武功中,只有葵花宝典才是最厉害的,也只有掌握了葵花宝典,才能称为"不败". 1浅谈软件开发的神速进步 1.1什么才是软件开发的葵花 ...

“祖尔谈软件”——过时的悲叹？

“祖尔谈软件”——过时的悲叹？相关推荐

最新文章

热门文章