在我的唯一(1-3小时)会议期间,我应该问以前的开发团队?

时间:2009-06-24 14:42:36

标签: ruby-on-rails ruby

有Ruby on Rails(1.8,2.3.2)项目。项目的第一个版本是由某个组织制作的。我将在没有该组织的任何帮助的情况下实现该项目的下一版本。我将能够在会议期间(1-3小时)与之前的开发团队的开发人员交谈。

项目统计:~10k LOC,1.0 / 0.6代码测试比率,rspec

您可以建议询问有关项目的哪些问题?

9 个答案:

答案 0 :(得分:41)

首先检查整个项目并尽可能地弄清楚,以便您有上下文,并且能够真正了解他们告诉您的内容。

  • 如果您可以录制对话
  • 有关架构概述
  • 为什么他们在另一个
  • 上做出某些架构决策
  • 依赖项的完整列表(如果您无法自行解决)
  • 最大的问题是什么
  • 项目的哪些部分始终/永远不会被修复
  • 项目的致命弱点
  • 什么会引起最大的麻烦
  • 存在哪些安全问题以及修复它的限制因素
  • 如果你是我,你会做什么?
  • 你应该知道你没有问过(最重要的问题)

此外,不要评判,你希望他们揭示他们所知道的任何问题。他们很尴尬的应用程序可能有很多问题,你需要尽早知道。如果他们不信任你,他们就不会向你敞开心扉。

答案 1 :(得分:4)

我会要求代码演练。不是逐行,而是更多的是项目的整体结构,各个模块之间的关系等。

答案 2 :(得分:3)

找出为什么。在代码库中如何容易看到,但为什么有时候无法弄明白,并且会在屁股中咬你。

例如......

应用程序的哪些部分是最大的性能问题?哪些问题得到了解决?还有哪些问题?

为什么选择模式/工具/库x?您还考虑了其​​他什么?为什么呢?

希望如此。 (打一些木头。)帮助你避免不得不跋涉同样的学习曲线和第一支球队必须处理的错误,并且应该让你很好地了解第一支球队实际做出糟糕选择的地方,而不是制造一个选择基于你尚未考虑的因素。

答案 3 :(得分:2)

询问新功能是否会对现有代码(架构上)造成任何重大更改,以及该应用程序的其他相关部分的含义是什么。

也可以收到他们的电子邮件,因为您会有更多问题。

答案 4 :(得分:1)

在我看来,最重要的事情之一是在与他们会面之前获得尽可能多的技术文档。您应该尽可能地告知会议,这样您不仅可以了解最需要关注的领域,还可以了解一些子系统如何相互关联的预先知识。

另外,如果有机会,不要害怕问他们会做些什么不同的事情。一些最好的想法在开发过程中来得太晚了 - 无论是图书馆的可用性,需求的变化,团队的变化等等。

答案 5 :(得分:0)

带上饼干(或适当的披萨,啤酒或葡萄酒);当你打电话问候时,你会希望他们对你有正面的回忆。

修改:以问题的形式回答:“我可以为您提供自制饼干吗?”

答案 6 :(得分:0)

也许你已经这样做了,但我确保你可以:

  • 查看最新版本
  • 运行所有迁移
  • 运行所有测试
  • 部署(即使是登台服务器)
  • 在本地运行应用程序

在你去参加会议之前,你可以确保在结束之前就可以。

答案 7 :(得分:0)

其他可能有用的东西

  • 数据模型
  • UI线框
  • 错误跟踪器数据/问题跟踪器数据
  • 谁是代表客户的客户/人
  • 开发环境配置
  • 源控制位置等
  • 特殊配置设置的说明

答案 8 :(得分:0)

哇!所有伟大的答案,直到饼干。

我的贡献假设这是您唯一的机会访问旧的开发团队,因此您需要提升一个档次:

  1. 议程。将会议分成几个部分,例如:

    • 快速(15分钟)介绍和拱门概述
    • 与团队成员一对一。
    • 将评审作为一个小组等进行设计
  2. 正能量。特别是如果这种关系本来就很困难,可以通过假设保持积极的关注:你将在下一个版本中进行哪些改进 - (重写不是一个选项,正确的Joel) - 捕捉每一个细微差别,并向下钻取他们的舒适程度端。

  3. <强>主持人即可。使用训练有素的设计会议主持人。他们可以帮助准备会议,进行会前面试,设计议程。在会议期间,他们可以提高强度,并保持焦点。他们还可以建议捕获可以提供大量信息的形式。

  4. 此外,我会尝试在代码之外识别所有设计工件(如果有的话),并了解其准确性。这可能包括对竣工系统进行这些文件关键要素的设计审查。

相关问题