最近在用nodejs + mysql 做了一个 类似商城的应用(没错,就是这么作死),但事务不多(其实是用户不多).随着时间,市场这边有很多的想法也一步步的在这个项目里实现.但是代码量及项目大小,项目越来越难维护,就想作死一下搞个重构. 目前有这个构思: 1.将数据层的接口封闭到一个项目里,这个项目不对外暴露; 2.服务层按功能划分多个项目(nodemodule之类 ),如 订单系统 就独成 orderModule 的项目包, 商品管理做成 storeItemModule 之类的; 3. 主项目(BOSS)是将 所有的服务层对外暴露的项目,这个项目就想用 supervisor 之类的特性来热加载 服务层 的模块;
这个做法我暂时想到的是可能一个接口要开N个项目窗口来调试... 还有...最后一点我是这个项目的前后端攻城师...
这个做法会不会作死?
@klesh T—T，这方面不足仅能多点去思考和多点找牛人讨论了
重构下，把不合理的地方修正，架构上要可自动化测试。构完就会舒服多了。重写代价很大，也不一定能达到你的要求。再说你这方向太吓人了。
@klesh 主要是看到以前写的代码不堪入目就想些有想法想作死一下......当然现在没有实行过
听起来就很作死的节奏。。。 你这些模块又不可复用，拆了有什么意义吗，这些东西是项目内部的高耦合模块。模块与模块之间相互依赖，对应到 web instance 上面简直是自寻死路啊。原来的内部调用要变成外部调用，中间多了 toJSON/fromJSON 转换浪费资源，将来接口变动时也能搞死人，复杂度也提高了，不科学啊。 模块用文件夹组织就可以了，用单元测试确保各种模块功能正常运行，API或者说功能的暴露通过 express route 控制就可以了吧。单元测试很重要，如果没有要先考虑做这个 supervisor 用来开发调试还可以，生产环境貌似不合适吧。它是每一个文件变动都会触发重启，那在你上传新网站的过程中，要重启多少次啊……在这个过程中还要考虑别的模块在调用这个模块的时候可能会引发的 http error
