与非开发者一起构建跨学科算法
是的，我知道这个标题很拗口……
我的意思是说，你如何与需要编码和测试理论的主题专家沟通？
例如，天气模拟是气象学家、计算机科学家和软件工程师之间的合作。 计算机科学家和软件工程师通常说同样的语言，但气象学家却处于完全不同的世界。
如何提高学科之间的沟通和理解水平？ 不一定只是天气，其他科学也是如此。
Yeah, I know the title is a mouthful...
What I mean is to say is how do you communicate with a subject matter expert who needs a theory coded and tested?
For example, weather simulation is a collaboration between meteorologists, computer scientists, and software engineers. The computer scientists and software engineers generally speak the same language, but he meteorologist is in a completely different world.
How do you increase the level of communication and understanding between disciplines? And not necessarily just for weather, other sciences too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
最简短的答案是持续的客户参与。
所有漂亮的 UML 图、crayola UI 模型、对四岁孩子的解释和其他技术永远不会提供使用工作应用程序的完整体验。 让消费者了解情况可以实现向客户以及从客户到您的反馈循环。 这种共生关系最有可能生产出对他们有用的产品。
如果你打开一个盒子，拿出一件你认为他们需要的产品，那么很可能里面有很多他们不想要的东西。 通过定期演示您的产品，您可以限制任何误解的影响，这样您就不会花太多时间走上错误的道路。
它可以与航位推算相比较。 如果你蒙住自己的眼睛并尝试在你熟悉的区域中导航，那么你所在的位置与你认为的位置之间的误差会随着时间的推移而累积。 然而，如果你定期摘下眼罩，你就可以更新你的心理位置。 仍然会有误差因素，但您正在消除累积的误差因素。
即使您认为自己的沟通/解释能力是一流的，您仍然必须考虑到他们沟通方式中的错误。
The shortest possible answer is Continuous customer involvement.
All the pretty UML diagrams, crayola UI mockups, explanations-to-four-year-olds and other techniques will never give the full experience of using a working application. Keeping the consumer in the loop allows for a feedback cycle both to the client, and from the client to you. This symbiotic relationship has the greatest likelyhood of producing a product that will be useful to them.
If you go into a box and come out with a product that you think they need it will likely be a whole lot of what they don't want. By regularly demoing your product you limit the impact of any misunderstanding, so that you don't spend too much time going down the wrong path.
It can be compared to dead reckoning. If you blindfold yourself and try to navigate through an area you know, the error between where you are and where you think you are will accumulate with time. If, however, you take off the blindfold periodically you can update your mental location. There will still be an error factor, but you are eliminating the accumulating error factor.
Even if you think your communication/explanatory skills are top notch, you still have to account for error in the way they communicate.
状态图可以为这项任务带来奇迹。 它们允许您以适合与您通信的人的级别来表示计算过程。 各州对那里的处理情况发表了简短的评论。 状态之间的弧线显示导致转换到新状态的条件。
构建了基本状态图后，您可以继续讨论输入状态机的信息。 这就是人的领域知识应该发挥作用的地方。 通过图表查看一些数据以查看其处理流程。 一般来说，在这一点上，他们开始注意到其他尚未讨论的情况。
可能需要拖入另一块白板，将一个或多个状态展开到它自己的状态图中。
然后，通常，当他们对流程感到满意时，就可以将错误处理注入到图表中。
这项技术对我来说非常有效。
State Diagrams work wonders for that task. They allow you represent a computational process at a level suitable for the people you are communicating with. The states hold a brief comment on what processing goes on there. The arc between states show the conditions that cause a transition to a new state.
Having constructed the basic state diagram, you can move on to discuss the information that is being fed into the state machine. This is where the persons domain knowlege ought to come into play. Follow some data though the diagram to see the flow of how it gets processed. Generally at this point, they start to notice other situations that haven't been discussed.
It may be necessary to drag in another white board, expand one or more of the states into its own state diagram.
Then generally, when they are comfortable with the flow, it's time to inject error handling into the diagram.
This technique has worked pretty well for me.
“最简短的答案是持续的客户参与。”
我建议你通过一些具体的方法来做到这一点。
一种可以快速开发的语言。 Python 是我的选择，你的可能不同。 例如，Java 可能不会在您的列表中名列前茅，因为它需要一段时间才能运行起来。 C++ 对于快速开发来说可能需要花费太多精力。
快速构建小东西。 从可以开始对话的事情开始——任何事情。 构建、审查、扩展。
通过单元测试将结果形式化，以便您尽早且经常进行重构。
一旦你有了可靠的东西，你可以考虑用 Java 或 C++ 或其他东西重写来提高性能。
"The shortest possible answer is Continuous customer involvement."
I suggest you do this through some specific approaches.
A language in which you can develop quickly. Python's my choice, yours may be different. Java -- for example -- might not be high on your list because it takes a while to get stuff up a running. C++ may be too much effort for rapid development.
Build small things quickly. Start with something -- anything -- that can get the conversation started. Build, review, expand.
Formalize results with unit tests that allow you refactor early and often.
Once you have something solid, you can consider rewriting in Java or C++ or something to improve performance.
我一直发现流程图是普遍可以理解的，尤其是在表示算法时。 流程图通常易于阅读和制作，并且被普遍理解。
I've always found that flowcharts are universally understandible, especially when representing algorithms. Flowcharts are generally easy to read and make, and are universally understood.
我认为大多数评论者所遗漏的内容实际上对您的问题非常重要 - 您正在与领域专家合作构建他们的模型的实现来测试他们的理论。
大多数软件工程的东西都与这个制度无关——就像你说的，这与实现某些业务流程或构建必须实现 RFCxxxx 的服务器有本质上的不同。
有人从两端致力于此 - 试图向科学家传授负责任的软件工程的基础知识（例如，Greg Wilson 的 Software Carpentry）并向软件工程人员教授大规模计算科学（例如 Steve Easterbrook 的 非常有趣的博客，来自这个 特别相关）。 我不知道为什么事情在这方面如此原始。 两人的博客上都有相关同事的链接。
这个体系与你可能学到的东西有许多重要的区别。 其一，科学软件的整体结构一般都很简单，但微妙之处却相当高——每一行数字都可能是多个领域10年科学文献的结果。 其次，规范的整个想法有点被颠覆了——规范是“准确地模拟现实”，而科学家拥有的是他们希望做到这一点的模型。 在某种程度上，科学代码开发既是实现规范草案，也是摸索真正的规范。
@vfilby 的想法是正确的——持续的客户参与——但又不止于此。 为了实现这一点，你将进入科学循环 - 而不是科学家→理论→测试→解释→更新理论的循环，它将是科学家→理论→你编码→你和科学家两者解释你自己的部分→更新理论和/或实现。 领域科学家不会像您一样了解如何最好地实现他们想要的东西，或者如何将他们的模型结果与您的模型实现结果区分开来； 另一方面，他们会比你更好地理解模型的含义以及如何更新理论。
这是一个很难做到正确的平衡行为。 为了使其发挥作用，双方必须（a）尊重对方的专业领域，（b）学习其他领域的一点知识，以及（c）对整个项目的运作进行投资。 这类跨学科项目失败的次数比成功的次数多，但它们至关重要。 我真的希望能为您提供一些简单、可靠的技巧。
I think what most of the commenters are missing is actually pretty crucial to your question - the idea that you're working with domain experts to build an implementation of their model to test their theories.
Most software engineering stuff out there is not about this regime - and like you say, this is just qualitiatively different than implementing some buisness process or building a server that has to implement RFCxxxx.
There are people working on this from both ends -- trying to teach scientists about the very basics of responsible software engineering (eg, Greg Wilson's Software Carpentry) and teaching software engineering people about large-scale computational science (eg, Steve Easterbrook's very interesting blog, from which this is particularly relevent). Why things are as primitive as they are on this front, I have no idea. Both have links to relevent colleagues on their blogrolls.
There are a number of important differences in this regime from stuff you may have been taught. For one, the overall structure of scientific software is generally quite simple, but the subtlety is quite high - each line of numerics may be the result of 10 years of scientific literature in a number of fields. Secondly, the whole idea of specifications kind of gets flipped on its head -- the specification is "accurately models reality" and what the scientist has is a model that they hope does that. In a way, scientific code development is both implementing a draft specification and groping around for the real specification.
@vfilby sort of has the right idea - continuous customer involvement - but it's a little more than that. For this to work, you are going to get put into the science loop - instead of the cycle being scientist → theory → test → interpretation → update theory, it's going to be scientist → theory → you code → you and scientist both interpret your own parts → update theory and/or implementation. The domain scientists aren't going to know as well as you how to best implement what they want, or how to disentangle the results of their model from the results of your implementation of the model; on the other hand, they're going to understand the implications of the model much much better than you and how to update the theory.
This is a hard balancing act to get right. For it to work, both sides have to (a) respect the others domain of expertise, (b) learn a little bit of that other field, and (c) be invested in the project as a whole working. These sorts of cross-disciplinary projects break down more often then they succeed, but they are vitally important. I really wish I had some easy, guaranteed-to-work tips for you.
非常细心和耐心。 您不能假设理解，因此请使用原型设计或图片等技术来进行交流。
当客户发表声明时，您需要执行您认为他所说的内容，或者画一张图并向他展示。 这样他更容易认识到你的误会。 我会避免冗长的书面描述，因为很难知道你是否理解。
客户不需要了解您的语言，因此不要尝试教气象学家 CS 术语。 你需要学习他的语言。 即使是最微不足道的要求也应该使用原型进行测试。 如果他们说：“我们需要看一张美国地图”，那么你需要画一张美国地图给他们看，并说“这是你想看的吗”？ 然后他会说“但我在这张地图上看不到密西西比河”，然后你说“但你没有要求河流”然后返回并重新绘制地图。 我曾经遇到过需求简单得多的情况，
但结果却出了严重的错误，因为客户认为它很简单，而我认为我理解。
With great care and patience. You cannot assume understanding so use a technique like prototyping or pictures to communicate.
When the customer makes a statement you need to implement what you think he says, or draw a picture of it and show him. It is easier for him to recognize your misunderstandings this way. I would avoid long written descriptions because its very difficult to know if you understand.
The customer should not need to know your language, so do not try to teach the meteorologist the CS lingo. You need to learn his language. Even the most trivial requirement should be tested with a prototype. If they say: "We need to see a map of the US", then you need to draw a map of the US and show them and say "Is this what you want to see"? He's then going to say "But I can't see the mississipi river on this map" then you say "but you didn't ask for rivers" Then go back and re draw the map. etc etc.
I have had situations with much simpler requirements that went horribly wrong because the customer assumed that it was simple and I assumed that I understood.
我在威格的东西上取得了巨大的成功：
http://www.processimpact.com/reqs_book/reqs_book.shtml
从做开始愿景和范围文件：
http://www.processimpact.com/pubs.shtml#requirements
I've had good success with Weiger's stuff:
http://www.processimpact.com/reqs_book/reqs_book.shtml
Start by doing a vision and scope document:
http://www.processimpact.com/pubs.shtml#requirements
你应该经常问自己：“我该如何向市场上的那位老奶奶解释这一点？”。 一旦你掌握了这些，你就可以向几乎任何人谈论和解释你的方法和程序。 如果他们有一些额外的知识，那就更好了。
如果你不能，也许你应该问自己“也许问题不在他们这边”。 即使站在他们一边，尝试理解他们的观点也没有什么坏处。
就我个人而言，我不是一名程序员，但只要我们都遵守上述原则，与人交谈就不会出现任何问题。
You should always ask yourself, "How would I explain this to that ol' granny at the market?". Once you have that covered, you can talk and explain your methods and procedures to pretty much anybody. If they have some additional knowledge, even better.
If you can't, than maybe you should ask yourself "Maybe the problem isn't on their side.". Even if it is on their side, there is no harm in trying to understand their point of view.
Personally, I'm not a programmer by trade, but had never any problems talking with ones, as long as we both stick to the aforementioned principles.
充当程序员，并使用“尽可能松散的耦合”方法。
对于气象学家的案例，我对这个领域了解一点，气象学家和程序员在实际代码上几乎没有交流。 这些程序员知道足够的数学知识来实现气象学家想要的任何方程，然后气象学家就足够极客来使用该软件。
我还可以将交易员、宽客和程序员的案例联系起来，这甚至更糟糕……
他们不讨论气象学，也不讨论代码。
Act as a programmer, and use the "loosest coupling possible" approach.
For the meteorologist case, I know a little the field, and meteorologists and programmers hardly communicate on the actual code. Those programmers know enough math to implement whatever equations meteorologists want, and then meteorologists are geek enough to use the software.
I could also relate the traders vs quants vs programmers case, which is even worse...
They don't discuss meteorology, and they don't discuss code.