中小型规划项目方案计划前端架构.docx

中小型规划项目方案计划前端架构 中小型规划项目方案计划前端架构 PAGE PAGE / NUMPAGESPAGE20 中小型规划项目方案计划前端架构 PAGE ,. 中小型项目前端架构 ,. 一、为何要有一个好的架构 第一明确一点， 架构是为需求服务的。前端架构存在的目的，就我个人理解来说，有以下几点： 提高代码的可读性 一个好的架构，代码的可读性必定是很强的。 简单来说，若是有一个新人加入团队，那么他接手这个项目，必定是简单上手的，能简单轻松的认识整个前端 部分的互相关系，进而找到自己需要要点关注的点。而不是需要花好多时间去熟习这个项目的好多细节，才能 开始上手做东西。 就文件来说，能够从文件名上，分清哪些是页面、哪些是逻辑、哪些是款式、哪些是能够复用的组件、哪些是 图标组、又有哪些是挪动端或是 PC端专享的款式 /逻辑等。 就代码来说，包含一致的命名风格，封装在同一个文件里的代码的有关性足够强等。 提高代码的可保护性 ,. 一个好的架构，必定是易于保护的，比如在新增需求、改正需求、修正 bug，都不会造成预料以外的变化，比 如说改正了一个页面组件的内容，却致使此外一个页面组件发生变化（这也太坑了）。所以，要低耦合，高内 聚，以及输入和输出是可预期的。 提高代码的可扩展性 一个好的架构，必定扩展性要强，不可以写死。 需求改正太 TM正常了，新增需求也太 TM正常了。所以好的架构，一定要考虑到这些状况的发生，因为这些 是必定会发生的。所以，必定要防止把代码写死。 比方页面组件A里需要有一个日历组件，而这个日历组件引用的是他人的（比方从量不要直接在页面组件A里面直接引用这个日历组件，而是将写一个日历组件引用的日历组件C，而后经过这个日历组件B来进行操作。  github 上找的）。那么尽 B，在这个日历组件 B里封装你 原由很简单，若是某天产品经理说，这个日历组件太丑了，我们换一个吧。假如你直接在页面组件 个引用的日历组件 C，你很可能就要改好多代码（因为不一样日历组件的使用方法和裸露的接口可能不一样）。假 如你还在其余多个地方引用了这个日历组件，那就更糟糕了！每个地方都要改。  A里内嵌这 ,. 而若是将引用的日历组件C封装到自己写的日历组件B之中，那么你只要要他日历组件而因为日历组件B裸露的接口是不变的，那么自然不用改正页面中的代码了。  B里的相应代码即可， 附图，以日历组件为例，能否考虑到扩展性的结果 未考虑到扩展性： ,. 考虑到扩展性： 便于共同 包含前端和后端的共同，前端和前端之间的共同。 详细来说，前后端的共同往常是以 ajax为交互，那么应起码有一个用于特意封装了全部 ajax恳求的文件，所 有ajax恳求都封装在这里。在开发时，这里封装的方法应当能够模拟发送和接收商定好的交互内容，方便开发联调。 ,. 而前端和前端的共同，主要表此刻同时在改正代码时，不会影响对方代码的正常运转。所以要求封装、解耦以 及低扰乱度是一定的。 自动化 自动打包，压缩，混杂，假若有必需，再加上自动单元测试。 总结：总结来说，一个好的架构的目的是，让前端写代码写的舒畅，让后端联调的舒畅，让产品经理改需求改 的舒畅。 二、我怎样设计架构 我不敢说自己的架构是好的架构（明显不是啦），只好分享自己近来做的一个项目，它的架构的怎样做的。 ,. 第一，确立需求： 1 、一此中小型网站，同时面向挪动端和 PC端（单端大体 15个页面，算上弹窗大概 20个）； 2 、估算有限（给的钱少），开发时间有限（一个月）； 3 、可能存在必定程度上的需求改正（比方增添页面或改正某些页面内容）； 4 、客户可能不太在意优化（可是我自己在意啊）； 5 、要求兼容IE9以上。 其次开始决定： 1 、兼容IE9以上说明能够使用主流框架，而无需一定使用 jQuery。所以我采纳了vue，版本是 ； 2 、估算有限，时间有限，所以 PC端和挪动端共html 和js，独立css； 3 、页面有限，所以无需将架构层级区分的比较细，只要要按其种类区分即可； 4 、依据原型图来看，页面复杂程度有限，复用部分不是好多，所以能够确立哪些东西需要封装复用，哪些比较 复杂需要独立封装，哪些比较简单为了简化开发难度能够直接耦合； 5、自己比较娴熟单页面网站，所以采纳以单页面为主，异步加载其余页面的形式。 ,. 于是使用有关配套的东西，比方 webpack ，vue-router 等，此外为了开发和生产的方便性，采纳以下模式进 行开发。 ,. 第三，区分功能： 第一有一个根 html，用户需要经过接见它来加载我们的 js逻辑，所以 js逻辑的代码被写在 之中。 在 之下，我们的前端代码能够被区分为三部分： 组件树 功能模块 各样资源 以下列图： ,. 功能区分好以后，同样功能的放在同