ufologist commented 8 years ago

结合我自己的经验和体会, 总结了一些大方向上的指导意见, 主要是考虑一个页面做好后, 要方便以后的开发和维护工作

命名

主要是文件命名, class 命名, 变量命名, 可以先根据他们的职责, 取中文名, 再翻译成英文

例如: 图片的取名最好不要用什么 img_09.png, 应该取个更有意义的名字, 不然以后连自己都不知道这个图片是用来做什么的了

class 命名最好也不要用什么 div1 div2, 这样的名字太萌了, 会让人懵掉的
模块

应该将页面多个部分的样式分别写在多个 css 中, js 也是一样的, 这样每个文件的职责就会很清晰, 方便大家重用和维护

例如: header.css/nav.css/banner.css... header.js/nav.js/banner.js...

那么我们一般如何组织一个网站各个页面中的前端资源呢? 核心思想其实很简单:
- 一个网站一个全局的 CSS/JS 以及全局的基础库
- 每个页面一个独立的文件夹用于放置页面特有的 CSS/JS/资源(图片字体等等)
- 每个公共组件一个独有的 CSS/JS/资源
至于为什么要这样组织前端资源, 关键在于代码的维护和共用, 大家协作的时候可以相对放心地修改页面的样式(CSS)或者逻辑(JS), 因为各个资源都限制在一定的作用域下, 不必害怕改动会产生预料之外的结果(例如修改了页面A的样式却影响到了页面B). 详细内容请参考网站项目目录结构规范
组件

如果需要用到通用组件, 先找开源的成熟组件, 基础样式最好基于开源的框架来做(例如使用 Bootstrap)

例如: 焦点图/幻灯片组件, 就可以使用 swiper.js, 而非自己实现一个

因为自己实现的可能有很多情况没有考虑在内, 使用起来不够灵活, 你写的这个组件就有可能变成一次性投入, 不利于大家重复使用

因此关于组件的使用, 一般为先找已有的, 如果找到了但细节不满足, 可以考虑扩展, 最后还不满足, 才自己来实现
细节

注意细节, 严格要求每个页面的界面和交互, 站在用户的角度思考, 前端工程师应该是最具产品意识的

一个页面做完后, 一定要反复测试反复检查, 考虑以下几个问题
- 切图追求"像素完美", 可以参考前端工程师必备的PS技能——切图篇
- 语义化, 最简单的办法就是看一个页面没有任何样式时是什么样子的, 是否结构清晰
- 多分辨率下有问题吗? 做了响应式布局吗? 移动端适配吗? 在 PC 端和移动端显示都 OK 吗?
- PC端多分辨率适配主要靠响应式布局(responsive layout by media query), 可以参考 Bootstrap
- 移动端适配主要靠 rem 布局, px(设计稿单位)->rem(前端单位) + 动态 meta viewport + 动态 html font-size 和 data-dpr, 具体参考班会第 15 期 - 使用Flexible实现手淘H5页面的终端适配和班会第 10 期 - 移动端适配专题
- 页面加载的速度怎样? 是否需要优化? 常规的性能优化都做了吗? 让 PageSpeed 和 YSlow 给你一些优化建议
- 页面有哪些公共部分, 是否可以提取出来作为组件, 又或是写一个通用组件让大家都可以使用
- 精简最终实现的代码, 越少越好(但是不要走极端, 以便于维护扩展为准)
- 如果需要与后端交互, 最好自己做好测试接口, 预先完成前端的逻辑
- 考虑用自己的电脑做服务器, 发布出页面来让大家评审(code review), 以此相互学习
- 考虑前端工程问题(例如如何发布到正式服务器上), 可以参考大公司里怎样开发和部署前端代码？
规范

HTML/CSS/JS 都有相应的成熟规范, 可以理解为多年实践中形成的最佳指南, 应该多参考这些规范, 最终形成自己的编码习惯

最重要的莫过于 CSS 规范了, 推荐使用 BEM 规范 .block-name__elem-name--mod-name 来书写 CSS

请参考我的前端之旅中的编码规范
监控

做完一个页面后, 不要以为工作就完成了, 大家应该学会用事实说话, 用数据说话, 确保我们的工作是有效果的(PV/UV 等指标), 因此需要在每个页面中添加统计代码(例如x度统计). 最好再加上事件跟踪代码, 用以评估功能的价值(例如某个按钮被用户点击了多少次).