Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

目录结构为何总变成一坨?

  关于目录结构设计,所谓的「最佳实践」根本就是个伪命题。无论哪个项目,随着业务的迭代,文件结构最终都会变成一坨。所谓的「最佳实践」都只不过是「没把项目搞挂的实践」罢了。其实目录结构本身都差不多,真正的问题出在一些细节上。
  目前目录结构设计大致可以分为两种。一种是传统风格,按文件类型分目录,另一种则是以功能模块来分。
/ js index.js articles.js css index.css articles.css html index.html articles.html img / common img index index.html index.css index.js articles articles.html articles.css articles.js
  上面只是一个很普通的范例,其实细节还有很多差异。比如对 common、img 这些东西的处理方式并没有一个特定的套路。这些细节差异才是造成整个目录结构最终变成一坨的元凶。
  结构变得越来越糟糕是因为抽取通用之后业务需求的变更。把通用的东西抽取出来后一旦有局部变更的需求就可能造成通用性丧失,最终形成一段僵尸代码。比如一个网站有首页和文章页。一开始他们都是一样的风格,也就是顶部底部可以通用。但可能没过多久设计师不知哪根筋搭错,想对文章页的顶部做变更而不动首页的。于是这时候可能这么几种情况:
    1. 在顶部模块中插入奇怪的代码使其对文章页做特殊处理
    2. 复制一份顶部模块的代码
  第一种做法也许并不用动多少代码,也不会产生冗余,但造成的问题是依赖错乱、逻辑崩坏。既然顶部模块属于全局的,它就不该依赖于业务级的东西来决定表现。业务可以用无穷多个,假如每个业务都在全局模块中注入代码,会导致全局模块最终变得非常臃肿。
  第二种没有第一种那么蛋疼的逻辑问题,但造成了冗余。这不仅仅是代码层面的冗余,还涉及了逻辑的冗余。原来的头部是两个模块通用的,现在文章模块不再依赖原先的通用模块,于是无论是原先的头部模块还是文章页的头部模块都已经变得不通用了,这就是通用性丧失。可怕的是它们依然会被放在 common 中。
  假如现在设计师的脑袋又被门夹了,要把文章页的头部模块改成另一种风格。那么文章页的头部又会被再复制一遍。而且这个期间也许开发的负责人早就换了 N 波了,而原来的头部由于在 common 中,没人敢把它删除掉,于是就出现了一坨僵尸代码。这些僵尸代码占据了大量的优秀命名,让后续的模块彻底词穷。比如一开始的头部模块名叫 header,后来文章页面的头部模块名叫 articles-header,那之后呢?难道叫 articles-header2?
  前面给出的两种目录结构风格其实并没有本质区别,甚至一个项目可以同时使用这两种,使用软连接来做映射。目录之所以会变成一坨,根本原因是依赖关系管理不好。这和到底使用何种风格的目录结构没任何关系。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^