您在编码过程中是否有非IT人员与程序员合作的经验？
这就像结对编程一样，但是一个人是一个非IT人员，对业务有很多了解，也许是一个具有数学背景的流程工程师，他知道事物是如何计算的并且可以理解非惯用的程序代码。
我发现非IT工程师很容易理解某些过程性领域特定语言，例如PL / SQL。这些人最终成为代码的共同作者，并保证公式，因子等的正确性。
我发现这种成对编程非常有效率，这种工程类型的用户认为他们也是代码的“所有者”和“作者”，并有助于最大程度地减少沟通过程中的误解。他们甚至帮助设计测试用例。
Answers:
尽管您将其描述为共享编码会话（我不能称其为配对编程，因为只有一个人在“开车”-在配对编程中，双方都需要键盘并编写代码），但我会称其为收集接受标准。
也就是说，您正在与业务用户（尽管技术角色非常强的工程师）一起验证业务规则（正确的计算和流程）。
在这种情况下，它会立即转换为书面代码（SQL），但对于许多其他活动却不会，尽管有针对不同语言和平台的自动验收测试工具（我正在专门考虑小黄瓜语言和相关工具）。
这种做法并不像应有的那样普遍，但是它吸引了越来越多的追随者，并且追随者（以可以执行的形式获得接受标准）发现，它既可作为与企业沟通和推动的工具，又具有不可估量的价值。发展。
是。在我工作的地方，我从事核心编程类型的工作，而战略家则在从事庞大的战略工作。也就是说，我编写了实现其交易模型的程序。
这里的关键是坐在右侧旁边，准确地了解想法是什么，并要求很多的事情可能是附带他们的问题，而是要执行的一面。例如，我想问一下交易需要执行多快，是否会影响他们的模型。这对我编写代码的方式有很大的影响。实际上，由于我们每天坐在那里工作，所以我倾向于向房间里提问。
有双向反馈。如果我告诉他们某些交易方案不容易建立，他们会回头考虑在决策方面可以进行哪些折衷。如果他们决定他们的新策略需要一些新功能，那么我将与他们聊天，讨论构建需要多长时间以及潜在的陷阱。
他们编写的代码模块会不时地封装交易策略的某些方面，但是我将各个部分组合成一个体系结构，该体系结构使我们能够跟踪所有不同的策略以及后端操作内容。这样，他们就不必知道系统的本质了。