您何时决定将大型项目拆分为较小的项目？

Question

何时/何地决定将大型Visual Studio项目拆分为较小的多个项目？如果它可以重复使用？什么时候项目太大了？(但有多大太大了？)

当你拆分项目时,你呢,

• 按数据库表分组

• 按类似功能分组

• 其他..

Answer 1

许多项目的优点:

• 更容易隔离代码进行单元测试.我喜欢隔离依赖于大型外部服务器的代码,例如与SMTP服务器通信的代码获得自己的程序集,与数据库通信的代码获取自己的程序集,与Web服务器通信的代码,代码是纯粹的业务逻辑,如验证.

少数项目的优点:

• Visual Studio变得更快
• 一些开发人员只是没有实现分担责任的愿景,并且会开始在各地开设课程,因此您最终会遇到额外项目的痛苦以及将所有项目放入一个项目的好处.
• 每个项目都有一个配置,当您决定项目配置时,通常您必须在任何地方制作相同的chagne,例如设置或更改强名称密钥

许多解决方案的优点

• 您稍后达到了最高项目级别.
• 每次点击f5时,只会编译当前解决方案中的内容
• 如果预计项目在应用程序的生命周期中不会发生变化,为什么要反复重新编译？称之为完成并将其移至自己的解决方案.

许多解决方案的缺点

• 由您决定解决方案之间的依赖关系并首先手动编译依赖关系.这导致了复杂的构建脚本.

Answer 2

项目应该具有凝聚力.逻辑应该是相关的,并实现类似的目标

这个答案取决于您支持的产品的大小.通常,我们按照域和逻辑组织项目.我们将进一步划分,你划分的越多,你必须做的越多,或者你将遇到可怕的递归依赖问题.

当我选择拆分项目时,它会变得太大或两个区域变得太相似.

当复杂性上升时,我不会按表拆分,我通常会分割功能.

可重用性是减少代码行的另一个绝佳时机,同时也是一个新项目.但是要小心你引入了多少"实用程序"库,因为它们确实会影响可读性/可理解性.

我不认为沙子中有一条线说,如果你达到3k SLOC,你就会有太多.这一切都是语境.