导致软件无法维护的 5 个 C# 常见错误 - Derek Comartin 解说

编写简洁、可维护、高效的代码是专业 C# 开发人员的标志。 然而，C# 编程语言中的许多常见错误使代码库长期以来成为工作中的噩梦。在本文中，我们将通过总结 Derek Comartin 题为"5 个让您的代码无法维护的错误"的视频中的见解来探讨这些错误。

Derek 分享了他在构建大型业务系统过程中的心得体会，并指出了开发人员--尤其是 C# 开发人员--常犯的五个关键软件设计错误。 让我们以 Derek 的视频为指导，深入了解这些问题。

1.缺乏对状态的所有权

Derek 首先指出了允许多个边界或服务在没有明确所有权的情况下更新共享数据的错误。他以计费系统进入应用程序的另一部分并更改状态为例。 这就导致了数据一致性问题，尤其是当该对象位于系统中的不同位置时。

这种自由发挥的方法会产生错误，开发人员会问："为什么这个数据不正确？"或者 "谁修改的？"德里克强调，必须明确所有权。系统的每个部分都应公开一个定义明确的 API 或方法--负责管理状态。

Derek 建议创建明确的命令和查询，而不是允许应用程序的任何部分修改共享数据。 例如，当您要更新货物时，您需要通过专用界面发出命令。 这样可以提供结构，避免因无法跟踪的更改而造成资源泄漏。

2.隐式代码与显式工作流

Derek 认为，许多系统严重依赖 CRUD 操作（创建、读取、更新、删除），但这导致了隐式工作流。 代码在技术上是实用的，但其功能不够清晰。 如果您的类只支持通用操作，实际的业务工作流程就会被隐藏起来。

以下面这个例子为例：一名司机取走了一个包裹，并生成了提货单。 如果系统只是运行 UpdateShipment，则不清楚字符串变化（如 BOL 编号）是由于取货还是更正。 Derek 指出，我们应该用明确的操作（如 PickupStopLoaded）来取代模糊的更新。

这将使代码更具可读性。 它还有助于异常处理，因为当异常发生时，堆栈跟踪将清楚地显示哪项操作失败了。 显式方法还支持更好的编码标准，因为每个函数都有单一的责任。

3.添加无用的指向性

Derek 接着介绍了间接法--在调用者和目标方法之间插入不必要的层。 他用数据库连接来说明这一点。 控制器可能会调用一个服务，该服务调用一个辅助器，辅助器调用另一个服务，最后辅助器通过Entity Framework执行查询。

这种金字塔式的抽象结构增加了追踪问题和提高性能的难度。 虽然创建抽象是有用的，比如封装 IDisposable 接口以更好地管理资源，但 Derek 提醒大家不要过度。 扪心自问，您的抽象是否简化了应用程序接口，或者是否只是隐藏了仅存在于一处的第三方依赖关系。

Derek 建议直接管理耦合，而不是为了分层而分层。 过多的间接性不仅会使代码混乱，还会增加内存泄漏的可能性，削弱垃圾回收的优势。

4.玩 "假设 "游戏

Derek 指出的下一个错误是为可能永远不会发生的假设用例做准备，他称之为 "假设游戏"。许多 C# 开发人员编写灵活的类和函数，以满足未来的需求。 例如"如果我们需要支持两种语言怎么办？"或 "如果我们需要转换技术怎么办？"

Derek 警告说，这种思维模式会导致臃肿的框架和过于通用的代码。 他提到会遇到字符串连接逻辑和引用类型包装器，这些东西没人能理解，因为它们只服务于一个实际用例。

Derek 建议将重点放在实际需求上，而不是为未知做准备。 每个方法和变量都应具有当前合理的用途。 未使用的功能只会增加维护成本。正如 Derek 所说，这不仅仅是开发时间的问题，更是拥有成本的问题。举例来说，如果你的公共 bool Equals 实现涵盖了你能想象到的所有边缘情况，但却没有一种情况会实际发生，那么你就浪费了宝贵的时间。

5.未正确管理工作流

最后，Derek 讨论了将工作流视为程序块而非模块化步骤的错误。 他举了一个现实世界中的例子：在线下订单。用户完成结账后，系统会从信用卡中扣款，然后发送一封确认电子邮件。

如果一个步骤失败，例如支付过程失败，您的代码会如何反应？ 您会退回订单吗？ 显示错误？ 发送失败邮件？ Derek 解释说，将这些内容整合到一个模块中会造成难以管理的复杂性。

他建议将工作流设计为通过消息传递进行交流的小型独立单元。 使用异步任务操作和收益返回使这些步骤更易于管理。 此外，在文件访问或数据库连接等外部资源周围使用 using 语句和 using 块有助于防止内存泄漏。

例如，流周围的 using 块可以确保流得到正确处理--这在使用 IDisposable 接口时至关重要。 当工作流程变得复杂时，这些最佳实践可确保捕捉异常并有效处理，从而保持性能和可维护性。

总结：编写整洁、可维护的代码

正如 Derek 在 12:45 分的视频中所总结的那样，他对这些错误的反思不仅是他所看到的，也是他个人在构建大型业务系统时所犯的错误。 这些都是经验之谈，他鼓励观众在评论中分享自己的错误。

Derek 的建议不仅适用于 C#，也适用于许多其他语言。 无论您是在使用字符串比较、Equals() 方法，还是在设计新功能，关键都在于清晰、明确，以及保持代码的可维护性。

如果您对提高 C# 技能和避免这些常见错误感兴趣，Derek 的频道提供了许多有关系统架构、设计模式和实际编程语言建议的免费资源。只要避免其中一个错误，就能大大提高项目质量。

因此，下一次当您开始编写代码时，请记住德里克的话，并问："我是否将其复杂化了？

如需了解更多类似内容，请访问 Derek Martin 的 CodeOpinion YouTube 频道。