Open Gentlegay opened 9 years ago
目前我在公司再做基本架构，基于2个概念，”前后端分层“和”模块化“， 首先想到的就是使用seajs+spm的支付宝开发方式， 原因大家可以猛戳。。。, 但是seajs配套工具spm,出现以来一直问题多多，其它只要按照规范去写， 也没什么太大问题，但是在开发中还是遇到了一些没办法解决的坑。 这就是坑。 打包慢，我上个项目因为完全实现前后端分离,如果有复杂的代码库，spm又不支持单文件打包，所以每次修改个小东西打包至少都要3分钟。 不支持md5,前端开发遇到的最痛苦的事情就是缓存，而解决缓存的方法无非加时间戳或随机数，spm并不具备，那么我就选择fis。 不具备像fis的辅助开发功能，比如文件监听，但是fis有没有像seaJs一样完整的套件和开发方式,fis打包seajs会把一些关键字删掉。 但是割舍不掉。 spm会自动生成js的debug文件，这样在真实环境调试会方便很多。 spm是为seajs定制的，使用方便。 包依赖管理，spm合并代码时对于包扫描，还是相对简单，不用配置很多东西。 可不可以根据场景为技术导向的开发模式？ seajs最大优点有一套成熟的套件和模块化开发方式，那么我们可不可以把我的前端开发方式也剥离开。 组件开发组 项目开发组 组件开发
目前我在公司再做基本架构，基于2个概念，”前后端分层“和”模块化“， 首先想到的就是使用seajs+spm的支付宝开发方式， 原因大家可以猛戳。。。, 但是seajs配套工具spm,出现以来一直问题多多，其它只要按照规范去写， 也没什么太大问题，但是在开发中还是遇到了一些没办法解决的坑。
seajs最大优点有一套成熟的套件和模块化开发方式，那么我们可不可以把我的前端开发方式也剥离开。
这部分因为功能单一，因为为多个项目提供引用的问题， 不能随便修改，而且每个完成版本都要做非覆盖方式的发布，以保证引动的项目不出现问题， 所以我们要做的工作只是写测试demo，压缩打包，这样就不需要fis强大的功能，直接使用spm就可以了。
这部分东西有很深的业务场景，功能比较复杂，我们这部分也可以分成2部分， 一个是项目级别的组件加载器，一个是页面级别的js代码，主键加载器还是使用spm打包压缩 页面级别的js代码直接使用fis做为管理工具，这样我们就完美结合了3者的优点。
Q:如果通用组件不满足需求或者有bug怎么办？
A:每个公共的组件都需要要有对应的owner,可以找Owner解决组件问题，解决后会提供新的版本，项目中只要修改对应版本号就可以了。
Q:两种方式并存是不是很麻烦？
A:其实具体到项目开发，项目中刚开始不需要对加载器编译，只有在项目发布的时候做一次性编译工作，好处和坏处总要有个选择，麻烦是麻烦了一点， 但是你可以看看aralejs，很多现成的东西都用，是发布难，还是写一套规范的可维护的代码难呢？
Q:学习成本是不是有点高，如果要在一个公司里推这套东西，怎么推？
A:这个工作是先苦后甜的活，要知道我以前项目早期使用传统开发方式，bug修复率很低，经常改了一个bug又出现很多bug, 而且前端开发的代码时间稍微长些就不记得里面的一些逻辑了，最重要的是我们在一个项目里一直在写重复代码，不烦吗？ 所以大家还是要一起努力，完成前端工程化，这过程中大家要多交流，并且勇于拿出自己写的代码让其他人一起品头论足一番。
前端工程化（战国化）
项目开发组
开发中的其他问题及解决方式
Q:如果通用组件不满足需求或者有bug怎么办？
A:每个公共的组件都需要要有对应的owner,可以找Owner解决组件问题，解决后会提供新的版本，项目中只要修改对应版本号就可以了。
Q:两种方式并存是不是很麻烦？
A:其实具体到项目开发，项目中刚开始不需要对加载器编译，只有在项目发布的时候做一次性编译工作，好处和坏处总要有个选择，麻烦是麻烦了一点， 但是你可以看看aralejs，很多现成的东西都用，是发布难，还是写一套规范的可维护的代码难呢？
Q:学习成本是不是有点高，如果要在一个公司里推这套东西，怎么推？
A:这个工作是先苦后甜的活，要知道我以前项目早期使用传统开发方式，bug修复率很低，经常改了一个bug又出现很多bug, 而且前端开发的代码时间稍微长些就不记得里面的一些逻辑了，最重要的是我们在一个项目里一直在写重复代码，不烦吗？ 所以大家还是要一起努力，完成前端工程化，这过程中大家要多交流，并且勇于拿出自己写的代码让其他人一起品头论足一番。