上周新人 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 做更多测试； - 测试有益心理健康；
一个工程师害怕改代码，那简直是笑话；
改了一个问题引起两个问题，那更是灾难；
有测试做保障，特别是自动化测试，可以解除恐惧，卸掉心理负担，从此放心大胆地重构，质量还能得到保证；
