我的架构经验系列文章
程序员文章站
2022-05-20 17:12:22
...
框架层面：近几年前端发展很快，前端之所以叫前端因为前端是已经可以独立成为一种职业了，js也不再是十年前的玩具了，以前富客户端RIA的应用可能会用flash/flex或是silverlight，现在可以使用js来完成大部分的功能，因此js作为一门前端的支撑语言也不仅仅是进行的简单的编码，越来越多框架性的东西出现了。越来越多的开发模式转变为后端只是吐json的数据源，而前端做所有UI的事情。
MVC
MVC实现职责分离是很好的，大多数网站在后端都会引入MVC框架，对于一个前端负责所有呈现和前端业务逻辑的网站来说，使用MVC框架也是很有好处的。Javascript的MVC框架现在很多。每一个框架其实都有其特点的，但是前端的MVC框架会和后端的有些不同的。比如前端的MVC框架可能会做一些M和V元素的双向绑定，对于后端来说往往是单向的比较多。通过引入MVC框架我们可以让同一个页面做很多事情，通过一个不刷新的页面实现一个应用程序的根基，还可以很清晰地进行MVC的分离并且突出M的概念，这是没有框架所办不到的。
通讯
对于一个比较复杂的页面可能会有比较多的Javascript模块，如果要进行模块之间通讯的话（比如一个页面有左边菜单和导航以及列表，左边菜单点选一级分类之后要通知导航加上去这项，并且通知列表重新读取数据并刷新，然后从导航删除这个选择的话要通知列表重新获取数据，通知菜单显示所有）。对于比较复杂的通讯，如果把模块模块之间进行强耦合直接调用其它模块的函数的话是不利于可维护性的，我觉得可以引入发布订阅机制，每一个模块做了什么修改把信息发布出去，关心这个信息的人订阅这个信息，并且在回调函数里面做相应的操作就可以了。可以使用Amplifyjs作为发布订阅的框架。
模板
对于前端来说和后端一样一个比较麻烦的问题就是往往会在脚本里面把html也混在一起，个人觉得是这样的，如果对于非常琐碎一些dom修改问题倒不大，如果是大块的html拼接的话，数据和html甚至是css混合在一起，那么代码的可维护程度非常差。此时可以考虑使用一些模板引擎来分离数据和表现，比如Twitter hoganjs。由于很多模板引擎，比如大胡子引擎不仅仅是针对前端的，后端语言也有相应的引擎，因此甚至可以把模板放在文本文件中，前端后端共同使用一套模板引擎，也就是说现在的代码偏向于服务端渲染的那么就在后端使用模板，如果要以后改为客户端渲染了这套模板可以直接被前端使用。
类库
除了框架之外还有很多类库，比如jquery，underscore，linq.js（linq to javascript），jscex（wind）反正后端有啥现在前端也有啥，尽情发挥想象吧。用好这些框架可以大大改善生产力的，脚本能做的事情真的比想象的要多的多。我是做后端的前端知道的不多在这里列出的可能只是九牛一毛。
依赖
可以使用Requirejs、Commonjs之类的组件来管理脚本之间的依赖，好处很多的，我们的模块只需要写清楚需要依赖什么，Requirejs自然会帮我们按照一定的次序加载进来，这样我们既不用担心顺序问题也不用担心组件的版本号问题。基于Requirejs它具有丰富的配置，即使是我们进行了静态资源合并也完全能处理，只要通过配置把组件配置到相同的服务端生成的一个路径上即可，不过以前在做的时候发现它会自动加上.js 扩展名，不过完全可以通过改Requirejs源代码解决。在架构上我的观点是既然使用开源的东西，遇到问题了就不要去怕改源代码。我们一定不能停留在框架的使用者，定制框架甚至向作者贡献自己的代码没有这么难。 设计层面：
职责分离的理念
虽然我们都知道CSS样式、JS行为以及HTML结构。个人觉得只有HTML是必须的，也就是说如果一个页面没有样式没有脚本的话它应该是一个清晰的页面，可以大致表现出页面需要表现的内容，只不过样子比较难看，并且也是交互的。如果说很多功能是ajax实现的话那么就把交互工作转到服务端实现服务端的渲染。多了样式只是布局上样子上更好看，多了脚本只是交互性上更友好，不需要刷新页面，但是少了也不代表这个网站就是废物了，现在有很多理念其实目的是一样的。如果达不到这个境界至少我们要很明确的让css、js和html履行自己的职责，不要把过多的事情赋予不相关的组件。比如尽量不要在html中包含操作性的脚本代码，而是应该直接在脚本中选择dom元素进行操作，尽量不要在脚本中包含大段的html代码而是应该从模板读取然后把数据填充进去，也尽量不要在html代码中包含大量内嵌的样式而是应该通过选择器选择进行样式赋值。
分层和目录结构
对于一个比较复杂的大型的项目，合理规划目录结构也是很重要的，你可能会说脚本和样式分两个目录就可以了，但是如果一个复杂的项目有几百个脚本都列在一个文件夹下吗？后端有分层的概念其实前端完全也可以有分层的概念，有表现层、业务逻辑层和模型层，然后是下面的数据访问ajax层，当然还会有常量的文件，我反问觉得前端的分层可以超大型项目的ios或android程序来靠。比如之前我做的一个ios程序的示例,个人觉得这样的分层就比较一目了然的。
合并和拆分的平衡
很多时候架构上的东西就是一种权衡，如果有固定的标准的话也就不需要架构师了，我们只需要按照固定的标准去做就行了。比如，一个页面上使用了10个脚本文件，5个样式文件，按道理说合并成两个文件可以达到最小的请求数，但这样一定是好的吗？这个10个脚本和5个样式文件中有很多或许是其它页面也需要公用的，如果仅仅简单的合并在一起反而可能增加用户的下载流量，因此怎么规划通用的东西合成一个文件，框架的文件单独，而每一个页面都有自己独特的脚本和样式，也是一种学问。 性能层面：
性能检测
诸如YSlow和PageSpeed等工具可以分析出前端的性能问题，在这里就不展开讨论了。对于前端来说由于涉及到用户的客户端环境和网络环境所以情况不是这么单纯，但是我们可以做到的就是在我们的可控范围之内尽量减少用户域名解析数量，减少用户下载的数据量，增加并发等等。其实说白了，我们就是清理管道使得管道更大，或者增加更多的管道，或者就是尽量让管道之内的水少一点了，这样就可以更顺畅。
性能分析
现在有一些工具可以对Javascript的性能甚至是DOM解析的情况进行细致的分析，比如dynaTrace AJAX Edition，通过这样的工具我们可以分析我们的脚本代码以及页面布局是否合理，从开发的角度来全面了解和优化我们的前端代码。客户端的资源虽然不像服务端的资源这么重要，但是为了给用户的机制体验最好还是对客户端的性能消耗有所优化。
MVC
MVC实现职责分离是很好的，大多数网站在后端都会引入MVC框架，对于一个前端负责所有呈现和前端业务逻辑的网站来说，使用MVC框架也是很有好处的。Javascript的MVC框架现在很多。每一个框架其实都有其特点的，但是前端的MVC框架会和后端的有些不同的。比如前端的MVC框架可能会做一些M和V元素的双向绑定，对于后端来说往往是单向的比较多。通过引入MVC框架我们可以让同一个页面做很多事情，通过一个不刷新的页面实现一个应用程序的根基，还可以很清晰地进行MVC的分离并且突出M的概念，这是没有框架所办不到的。
通讯
对于一个比较复杂的页面可能会有比较多的Javascript模块，如果要进行模块之间通讯的话（比如一个页面有左边菜单和导航以及列表，左边菜单点选一级分类之后要通知导航加上去这项，并且通知列表重新读取数据并刷新，然后从导航删除这个选择的话要通知列表重新获取数据，通知菜单显示所有）。对于比较复杂的通讯，如果把模块模块之间进行强耦合直接调用其它模块的函数的话是不利于可维护性的，我觉得可以引入发布订阅机制，每一个模块做了什么修改把信息发布出去，关心这个信息的人订阅这个信息，并且在回调函数里面做相应的操作就可以了。可以使用Amplifyjs作为发布订阅的框架。
模板
对于前端来说和后端一样一个比较麻烦的问题就是往往会在脚本里面把html也混在一起，个人觉得是这样的，如果对于非常琐碎一些dom修改问题倒不大，如果是大块的html拼接的话，数据和html甚至是css混合在一起，那么代码的可维护程度非常差。此时可以考虑使用一些模板引擎来分离数据和表现，比如Twitter hoganjs。由于很多模板引擎，比如大胡子引擎不仅仅是针对前端的，后端语言也有相应的引擎，因此甚至可以把模板放在文本文件中，前端后端共同使用一套模板引擎，也就是说现在的代码偏向于服务端渲染的那么就在后端使用模板，如果要以后改为客户端渲染了这套模板可以直接被前端使用。
类库
除了框架之外还有很多类库，比如jquery，underscore，linq.js（linq to javascript），jscex（wind）反正后端有啥现在前端也有啥，尽情发挥想象吧。用好这些框架可以大大改善生产力的，脚本能做的事情真的比想象的要多的多。我是做后端的前端知道的不多在这里列出的可能只是九牛一毛。
依赖
可以使用Requirejs、Commonjs之类的组件来管理脚本之间的依赖，好处很多的，我们的模块只需要写清楚需要依赖什么，Requirejs自然会帮我们按照一定的次序加载进来，这样我们既不用担心顺序问题也不用担心组件的版本号问题。基于Requirejs它具有丰富的配置，即使是我们进行了静态资源合并也完全能处理，只要通过配置把组件配置到相同的服务端生成的一个路径上即可，不过以前在做的时候发现它会自动加上.js 扩展名，不过完全可以通过改Requirejs源代码解决。在架构上我的观点是既然使用开源的东西，遇到问题了就不要去怕改源代码。我们一定不能停留在框架的使用者，定制框架甚至向作者贡献自己的代码没有这么难。 设计层面：
职责分离的理念
虽然我们都知道CSS样式、JS行为以及HTML结构。个人觉得只有HTML是必须的，也就是说如果一个页面没有样式没有脚本的话它应该是一个清晰的页面，可以大致表现出页面需要表现的内容，只不过样子比较难看，并且也是交互的。如果说很多功能是ajax实现的话那么就把交互工作转到服务端实现服务端的渲染。多了样式只是布局上样子上更好看，多了脚本只是交互性上更友好，不需要刷新页面，但是少了也不代表这个网站就是废物了，现在有很多理念其实目的是一样的。如果达不到这个境界至少我们要很明确的让css、js和html履行自己的职责，不要把过多的事情赋予不相关的组件。比如尽量不要在html中包含操作性的脚本代码，而是应该直接在脚本中选择dom元素进行操作，尽量不要在脚本中包含大段的html代码而是应该从模板读取然后把数据填充进去，也尽量不要在html代码中包含大量内嵌的样式而是应该通过选择器选择进行样式赋值。
分层和目录结构
对于一个比较复杂的大型的项目，合理规划目录结构也是很重要的，你可能会说脚本和样式分两个目录就可以了，但是如果一个复杂的项目有几百个脚本都列在一个文件夹下吗？后端有分层的概念其实前端完全也可以有分层的概念，有表现层、业务逻辑层和模型层，然后是下面的数据访问ajax层，当然还会有常量的文件，我反问觉得前端的分层可以超大型项目的ios或android程序来靠。比如之前我做的一个ios程序的示例,个人觉得这样的分层就比较一目了然的。
合并和拆分的平衡
很多时候架构上的东西就是一种权衡，如果有固定的标准的话也就不需要架构师了，我们只需要按照固定的标准去做就行了。比如，一个页面上使用了10个脚本文件，5个样式文件，按道理说合并成两个文件可以达到最小的请求数，但这样一定是好的吗？这个10个脚本和5个样式文件中有很多或许是其它页面也需要公用的，如果仅仅简单的合并在一起反而可能增加用户的下载流量，因此怎么规划通用的东西合成一个文件，框架的文件单独，而每一个页面都有自己独特的脚本和样式，也是一种学问。 性能层面：
性能检测
诸如YSlow和PageSpeed等工具可以分析出前端的性能问题，在这里就不展开讨论了。对于前端来说由于涉及到用户的客户端环境和网络环境所以情况不是这么单纯，但是我们可以做到的就是在我们的可控范围之内尽量减少用户域名解析数量，减少用户下载的数据量，增加并发等等。其实说白了，我们就是清理管道使得管道更大，或者增加更多的管道，或者就是尽量让管道之内的水少一点了，这样就可以更顺畅。
性能分析
现在有一些工具可以对Javascript的性能甚至是DOM解析的情况进行细致的分析，比如dynaTrace AJAX Edition，通过这样的工具我们可以分析我们的脚本代码以及页面布局是否合理，从开发的角度来全面了解和优化我们的前端代码。客户端的资源虽然不像服务端的资源这么重要，但是为了给用户的机制体验最好还是对客户端的性能消耗有所优化。
回复讨论(解决方案)
蛮好看，就是要价太高
好吧 经验收下了
学学经验了
写得挺不错，价格也不错，其实我是过来专门接分的。