后端开发和部署的若干约定

上周新人 Los 加入；对 Yii 熟悉的对 Laravel 不熟悉，反之亦然；这里记录一下代码设计的约定；关于 Redis 的约定初步成型（after 3 weeks since 1st Nov.）；

原则

• 结构良好；
• 代码整洁；
• 风格一致；

数据库

• 数据库名：db_*
• 时间字段
  _intm 插入时间，_uptm 更新时间，_detm 删除时间，_pptm：参与时间；
  使用 UNIX 时间戳格式；
  时间字段大多内部使用，提升可测性和运营排查问题；

Redis 的原则

• 一个应用一般使用一个 redis 实例；
  不同的应用可以使用同一个实例；
• 一个应用一般使用一个库；
  不同的应用一般使用不同的库；
  多库不会增加性能，只会增加部署复杂性；
• 使用命名空间对库进行分隔；
  提高 key 的可读性；改善 key 冲突的可能性；

Redis 库

• 0：通常不使用，保留供 laravel 升级使用；
• 1：数据缓存；
• 其他：一般不使用，特殊业务考虑使用；
• 32：st:$short_tag => long_url；

不同环境下的 Redis 库配置

环境	库ID	范围
me(local)	1	[1-10]
dev	11	[11-20]
test	21	[21-30]
prod	31	[31-40]

Redis key 约定

• 以:做间隔符，形如：a:b，a:b:c；字母全部小写；
  a：业务；b：数据（by 指明筛选条件）；c：条件；
  对于 b 要使用一个 word 来表示数据或者 action，比如：chatter，onliner，focus；
  key 不要太长；简洁能标明主旨即可；可以通过 redis_key 字典查询具体含义；
  不标注数据类型，不标注 _list（抛弃执念）；
• www:user:$id
  哈希结构，www 表示默认业务；user 表示用户表；$id 表示主键字段值；
• www:uid_by_phone:$phone
• 已发言用户：im:chatter_by_demand_id:；
  zsets 结构，首次发言时间为 score，uid 为 member；
• 在线用户：im:onliner
  哈希结构，uid 为 field，上线时间为 value；或者 zsets 结构；
  相对 zsets，哈希耗费小，数据多时可自动压缩；
• 接口形式：i:接口索引:
  比如：i:a08 就是 a08 接口默认类型（string）数据；

接口

• API Design First
  接口的设计很重要；如何对接口分组，要考虑 controller 和 model 两方面；
• controller/action 设计：demand/b42，其中 b42 就是接口文档的命名索引；
  好处是便于交流，要了解其具体含义要依靠查询接口文档来解决；往常 action 的命名是一个难题，命名不好的话反而造成误导；索引法至少不会太坏；
• 接口的测试代码和实现代码 同等重要；
  探索性测试用例的设计、测试代码的编写，要和实现代码一起 review；

关于测试

• 模块的可测试性；
  类似 前端，后端要建立模块测试机制，实现可单独调试、可单独测试、可单独发布，以支持持续集成、持续测试、持续发布；
• Debug 技术不仅要掌握，而且要精通；
  比如 ZendDebug；
  不会 Debug，编码效率不会太高；学会 debug，上了一个台阶；
  没有条件 Debug，解决问题的效率不会太高；
• PHPUnit；
  Yii 和 Laravel 框架的默认 Unit Tests 测试工具都是 PHPUnit；Yii 也使用 codeception 做更多测试；
• 测试有益心理健康；
  一个工程师害怕改代码，那简直是笑话；
  改了一个问题引起两个问题，那更是灾难；
  有测试做保障，特别是自动化测试，可以解除恐惧，卸掉心理负担，从此放心大胆地重构，质量还能得到保证；