我正处于开发阶段，遇到了架构问题。我已将其归结为以下选项，无法确定哪个最佳。也许（最有可能）那里有一个完全不同的更好的解决方案，我的问题将帮助其他人制定未来的建筑计划。
V1 ------------------
usersModule - fns：private A B C
adminModule - fns：私有X Y但也是C（与usersModule中的fn相同）
编译成users.js（仅限usersModule）和admin.js（仅限adminModule）
V2 ------------------
usersModule - fns：private A B，public C
adminModule - fns：private X Y并抓取usersModule.C
编译成main.js（包含usersModule和adminModule）
V3 ------------------
shareModule - fns：public C
usersModule - fns：private A B并抓取shareModule.C
adminModule - fns：private X Y并抓取shareModule.C
编译成users.js和admin.js（usersModule with sharedModule into users.js，adminModlue with sharedModlue into admin.js）
V1提供最小的文件大小，但是没有：不要写两次相同的fn-C。
V2编译为最大文件大小，因为usersModule和adminModule都编译成一个main.js. adminModule只需要fn-C，因此在所有usersModule中编译都是浪费。如果用户登录，则不需要任何adminModule代码。更大的浪费！
V3提供最小的文件大小，只有所需的代码，似乎是明确的选择......但是......现在添加：
login.php传递加载admin.js或users.js的html标头。它还将数据加载到js全局空间：userInfoJson和adminInfoJson。
usersModule将userInfoJson和adminInfoJson解析为privateavailableInfo1和usefulInfo2（其中一些由fn-C使用）。类似地，adminModule将adminInfoJson解析为可私有使用的变量。
坚持使用V3，如果admin登录，则userInfoJson永远不会被解析为usefulInfo1和usableInfo2（因为userModule永远不会被编译成admin.js），现在fn-C（来自sharedModule.C）不起作用。
所以V3出局了吗？或者我们是否将代码添加到sharedModule，将userInfoJson和adminInfoJson解析为公共变量？或者V2真的是更好的选择吗？或者有更好的方法吗？
答案 0 :(得分：0)
我最终将所有共享方法移动到lib模块。 （顺便说一句，我正在使用揭示模块。）
然后Grunt与用户一起为userMain.js和lib与admin为adminMain.js联合lib。
到目前为止，这项技术运作良好。