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

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

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

开源深度爱好者

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

联系我: h@phodal.com

微信公众号: 与我沟通

标签