代码在大多数适合是给人阅读的，只有很少时间是在机器上运行。
规范
规范有以下优点：
- 高效编码 - 避免了过多的选择造成的『决策时间』浪费；
- 风格统一 - 最大程度统一了开发团队成员代码书写风格和思路，代码阅读起来如出一辙；
- 减少错误 - 减小初级工程师的犯错几率。
- 简单易懂 - 写自解释的代码,选择直接的解决方案,牺牲那些可能混淆代码的小的优化
开发哲学
- DRY –「Don't Repeat Yourself」不写重复的逻辑代码；
- 约定俗成 - 「Convention Over Configuration」，优先选择框架提倡的做法，不过度配置；
- KISS - 「Keep it Simple, Stupid」提倡简单易读的代码，不写高深、晦涩难懂的代码，不过度设计；
- 主厨精选 - 让有经验的人来为你选择方案，不独创方案；
- 官方提倡 - 优先选择官方推崇的方案。
代码约束
- 代码调用自顶向下，单向调用：Controller ——> Service [通过Event ——> Service ] ——> Repository ——> Model
- 同层级代码部允许互相调用(避免环形调用)
代码评审
解耦
- 用配置功能替代配置文件,使用者可以自己修改配置规则
- 用 事件-监听 模式解决 触发条件多变的场景
数据精度
- number_format 多保留一位小数，或转为整数
- 加bcadd() 、减 bcsub() 、 乘bcmul() 、除 bcdiv() 的第三个参数 $scale 保留小数位数是直接截取，不进行四舍五入
- 金额比较应使用 bccomp(string $num1, string $num2, ?int $scale = null): int 指定精度，避免浮点数影响
两个数相等时返回 0； num1 比 num2 大时返回 1； 其他则返回 -1。
- 数据库读取的浮点数是近似值，和手动指定的相同数值的浮点数 相减可能得到负值(非常小)，需要对结果进行一次格式化再存储，否则可能因为数据库字段unsigned导致程序报错
可以考虑在字段上兼容有符号数，需要谨慎应对出现负值的处理方式??? 也可以考虑在全局精度确定且int型满足数据范围的前提下使用定点数，如：金额数据精度到毫(3位小数),数据*1000存储，输出时除以1000
