项目模块化管理-有感于team retro

背景：c# visual sutdio 2010 200+ projects

昨天项目组进行Retro，其中一项就是项目的模块化管理。这个问题存在有一定时间了。经常在修改代码的时候，引入新的dll出现循环引用。

那么，让我们打开all-in-one solution，看看我们这200多个project之间的引用关系。我们项目中的一个成员开发了一工具生成一张图来显式的表现这个依赖关系。看了图之后发现这个确实出乎想象，混乱之极。两个不相关的模块竟然互相依赖；一个model project竟然会依赖一个web project。

那么如何判断project之间的引用或者叫依赖关系呢？每一个Project就好象一个类一样，需要有自己的职责有自己的scope。如果它出现了诸如非内聚的坏味道，那么project肯定会被别的不应该依赖的project所引用或者引用别的不应该已经用的project。

在讨论中，其中一个成员提到一个方法：从业务逻辑出发，如果拿掉A功能，B还能work，A和B之间就不能存在依赖关系。

A需要访问B的时候，B需要提供合适的API，A直接依赖于API，而不依赖于B。当B的逻辑发生更改时，A的代码是无需发生的改变的。这是消除依赖饿一种手法。这其实不正是interface设计的简单原理么，或者说是面向接口编程的基本技巧么？想到这里，发现编程的技巧或者原则在project上都是可以贯通的。

另外一个考虑是如果A和B之间需要共享数据，那么可以用Conext Provider这样的中间层，用于创建维护共享数据，而需要使用这部分共享数据的project就可以依赖于这个Context Provider。 

反思：

如果用对代码同样的细心和技巧去管理projects，是不是就不会出现这样的问题了呢？从这里可以看出，一个项目中开发不仅要关注底层代码的质量，也要关注模块，模块之间的管理。当我们的应用重新拆分组装的时候就逼的我们不得不关注这些了--模块化编程，一切都是可配的！