在担任职位之前，如何确定潜在雇主守则的质量？[关闭]

根据我的经验，在您开始为公司工作之前，您没有机会查看代码库（我已经问过，出于保密原因，每个人都一直拒绝，我认为这很公平），所以在面试过程中，您是否想问最重要的问题以找出代码处于哪种状态（毕竟，如果它是狗，那么您将成为每天不得不走路的可怜的不幸者）？

更新：

清单：询问；

• 什么他们认为代码库。而且当您这样做时，请密切注意面部表情及其反应所需的时间。[阿农]
• 公司的CMM级别[DPD]是多少（如果您听到第5级的运行情况，则以其他方式运行[Doug T]）
• 他们使用什么生命周期[DPD]（如果您确实听到了“敏捷”，那就是当您开始问一些有穿透性的问题，试图通过“敏捷”来弄清楚它们是指“敏捷还是牛仔编码” [Carson63000]）
• 他们使用什么工具来评估代码质量？[DPD]
• 他们使用什么工具进行开发？[DPD]（寻找重构工具和连续构建服务器）
• 他们使用哪种源代码（版本控制）系统，以及良好的后续措施是询问为什么要使用它。[Zachary K]。
• 他们的测试程序是怎样的？[Karl Bielefeldt]（特别是对于使用模拟框架并通过已建立的框架（例如NUnit / JUnit）强调彻底的自动化单元测试的团队；不要被那些不使用测试驱动的开发TDD的团队所推迟，而是如果他们不认为测试是整体软件开发不可或缺的组成部分，请保持警惕。请寻找有专门测试人员的团队。）
• 给新开发者什么样的任务？对于经验丰富的开发人员？[Karl Bielefeldt]
• 有多少人从事一个项目？[Karl Bielefeldt]
• 是否允许重构？鼓励？[Karl Bielefeldt]
• 正在考虑或最近进行了哪些与质量相关的过程或体系结构更改？[Karl Bielefeldt]
• 个人在模块上有多少自治权？[Karl Bielefeldt]
• 您将要开发较新的项目（未开发的项目）还是旧项目（未开发的项目）？（绿地开发通常更有趣，并且问题更少，因为您无需清理别人的错误）。
• 组织或团队中员工离职率高吗？（这通常表示代码质量较低）[M.Sameer]
• 您自己的一些编程问题；但请避免看起来像个混蛋。[活泼的]
• 开发人员如何进行协作，团队之间如何共享知识？（这应该与您的个性相匹配；我想说，单人和双人工作的混合可能是最好的，比例要符合您的社交需求）
• 他们的数据库与第三范式（3NF）的距离有多近？如果偏离了何处？为什么？（如果他们说“ 3NF ???”，请离开。如果没有，并且可能有充分的理由不这样做，请找出它们是什么）。

注意： 我接受了Anon的答案，因为大约一周后，社区认为这是最好的答案-我认为这表明您只是需要以某种方式开发第六感。但是，我认为每个人都有话要说。

与其问看他们的代码，不如问他们对代码库的看法。而且当您这样做时，请密切注意面部表情及其反应所需的时间。

然后运用您对文化的非语言手势的了解来解释它们的真正含义。对于北美公司，以下内容应准确无误：

• 耸耸肩，然后迅速回答“可能会更好”：可能还不错。
• 长时间的停顿，呼吸，也许是一个小小的笑声：这并不令人愉快，您正在面试的人告诉您这一点也不感到舒服。
• eyes着眼睛，对“糟透了”的快速反应：可能是好事，可能是坏事，但正在发生政治游戏。除非您准备好玩该游戏或成为一个安静的人，否则请远离。
• 抬起眉毛或皱巴巴的眉毛：他们不理解这个问题，并且代码库几乎肯定是腐烂的。

当然，如果您在人际交流方面遇到麻烦，这可能对您不起作用。

令您惊讶的是，我感到很惊讶。加入之前，没有公司会向您显示代码。除非他们已经签署了保密协议，否则甚至没有邀请顾问参加该过程。

这是您可以要求查找的内容。

• 公司的CMM级别是多少（理想情况下为5）
• 您的预期项目中遵循的流程是什么（顺便说一句，问这是件好事，因为它表明您对“这项”工作感兴趣，而不仅仅是任何一项工作）
• 他们使用什么生命周期（如果您没有听到“敏捷”的声音，请不要做判断。他们可能有使用旧学校模型的正当理由）
• 询问他们是否使用任何工具和指标来检查代码质量。如果是，则使用哪一种（如果他们至少使用一种工具进行度量，而另一种工具用于质量，则这是一个好兆头。）
• 还要注意他们使用什么工具。如果它是诸如Resharper之类的昂贵工具，而不是某些免费软件工具，那么他们对质量一无所知。

1. 询问他们是否使用源代码管理。
   • 没有源代码控制？->代码很可能很糟糕
2. 询问他们代码复审的频率。
   • 没有代码审查？->代码可能令人怀疑（但不一定如此，特别是如果它是由体面的开发人员组成的小团队。）
3. 问他们在投入生产之前是否进行测试和部署？
   • 没有测试环境？直接部署到生产中？->代码很可能很糟糕。
4. 询问他们是否进行持续集成（即使用Hudson运行内部版本）
   • 没有持续的整合？->代码可能令人怀疑，但不一定如此。
5. （与＃3相关），请问他们的测试环境是否与您的开发环境分开？
   • 测试是开发人员吗？->这不是一个好兆头，除非他们真的没有足够的现金，否则一个额外的盒子要多少钱？
6. 询问他们是否在部署到生产中之前查看操作列表。
   • 在生产部署之前不审查任何操作？->烂枣。
7. 询问他们完成构建需要多少步骤。
   • 超过3个？->通常是烂枣。
8. 他们是否采用（或猜测）代码量度，例如圈复杂度或LCOM（类内聚度的度量）。
   • 是？->关于其代码质量，可能（但不是肯定）是一个好兆头。
   • 不，但是他们了解概念（至少是圈复杂度）吗？->很难说
   • 他们认为圈复杂性是廷巴克图的异国情调或壮阳药（换句话说，他们不知道那是什么）吗？->可能是坏枣。
   • 他们认为这是无关紧要的（或其他类似的举止）吗？->逃跑。
9. 询问他们如何跟踪错误。
   • 他们根据某个指标（例如，每个项目，更改的模块数或需求/更改请求数，等等）跟踪错误的数量吗？->有关其代码（及其软件过程）的好兆头。
   • 他们做了上面的一个，并试图根据期望的指标（变更请求的数量，项目规模等）来预测他们在未来（或正在进行的）项目中可能遇到的错误数量？-> 非常好的迹象。
   • 他们仅为了解决错误而跟踪错误？->很难说
   • 没有一致的跟踪？->逃跑。

那是从我的头上。您会注意到，我的一些问题与软件开发过程有关，而不仅限于编码。后者的质量是前者质量的直接函数。

话虽如此，当您提出这些问题时，请谨慎行事。研究它们并在面试时选择一些。

您应该记住几件事。一个优秀的开发团队将很高兴听到受访者提出这些问题……只要他们被问到机智。如果做错了，您会给面试官以傲慢和完美主义的印象。无论开发团队有多出色，都没有一个团队是完美的，他们都需要解决问题，在质量上妥协等等。他们希望团队成员对质量充满热情，而不是破坏性的完美主义者。所以要小心

同样，在某些情况下，您可能会有一群优秀的人，这些人在外部环境下必须使用质量低于标准的代码（他们可能是初级开发人员，或者他们只是继承了一堆废话，现在必须在有限的条件下工作）如果您周围的人也都是好人（无论是个人还是专业），您都可以使用低劣的代码工作，并且仍然具有良好的工作经验。当您提出问题时，给他们留下错误的印象，他们可能只是避免完全雇用您（抢夺您在困难和充满挑战的情况下与好人一起工作的机会。）

• 顺便说一句，我全心全意地认为，软件开发人员必须至少使用某种类型的超越（或接近超越）代码工作一次。您可以从中幸存下来，并做好工作，这是一个宝贵的教训。

您可能还会遇到一个与卑鄙的人组成的卑鄙的发展小组。显然，那时他们的代码很糟糕，他们对这些问题都不满意。他们可能会鄙视您，向他们询问硬性问题（因此可能会帮您一个忙），或者因为他们需要您而会雇用您（即使他们无法与您合作）。

发生这种情况时，您必须问自己是否需要那么糟糕的这项工作。有时您会这样做，并且您必须一堆意大利面条屎。有时你不这样做（意思是，你负担不起）。

当/如果您选择询问访问员有关其代码和软件流程的质量，这些就是您需要考虑的事情。

除了寻找实际的代码质量之外，我宁愿寻找一家能够充分了解代码质量重要性的公司。

例如，假设公司A的经理相信“计划浪费时间”，并且“以后我们可以解决设计问题（例如，当地狱冻结时，我们将有时间）”。即使该公司现在碰巧具有良好的代码库，他们也不会长期使用它。而您将成为（将被迫）使情况变得更糟的人。

另一方面，假设公司B的代码基础很差，但是管理层知道代码质量正在导致所有这些错误和延迟，他们看到需要更改，并且愿意为此做些事情（例如大规模重构甚至重写）。该公司将改善其代码库，您可以帮助他们实现这一目标。

我知道我想在哪里工作。

有99.9％的可能性，您将无法在开始之前看到代码。（除非他们当然推出了免费软件产品）

所以，我想问一下流程，一般情况下，好的流程会产生好的代码。我将从Joel测试开始，然后询问开发方法。也要超越基础。例如，我总是问他们使用什么源代码系统，所以一个很好的跟进就是问他们为什么使用它。

我使用高质量代码的地方基本上不允许三分之二的开发人员接触代码。其他人则改为编写自动黑匣子测试脚本。如果您证明自己值得更改实际的代码，那么这些要求就被过度指定了，以至于基本上只不过是复制到源代码。测试脚本实际上更有趣。

我见过的最低质量代码的地方恰好相反：只有相对没有经过培训或没有指导的程序员才接触过代码，通常是因为它是与公司产品没有直接关系的工具，或被认为是试验工具。

最宜人的工作场所保持平衡。给新开发人员真正的工作，但要进行指导。有一个良好的质量检查部门和同行评审流程来发现您的错误。您不会因犯错而受到惩罚，但是应该纠正它们并从中学习。有时候，编写不当的模块会掉入裂缝，但是当您遇到这些问题时，并不会因为花费时间来提高代码质量而受到批评。整个公司都在不断努力寻找新方法来改进代码。

因此，我要评估代码质量的问题是：

• 您的测试程序是怎样的？
• 给新开发者什么样的任务？对于经验丰富的开发人员？
• 有多少人从事一个项目？
• 是否允许重构？鼓励？
• 正在考虑或最近进行了哪些与质量相关的过程或体系结构更改？
• 个人在模块上有多少自治权？

正如@DPD和@Zachary所说，过程和SDLC是非常重要的因素，但我想补充一些其他因素，根据我的经验，这些因素会对代码质量产生重大影响：

• 询问您是要在相对较新的项目中进行开发工作还是要维护旧版应用程序。遗留应用程序往往不如较新的项目干净。
• 尝试了解组织或团队中员工的离职率是否很高。这很可能也会降低代码质量。

请注意，一个过程确实有很大帮助，但不能完全抵抗上述因素。当许多开发人员进行一个项目时，每个人都有不同的心态。架构师和开发人员将不会遵循其前任所遵循的确切方式，这将导致某些不一致之处。

我的态度是，代码就是代码，如果不好，那么使其变得更好是一个挑战。如果它很好，那么使其变得更好将是一个更加困难的挑战！

对我而言，最重要的是我是否想为公司以及与我有机会互动的人们一起工作。代码可以更改，人们不能...

我开玩笑的说，采访我。

我通常在代码库中使用一个实际的错误（已经修复）作为采访测试，因此您会看到一些实际的代码。通常略复杂的代码，并且其中包含错误。

我鼓励每个人都使用此技术，因为您已经知道错误是真实的，问题是真实的，并且您知道查找和修复所需的时间。

伟大的事情是您可能会遇到一个相当困难的问题。

我使用了一个非常棘手的问题作为最后一个面试问题，以将专家与优秀专家区分开。

与OP的问题相关的是，参加物理面试的每个人都可以看到一些代码。（没有任何包含公司机密内容的内容）

如果由于代码库中的亵渎原因而无法使用此技术，则该测试将奏效，因为潜在的员工会询问“我能看到代码”，然后回答是“哦，你不能。充满亵渎”。

当然，标准的“全部是公司机密”答案是完全的马球。
我的证明：在我以前的雇主那里，军方的非机密部分产品是面试问题的代码示例。[幸运的是未分类]

在让一个比我聪明的人之前，我要先确定分类设计的质量。我建议机密是无监督的同义词，这很常见。

他们是否会让您看到他们的代码是令人怀疑的，但是如果您给他们编程家庭作业，您可能会了解一下。在许多地方，受访者都可以带回家进行编程任务，他们可以用来评估您的情况。回报您的青睐-期望其中之一，这样您就可以更好地评估自己的目标。

询问将代码加入生产版本所需的内容。如果您得到“呃...开发人员提交了...”，那么几乎可以肯定是垃圾。

很多事情都有提高代码质量的趋势（显然，没有保证）。

• 静态分析（在.NET中是fxcop / stylecop之类的东西）
• 测试套件的子集（或全套）-单元/集成/回归/手册等。
• Buddy构建（团队中的另一个开发人员构建更改，以查看是否存在任何机器/用户相关的问题-有时还需要快速处理）
• 代码审查

这些不仅可以帮助提高代码强度，而且可以帮助提高代码质量。

向他们询问单元测试。如果他们认真对待，那么面试官可能会对这个问题有一些明确的意见，并乐于分享。如果答案不清楚，那将是一个很大的警告信号。

如果是Java商店，请询问他们使用的是哪个ORM库。如果他们自己动手，那么它可以任一种方式-可能会吮吸，也可能很好。如果他们不使用任何东西，请立即奔向大门。

这是一项艰巨的任务，因为有许多不同的不良编码实践，您将永远无法预测所有这些。

不幸的是你不能。没有公司会允许您查看他们的代码（但是他们会要求您查看您的代码...），并且很可能是如果您问他们关于环境的问题，您可能会被直接欺骗（“版本控制？确定。我们使用..呃.. 思考 Sub..Sub -something”）或对质量误入歧途（“我们正在使用最新，最强大的.NET 4”，只是发现他们在使用.NET 4时，将其编写为.NET 1.1）。

过去，我已经被它烧死了很多次，但是我还没有找到一种评估质量的好方法。通常，最好的方法是使用自己的判断，如果归结为它，如果比您想象的要差，请立即离开。您可能最终会找到工作，但会保持理智。