前端项目代码结构的管理

　　总结一下，自己对前段项目结构的构建。

　　匆忙写下，后续修改。

　　对于前端的各种风格，我倒是没有什么所谓，每个人有每个人的风格。我比较在意代码的结构，代码的结构清晰，更容易帮助人理解业务逻辑，而不至于陷入各种api的调用使用中无法自拔，api使用不合理，倒无所谓，每个人都有自己的欠缺，有些知识不够深入，就容易api使用不合理，但是，客户端的性能很强大，这些东西在前期都可以暂时性忽略。

　　1、唯一入口。

　　每一个页面都有一个唯一的入口，即，从文件夹，css，js，html都是从一个入口进入，往深入扩展，让整个结构看起来像一棵树，一层套一层。这样，在无形之中，自己就会将代码写在合适的地方。下一个接手的同事，在梳理代码的时候，更容易熟悉业务逻辑，在不是很熟悉的时候，也会将代码写在合适的地方。

　　2、静态文字，资源的管理。

　　从国际化角度来说，所有显示在页面上的文字都应该抽离出来；所有接口的调用地址，也应该独立存放，根据上面的唯一入口原则，当项目非常大的时候，可以折叠，查找维护起来会更加方便。

　　3、动态数据的管理。

　　在前端构建项目的时候，大多时候都是先写好静态页面，写好交互，再接入接口；后台版本迭代过多的时候，也可能会重构项目，将很多冗余数据，字段去除，整个项目重构，后台重构，往往前端也要跟着重构，这个时候就可以将动态数据静态化，意思是，前期构建好的项目，需要的数据，封装成一个JSON，通过一个格式化数据的js文件，转化过来，之后所有通过接口返回的数据，都通过这个js文件，转化成前端说需要的JSON结构。即，ajax ---> js文件 --->  JSON  --->  页面数据。往后，后端重构，前端样子不变，或者结构不变，我们只要在js文件中将后端返回的新的数据结构，转化成为之前的结构即可，将整个项目的交互和动态数据解耦。

　　4、不同页面交接，入口分发式。

　　现在很多项目都是spa，spa很大一个问题是首屏加载，而更多时候用户是过路式使用，即，只用之中一个功能，用完就走，例如打卡，打完卡就直接关闭页面（没有想解决这个问题）。比较常见的处理方式是：按模块加载，即，打包的时候将每个模块打包成一个js文件，就减少了首屏加载的一部分问题。在不断的迭代中，需求发展着很可能会让多个模块耦合在一起，随着版本的迭代，在项目的某个部分公用多个地方，又不能抽离成组件的时候，整个项目版本迭代过多之后，大多会变得不可维护，难于维护，特别是赶时间，写了代码没有时间去重新整理，就需要一个公用耦合页面入口进行分发，以后维护，还是交接时，都知道应该在哪里写代码。

　　5、第三方组件，二次封装。

　　现在提倡的模式是敏捷开发，各种npm，各种UI库。刚构建项目的时候，用得很爽，抬手间就将项目写完了。但是，现在定制化程度很高，产品经理需求也更多，更加想象不到，用着用着第三方的UI库，特别是多个地方用上的时候，并且UI妹子没有组件化思想，一点点改动的时候，UI库的组件就会变成非组件，最后统一组件的时候，就会发现一个残酷的现实，某些组件写着写着变成了另一个组件，某些本来不是组件的，写着写着变成了组件（写代码没有组件化，别人骂你，你还不能反驳），当某些某些组件变成了新的组件的时候，处理不恰当，新组件跟业务会耦合在一起，如果没有足够的时间梳理，那么，最简单的方法就是拷贝。。。从此，再无组件。

　　6、本来不是组件的，写着写着变成组件了。无解，求搭救。 

　　本文原创，不允许转载，如有问题，欢迎探讨。