4

我们目前有 3 名开发人员，他们的风格有些冲突，我正在寻找一种为王国带来和平的方法......

编码员：

Foo 1 : 喜欢在公共方法中使用 Func 和 Action。他使用动作来消除冗长的方法调用和 Func 来执行简单的任务，这些任务可以用 1 或 2 行来表达，并且将在整个代码中经常使用

优点：他的代码主体简洁且可读性强，通常每个类只有一两个公共方法，很少有私有方法。

缺点：方法的开头包含其他开发人员不喜欢阅读的 lambda 富代码块；并且，有时，可以包含其他开发人员真的不喜欢阅读的高阶函数。

Foo 2：喜欢为（几乎）公共方法必须做的所有事情创建私有方法。

优点：公共方法仍然很小且可读（对所有开发人员）。

缺点：私有方法很多。使用调用其他私有方法的私有方法，调用...等，等等。使代码难以导航。

Foo 3：喜欢为每个需要执行的非平凡任务创建一个具有单个公共方法的公共类，然后将它们依赖注入到其他对象中。

优点：易于测试，易于理解（一个对象，一项职责）。

缺点：项目被类乱七八糟，打开多个类文件以了解代码的作用使导航变得尴尬。

如果能充分利用所有这些技术，那就太好了……

Foo-1 具有非常好的、可读的（几乎类似于 dsl）的代码......在大多数情况下，除了在方法开始时聚集在一起的所有 Action 和 Func lambda 恶作剧。

Foo-3 具有高度可测试和可扩展的代码，对于某些解决方案来说只是感觉有点“大括号”，并且有一些代码导航问题（在 VS 中不断按 F12 并打开 5 个其他 .cs 文件以找出单个方法）。

还有 Foo-2... 嗯，我不确定我是否喜欢这个包含 2 个公共方法和 12 个私有方法的巨大 .cs 文件，除了它更容易让初级人员深入研究。

我承认我过分简化了对这些编码风格的解释；但是，如果有人知道任何模式、实践或外交策略可以帮助我们三个开发人员团结起来（而不只是告诉他们中的任何一个“停止它！”），那就太好了。

从可行性的角度来看：

  • Foo-1 的风格遇到了最大的阻力，因为一些开发人员发现 lambda 和/或 Func 难以阅读。
  • Foo-2 的风格遇到的阻力较小，因为它很容易陷入。
  • Foo-3 的风格需要最具前瞻性的思维，时间紧迫时难以执行。

关于可以使这项工作的某些编码样式或约定的任何想法？

4

5 回答 5

3

完全不清楚您为什么不喜欢 Foo-2 的私有方法。

您抱怨“巨大”的 .cs 文件——但为什么它会比 Foo-1 的样式大得多？那里有相同数量的代码，只是动作被拆分为方法而不是表示为 lambdas。

老实说，Foo-2 对我来说似乎是最好的选择。只保留您想要公开的公共 API，然后以最简单的方式实现它。虽然 lambda 在某些情况下绝对合适，但 Foo-1 的风格听起来像是把它发挥到了极致——超出了它真正明智的地方。

特别是，考虑您的两个公共方法是否有一些共同的子任务。Foo-1 的方法最终会复制该代码 - Foo-2 的方法会将公共代码放在从两者调用的私有方法中......这对我来说似乎是一种明智的方法。

同样，您谈论私有方法调用私有方法......当然，等效的 Foo-1 代码将是 lambda 表达式调用 lambda 表达式，这几乎没有更好的！

此外，如果您对白盒单元测试感到满意，Foo-2 的方法可以通过单独测试实现的“较小”位来更轻松地测试“笨重”的公共 API 实现 - 诚然迫使您使用内部可见性代替私有的方法，或使用反射。

Foo-3 听起来完全是一种不同的方法，因为它改变了公共 API 而不是实现。这更多是关于设计而不是编码风格，应该单独考虑。

于 2010-12-31T16:57:05.603 回答
2

我想说的是，在你引入新的规则和约定之前，你应该留出一些团队时间，并在你的开发团队中就当前的代码库进行尊重和公开的讨论。让您的开发人员讨论编码风格以及他们喜欢和不喜欢的关于代码库及其混合编码风格的事情。

简而言之，把事情公之于众；这比让感情恶化更健康，即使你引入新规则来解决代码问题，政治也可能会继续存在。

让团队感觉他们被视为明智的成年人，并且他们对您介绍的编码约定有一些投入和影响。

首先尝试一种自我监管的方法总是值得的，如果讨论顺利，你可能不需要强制执行任何事情。

最重要的是：尽量确保每个人都在倾听（包括你自己）。

于 2010-12-31T17:03:58.640 回答
2

对于我的 2 美分，它们都有自己的位置，但不应只使用一种样式，尤其是 1 和 3。样式 1 的代码难以理解，样式 3 导致对象模型难以计算。

聚在一起，试着解决它。这出人意料地难以做到，而且通常更多的是为了获得一致性而妥协，而不是做“正确”的事情。妥协者是这里的无名英雄。:)

富 1

我必须承认我偶尔喜欢使用 lambda 和 funcs 以“协同程序”风格进行编程。但是，这种情况很少见，并且仅在替代方案不那么整洁或无法清楚地表达设计意图时使用。

我真的不认为这种编码风格像一般编程风格（至少在 C# 中）那样好，因为许多其他程序员必须玩编译器才能弄清楚发生了什么——不好。然而，它确实有它的位置。

富二

这听起来像是一种合理的编码风格。私有方法之间存在依赖关系的事实只是小规模的 DRY 工作（如果执行得好）。

Foo 3

使用 DI 并不强制要求使用这种风格，即每个类有一个公共方法。这种风格最糟糕的表现是忘记了在 OO 中我们实际上是在尝试对“事物”进行建模。将一大堆没有可识别对象模型的方法粘合在一起并不是很好，可发现性很糟糕。但是创建好的对象模型很困难。

于 2010-12-31T17:23:04.373 回答
1

方便开发人员遵循严格的准则确实非常棘手，尤其是当出现新的语言功能时，尤其是 Foo-1 开发人员想要使用 lambda。

看起来 Foo-1 和 Foo-2 在使用更多函数式编程方面有一些相似之处。

在你的团队中，主要的开发语言是 C#，它主要是面向对象的，所以你必须尝试将更多的面向对象的方法引入开发，并尝试说服他们使用类/对象来实现可重用代码。其中一项技术是同行评审也会对你的团队成员有所帮助，并不是每一行代码都需要它，但几个开始会议可能会有所帮助，你应该先与他们一起管理/开始这些评审，然后让他们去做。

于 2010-12-31T17:05:10.037 回答
1

我相信你会对此有很多不同的看法，但我的感觉是类的内部实现是隐藏的，对类的使用者并没有太大的影响。因此，Foo1 和 Foo2 基本相同，唯一的区别是 Foo3。我也不喜欢到处都有多个对象。如果我不得不倾向于 Foo1 或 Foo2，我会更喜欢 Foo2，因为它更容易重构并将代码移动到子类中。

于 2010-12-31T17:12:23.857 回答