帮助一个并非永远不会成为职业程序员的人，将可以编写出更清晰易懂的代码，以供使用和解释。

我是猫王，努力学习成为爱因斯坦。我为Mort工作。

这个疯子白痴在说什么！？！？（您只需要阅读前几段）

如果您不想阅读该链接，那么基本上，我是一名专业程序员，而我的老板是（这非常准确）：

缺乏计算机科学学位但对Office和VBA十分熟悉的专业业务线程序员，通常编写在同事之间共享的生产力应用程序

话虽这么说，我的大部分工作是将他拼凑的代码准备好并投入生产。但是，非常差的风格和杂货主义使这变得困难。他不愿意阅读编程书籍或不愿意让我帮助他重构代码，这使情况更加复杂。

还有其他一些策略可以帮助不是专业程序员的人，也永远不会成为专业程序员编写对我而言更易读和易用的代码吗？

在查看您在数条评论中的回答时，我不知道您是否意识到自己遇到的事情很普遍，尤其是在需要领域专家（让他们称为科学家）的专业领域工作时，结合并定制解决手头问题的算法。

与其抱怨抱怨科学家并期望他们改变，不如说您不应该期望科学家对“代码质量”太在乎。通常很难让其他软件开发人员关心“代码质量”，更不用说主要关注领域而不是编程的人了。

您从何处去很大程度上取决于“科学家”对您理解他们的工作的能力的信任程度。如果他们有信心您可以理解他们的代码，并且在修改内容时不会把代码搞糊涂，那么通常就没有问题了。他们将依靠您的专业知识。

但是，如果科学家不希望您更改他们的代码，那么很可能您还没有“赢得”他们的信任。如果是这样，那么您应该专注于“修复”自己，而不是专注于修复科学家。我的意思是要采取步骤获得他们的信任。可能最简单的方法如下：

作为测试过程的一部分：

1. 开始将算法转变为更容易理解的内容（例如图表，PDL，数学符号）
2. 学习了解算法。
3. 确保确定边缘情况。
4. 询问科学家您简化的“替代”表示是否正确
5. 最重要的是找出您发现的问题；并且没有听起来“有指责”，而是说“我正在查看算法，发现XYZ应该执行此操作还是应该执行该操作？”。没有什么比这枚子弹更能赢得他们的信任了。

一旦您开始发现错误并且对他们感兴趣的领域表现出了兴趣，那么可能性至少会变得更高，至少它们会让您开始修改代码以使其更“专业”。通常，他们甚至不再觉得需要编写原型了。他们只是用您已经教过的“替代”表示法之一写东西（他们甚至没有意识到），他们会相信您会明白它们的意思。

无论如何，我的第一个尝试是就科学家如何最好地帮助更好地“交流”以提供帮助的建议。但是听起来您已经尝试过了。因此，您掌控的唯一步骤就是您要做的事情。赢得他们的信任，领域专家几乎总会放心地将代码传递给其他人，而不必担心编写代码的所有小细节。他们宁愿专注于改进算法。

有时候，您所能做的就是提供建议，然后再提出。如果您不断对他们已经拒绝的事情或决定他们不想做的事情进行举报，即使您100％正确，您也不会给您的老板或前辈留下深刻的印象。实际上，无论您是推荐人还是被推荐人，这都会破坏关系。只需专注于可以使您的工作更轻松的方法即可。

正如您所说，当他真的是“不是专业程序员的人，永远不会成为专业程序员”时，而当您的大部分工作确实是“将他拼凑的代码并准备好投入生产”时，听起来就像您当他将编程留给您并专注于项目的管理部分时，两人团队会更有效率。

但是，这假设您是对的。我们程序员总是倾向于忽视别人编写的代码，这要比我们自己编写的代码差得多。这种先入之见确实很难击败，并导致我们低估了我们的同事。从他的角度来看，您认为“货物崇拜编程”可能是“经过验证的最佳实践”，而他认为“过分应用面向对象模式”可能对他来说是“不必要的过度设计”。我很难说，因为我只知道你的故事。

我们的编程风格越不同，对他人代码的蔑视就越强烈。在那种情况下，这是一个积极的本能，因为在一个项目中混合使用不同的编程样式会使维护变得非常困难。

当你们俩都无法模仿对方的风格时，您可以定义明确的职责。让一个人对应用程序的一部分负责，另一人对另一部分负责。一起在两个模块之间定义清晰的接口，但将内部实现留给责任一人。为了使他更清楚自己代码中的错误，您可以为他编写单元测试，并指出何时他的代码明显不符合您一起指定的接口协定。

通过建立明确的代码所有权，您可以更好地共存各种样式。同样，当你们俩都有责任修复各自代码中的错误时，您不必经常浏览彼此的代码。

您必须问自己：您的最终目标是什么？1.帮助你的老板？2.帮助公司？3.帮自己吗？在回答“以上所有问题”之前，请放慢速度。您的首要任务是明确定义您的主要目标，因为答案取决于它。

如果您的目标是：

1. 帮助你的老板？放弃。他似乎没有要求。您说：“他知道自己的代码不好，但是可以满足他的要求。” 好了，讨论结束了。除非并且直到您的老板对当前状况不满意，否则他不会改变，他会不满您的帮助。如果将来某个时候他确实感到现状的“痛苦”，那么希望您将自己确立为值得信赖的导师，并且他会知道该向哪里寻求帮助。

2. 帮助您的公司？当前局势是否在威胁底线？截止日期有风险吗？高层管理人员是否正在发热量？如果不是，则放弃。（这实际上是Jimmy Hoffa在对您的原始帖子的评论中指出的观点。）但是，如果当前的情况确实对您的部门/公司构成了无法接受的风险，那么就必须进行流程更改。在这种情况下，我建议您坐下来，勾勒出不同的轮廓分工。这里的关键是要说明，花在重构老板代码上的时间最好花在编写新代码上。您说您没有时间自己编写所有内容，但这不是我的建议。您需要弄清楚如何最大程度地发挥各自的优势。不要再将他视为Mort，而应将他视为具有高级领域知识的初级开发人员。这是行业中非常普遍的工作安排，您应该学习如何在其中蓬勃发展。例如，确保他知道您知道他的专业知识很重要（经常重复此步骤），然后谦虚地建议采用以下策略（或类似方法），作为将其知识推向市场的更快途径：（a）将工作分解为“敏捷”冲刺，（b）在每个冲刺中进行大量的前期协作以定义-所有要求和体系结构。（c）在构建上一步中约定的基础结构时，让他离开并构建原型以解决所有算法决策。（d）在他构建测试进行验证时，将他的算法应用于您的结构。（e）在同伴编程环境中一起进行V＆V。（例如，“此测试失败；为什么？算法逻辑错误或编码错误？”；请在此处进行迭代）。

3. 救命 在这里说实话。如果您所做的只是抱怨您不喜欢工作，我建议您需要花更多的时间考虑上述＃2。如果您不关心公司并且不喜欢您的工作，请开始分发您的简历。如果您确实关心您的公司但不喜欢您的工作，那么专注于＃2应该对两个帐户都有帮助。但是，在那种情况下，只有所有人都清楚您的热情确实来自对团队的渴望，而不仅仅是因为您对工作的自我挫败感，才算是“双赢”。

我不确定是否会在此讨论中添加一些内容，但是在类似的情况下（访问冲突与 ShowMessage('Hello');或类似，只是发现同一行在屏幕外有更多代码。对，

我相信您有两个基本选择：

1. 让代码运行。如果代码可以正常工作并且正在执行应做的事情，除非您的老板特别要求您修复他们的代码，否则请保持原样。这也可能使他理解您的代码看起来更好，并将工作留给您（Dunk在回答中也指出了这一点）。
2. 如果您决心使代码变得专业，请构建他可以使用的库/框架。如果您通常能解决一些错误/策略的模式，则可以将这些错误/策略打包成几个库文件，并将其作为“公司的基础库”提供给他，您也可以将其用作通用接口。