网站开发用什么写得比较好,企业网站制作规划,做线上兼职的网站,怎么设网站前端#xff0c;真的是让我哭笑不得的职业#xff0c;从几年前作为打酱油的理想职业到现在的热门职业#xff0c;无疑在这个过程中#xff0c;门槛变高了#xff0c;而且还是非常高。一大堆的框架和库#xff0c;像什么vue啦、react啦、angular啦、webpack啦等等等等。让… 前端真的是让我哭笑不得的职业从几年前作为打酱油的理想职业到现在的热门职业无疑在这个过程中门槛变高了而且还是非常高。一大堆的框架和库像什么vue啦、react啦、angular啦、webpack啦等等等等。让人眼花缭乱 首先说说工作场景。目前做的项目是微信h5相关的选择的是react那一套的技术栈。
现在前端js中基本上已经是普及了模块化的概念从很早的seajs、requirejs到现在的es自带的模块化系统已经是越来越完善。
import request from superagent
import { getToken } from ../../actions/global;
import { Toast } from antd-mobile;
import { getQueryString, url_for, isWeiXin } from ../global_agency;都是通过import的方式很方便的来引用各个模块里面方法但随着项目的不断迭代文件越来越多就很容易会出现下面这种情况。 这就造成了模块间的方法很混乱的传递。这样的情况在一开始是无伤大雅的项目的前期每个模块的每个方法的作用都是很明确的对应着项目的某个地方依然保持着简洁。但是到了项目的中后期就会出现破坏性的混乱。为什么这样说呢试想一下当你某个方法使用的地方从一开始固定的一个变成了后来的不知道多少个方法的迁移以及方法对应模块文件的迁移就会变得特别困难虽然目前的IDE足够完善到已经可以做文件迁移后相应文件位置的批处理了但或多或少的还是让人不安。经历过的人会明白我的感受
混乱也意味着后期开发会越来越难这也意味着代码耦合度高准确的说应该是项目结构的耦合度高。一个模块到处可以使用import引入使用确实很方便却也给我们带来了烦恼。我们要做的就是通过增加模块传递的约束条件来让结构耦合度变低当然代价就是失去这种完全的便利也可以说是规范这种便利。
那么我们应该怎么做呢一图胜千言 如上图所示我们可以建一个中转文件把我们觉得可以统一管理的但又比较分散的模块文件中的方法统一import到这个中转文件中如下图 这就有点像一个中介者模式说形象点就像是飞机场、飞机以及工作人员的关系假设每架飞机都有固定的工作人员但是所有的飞机的工作人员都是由飞机场管理的就算是这一架飞机需要另一家飞机的工作人员帮忙也是要通过飞机场来调控。
我们的代码结构也是一样的道理。这样做的好处是在让结构清晰、可读性变强的同时结构耦合度也降低了到后续我们还能很方便的在各个模块内部做一些适当的封装以满足更多的需求。就像一架飞机里面有机长、副机长、乘务人员等等他们都有不一样的工作职能。
以上就可以是一次架构提升我相信我们的日常工作中可以有很多这样的架构提升的机会。
文章题目是关于前端架构那么有的同学可能就会想:前端还需要架构吗这个问题我自己也不知道其实很早之前就听说过前端架构这个词也只是只见过猪跑没吃到肉。我联想到前端架构之前的第一个问题是在我做的项目快要百八十个文件的时候自己感觉有点乱虽然自己也还可以接受毕竟项目也是在正式环境好好地运行着但是如果这个项目交到下一个项目负责人手里那他的日子就不好过了在我这里的有点乱到了他那里就会变成非常乱。于是我还是为自己积积德去整理一下。
于是乎我在网上下载了一本电子书名叫《恰如其分地软件架构》是之前有幸跟闲鱼的宗心交流的时候他推荐的值得一提的是大公司还是有很多有大家风范的人的。这本书里面都是传授架构的思想并没有很明确的架构的具体方法。所以这是一本好书授人以鱼不如授人以渔嘛。
当我们选择了诸如react、vue、angular等这些技术栈其实我们就已经选择了一整套的现成的架构视图写在哪里、接口调用写在哪里、路由写在哪里等等的做法都已经有很成熟的范式给我们运用。
往往在同一个项目面前会有三种不同的人不做架构的人、选择做架构的人和完善架构的人。
选择了技术栈我们还仅仅是选择做架构的人但是还不是完善架构的人。所谓的完善架构也就是架构提升。就跟刚才说的我们已经选择的技术栈选择了一套现成的架构但是请相信我这套架构绝对不是没有任何缺点了。我们在做项目的过程中可能这也是发现现成架构缺点的过程那么在这个过程中或者在这个过程之后我们可不可以想法设法去完备它答案是肯定的。怎么样才算完备这就要问我们自己了。
