了解开发商如何处理棕地项目
我第一次为我的替代者进行一些工作面试。我想知道他们将如何处理 brownfields 项目，但我并不是真的确定如何表达这个问题。
我想知道他们的态度是什么：例如扔掉并重写，使用工具重构，逐步浏览代码并理解，他们读过哪些书（例如“有效地处理遗留代码”）。
您如何了解某人如何从事棕地软件开发？
I'm doing some job interviews for the first time for my replacement. I want to know how they would approach a brownfields project, but am not really sure how to phrase the question.
I'd like to know what their attitude is: e.g. throw out and rewrite, use a tool to refactor, step through the code and understand, what books they've read (e.g. "Working Effectively with Legacy Code").
How do you find out how someone takes on brownfields software development?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
面试时，尝试进行情景头脑风暴或角色扮演，而不是交换定义。在这种情况下，尝试让申请人讲述他们的故事，讲述他们的期望“......当接管主要财务系统的责任时，这个部门和那个小组每天都使用这些系统，并且有一些事情今天错了，哦，顺便说一句，计划从现在起三个月后发布升级版本，该版本将允许与这个新的银行合作伙伴直接集成以进行 1099 处理”。根据您的情况制定具体且真实的场景，并让他们交谈。
重要的是，不仅要从他们身上汲取他们会做什么，而且几乎同样重要的是，他们知道会做什么。如果你的候选人坐在你对面，编了一个关于在几天内加快速度并在下周五之前通过生产进行重大改变的故事，没有提出任何重要问题，也没有给你留下深刻的印象，怀疑他们的经验（并且如果您处于受监管的行业，或者不幸的是，大公司，可能是他们的理智）。相反，如果他们提出一些很好的问题，例如今天的环境是什么样的，审查流程是什么，谁对功能做出决定，是否有测试环境，代码是否可测试，或者是否有单元测试（喘息），以及发生了什么今天，如果需要在周五之前进行更改 - 嘿，他们以前可能已经来过这里并做过这件事。
您当然想听听他们如何确保现有功能正常运行并且不会设置定时炸弹，但您也想听他们提到他们将要做的事情，以便该项目变得更好、更容易使用，并且随着时间的推移会变得更有趣。他们专门从事的将继承的遗产项目变成一个充满乐趣的摇滚世界的活动应该在他们的故事讲述中体现出来。我的意思是，他们正计划这样做，对吗？
伟大的采访是对话、经验分享和故事讲述。把这些故事画出来，把它们弹到bs盾牌上，然后走。
When interviewing, try to engage in scenario brainstorming or role playing, not definition swapping. In this case try to engage an applicant in telling their story about what they would expect "...when taking over responsibility for the main finance system, which this department and that group use daily for these things, and there are a couple things that are wrong with it today, and oh by the way, there is a upgrade release scheduled for three months from now that will allow direct integration with this new banking partner for 1099 processing". Make the scenario specific and real for your situation, and get them talking.
The important thing is to draw out from them not only what they would do, but almost as importantly, what they know to expect. If your candidate sits across from you and weaves a story about getting up to speed in a couple days and making major changes up through production by next Friday, without asking any of the important questions and impressing you with their effectiveness, doubt their experience (and if you are in a regulated industry or, unfortunately, Big Company, possibly their sanity). If instead they ask good questions about what the environment is like today, what's the review process, who makes the decisions about functionality, is there a testing environment, is the code testable or are there unit tests (gasp) in place, and what happens today if a change needs to get in place by Friday - hey, they've probably been here and done this before.
You of course want to hear how they would make sure existing functionality works and time bombs aren't being set but you also want to hear them making reference to things they would be doing so that this project becomes better, easier to work with, and more fun over time. The activities they specifically are engaging in to turn the inherited legacy project into a rocking world of fun should come through in their storytelling. I mean, they are planning on doing that, right?
Great interviews are conversations and experience sharing and story telling. Draw those stories out, bounce them against the b.s. shield, and go.
这听起来是一个很棒的面试问题。为什么不直接问他们
他们会采取哪些步骤来继承/维护/扩展编写糟糕的遗留代码库，或者如何确定代码库何时需要重构？另一种选择是给他们一段中等大小的意大利面条式代码，并询问他们如何扩展它。
这里有很多很好的答案建议。
This sounds like a great interview question. Why not just ask them
what steps they'd take on inheriting/maintaining/extending a badly written legacy codebase, or how do you determine when a codebase needs to be refactored? Another option would be to give them a medium sized piece of spaghetti code and ask them how they'd extend it.
Lots of good suggestions for answers here.