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