一次完整的项目管理实记

[miniflycn]

可能会是一个good example，也可能是个bad example，且写下来看看

项目流程

• 开发前需求评估拉当前项目负责人参与，保证上游输入
• 开发工程中通过editconfig、jshint、scss-lint保证代码质量
• 发布前，通过reveiw保证输出质量，并将问题和解决方案纪录在REVEIW.md，方便沉淀
• 发布时，将版本即修改信息（可以直接贴需求单地址）记录在CHANGELOG.md中，方便回溯
• 发布后，通过监控及工具保证运营质量，并可快速响应bug
• 性能瓶颈时，提技术需求，进行专项优化
• 通过tapd记录需求信息，通过dcloud来记录项目信息，保持对项目的异步跟进
• Eating your own dog food 变种，保持模块维护者稳定性，让其可能在反复被自己“烂”代码坑的过程中找到更优雅的编码方式

CSS规范

• Principle：遵照现有写法逐步进行改造，符合模块化思想的模块分割，为未来介入Component铺路
• Goal：不管多少人同时参与编码，所有代码都应该看上去像是一个人编写的一样。
• Why：简单的说我们要符合工程化需要，那么工程化后有什么好处
  1. 任何腾讯的项目都要有预期未来可能发展成庞然大物的可能，如果初期架构没弄好，未来会增加大量的维护和重构成本，这上面我们是有颇多教训的
  2. 统一化的项目规范可以减少项目人员接入成本
  3. 合理的规范和命名是能大大减少我们构建工具或组件上的成本
  4. 可为我们节省大量维护时间，让我们将更多精力花费在比bug更有意思的事情上，例如更好的体验，更快的性能，更佳的安全性……

基本要求

1. 使用四个空格的 soft tabs

   这是保证代码在各种环境下显示一致的唯一方式。

2. 使用组合选择器时，保持每个独立的选择器占用一行

   // good example
   div,
   ul,
   li {
       padding: 0px;
       margin: 0px;
   }
   // ugly example
   div, ul, li {
       padding: 0px;
       margin: 0px;
   }
   

3. 声明块的右括号应该另起一行

   // good example
   div {
       font-size: 14px;
   }
   // ugly example
   div { font-size: 14px; }
   

4. 每条声明 : 后应该插入一个空格

5. 逗号分隔的取值，都应该在逗号之后增加一个空格

   // good example
   div {
       background-color: rgba(255, 30, 40, 0.8);
   }
   // ugly example
   div {
       background-color: rgba(255,30,40,0.8);
   }
   

6. 尽量不使用需要特定雪碧图合成方案的css背景方案

   便于自动化雪碧图合并

7. 尽量使用Pixels，而非Ems

   Ems应当更多用在line-height中

8. 使用.editorconfig保证缩进、换行等统一

9. 命名使用现有格式，即英文单词 ＋ 数字 ＋ _

   // good example
   .enter_qiqi_btn {
       // some styles
   }
   // bad example
   .enter-qiqi-btn {
       // some styles
   }
   // ugly example
   // 单词没有语义
   .enter-q-b {
       // some styles
   }
   

项目要求

1. css文件分为三层，合理的分层能避免代码之间耦合，增加重用可能性，将不经常变的和经常需要变化的代码分离

   • 基础库层（如：reset.scss，responsive.scss）
   • 组件层（如：nav.scss，tab.scss）
   • 业务层（追求速度，烂代码就烂代码，因为已经很好的隔离，由于变化很快，重写的可能性也很高）

2. 模块命名空间话，简单的说css没有很好的样式隔离方案，所以必须通过命名空间来保证模块之间不互相影响，下面是我们的例子：

   我们把一个tab看成一个模块，则起命名为.my_page，则里面的所有东西的命名空间都应该时.my_page，并对应应当有一个.my_page.scss文件，则该scss应当如此写：

   // .my_page这是命名空间
   .my_page {
       .mod_A {
           // some styles
       }
       .mod_B {
           // some styles
       }
   }

   故之后我们需要对一些css做拆分和命名空间的重构，以满足未来可能出现的业务越来越复杂的需求。

3. 合理的嵌套，除了业务层，前两层应当保证在三层嵌套以内，多余三层嵌套有以下两个问题：

   • 难以看清楚嵌套，难以维护
   • 选择器过多导致性能较差

4. CSS Reveiw及性能测试工具，Workflow代表在工作过程中需要执行，Reveiw代表在Review工程中可以拿来使用，Checker代表上线检查项，建议上线后跑一下，Performance代表性能工具，在发现性能问题时可借助帮忙解决的工具。

   • scss-lint Workflow scss代码检查项
   • cssstats Reveiw css基本信息统计
   • tidycss Review 检查css的冗余情况，建议在大改版时使用
   • page-valid Checker 此项目还在开发
   • analyze-css Performance 性能调优工具，在css性能出现问题时，可借助该工具检查
   • stress-css Performance 当滚动卡顿时候可以借助该工具来找到需要优化的Selector

Javascript规范

基本要求

这一块较多，我们直接使用我们团队的规范，利用jshint来保证执行

项目要求

1. 同样分成三层，组建层和业务层需要和css有明显的映射关系，便于管理

   • 基础库层（如：jquery.js、zepto.js、db.js）
   • 组件层（如：nav.js、tab.js）
   • 业务层

2. 提测或发布前代码Review，并将代码Review结果记录，类似Changlog，记录在代码Review过程中遇到的问题以及解决或从中学到的东西，用于积累沉淀

3. 模块通过备注划分负责人，代码Review需要负责人一同参与

   /**
    * @maintainer donaldyang
    */

4. 前两层需要详尽的方法备注，并可使用工具生成文档

5. Javascript Reveiw

   • jshint Workflow Javascrit代码检查项
   • flow Workflow facebook的js类型分析技术
   • scanjs Review Javascirpt脚本安全扫描技术