我目前面临着一个非常不寻常的设计问题，希望比我更聪明的开发人员能够提供一些见解。
我没有太具体，我被非营利组织聘用，以协助重建他们的遗产，但非常有价值（在社会价值方面）软件。开发团队不同于我作为软件开发人员时遇到的任何开发团队，由少数开发人员和更多非编程领域专家组成。这种安排的不寻常之处在于领域专家（让我们称之为内容创建者），使用自定义工具（其中一些基于prolog专家系统引擎）来开发基于Web的软件组件/表单。
系统使用非常笨拙的回发模型来执行服务器端的逻辑操作并返回新的表单/结果。它很慢，容易出现故障。简单的事情，比如使用现有工具创建html表单，很多比它应该更加艰巨。随着对更具交互性和高性能体验的需求的增长，软件开发人员越来越多地发现他们必须绕过内容创建者使用的专家系统/可视化工具，并在javascript中手动编写新组件。内容创作者越来越觉得他们的双手并列，因为他们现在无法贡献新的组件。
我一直在倡导完全放弃以前的模型并采用典型的软件开发流程。如前所述，由于非程序化开发工具已无法满足业务需求，因此该项目自然而然地向此发展。
然而，内容创作者可以做出非常宝贵的贡献，我希望他们能够专注于使用像Cucumber这样的工具正式指定软件的预期行为，而不是参与实现。
我的同事，我非常尊重和怀疑比我更有知识，认为现有的流程很好，我们只需要建立更好的工具。然而我不禁觉得这种方法存在根本性的缺陷。我还没有找到一个实例，无论是历史还是现代，这种软件开发模式都取得了成功。 COBOL的开发理念是允许业务人员/领域专家在不需要程序员的情况下编写应用程序，在我看来，所有这些都是创建一种新的程序员 - COBOL程序员。如果有可能开发出有效的系统，允许非程序员创建非平凡的应用程序，那么程序员的需求肯定会低得多吗？我所知道的唯一适合这种模式的框架是SAP的Smart Forms和Microsoft的Dynamix AX--两者都是特定领域的ERP系统。
这两个概念之间的妥协是将某种DSL作为模板语言实现。我甚至不确定这会成功，因为除了一个例外，所有内容创建者都完全没有技术性。
我还考虑过使用Visual Studio或Net Beans构建基于图形/工具箱样式工具的自定义IDE。
非程序化开发是一项愚蠢的事吗？这总是会导致一些令人不满意的事情，需要程序员亲自动手吗？
非常感谢您花时间阅读本文，我当然感谢任何反馈。
答案 0 :(得分：11)
你说：
之间的妥协 两个概念将是实施 某种DSL作为模板 语言。我甚至不确定这一点 然而，就像所有人一样 内容创建者，有一个 例外，完全不是 技术
老实说，这听起来就像我会使用的方法。甚至“非技术”用户也可以通过简单的DSL或模板语言熟练（足够）以完成有用的工作。
例如，我在科学建模软件方面做了很多工作。许多建模者虽然在科学方面比在任何形式的工程学中更多，但却被迫学习一种或多种编程语言，以便以他们可以使用的方式表达他们的想法。哎呀，据我所知，Fortran仍然是获得气象学位所必修的课程，因为目前使用的所有主要天气模型都是用Fortran编写的。
因此，存在一定的“科学编程”社区，其中大部分都是由领域专家组成，他们的正式软件工程培训，专业知识甚至兴趣都很少。这些人更喜欢使用Matlab，R甚至Visual Basic等语言/平台（因为他们可以使用它来编写Excel和ESRI ArcMap等应用程序）。最近，我看到Python在这个领域也取得了进展，主要是我认为因为它相对容易学习。
我想我的观点是，我看到这个领域和你的例子之间有很强的相似之处。如果您的域专家能够严格考虑他们的问题（可能不是这种情况，但您的问题可能是开放式的，那么他们肯定能够以适当的特定领域语言表达他们的想法）
我首先要与内容创作者讨论一些关于他们如何表达自己的决定和选择的想法。我的猜测是，他们很乐意编写“代码”（即使你不必称之为代码）来描述他们想要的东西。给他们一个“调试器”（交互式地探索他们的“代码”变化的后果的工具）和一些不错的“IDE”支持应用程序，我认为你将有一个非常可行的解决方案。
答案 1 :(得分：7)
想想电子表格。
电子表格是一个简单的系统，允许非技术用户使用计算机的计算能力。在这样做的过程中，他们开辟了计算机来解决大量任务，这些任务通常需要开发用于解决它们的定制软件。所以，是的，非编程软件开发是可能的。
另一方面，请查看电子表格。尽管他们的计算能力，你真的不希望作为程序员必须用它们开发软件。最后，许多使编程语言对程序员更好的技术使得它们对于一般人群来说更糟糕。例如，定义函数的能力使程序员的生活变得更加容易，但我认为会使大多数人感到困惑。
此外，尝试使用电子表格过去一定程度的复杂性将是一个真正的痛苦。电子表格在其设计的领域内运行良好。一旦你偏离了太远，它就是不可行的。再次，它是程序员用来处理复杂性的工具，这将阻止系统广泛使用和足够强大。
我认为对于任何给定的问题领域，您可以开发一个允许专家指定解决方案的系统。开发该系统然后首先要解决问题要困难得多。但是，如果您反复遇到专家可以为其制定解决方案的类似问题，那么它可能是值得的。
答案 2 :(得分：6)
我认为非开发人员的开发注定要失败。开发人员尝试它时很难。失败率是多少？ 50％或更高？
我的建议是购买你能找到的最接近的商业产品，或者雇用某人来帮助你开发一个定制的解决方案，同时考虑到非开发人员的维护特性。
作为一名开发人员意味着要立即记住一百万个细节并关注版本控制，部署，测试等细节。大多数不关心这些事情的人很快就会厌倦复杂性。
通过各种方式涉及领域专家。但是也不要让他们担心开发和维护。
如果解决方案做得不好，您可能会使您的组织面临风险。如果这很重要，那就做对了。
答案 3 :(得分：5)
我认为任何广泛的非程序员解决方案都不会起作用。编程不仅仅是语言，而是知道如何合理地做事。设计为非程序员友好的东西几乎肯定会包含程序员知道要避免的所有陷阱，即使它用英语或GUI表示。
我认为在这种情况下需要的是让内容创建者担心制作内容，而实际程序员则将其转换为合理的计算机代码。
我使用过两个专为非程序员设计的ERP系统，在这两种情况下，你可以用它们来解决书中的每一个错误。
答案 4 :(得分：4)
......简单的事情，比如使用现有工具创建html表单要比它应该更加艰巨......
对于谁来说，更为艰难的？你正在采用一种对非编程内容创作者有效（但非常糟糕）的开发模型，并且因为某些事情对于某些人来说是艰难的，你建议用内容创作者完全被冷落的模型？ 听起来很疯狂。
如果您的内容创建者可以学习围绕Prolog规则引擎构建的自定义工具，那么他们已经证明他们可以学习足够的形式主义来为项目做出贡献。如果您认为开发的其他方面需要改变了，我只看到两个光荣的选择：
使用您认为可以通过其他方式改善事物的新技术实施现有的形式主义（“自定义工具”）。内容创建者的贡献与现在完全相同。
设计并实施一种特定于域的语言，用于处理内容创建者知道和可以做的事情与您和其他开发人员认为应该完成工作的方式之间的阻抗不匹配。
您的方案是一个经典案例，其中特定于域的语言。但语言设计并不容易，尤其是在与严重的可用性问题相结合时。如果您很幸运，您将能够雇用某人来帮助您在语言设计和可用性方面都是专家。但如果你是非营利组织，你可能没有预算。在这种情况下，一种可能性是从另一所非营利组织 - 附近的大学寻求帮助，如果你有的话。
答案 5 :(得分：4)
我建议你在尝试废弃整个系统之前阅读this article。我是这样看的。什么改变促使重建？您的域专家没有忘记如何使用原始系统，因此您已经为您的域名拥有一些称职的“COBOL程序员”。根据您的描述，听起来大多数性能要求已经改变，并且可能对Web表单有更大的需求。
因此，理想的解决方案不是要改变领域专家的职责，而是要提高绩效并使创建Web表单变得更容易。您拥有现有代码库的优势，可以准确显示您的域专家的能力。不使用它将是一种真正的耻辱。
我意识到Prolog并不是最热门的语言，但有更快更慢的实现。一些实现主要是为程序员交互性而设计的，并且是动态解释的。一些实现创建优化的编译本机代码。还有复杂的逻辑编程技术，如memoization，可用于提高性能，但可能没有人在学校学习它们。内容创建者专注于创建新内容的流程以及专注于优化的开发人员可能非常可行。此外，Prolog非常适合模型层，但对于视图层而言则不是那么多。将更多视图层移动到不同的技术可能会有所回报。
答案 6 :(得分：3)
总的来说，2个想法：
您无法减少算法的生命。我们所知道的一切（哲学上，科学上）和经验证明了这一点。 （对不起，明斯基博士）。
也就是说，一个允许非程序员表达有限语言的特定领域工具绝对可行，因为有几个人给出了例子。此类系统的另一个例子是 Mathematica ，特别是 Simulink ，它们在一系列应用中非常成功地使用。然而，专家系统，模糊逻辑和80年代日本第五代计算机项目的失败表明了这样做的困难。
答案 7 :(得分：2)
Labview是一个非常成功的非程序化编程环境。
答案 8 :(得分：2)
这是一个多么有趣的问题。
我最终会同意你的意见，并且不同意你的同事。
Domain Driven Development/Design 的理念和方法完全出于您的目的，因为它最重视有经验的领域专家的具体知识，并将这些知识传递给有才能的软件开发者。
请参阅您的问题，有两个不同的事情。域名和软件。首先应该理解和指定域名，而不考虑软件开发。
然后，在域专家和程序员之间的沟通之间进行软件转换。
我认为尝试为领域专家构建“编程”工具是浪费时间。
在领域驱动开发领域，您的领域专家将继续发挥重要作用，您将获得更好的软件。
在你的同事的方法中，你试图用工具取代程序员....也许将来，比如，开始艰苦跋涉未来，这是可能的，但今天我不这么认为。
答案 9 :(得分：2)
我目前正在努力解决类似的问题，试图让医疗保健提供商为工作流编写规则，这并不容易，因为他们不是程序员。你是一名程序员，不是因为你去了编程学校 - 你是一名程序员，因为你认为你是程序员。幸运的是，大多数医院都有一些麻醉师或生物医学工程师，他们像程序员一样思考并可以设法编程。关键是要给那些非程序员 - 他们认为那样的程序员一种他们可以学习和掌握的语言。
在我的情况下，我希望医生能够制定简单的规则，例如：“如果患者的体温过低，请向医生发送短信”。当然，它比这更复杂，因为“太低”的定义取决于患者的年龄，患者可能有许多医生，等等，但聪明的医生将能够找出这些规则。真正的问题是温度传感器通常会从患者身上掉下来并读取环境温度，这意味着除非您能够弄清楚如何确定温度计实际上正在读取患者体温，否则该规则是无用的。
我遇到的一个大问题是，虽然创建一个DSL相对容易，医生可以表达IF [temperature] [less-than] [lookup-table [age]] THEN [send-text-message]，但要创建一个可以表达您在来之前可能需要尝试的所有不同启发式的方法要困难得多。以正确的方式确保阅读有效。
在您的情况下，您可能想要考虑VB如何变得流行：它有一个表单绘制工具，任何人都可以轻松地使用它来绘制表单和设置表单项的属性。由于并非所有内容都可以通过表单属性和数据绑定来指定，因此可以使用代码隐藏模式来执行复杂的逻辑操作。但是为了让初学程序员可以访问该工具，该语言是BASIC，因此用户无需了解指针，内存分配或数据结构。
虽然您可能不想给用户VB，但您可能会考虑使用混合方法。你会有一种“语言”（它可能是图形的，比如VB的表单设计师或Labview），没有经验的用户可以轻松地完成这些简单的工作，而另一种语言可以帮助专家用户完成复杂的工作。
答案 10 :(得分：1)
这是一个非常哲学的话题，很难回答每一个案例，但总的来说......
非程序化开发是一个愚蠢的错误吗？
在非常狭窄的范围之外，是的。多年来，主要的软件供应商已投入数十亿美元用于创建各种软件包，以试图让非技术用户创建和销售。定义工作流程和流程，但成效有限。你最好的选择是利用在那个领域所做的事情，而不是试图重新发明它。
修改： Sharepoint，InfoPath，一些SAP的东西就是我所说的例子。正如我上面所说，“范围非常狭窄”。可以让非程序员创建工作流程，复杂的表单，一些域名流程，但就是这样。任何更通用的东西都只是试图让非程序员为程序员提供非常粗糙的工具。
答案 11 :(得分：1)
之前我曾将此作为评论，但我认为它值得更多。
肯定有很多成功的“非程序化”工具，我可以想到Labview，VPL和graph based （编辑：我刚注意到）此链接不仅仅是着色器上的着色器）在3D应用程序中流行的着色器。
话虽如此，我不知道任何适合基于网络的开发者（看起来像你的情况）。
我非常重视开发此类工具的投资是值得的（除非您可以将其作为产品出售）。
答案 12 :(得分：1)
我同意你的观点 - 非技术人员将无法编写任何非平凡的。
有些产品尝试创建基本上非常简单的编程语言。问题在于编程是 aptitude 以及技能。在计算机使用的那种逻辑中需要某种思维模式来思考，这种逻辑不能被任何编程语言抽象出来（至少在没有做出假设的情况下不能没有它安全地制作）。
我已经在尝试在MS Dynamics CRM中构建工作流的业务人员中看到了这一点。尽管该产品显然是为了让他们在没有程序员的情况下完成它，但他们无法弄清楚如何制作循环或if-else条件，无论UI如何“友好”地完成它。我惊讶地看着他们挣扎着对我来说似乎完全不言自明的事情。经过一整天（！）之后，他们设法生成了一些非常基本的工作流程，这些工作流程在某些情况下有效，但没有处理缺失值或无效数据等边缘情况。这基本上完全是浪费时间。
当然，Dynamics CRM并不完全是用户友好性的缩影，但我看到足以让我相信这确实是一个傻瓜的差事。
现在，如果您的用户不是程序员，但仍然是技术人，他们可能学习编程，但这是另一个故事 - 他们真的变成了“新的程序员“而不是”非程序员“。
答案 13 :(得分：1)
答案 14 :(得分：0)
似乎问题属于组织性质，单靠技术手段无法解决。
根源是内容创建者完全不是技术性的，但必须执行设计表单和编写Prolog规则的固有技术任务。各种设计师和DSL可以缓解他们的问题，但永远不会解决它们。
重新组织系统和流程，以便知识载体真正进入知识 - 没有别的;或培训内容创建者使用现有工具进行必要的开发，或者可能是DSL。
非程序化开发可以节省低级别的工作，但是努力设置一次系统并让用户无限期地无限制地扩展它当然是个蠢事。
答案 15 :(得分：0)
计算机游戏公司一直这样运作，据我所知：一些程序员和许多内容创作者也需要能够控制逻辑（如关卡设计师）。
如果可以的话，能够将代码与驱动它的数据和规则分开也可能是一个健康的规则。
因此，我与你的同事在一起，但当然具体细节可能无法使这个一般的解决方案合适！