Blog

Blog

PHODAL

前端架构的思考

最近因为项目的原因,我又在思考前端代码结构的问题。

对于后台来说,人们有微服务。对于前端来说,人们有组件化。而组件化根本就不是灵丹妙药,随着业务的复杂,前端的代码来变得越来越多,然后成为“大泥球”(即指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码)。

Backbone

在我的第一个纯前端项目里,我们使用Backbone作为基础框架、Mustache作为模板引擎、Require.js作组件化。每个页面称其PageView,而PageView之间会有一个共同的父类View。在这个父View里,我们定义了一系列的基础行为,如Render、BeforeRener、AfterRender等等,这一点上看上去和React的思考很像。组件化在这个项目里,并没有什么大的问题(当然也有效率问题)。

当时,这个项目的主要问题是前台Render和后台Render的行为差异。我们使用Java的Mustache引擎来渲染HTML给Google等搜索引擎,当用户在前台浏览时,我们使用JavaScript上的Mustache来渲染。这时问题就出现了,他们之间的行为就会有一些差异,而要修复这些差异并不是一件有趣的事。

开始的时候,这个项目很容易上手。而随着业务的发展,在一些关键的领域知识上,我们缺少的知识越来越多。尽管我们重构代码、编写测试、Code Review,但是你几个月前写的代码,你还是需要好好回想一下。有时,你也会忘记了。

React

接着在这个移动站点上线一年多以后,我们开始使用React与响应式来完成桌面版和移动版的开发(当然,它也有APP版,只是它是基于某个跨平台解决方案完成的)。对于我们来说,它很好地解决了我们的前台渲染和后台渲染的问题。我们使用Express来处理来自搜索引擎的请求,再用React的RenderHTML来返回结果。

只是我们的开发方式变成了基于契约的开发,我们提供相应的API给前端开发。只是客户的前端Leader并不给力,真的把它写成了大泥球——没有测试、没有OOP或者FP的思想等等。不过,他们倒是在组件化方面做不得不错。

Angular.js

在上一个项目没完成时,我就进入到了现在的这个项目里。虽然仍是使用契约,但是业务比原来的复杂。我们使用Angular 2.0的思考在这个Angular.js项目上,组件划分在相应对应的文件里,即其Contorller、模板、样式。

随着业务的复杂度在扩大,我们在不断的重构系统。也因此,在一些知识点上我们失去了一些对应的领域知识。在进度和架构之前,我们总是要做出一些妥协。

问题

虽然,我们可以拆分项目来把项目变小。对于越来越臃肿的代码,一个比较有效的方法就是分而治之。但是如果一个项目划分不了呢?这时,我们应该怎么办??

我们也没有对应的领域模式可以应用在前端上,如果可以的话,我们是不是可以考虑用DSL?

对应的话,我们是不是也可以想办法将DDD的思考应用到上面?

是不是我还需要进一步提升在DDD方面的想法和能力?

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《前端架构:从入门到微前端》

《前端架构:从入门到微前端》是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前端工程师更好地进行系统设计。

前端架构包含以下五部分内容:

  • 设计:讲述了架构设计的模式,以及设计和制定前端工作流。
  • 基础:通过深入构建系统、单页面应用原理、前端知识体系等,来构建出完整的前端应用架构体系。
  • 实施:通过与代码结构的方式,介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
  • 微前端:引入6种微前端的概念,以及如何划分、设计微前端应用,并展示了如何实现这6种微前端架构。
  • 演进:提出更新、迁移、重构、重写、重新架构等架构演进方式,来帮助开发人员更好地设计演进式架构。
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签