Joel on Software

Joel on Software   周思博趣谈软件

 

其他文章(简体中文)

其他文章(英文)

与作者联系(英文)

 

给计算机系学生的建议
2005年1月2日

大多数锐气十足的学生从来不向前辈征求意见。在计算机科学领域,这样做是正确的。因为前辈们很可能说些“在2010年前,市场对于那些只会敲击键盘的代码工人的需求将会超过一亿(因此前景是乐观的)”,或者诸如“Lisp语言现在真的很热门”。

看起来简单, 实际上复杂
2002年3月4日

事情没有看起来那么简单,再加上减低风险性的指导思想,只能让你得出如下的结论:

 

 

先设计再编程序,先思而后行。

行进中开火
2002年1月6日

按步就班并不难。通常我一天是这样度过的:1,去上班。2,查电子邮件和上网等等。 3,考虑是否应该吃完中饭在开始干活。4,吃完中饭回来。5,查电子邮件逛网。6,终于决定应该开始工作了。7,查电子邮件逛网,东瞄瞄,西看看。8,再次决定确实应该开始开始干活了。9,打开该死的编辑器。10,一直会些程序学到晚上7:30,写到忘记时间。

在以上第8步和第9步之间似乎有点缺陷,因为我不是每次都能顺利地执行下去

第四战略篇:膨胀软件与80/20的谣传
2001年3月23日

膨胀软件的存在是有道理的。最起码的,如果程序员不用担心软件的大小,那么软件就可以早点出版。用户可以早点得到更多的功能。这些功能用时有益,不用时无害。

每日构建(daily build)是你的朋友
2001年1月27日

当你使用版本控制来管理源代码时,一个程序员偶尔会导入(check in)代码以至你构建失败。例如,他们新增了一个代码文件。在他们本人的机器上一切OK,但是他们忘记把这个新增的文件导入(check in)到版本控制服务器上了。 于是破坏构建的罪魁祸首高高兴兴的回家了。别的程序员由于构建失败以至无法继续工作,也闷闷不乐地回家了。

导入代码破坏构建的结果非常严重(但是又发生的很频繁),于是每日构建(daily build)自然而然地产生了。这样任何人的任何导入代码如果破坏了构建都会被尽快发现。对于大的团队来说,每日构建最好在午餐 时间进行。每个人都在吃中饭前导入(check in)代码,当他们吃完饭回来时,构建应该已经结束了。如果构建成功,好极了!每个人导出(check out)最新的代码继续开始 工作。如果构建失败了,某人来修正它。但是别人可以使用前一个构建成功的代码继续工作。

在微软的Excel团队,我们又一个规矩,谁破坏了构建,他(她)就是负责照看构建过程作为惩罚,知道他找到下一个接替者。这是个很好的办法,没有人原意破坏构建而接受惩罚,同时被惩罚的人也有机会学习每日构建(daily build) 

在我的最新的文章每日构建是你的朋友 中有更多的描述。

The Joel Test: 软件开发成功 12 法则
2000年8月9日

有没有听说过SEMA?这可是衡量一个软件开发组好坏的很深奥的系统。别按那个联接! 给你六年你也搞不清这玩意。所以我自己随便攒了一套衡量系统,信不信由你,这系统,三分钟就可掌握。你可以把省下的时间去读医学院了(译注:美国的医学院可是要读死人的!)。

轻松面试找到理想员工-非官方的面试技术指南
2000年3月23日

Fog Creek公司最重要的雇佣标准是:

有头脑, 并且
完成工作

就是这些了。




Joel Spolsky 是纽约市一家小软件公司,Fog Creek Software, 的创始人。他毕业于耶鲁大学,曾在美国微软公司,Viacom,  Juno 任软件设计师及经理。


网页内容仅为个人意见
©1999-2005 Joel Spolsky.  版权所有 保留所有权力

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky