一旦大型项目达到一定程度的复杂性，我就会变得不知所措。一旦到达项目中的某个特定点，我的进度就会缓慢地爬行，并且发现自己不断地追踪自己的步骤并理清各种混乱。

由于我的这个弱点，我真的很擅长重构。而且我总是尝试将对象分解为更小，更易于管理的对象。这种弱点也可能导致我过多地注意正确设计事物。

我知道如果我可以将问题分解为较小的问题，那么我将能够顺利完成任务。想到的一种策略是测试驱动的开发。我还可以做些什么？

停止思考代码

开始考虑层，功能，模块，服务和其他更高级别的抽象

您不知所措，因为您考虑的水平太低

使复杂简单是容易的 ; 等待，以为是另一回事。

每个人都为此而苦苦挣扎，没有直接的解决方案具有极高的效力。

由于您没有在问题中列出此内容，因此我的建议是：

通过以下方式关注功能凝聚力：

单一责任原则规定，每个对象都应具有单一责任，并且责任应完全由类封装。它的所有服务都应严格地与这一责任保持一致。

如果您在首页的搜索结果中使用Google进行搜索，则会发现两个很好的资源：

• 罗伯特·C·马丁（Robert C. Martin）的“ 单一责任原则 ”（Feb / 2002）：该原则讨论了将因不同原因而发生变化的事物放置在不同类别中的必要性。
• 杰夫·阿特伍德（Jeff Atwood）的“ 卷毛定律：做一件事情 ”（2007年3月）：“单一责任原则”指出，一个班级应该只有一个改变的理由，而只有一个。

计算机科学的凝聚力是什么？

内聚性是衡量单个模块的职责之间相关性或重点程度的度量。当应用于面向对象的编程时，如果服务给定类的方法在许多方面趋于相似，则该类具有很高的内聚性。在高度内聚的系统中，代码的可读性和重用的可能性增加了，而复杂性却保持了可管理性。

在以下情况下，内聚性会降低：-通过类的方法访问的，嵌入在类中的功能几乎没有共同点。-方法通常使用粗粒度或不相关的数据集来执行许多不同的活动。

内聚力低（或“内聚力弱”）的缺点是： -理解模块的难度增加。-维护系统的难度增加，因为域中的逻辑更改会影响多个模块，并且一个模块中的更改需要相关模块中的更改。-重用模块的难度增加，因为大多数应用程序不需要模块提供的随机操作集。

如果您有任何疑问，请告诉我。

将要素分解为最小的项目。例如，表单上的单个字段。选择风险最高或优先级最高的一个，然后像一个简单的错误修复程序一样前进，而不是一个大项目。的确，稍后您将进行一些重构，但是至少您会继续前进。

根据我的经验，您已经用有关TDD的评论回答了自己的问题。对我来说，我常常和您一样，一旦系统达到一定规模，早期的快速成功很快就会陷入对次要细节的困扰。我发现使用TDD会有所帮助，因为您可以将系统的每个部分都当作一小块来解决，因为您知道系统的其余部分将在您离开系统后继续工作。我还认为，借助TDD，它有助于确保您的系统清楚地分为可独立测试的较小块。

有些人擅长设计模块化，易于理解的程序，但是大多数程序员或多或少都缺乏此功能。我知道，除了可能有很多经验之外，没有书籍，程序或实践可以将第一种类型的程序员转变为第二种类型的程序员。但是我什至不确定。

最重要的是，大多数程序员都将努力超越平庸，少数人会成功（这是我（可能会）把自己以及（也许）IB行业中50％的专业程序员放在的位置），以及少数将是极好的。我应该说，我在漫长的职业生涯中从未遇到过这些出色的人之一：-)

我认为很多人都试图过度设计解决方案。他们采用“亚当与夏娃”的方法，只是稍微实用一点的方法就可以大大简化事情。

专业类不是邪恶的，它们是声音软件设计的自然结果。

在我看来，许多程序员都无法理解这一点，而且我所知道的书都没有清楚地说明这一点。

TDD无疑是有帮助的，它可以让您了解在实践中使用“班级”的“方式”，并且在很多情况下可以节省一天的时间，因为它会在一天初期显示最终的问题/局限性。

最后，如果我是你，我要寻找的另一个非常重要的事情是设计模式。设计模式是比您或我更聪明的人解决编程问题的方式。模式背后的想法，猜猜是什么？不是将它们用作食谱，食谱，而只是认真思考并首先了解您的应用程序领域。

明智地使用模式将大大减少您必须管理的细节数量。

围绕您的需求而设计的良好设计模式库将证明是无价的。让我们看一个非常简单的示例，将其放在上下文中：

想象您有一个表单，当按下按钮时，其他表单必须更新。这是典型的“观察者”模式。您有一个主题和几个观察者，他们将自己注册为该主题。为什么需要实现一个接口？您可以只添加方法，或者更好的方法是，为观察者使用接口，为主题使用通用列表。现在，您可以两全其美：观察者具有独立性，并且在主题上没有烦躁不安的事情。

希望这对您有意义！

安德里亚

当我们忽略抽象需求时，可能会出现开发速度和可读性的问题。在我工作过的一些大型代码库中，最常见的敌人是数量众多的专用类，它们具有非常相似的功能，导致代码膨胀。如果退后一步，而不是作为应用程序的一部分来整体理解需求，那么我们就会想到很多抽象。

一些简单的步骤对我有帮助

• 使用相似性分析器（如Simian）在整个代码库中查找重复的代码块。大量重复的代码意味着更少的抽象。
• 监视类和方法的大小，大类和方法意味着很少有服务或控制器成为神灵。
• 强制进行单元/集成测试，使您有信心重构，也可以作为规范。
• 每两周对企业进行一次回顾，以了解他们使用的技术/业务/领域术语是否反映在类名称中。这有助于理解和获取一流集合的名称，而不是表示为简单的集合和列表。当我们与商务人士坐下时，一些我们从未想到的抽象也将浮出水面。