👩🏾‍🤝‍👨🏼 🎵 🏓 如何避免编程大怒？积分技巧 🎭 🤟🏼 🔨

在上一篇有关将ERP引入工业企业的案例研究中的文章中，要点之一就是“程序混乱”。

我们有一个客户，其员工现在向我们发送令人怀疑的要求，并指定这是否是程序性违法行为。有些没有指定，而是创建了。

该主题是相关的，因此，我决定为此撰写另一篇文章。

它是什么？

当您听到“程序性违法”一词时，您的想象力会画什么样的画？

一个大胡子的男人，沉思而机灵的表情，打着满满的纳特打着眼泪的总会计师，说道：“科佩克，你说你还没有同意发票吗？收货人不适合进入牢房吗？现在，我们将在书上盖章，一切都将适合！”

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

这种现象比您想象的要少，但是更可怕。最后，总会计师可以冷静下来，擦干眼泪，然后送到心理学家那里，主人可以从椅子上解开，然后去上班。但是InventTrans中的发布曲线由于解决方案体系结构中的错误计算和不必要的改进而中断，因此心理学家不会纠正汇总计划。

程序性无法无天是一种情况，这种情况是由于编程而导致的，其目的是解决企业的某些问题，而这又给企业带来了其他问题，通常是更为严重的问题。

让我举几个例子：

, , . - , .
. , , «» . . , , .

我想将文章命名为“程序员的混乱。哭泣的集成商”，但意识到没有人在乎我们的眼泪。但是有关如何避免此类情况的提示可能会派上用场。

我将尝试预先概述建议的范围-我们正在谈论：

参与ERP系统的实施或维护的程序员。我认为与新产品或技术的开发人员相比，他们的要求略有不同。
与客户一起工作的程序员。集成商开发人员不太容易遭受“愤怒”。

那么，造成这种现象的原因是什么，可以采取什么措施呢？

不愿或无法看清过程的本质

我经常在新手分析师和程序员中看到这一点。他们只是回答客户问他们的问题。他们不考虑-他为什么要问，他真的需要吗？随着时间的流逝，这会过去，但是首先您必须抓住并解释。

“您能将此系数的小数位数增加到4吗？” - “当然”。但是这个系数没有被用来索引参数，其精度为小数点后1位，并且值不超过50？所有系数的准确性都会舍入。所以也许最好不要这样做？

“在命名参考中添加此类型的新字段”-“好。15分钟的复杂性。” 那么，为什么在术语中需要此字段？这是一个因党而异的特征。将此字段添加到各方目录中也许更好？

ERP中的开发人员不必只是用户所做更改的实施者。他需要了解系统的逻辑，并充当防止一切废话的保护者。为此，最好至少在常识水平上理解业务流程，并能够向用户提出不舒服的问题，这将是很好的。

因此，如果其中一位用户从未诉诸于拒绝执行其愿望清单的程序员的冒昧行为，则该开发人员应仔细研究。也许他只是按照他们说的去做。而且这很少以好的东西结尾。

缺乏耐力以对抗将一切抛弃的渴望

当程序员的麻烦不是由开发人员创建，而是由他们的纵容造成的，就是这种情况。

任何严肃的产品不仅具有一系列特定功能，而且还具有意识形态和最佳实践。人们想用旧的方式工作。他们给程序员施加压力，要求他提供这个机会。而且，如果他不能证明不应该这样做，那么一切都会令人遗憾地结束。

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

该怎么办？首先，不要让程序员服从经济服务。他必须在另一个部门工作，并且要独立于工作自动化的部门的管理。

最好在此链上添加一个链接：任何重大改进都不仅应由承包商批准，而且还应由了解整个企业业务并拥有权力的人批准。这样的人肯定可以说：“不。”

通过编程解决所有问题的习惯

对自动化的热爱会带来进步，但有时会带来伤害。我目睹了这种输入是如何自动执行的，而不是指示人们手动将数据输入到系统中。自动化，忘记了一些本来必须引起注意，讨论和最有可能通过手动输入进行纠正的细节或功能。如此-每个人都可以确定没有错误，但是过了一会儿，后果就整体显现出来了，这已经比根本原因要难得多了。

, , . , , , . . , . , , . : .

因此，当要求程序员编写脚本来修复由于用户未按照说明进行操作而引起的200个错误时，则他不应急忙进入键盘。我们需要估算手动修复一个错误所需的时间，如果手动修复所有错误的时间没有超过编写脚本的复杂性一个数量级，请让用户自行修复这些错误：将来有更多机会根据说明进行操作。通常应将其引入，挂在程序员附近的墙上，以便他可以将所有访问者戳入这张纸。

此外，出于某种原因，我们认为，如果人们由于自动化而摆脱了日常工作，他们会做些有用的事情：他们将开始提供改进业务流程，优化报告的想法，并培训经验不足的同事。但是最有可能的是，他们只会有更多的时间来喝茶，抽烟休息和上网。值得吗？

自信心

有不应修改的功能。例如，在Axapt中，这就是总体规划。在我的记忆中，我们只触摸了他两次。每次它不是在代码中嵌入，而是一种“斑点”-在合并计划之前或之后执行的功能。即使如此，我也怀念着这些改进。

在不太明显的地方，您不应该爬。区分有经验的程序员和初学者的一个好方法是提供完善的功能：有经验的程序员会感到惊讶和拒绝，可能会建议优化业务流程，而初学者会说：“加油”。

这里可以建议一件事：雇用经验丰富的人员，这些人员已经从其他客户或其他项目中获得了原则上可以弥补的所有障碍。

缺乏发展法规

当我们接受项目支持时，我们要求客户获得的第一批文件之一就是描述开发环境，对象命名规则，禁止和限制的开发规则。最奇怪的是，有时它不会发生。这是一个肯定的信号-代码中将会有垃圾：从经典的缺乏注释开始，到将算法不同分支的目录中的特定值直接写在文本中的情况结束。代码中的垃圾内容是解决业务问题的第一步。

因此，不要谈论“编程是一门艺术。它不是受管制的，但是敏捷又如何呢？就这样。如果您正在开发，那么应该有一个法规。这不是3分：

开发是在dev应用程序上进行的；
在测试应用程序上进行测试；
该代码必须有注释。

这应该是一个完整的文档，包含十页，各节各有一部分：

开发应用程序的要求。
编写问题陈述的要求。
编写代码的要求。
测试要求。
应用程序之间的迁移要求。

通常，按照“让我们快点做，然后再正常地做”的原则完成整个硬编码。它很快就完成了，然后被遗忘了...当有签名的文档指出无法完成时，您可以随时戳入并告诉用户：“它不会很快完成，我被禁止那样做。抱歉，Alevtina Svetozarovna，我很乐意就工人的所有支票发表评论，但随后他们将解雇我。”

孤独和缺乏控制

一个孤独的程序员是邪恶的。总应该有人说：“哦，笨蛋，你做了什么？” -否则，开发人员会放松，忘记规则，忘记责任。这是硬编码开始的地方，可疑的体系结构决策，影响业务的错误。

巧妙地将其称为“代码审查”，这是开发规则应始终遵循的内容。每次修订后，在进行测试之前，应检查代码是否符合开发法规和最佳实践。代码审查将允许：

控制发展质量；
培养经验不足的程序员。

因此，开发人员至少应包括3个部分（两个总是会同意您无能为力，而系统的第三方会大大减少串通的可能性）。他们必须按照内部法规进行工作，其关键点之一是强制性代码审查。

结论

因此，为了减少“程序性违法”的可能性，您需要根据以下规则创建自己的内部开发部门：

该团队必须至少由3个人组成。
这个团队中至少有一个必须具有实施或维护ERP系统的经验，这应该是他的第n个项目，其中n> 3。
理想情况下，开发部门应直接向CEO报告。
最终用户有时必须抱怨程序员拒绝实现他们的某些要求。
即使对于这样一个很小的部门，也必须制定规章制度，否则必须予以惩罚。

当然，这是我的愿景。可以说，对于以上几点，即使我不能满足要求，但一切都完美，我也可以根据自己的经验提出反例。但是，这些建议可以用作形成其打击程序不法行为的原则的起点。

如何避免编程大怒？积分技巧