Stackoverflow 用户，
您如何避免使用大型主体方法创建大型类。当最后期限很紧时，您最终会尝试将事物拼凑在一起，最终会变得一团糟，需要重构。
一种方法是从测试驱动开发开始，这有助于良好的类设计和 SRP（单一责任原则）。
我还看到开发人员双击控件并在触发的事件方法中逐行输入。
有什么建议么？
问问题
297 次
7 回答
8
我想这取决于你的内部流程。
在我的公司，我们实行同行评审，所有提交的代码都必须由另一个开发人员“加入”，你必须向他解释你的代码。
时间限制是一回事，但如果我审查具有令人发指的长类的代码，那么我不会同意签入。
一开始很难习惯，但归根结底，这对每个人都有好处。
此外，拥有一位拥护良好类设计并且愿意并且能够提供示例的高级开发人员也非常有帮助。
最后，我们经常进行编码“展示和讲述”会议，向同行展示我们的工作，我们应该不要用丑陋的代码来做这件事！
于 2010-06-03T13:24:00.797 回答
1
使用 Resharper 之类的工具和提取方法命令。
于 2010-06-03T13:29:07.787 回答
1
长类是许多可能的不良代码气味。
通过创建大量小类来补救过大的类可能会产生其自身的问题。您项目的新工程师可能会发现很难按照代码流来弄清楚在哪里发生了什么。这个问题的一个产物可能是非常高的调用堆栈，执行嵌套在许多小类中。
于 2010-06-03T13:38:26.517 回答
1
另一个建议是只做被问到的事情。不要玩“假设”游戏并尝试过度设计解决方案。这背后有“保持简单，愚蠢”的想法。
于 2010-06-03T17:37:15.680 回答
0
我们是一家 java 和 maven 商店，其中一个......我想你可以说我们使用的取证方法是优秀的 FindBugs、PMD 和 javancss 插件。所有人都会对方法中的长度过长发出警告，并且圈复杂度计算可能非常令人大开眼界。
于 2010-06-03T16:51:48.173 回答
0
对我来说，要避免经常违反 SRP 的大型类，最重要的一步是使用简单的依赖注入框架。这让我不必过多思考如何将事物连接在一起。我只使用构造函数注入来使设计免于循环。Resharper 之类的工具有助于从构造函数参数初始化字段。这种组合导致创建和连接新类的开销几乎为零，并且隐含地鼓励我更详细地构建行为。
如果数据与行为分开，并且您的语言支持诸如事件之类的构造，这些构造可以用来解耦在依赖图的向下方向流动的通信，那么这一切都最有效。
于 2010-06-03T17:34:02.427 回答
0
在您的自动构建中使用一些静态代码分析工具并编写/配置/使用一些规则，以便例如有人在他/她破坏它时必须写一个理由..
于 2010-06-03T17:35:51.120 回答