Skip to content

Latest commit

 

History

History
49 lines (33 loc) · 2.19 KB

7.2.1-refactor2.md

File metadata and controls

49 lines (33 loc) · 2.19 KB

网站重构

网站重构应包含结构、行为、表现三层次的分离以及优化,行内分工优化,以及以技术与数据、人文为主导的交互优化等。

从我所了解到的网站重构,它大概可以分为下面的几类:

  1. 速度优化
  2. 功能加强
  3. 模块重构

下面就我们来看这三类的网站重构

###速度优化

通常来说对于速度的优化也包含在重构中

  • 压缩 JS、CSS、image 等前端资源
  • 程序的性能优化(如数据读写)
  • 采用 CDN 来加速资源加载
  • 对于 JS DOM 的优化
  • HTTP 服务器的文件缓存

如对于压缩前端资源这一类的重构,不仅仅需要从代码层级来解决问题,也可以借由服务器缓存来解决问题。在这时候就需要去判断应该由哪个层级来做这样的事情——如果一件事可以简单地由机器来解决,但是由人来解决需要花费大量的时间,这时就应该交由机器来解决。而如果由人来解决是一个长期受期,并且成本比较低的事,那么就应该由人来解决。如我们只需要在我们的构建脚本中引入 minify 库就可以解决的事,那么应该交由人来做。

如,采用 CDN、HTTP 服务器的文件缓存这一类应该交由机器来做。

同时像程序性能优化、JS DOM 优化都应交由人来解决的事。特别是像程序性能优化,从长期来看可能是一件长期受益的事。当且仅当,我们遇到性能问题时,我们重构这部分代码才可能带来优势。如果我们的网站的访问量不是特别大,那么优化可能就是徒劳的。但是这种优化对于个人的成长还是挺有帮助的。

###功能加强

一般来说功能加强,应该是由于需求的变动才引起对系统的重构需求:

  • 解耦复杂的模块 -> 微服务
  • 对缓存进行优化
  • 针对于内容创建或预留 API
  • 需要添加新的 API
  • 用新的语言、框架代替旧的框架(如 Scala, Node.js, React)

###模块重构

深层次的网站重构应该考虑的方面

  • 减少代码间的耦合
  • 让代码保持弹性
  • 严格按规范编写代码
  • 设计可扩展的 API
  • 代替旧有的框架、语言
  • 增强用户体验