开发团队到底好不好,这 12 个问题能检验出来吗?

【伯乐在线导读】:「Joel 测试」是 Joel Spolsky 在 2000 年提出的 12 个问题,用来检验一个团队是否是好的开发团队。17 年过去了,Dale Myers 重新审视了这12个问题,并与时俱进地提出了修改建议。


就在 2013 年,我参加了一个课程:“软件的架构、执行和管理”。其中主题之一,就是如何评价一个开发团队?这不是一个简单的问题,如果要得到一个完整的答案,最后一定需要一些必要的研究,一篇冗长的报告。还好,Joel Spolsky 提出了12 个非常简单的测试问题,相对无痛地解决这个问题,这些问题被称为“Joel 测试”。该测试不是非常严谨,也无意于此。但是它可以为你提供坚实基础,进一步了解其他细节。

Joel 测试的优点在于:仅仅通过很小一组是非题,就可以得到需要的答案。你无需关注任何例外,或任何附加条件,只需要单纯的关注每个问题的答案是 yes 还是 no,就可以得到需要的结果: 12 分为优,11 分为良, 10 分及以下为差。这个优点并没有被我和我的几个同学忽视。我立刻将这个方法用到评估那些我面试实习的公司,以及后来毕业后第一份工作的公司。大多数雇主从来没有听说过这个测试,这倒不意外。真正令人意外的是,有多少公司没有通过该测试,而我曾认为这些公司非常棒!

我提问的不准确吗?他们真的理解我的意思吗?再或者我统计 12 个问题的时候算错了?

在面试时遇到 ”你还有什么想要问我们的吗?“ 这种问题时,Joel 测试是回答这个问题的大杀器,但是基本都没有及格的。当然,有可能刚好我面试的公司都很差劲,但是,尽管我是软件行业的新人,但是我有个感觉,事实绝非如此。我将该测试带入我的一些应用,发现我竟没有在任何地方考虑到这些问题。

那么我在 Joel 测试中出了什么问题呢?

每个开发人员都是不同的,他们对好坏都有着自己的标准,而且这个标准还会随着时间变化。Joel 测试试图规避这种偏差,用客观题替代了主观题。相信没有任何开发人员会反对,跟踪 bug 是个好想法,但是其他的问题呢?

从 2000 年发布开始,Joel 测试已经有 17 个年头了。它比 OS X 的历史还要久。在同一时期,Windows 2000 还是当时技术最高水平,PlayStation 2 刚刚发布, 奔腾 III 处理器还在 1GHz 下嗡嗡地工作。 在计算机世界里,这确实是很久以前的事了。随着处理器计算能力(还有硬件的整体性能)每18个月翻番,我们的开发进程也一同提升了。Joel 测试的问题反映了当时软件开发的时代缩影。时至 2017 年,它们就未必非常恰当了。

以第一个问题为例:

是否有源码控制?

如今最流行的版本控制系统——Git,在当时还没有出现。好吧,众所周知,Git 直到 2005 年才出现。也不要忘记,前任的版本控制系统之王——Subversion 也是到 2000 年才出现,比 Joel 测试首次发布晚了 2 个月。那时源码控制出现了,但是却不像今天这样普遍。这是不是意味着,今天还讨论源码控制这个问题显得多此一举呢?可能吧!我们应该修改这个问题与时俱进吗?也许吧!

让我们一起来看看这些问题,然后看看如何与时俱进吧。

1. 是否使用源码控制?

除了上面提到的,时至今日,这个问题似乎依然有意义。任何团队都需要源码控制,这是毋庸置疑的。如今的争议主要在是否使用集中式版本控制系统。一般的项目使用 Git 或者 Mercurial (举例来说)都可以。大型公司拥有超大型代码仓库,一般采用集中式版本控制系统。这个问题没有绝对答案。真正重要的是,有版本控制!既然这个问题已经是常识,我认为它就没必要继续存在了。

更新建议: 删除

2. 能实现一键编译吗?

Joel 的解释如下:

从最新的代码快照编译出交付版本,一共需要多少步?

其背后的原因,今天依然成立。好了,我认为这是我们对老问题的第一个挑战。我一直认为,编译交付版本,应当 0 步骤完成。持续集成已经广泛存在。使用它是非常明智的。创建一个交付版本的步骤应当这样:程序员们提交代码,当管理人员,或者其他负责人准备 release 时,他只需要点击 ”release“ 按钮即可,然后就成功了。所有开发人员只需要确保他们提交的代码无误,持续集成服务自动会完成其他工作。

持续集成系统将软件开发产业向前推进了一大步。如果我们能更广泛的使用,充分发挥它的潜力,我们将受益良多。

更新建议:所有版本,都由持续集成服务器自动编译吗?

3. 是否进行每日编译?

这个问题紧随第 2 个。如果对团队有用的话,每日编译是可行的。我一直认为每日应当是最低限度了。在我眼里更好的实践是,确保主开发分支的每一次提交,都可以正常的完成编译。这算是一种“预览”版本,同时也意味着你能更快、更有效地发现自己的问题,因为一旦发生任何故障,非常容易确认其版本。

该编译过程应当由持续集成系统自动完成。还有,你不止应当进行每日编译,而且应该使用它们。当然,如果你开发那些与你日常工作无关的软件时(定制或者专业软件),很难做到这一点。比如你在开发一款会计软件,或者火箭控制程序,显然你不可能使用这些产品。然而,我的建议是,每天至少花20分钟看看你的软件,试用一下,确保一切正常。假如你开发的软件每天都能用得到,那就更好了。它的作用与前面提到的 20 分钟试用一样,但在实际操作中,你可以进行远超 20 分钟的测试,使项目暴露在更加真实的场景下。

更新建议:是否执行每日编译,并使用这些版本?

4. 有无 bug 数据库?

当然啦,你应该使用某种 bug 数据库。你听说过任何人认为没这个必要吗?如今发生变化的是,bug 跟踪有了更加丰富的特性。它们已经不再单单是一个数据库表的接口,而是拥有丰富功能的规划、管理程序,通常在任务和 bug 之间有显著区别(参考第 5 条)。

如今,当你提交一个bug时,它有标题、描述、复现步骤、影响平台等等信息,一般都是如此。如今不同的是,管理将贯穿你的 bug 处理,bug 会被分派到若干迭代中,你需要利用看板规划任务,你的敏捷开发组长会就那些有困难的任务与你进行谈话。

问题跟踪器也不仅仅是记录需要做的事。它包含谁执行了操作,对团队的影响,对产品的影响,以及其他上百个属性。那么,我认为你应该有某种软件来做这些事情,这都不重要,它就是你的某种问题跟踪器。因为各个团队的情况有所差异,这个问题也没有确切的答案。我所做的一点调整,只是为了用文字的一点不同,来反映我们现有的能力。

更新建议:你是否使用问题追踪器(issue tracker)?

5. 在编码前是否解决bug?

Joel 对这一点的重要性给出了非常好的论述,17 年后的今天,它依然成立。

更新建议:无

6. 是否有实时更新的计划表?

作为开发人员,你可能没那么关心计划表。如果你的团队没有在按时完成任务会怎样?不是你的问题吗?把这个问题留给管理人员吧!

留个管理人员,也许有用,也许没用。如今,我们有各种敏捷开发理论,从开发人员,或者其他任何估时比较靠谱的人那里,得到的项目预估,是进行项目规划的关键要素。这帮助我们安排团队工作、谁来做这些工作,以及何时做这些工作。你可以掩耳盗铃,假装事事与你无关,但是最终,每一个人都需要对整个团队有一份责任。

这一条今天还有效吗?必须的!当然了,我们已经不用瀑布流了。确保准时达到测试阶段,对我们已经没有太多意义了,但在敏捷开发(很多人深信,跟“现编现造”一个意思),特别是敏捷开发,计划表是最重要的,而且需要时刻保持更新。如今不同的是,计划表会根据新信息,保持更新。

更新建议:无

7. 是否有文档?

计划表那一条完整的被保留下来,文档却未必同样走运。在瀑布流流行的时候,文档是你了解开发目标的关键。如果你无法有效调配资源,那么你的项目,注定会失败。

回到 2001 年,当你创建一个程序时,无论是一台咖啡机,一台火箭,或者只是一个简单的 CRUD(Create、Retrieve、Update、Delete等) 界面,你都很清楚需要做什么,以及大约需要多少开销,逐步实现它。开发人员、测试人员、项目管理人员各司其职,大家全程根据文档展开工作,测试,交付,然后进入下一个项目。而今,在很多方面已经不是这样了。当然了,如果你还在开发上面提到的东西,情况就基本没什么变化。但是,如果你在开发 Twitter 客户端呢?或者文本编辑器呢?再或者邮件客户端?以前的老方法还依然有效吗?通常不是。

只有当你可以从一开始就获得所有信息,并用来完成规划,文档才是有效的。当你的软件需要持续开发时,文档只在 MVP(Minimum Viable Product,最小可行产品)阶段比较重要,在此之后,它的用处就很小了。要让文档在今天依然保持重要性,就必须实时更新信息,并相应地适应当前进度和产品情况。

这里所谓的信息,可以通过很多形式获得。可能只是简单的模拟用户如何使用APP,或者应该更进一步,如果可能的话,应当对新特性和设计进行 A/B 测试。

更新建议:是否有关于产品功能和使用相关的最新信息?

8. 程序员有安静的开发环境吗?

当回想八九十年代的软件开发环境,一片小隔间的海洋就会进入脑海。如今,情形基本没变,唯独发生变化的是,隔断变得更小了,或者隔断在所谓的“开放式”办公室里,直接消失了。

我个人而言,我并不喜欢开放式办公室。我喜欢自己的办公室,我就可以拥有单独的开发时间,完全看我的喜好,我可以打开音乐,让我步入状态。然而并不是所有人都同意我的观点。我知道很多人喜欢开放式办公,这样更加有效率,促进团队成员之间直接沟通,通常可以获得更快、更好的问题解决方案。

这条规则对工作环境的要求,并不是什么特例。开放式办公室,通常比你自己的办公室更加嘈杂。每当有人问起关于开放式办公室的噪音问题时,我通常的解决方案就是带上耳机。通过消音技术,基本能解决绝大多数问题。这是我平常在开放办公室的办法。

总之,安静的工作环境,无非就是独立办公室和开放办公室之间的取舍,这两个也没有孰优孰劣。

( 《国内程序员的办公桌是什么样的?》文中黄钊的晒图 )

更新建议:删除

9. 是否使用市面上最好的工具?

这一条是最难取舍的,事实上我是写完本文其他部分以后,才回头写这一部分。

我通常遇到的情况是这样的,公司无法负担市面最好的工具。也就是今天无法负担而已,不代表以后不行。我认为这一条规则的精神依然是成立的。公司应当有义务,尽可能保证开发人员的工作惬意、开心。愉快、宽松的程序员会生产更好的代码。

有一点一定要切记,这并不意味着必须要用重金砸向这些问题,如果优秀的工具是免费的,那肯定还是要用免费的。

 

(《国外程序员的办公桌是什么样的?》,网友「土豆」晒图)

更新建议:无

10. 是否有测试人员?

不同公司在测试方面是有区别的。几年前,就在我还是个实习生,到成为全职之间那段时间,微软复用工程师作为测试人员。我曾撰文说明,为什么我认为微软复用开发和测试人员,很好的说明我作为实习生浪费了多少资源,还消除了曾鼓励我编写更好代码的安全网。现在这都在微软得到印证,我们还是看看 Joel 对此是怎么说的:

如果你的团队没有专业的测试人员,至少每 2~3 个开发人员一个测试人员,你要么会交付缺陷产品,要么你让时薪 $100 的开发人员,去做时薪 $30 测试人员的工作。

我和 Joel 观点的主要不同是,对于微软而言,开发人员和测试人员是一样的,开发人员的薪酬并不是测试人员的 3 倍。测试人员花费时间,遍历代码变更,确保提交的修改可用,而且没有引入新的问题,这些都与开发人员的时间一样有价值。当然,这也算安全网。

拥有测试人员是很好的选择,但是 Joel 提出了更好的观点,那就是,你千万不要浪费测试人员的价值。

开发人员需要对自己的代码负责。如果你不是特别确信自己的代码无 bug,就不应当提交。这意味着你需要进行人工测试、单元测试、集成测试等等。既然在未进行代码 review 之前,代码是不可提交的,那没有进行测试,又怎么可以提交呢?

测试人员不需要遍历每一个变更,但是他们需要确保,产品作为一个整体依然是稳定的。他们应该能将他们的时间投入测试模型,这远比开发人员更加有价值。有测试人员并不是最关键的,有完整有效的测试计划才是。

更新建议:是否有完整的测试计划。

11. 新员工面试时写代码吗?

当你在很多类似 Hacker News,或者一些  Reddit 之类开发网站搜索关键字“面试”时,结果中的文章有多少对现在的面试流程是正面评价呢?非常少!每个人都很清楚,现在的面试系统很烂,我们需要更好的选择。在某人想出更好的之前,就当现在只有这么一个办法,虽然看起来不像什么好点子,我们就将就一下吧。

目前有如下一些不同的面试方法:

  1. 白板面试。
  2. 做一个家庭作业式的小项目。
  3. 到公司来,与我们一起工作 6 个月,作为试用期。

有件事我们都有共识,开发人员应该编码。既然这是他们的工作,那你就应该在这方面测试他们。就不要用查找特定的语法错误这种问题来为难他们,也不要让他们选择你的团队的工作语言了,只要确保他们可以编码即可。

就像我们前面看到的,这一条也是非常常识的问题,我觉得就没必要继续保留了。

更新建议:删除。

12. 是否进行走廊可用性测试?

这是一条鲜为人知的规则,我们看看 Joel 的定义:

走廊可用性测试是这样的,你在走廊里,随手请一位路人,帮忙测试你刚刚编写的代码。如果如此请了 5 个人帮忙,你就可以找到代码中 95% 影响可用性的问题。

现在,如果我说走廊可用性测试是个好东西,应该不会有太多人反对吧,但是对于灰色桌面背景上的灰色工具栏,上面还有灰色按钮的情况,这就未必了。电脑用户(如今这个定义非常宽泛)通常不是特别了解其工作原理。对于专业工具,你可能需要按钮提示信息、拖拽支持、键盘快捷方式等,这样就非常棒了。然而对于 Facebook,得让你的爷爷奶奶也能用才行。这需要清晰的设计:元素之间采用高对比度,在合理的位置进行交互,还要有适合的大小。

在各种情况下,需要创建用户界面和用户体验,我所说的不仅仅是常规的 UI,而是类似“以合理的方式,控制文件保存操作”这样的事,这已经不是一个开发人员能做到的了,应该由专业人员来做。现在这是专业的 UI 和 UX 设计师应该掌握的一种专业技能。

更新建议:是否有专业的 UI 和 UX 设计师?

现在我们看看「Joel 测试」变成什么样了:

我们砍掉了部分规则,修正了其他的。但是这还没完。这只是我们如何修改已有规则,使之与时俱进,但是我们还需要新增一些如今非常重要的规则。

新增的 3 个规则

所有代码都经过 review 了吗?

每个人都会犯错,无论你是刚刚毕业的新人,还是身经百战的编程老司机,你都会犯错。我们总是过于依赖编译器帮我们发现错误,这并不是编译器的正确使用方法。这就是我们需要“测试”的原因。但是测试也可能失效,我们不能 100% 依赖它。对你的代码擦亮眼睛,能让你发现平时未发现的东西。除此之外,这还能让你的代码与团队代码风格保持一致,编译器通常不具备这样的能力(代码检查这个主题,我们换个机会再谈)。一致性良好的代码,可以方便团队成员阅读、使用你的代码。

是否有编码标准?

这条规则与上面一条相互依存。编写代码非常重要,但是最终你需要能重读你的代码。很遗憾,现实并不是这样。所以,我们应该尽可能让代码易于阅读。首要任务就是,保证代码库的一致性。通过制定一系列规范,在团队内贯彻,令代码易于阅读和理解。在代码库中搜索最常用的模块、类型等等,清晰定义期望的代码风格,帮助新进开发人员逐步跟上进度,这比在开发过程中一点点明确风格要好的多。也可以在持续集成系统中,增加自动代码检查工具,推进这些代码规范。

新员工是否有培训?

这看起来显而易见,但事实上却并不常见。很多新进开发人员,加入一家公司,就立刻被投入深水区。这个过程对开发人员和公司,都是浪费。有一些会试着游起来,但是绝大多数会沉没。当你加入一家公司后,你应当获得工作所需的一些必要信息。我并不是说你应该在一间会议室里待一周,学习 HR 课程、聆听 VP 的宣讲,这确非我的本意。实际上你应该获得你所工作系统的文档,并且,有一位团队成员,给你当一段时间导师,以帮助你尽快跟上进度。没错,这意味着这个开发人员可能在培训阶段的输出会有所减少,但是在此之后,你就获得了两个开发人员,任何会算数的人,都会看出来,这事一笔值当的投资。

结语

那么,我们看看我们 2017 版 “Joel 测试”是怎样的:

好棒耶!让我们喜大普奔地照办起来吧。

还是不要了!该测试不是万金油,只是个指导意见。它是一个指导系统,而非一套完整的评估系统。一个得到满分的企业,依然可能是一家不宜工作的地方。当然,如果一家公司连 10 分都拿不到,那这是家不靠谱的公司基本没跑。只要确保你的雇主能获得 11~12 这样的高分,然后根据自己的判断来。千万不要迷信!

2 7 收藏 评论

关于作者:alvendarthy

一个热爱生活的家伙! 个人主页 · 我的文章 · 15

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部