The Way To Great

Joel on SoftwareChoosing a language选择一门语言by Joel SpolskySunday, May 05,2002 Why do developerschoose one programming language over another for a given task?为什么对一项给定的任务，开发者会偏向于选择某一门语言？我啥事也

但是一旦你开始在大一点儿的团队，团队里有多个开发人员和测试人员，你还是会遇到相同的循环，更大而已（朋友，这就跟分形一样）。测试人员发现了代码的错误，报告了错误。程序员修复错误。测试人员获得修正的代码要多久？在有些开发机构里，这个报告-修正-重新测试 循环能花上几个礼拜， 这意味着整个组织的运行都很低效。为了让整个开发过程运行得很平滑， 你应该专注于精简 报告-修正-重新测试循环。

你从那些确实编写规范的团队听到的最大抱怨就是“没有人会读规范”。如果没有人阅读规范，那么写规范的人就会有点儿愤世嫉俗。就像迪尔伯特漫画里描绘的那样，工程师们使用一摞摞4英寸厚的规范来扩展他们的工作隔间。在你们那些大的，官僚作风的典型公司，每个人都会花数月来编写无聊的规范。规范一写完就会被放到架子上去，再也不会被拿下来，而产品则是从头做起绝不会参照任何规范的描述，因为没有人阅读规范，因为规范是如此的让人头皮发麻（无聊，愚蠢）。编写规范的过程也许是个很好的训练，因为它让每个人至少去仔细思考这些问题，但是规范完成

既然你已经了解了为什么你需要规范和规范包含了那些部分，让我们聊聊谁应该写规范。谁应该写规范。让我先给你讲一点微软的历史。严格来说，20世纪80年代的微软开始增长的时候，每个人都读过 人月神话 ，软件管理的经典之一。（如果你没读过，我极度推荐你去读读。）那本书的主要观点是当你往一个延迟的项目加派程序员的时候，项目会延迟的更多。 因为当你的团队里有n个程序员的时候，沟通路径为n(n-1)/2，以O(n2)渐进速度增长。因此微软的程序员担心如何来编写越来越大的程序，因为那个时候盛行的观点认为往项目加派程序员

这系列的文章是关于功能规范的，不是技术规范。人们会把这些混淆起来。我不知道是不是有什么标准的哦术语，但我用这些称谓的时候意思是。 功能规范完全从用户角度描述了产品如何工作。它并不关心具体实现是什么样子的。它讨论的是功能，它会制定屏幕，对话框，之类的。 技术规范描述的是程序的内部实现。讨论了数据结构，关系数据库模型，编程语言的选择以及工具，算法之类的。

“现在几点了.com”是一项通过网络告诉人们现在几点了的服务。这份规范，从来没有想过要是，完整的。 所有的措辞在敲定之前都需要修改几遍。图形和屏幕的布局只是为了展示相应的功能。实际的外观会逐步通过迭代的用户反馈输入由图形设计师设计完成。这份规范不会讨论时间计算引擎算法，这些算法将在其他地方讨论。本规范只讨论当用户和“现在几点了.com”交互时候的用户所能看见的东西。麦克是个业务繁忙的执行董事。他是一家很重要的大公司的总裁，该公司主要为儿童生产基于炸药的产品，这些产品会通过全国连锁店如 Toys‘R’

为什么人们不写规范？他们会宣称因为他们跳过了书写规范阶段从而节省了时间。他们觉得似乎书写规范是只有NASA宇宙飞船工程师，或者是大保险公司的员工才能享用的奢侈品。胡说八道。首先，不写规范是你在软件项目中承担的最大的不必要风险。就跟仅穿着你身上的衣服然后想着“飞过去”去穿越莫哈韦沙漠一样蠢。不写规范马上钻到代码里的程序员和软件工程师会把自己想象成很酷的神枪手，从关键部位开始设计。不是这样的，他们会非常低没有效率。他们会写出糟糕的代码并且会写出以次充好的软件，他们的行为给他们所在的项目带来了完全没必要的巨大风险

所有软件开发者绝对，一定，必须，至少要知道的Unicode和字符集（没有任何借口）我很失望的发现原来那么多的软件开发者对于神奇的字符集，编码，Unicode等等东西的了解真的并不是那么到位。几年前，FogBUGZ的beta测试员很好奇能不能处理进来的日文电子邮件。 日文？他们还用日文写电子邮件？完全没概念。 当我仔细的分析了我们使用的用来解析MIME电子邮件消息的商业ActiveX控件之后，我们发现它对于字符集的处理完全是错误的。所以我们只好英勇地先撤销它做的错误转换然乎再正确的转换一遍。我看了另外一个

Joel on SoftwareThe Joel Test: 12 Steps to Better CodeJoel测试：12步写出更高质量代码byJoel SpolskyWednesday, August 09, 2000Have you ever heard of SEMA[w1] ? It's a fairly esoteric system formeasuring

软件开发人员实在是不喜欢定计划。他们通常会尝试不做计划。他们会说“做好的时候就做好了！”，期望这样勇敢，幽默的台词会让老板付之一笑，在随后的愉悦中，软件计划就被忘到一边了。你通常看见的计划大都是漫不经心的产物。他们被存在某个共享的地方然后就完全被忘记了。当这些团队两年后发布产品的时候，那个守着文件柜的怪人事后就从他的办公室拿出了那份老的打印版，然后每个人都开始大笑。“嘿，看，我们当时居然允许花两个礼拜时间用Ruby来重写！”。