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

原创 2003年10月27日 02:12:00

不知道什么时候(大概是从几个台湾人翻译了他的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:

  1. 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.

  2. 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.

陈省身文集28——我同布拉施克、嘉当、外尔三位大师的关系

 原载《科学》第38卷第4期,上海,1986年。 张奠宙教授在《现代微分几何的形成与发展》中提到我同布拉施克、嘉当、外尔这三位大师的关系。他们自然是二十世纪初期最伟大的数学家,学问广博,影响至...
  • u010401391
  • u010401391
  • 2017年01月21日 15:43
  • 468

Joel on Software 祖尔谈软件:行进中开火

行进中开火 作者: Joel Spolsky译: Siyan Li 李思延 编辑: Paul May 梅普華 2002年1月6日时不时,总有一阵儿,我什么事也干不了。 我也去办公厅,东瞄瞄,西看看,每...
  • shadowkiss
  • shadowkiss
  • 2003年10月14日 20:56
  • 971

直播系统开发:宋祖儿直播自曝“抠脚妹”

直播作为直播系统开发的新产品,吸引了几乎整个娱乐圈,连“国民妹妹”宋祖儿都被圈粉。    昨日,“国民妹妹”宋祖儿为了庆祝微博破百万粉丝,突袭某直播平台,满足粉丝们的心愿,献出了第一次直播。...
  • qq_38724956
  • qq_38724956
  • 2017年05月10日 10:04
  • 190

软件随想录:程序员部落酋长Joel谈软件(阮一峰译)-2

2. 寻找优秀的程序员       2006年9月6日,星期三 优秀的程序员都在哪里 这是你第一次公开招募雇员。如同大多数人一样,你会发布广告,可能也会浏览一些大型的网上论坛,然后你就收到...
  • tiewen
  • tiewen
  • 2013年01月18日 10:38
  • 634

The Joel Test(祖尔测试)

Do you use source control?      你们使用源代码控制吗? Can you make a build in one step?     你们一步就能完成构建吗?...
  • lanxinju
  • lanxinju
  • 2010年10月07日 12:18
  • 868

有关贝祖定理的一个小问题

有关贝祖定理的一个小问题   所谓贝祖定理是说: 两个整数 a、b 是互质的,等价于方程有整数解。  ax+by=1 当然, 贝祖定理还有一种更一般的形式,说的是两个整数 a、b有最大公因数是c,等价...
  • liyuanbhu
  • liyuanbhu
  • 2014年07月12日 22:27
  • 4591

软件随想录:程序员部落酋长Joel谈软件(阮一峰译)-4

4. 三种管理方法 2006年8月7日,星期一     如果你要领导一个团队,或者一家公司,或者一支军队,或者一个国家,那么你面对的主要问题是如何"使得人们去做你要他们做的事",更文雅的说法是如何...
  • tiewen
  • tiewen
  • 2013年01月18日 12:00
  • 365

软件随想录:程序员部落酋长Joel谈软件(阮一峰译)-7

7. 认 同 法   2006年8月10日,星期四     你想让一个团队中的所有人朝同一个方向齐心协力地工作。我已经在前面的文章中指出,军事化管理法和经济利益驱动法在高科技的知识团队中效果很差...
  • tiewen
  • tiewen
  • 2013年01月18日 12:25
  • 504

新闻祖阅读软件

最近我使用了将近十个阅读newsgroup 的软件,竟然没有一个既能正常显示不同编码的中文,又能够通过代理服务器上网的。由于我用的是gprs+笔记本上的网,中间有个wap代理服务器,好多软件不支持代理...
  • bluepowerwzh
  • bluepowerwzh
  • 2007年03月22日 10:08
  • 303

谈软件项目中的“业务”因素

写这一篇文章的初衷来自于我从一个人blog上看到的东西,他在blog上及其坚定地说了这样一句话:业务永远比技术重要。而在现实中,我也总是听到这样的声音,即决定一个软件项目成败的最大因素并不是技术问题,...
  • jayliu
  • jayliu
  • 2005年04月01日 20:43
  • 1814
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:“祖尔谈软件”——过时的悲叹?
举报原因:
原因补充:

(最多只允许输入30个字)