有关如何传播面向对象实践的技巧

我为一家拥有250名开发人员的中型公司工作。不幸的是，许多应用程序都陷入了过程性思维之中，一些团队不断交付大型事务脚本应用程序，而实际上该应用程序包含丰富的逻辑。他们还无法管理设计依赖性，最终得到的服务依赖于另一批大量的服务（“泥浆大球”的一个清晰示例）。

我的问题是：您能否建议如何传播这种知识？

我知道问题的表面在于这些应用程序的体系结构和设计不佳。另一个问题是，有些开发人员反对编写任何类型的测试。

我正在做一些改变这种情况的事情（但是我要么失败，要么改变太小了）

• 关于设计原理（SOLID，简洁代码等）的运行演示。
• 关于TDD和BDD的研讨会。
• 指导团队（这包括使用声纳，findbug，jdepend和其他工具）。
• IDE和重构讲座。

我将来打算做的几件事（但我担心它们可能不好）

• 组成一个由OO传播家组成的团队，他们在不同的团队中传播OO的思维方式（这些人每隔几个月就要更换团队）。
• 运行设计审查会议，以批评设计并提出改进建议（即使由于时间限制而未完成改进，我认为这可能会很有用）

。

我在我的教练团队中发现的一件事是，一旦我离开他们，他们就会恢复到原来的做法。我知道我不会花很多时间陪伴他们，通常只有一个月。因此，无论我在做什么，它都不会粘住。

对不起，这个问题让我无奈，但写这个的替代方法是打我的头，直到我晕倒。

不要试图推动OOP，这只会使情况变得更糟。不是因为OOP通常不是一个好主意：而是。但是，因为似乎负责该毛发代码的人不仅缺乏避免这些问题的工具，而且缺乏经验，更重要的是缺乏动力。

希望编写干净代码的人可以在任何给定的范式中进行操作，无论是OOP，过程，功能等。但是，并非所有程序员都喜欢这样，如果您将任何干净代码工具推向那些不希望这样做的人了解了需求之后，您将最终滥用这些工具，就像已经使用的工具一样。您将看到不相关的方法分组为一个类，从不相关的类继承的类，基于反复试验调试而不是有意识的设计的方法可见性集，不应为静态的静态方法和应简而言之的非静态方法，您会浪费时间。

相反，看看您是否可以投资于提高对可维护性和美观度的意识。毕竟，OOP的核心目标与其他任何复杂性管理策略（编程范式实际上就是所有这些）没有什么不同：封装，模块化，松散耦合，相互依赖性低，保持可变状态及其范围OOP当然不是唯一为您提供实现此目标所需工具的范例。

这使我得出了最后一个结论：OOP是一个好主意，它对于某些类型的问题非常有效，但是（而且我是根据自己的经验讲，这里是对一些伟大思想家的解释）问题，这是完全不合适的。当您刚接触OOP时，半程序面条式代码是您所熟悉的唯一替代方法，OOP自然地看起来像是天上的礼物（相对而言），并且您很可能会接近所有问题，例如OOP锤子的钉子。这是自然而然的，将OOP推向（或超越）其局限性是建立OOP技能的好方法，因此，这并非全都是负面的。但是也许（也许）这个特定的代码库根本不需要OOP。也许它将从程序架构中受益更多，

TL; DR：如果您想传播任何东西，那就让它成为（与平台无关的）良好编码实践，而不是任何特定的范例或方法。

您无法让任何不想更改的人进行更改。这就是为什么您所指导的球队恢复了原来的方式。

因此，实际上，您的问题应该是“我如何使开发人员希望更改为面向对象方法？”

从简单开始，从小开始，让事情从那里开始。向单个开发人员显示收益，而不是向代码，其他开发人员或公司显示抽象或哲学收益。

展示各种OO技术如何减少必须编写的代码以及缩短开发时间。几乎所有开发人员都会听取一项使他们的工作更轻松的提案。

然后开始演示OO技术如何导致更容易维护的代码。这种环境中的每个人都生活在担心进行“ 更改 ”而使生产应用程序减少三分之一的情况下。封装是避免这种风险的关键，它使应用程序的每个（即将成为）层都保持与其他层的契约。

我将研究数据如何传递。如果每次变量列表都很长，请考虑将其中一些变量包装在结构中（或喘气！一个类！！！），作为第一步。简单地将数据包装在一个对象中就是层之间契约的开始。

在更广泛的层面上-如果还没有考虑，可以考虑让管理层为此付出努力。管理层需要看到减少缺陷并从更改中降低风险的具体好处。最终，重构过程将导致更快的开发时间，但这是长期的利益。

您的审核小组和OO福音传教士的想法是好的。推动这一议程的不仅仅是您。

我的经验是，从过程思维方式转换为面向对象思维方式是一个很大的障碍。它需要许多开发人员无法忍受的毅力。这主要是因为对OO的基础进行了研究。

组成一个由OO传播家组成的团队，他们在不同的团队中传播OO的思维方式（这些人每隔几个月就要更换团队）。

是个好主意。这应该是彻底的，应该从头开始讨论OO。当我学习OO时，历史轶事很有帮助。

我也建议

• 因为动机是关键，所以要激励他们详细说明OO如何改善其工作，尤其是代码的可维护性。
• 进行代码审查并展示如何重构应用组成，继承，多态性和模式。
• 引入一个像SCRUM这样的好过程，并使开发人员参与其中。
• 强制阅读“重构”和“重构为模式”之类的书籍。

我同意Shuvo Naser。这是一个很大的障碍，因此请更像是攀爬。学习如何使用OOP设计整个应用程序将需要时间。

1. 确定那些了解OOP的人，并将他们与团队负责人，培训师，设计师，代码审查员等保持更紧密的联系。
2. 使用现有项目作为培训参考。排名第一的人可能在那个团队中。
3. 重构一些现有项目。这可以帮助某些人在其过程代码与OO代码之间架起一座桥梁。从基础开始。他们必须了解何时，何地以及为什么使用这些原则。
4. 让他们与知道自己在做什么的人一起参加设计会议。
5. 将他们与可以提供设计指导的人员一起放在开发团队中，并确保该项目遵循OO原则（假设您之所以要这样做是因为它将改进开发。）

领养很少会先看到好处。我们正在谈论的是复杂的设计，而不是使用TPS报告封面。

您已经有了好主意

您在问题中概述的想法听起来很棒。没有找到成功是一个很大的惊喜。现在是2012年，面向对象的革命已经从最先进的技术过渡到了最先进的技术。除非您的周转率非常低，而且招聘很少，否则您将很难获得几十个甚至一百个优秀的面向对象的固态程序员。

敏捷还是面向对象？

您提到了诸如TDD之类的敏捷技术和一些较新的概念，因此不要因不接受某些管理团队仍在积极奋斗的东西而对人们太苛刻。一些人声称拥抱敏捷，但是当他们谈论敏捷时，这意味着他们所说的意思。该组织的特点不是决策和适应团队，而是强大的分层合同式控制。

但是回到面向对象。您没有提到面向对象的分析或设计，而且我不太确定哪种编程语言会让位给哪种面向对象的编程语言。我知道UML在许多面向对象的程序员中都存在普及问题。经过OOAD的全面培训，我相信这就像在学习您想学习自然语言的国家的文化和历史一样。例如，如果我想学习希腊语，我可以学习字母，词汇和语法，但是如果我忽略了丰富的历史和文化，我会很想念的。无论如何，如果您学习了所有有关面向对象的编程语言的知识，而没有学习有关OOAD的知识，那么我认为已经失去了一个重要的机会。

要克服的问题？

桥太远了？ 如果您要求人们每周，一年内在参与的人们中学习一件事，那将会有很多改变。如果您要求他们更改他们所知道的一切，那么它将受到少数人的欢迎，许多人很难接受，而其他人则不可能。某些更改（如源代码管理）已本地化。您可以从以前不做的事情过渡过来，您进行的培训并不强调内存的限制，有人第一次引导您完成操作，然后每天的工作都非常简单。

其他变化无处不在。例如，转储C并切换到Java要求每天进行大量的培训，设置和大量更改，以采用新的IDE，新的编译器，新的语言，新的API，新的部署模型等。最常与试点计划或公司重组一起发生的事情。

领导一场革命？ 如果当前从事这项工作的人有获得奖励的历史，而公司似乎没有失败的危险，那么他们改变的动机是什么？如果您看起来像是一个局外人，想指出方向并让他们对他们无法预测的结果负责，那么看来似乎所有的风险都没有回报。

职位力量还是思想领导力？ 许多组织都是根据职位权力来运作的。如果您缺乏经理，部门负责人，董事和副总裁的明显支持，则您只是想法领袖。有些人处于危险的位置，只有一个主意，却无法招待另一个主意。如果您能告诉他们而不是告诉他们，这将对静默怀疑者和有才华的盟友产生很大的帮助。

支持基础太小？ 在这250个人中进行分类，将他们分为三类：准备好拥抱，愿意学习和不愿意学习。您有充分的理由对一些对更改没有兴趣的人感到沮丧。您不妨推上一根绳子。这是浪费的精力。如果您有谁支持改变，可以找出他们感兴趣的地方。

与医学分类法不同，伦理和实践选择是为了帮助中产阶级获得帮助，您可以根据自己的判断和偏好来投入精力和时间。为了您的成功，为什么不培养准备好接受新想法的团队？他们可能只是第一时间，但就像滚雪球一样，您作为倡导者的知名度和公信力将会提高。很快人们会问您下一次培训的时间。

长期来看吗？ 在培养一个负责人随身携带的东西之前，您应该期望花费时间建立关系。您可能需要在您的教练团队中呆一个月以上。除非团队为自己拥有完善的实践，否则您只是技术或方法上的警察。指导过程可能需要数年时间。您的开发人员不想做很多事情，您认为它们很重要（我认为您特别提到了单元测试）。对由此带来的价值建立共同的愿景可能需要一段时间。我凭经验知道这一点，因为我曾经在一家财富500强公司中倡导一种代码覆盖工具，该工具在质量上享有很高的声誉，但是管理人员和同行都对承诺使用它持谨慎态度。

专家还是基层？ 比起指导，要快得多，因为要获得每个团队成员的基层支持。从一个由十名软件专家组成的团队开始，如果我选择让一个人一直在处理流程，或者让十个人在百分之十的时间处理流程，那么我会选择第二个。草根过程使倡导者可以感觉到方法的影响，并可以量身定制方法以最好地解决拥有工作团队的问题。

你看到自由线了吗？ 引入“最佳实践”的部分目的是使人们放弃以一种共同的方式做事的自由。如果您寻找机会将很多选择留给开发人员，那么放弃程序员的酌处权将更加可口。他们选择的对象是根据我们可以称为自由线的分区所规定的。可能有必要对组织，区域/特定地点，团队和个人实践进行类似，充分合理的划分。

这本来应该是评论，但由于我显然还不能对内容发表评论，因此也可能是一个答案。

在这种突破中，最重要的事情（无论是OOP还是其他范式转换，例如，函数式编程或明年出现的任何事情）都是DO CODE REVIEWS和PEER PROGRAMMING。陪伴他们，带领团队进入一种可以帮助他们的新方法。

我的面向对象程序设计之路始于一些随机的汇编代码审查使我难以以模块化的方式完成工作并维护状态而没有使用完整的C ++ OO。认为代码像

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

（请注意，clients_total可能完全是多余的，这是计划不充分的示例）

最后，只有当更多的高级同事只是指向我的屏幕并说“看，如果您多次编写相同的东西，请使用一个过程或一个函数并反复调用它”，我才结束此操作。

对话和会议以及可选的实践不会使他们进行范式转换或引入新的实践，因为除了纯粹的好奇心之外，没有真正的动力去做。另一方面，不做不好或只是皱眉就可以很好地提高采用率。

为抱怨和面向类的开发做好准备，直到他们将适当的设计融入他们正在做的事情中。您会看到很多东西，这些东西会让您死于一点，但这就是学习之路的样子。