CSS 里的整洁架构
在历数技术进步的代价时,弗洛伊德遵循的路线使人感到压抑。他同意塔姆斯的评论:我们的发明只不过是手段的改进,目的却未见改善。 ——尼尔波斯曼《技术垄断》
A collection of 13 posts
在历数技术进步的代价时,弗洛伊德遵循的路线使人感到压抑。他同意塔姆斯的评论:我们的发明只不过是手段的改进,目的却未见改善。 ——尼尔波斯曼《技术垄断》
随着应用程序的日趋庞大,它变得越来越难以维护。随着可复用模块的重要性逐渐递增应用的复杂性也随之增长。我们都意识到我们应该在它面临难以维护的风险之前做些什么
这篇文章或许看上去仅和 Angular2 开发者相关,但我相信它也适用于其它的框架。这只是一份关于编写具有可拓展性和可维护性单页面应用的指南。需要指出的非常重要的是,这并不是达成目标的唯一方式,但是对我个人而言它们在不少的场景中都行之有效
我猜此时此刻你心里的疑问一定是:为什么是 Angular,不是 React,不是 Vue,不是 Flux,不是 Redux ? 因为你已经对它们太熟悉了。我个人作为开发者而言最希望是能够汲取到“圈外”的“营养”,这样才能给我的成长带来帮助。我想对各位也是一样。
如果你对整洁架构(Clean Architecture)有所了解的话,回想一下我们前几篇中描述的内容,你会发现整洁架构对前端,对 MVP 来说也是同样适用的。
在 Flux 架构中,有两个问题依然没有被提到,一个是表现层模型,另一个是测试
MVC 的不足
在上一篇中,我提出了一个应用中常见的问题:如何在多个视图中共享同一份数据,并且保证它的改动能够同步到不同的视图中去?
我把 MVC 框架作为我们理解架构的切入点。虽然它现在已经式弱了,但在我看来它非常重要并且起到了承上启下的作用:作为经典的解决方案第一次系统的把应用的从复杂的混沌中解救了出来。从这套方法论中我们能学习到很多至今能受用的思路,同时我们也能了解到它的不足。
在这个系列里面,我会谈到前端架构的进化;它们解决了什么样的问题以及又是如何面临新的无法解决的问题的;最后这些架构背后常见的组件和模式。