1. 是否需要建立仓库？建仓库
2. 是否需要切换分支？切换分支
3. 是否需要另起一个分支？新建分支
4. 是否有研发记录文档？

1. 写文档总结一下遇到的 bug，以后再遇到的话可以快速定位，DRY 原则
2. 是否需要测试？写一份测试文档

* 先思考！先理清思路和需求！再编码！这是最重要的！！！
* 不要浅层思考，不要意识流
* 考虑可扩展性，需求改了后会不会改变
* 冗余的代码很难维护，因为改了一个地方，可能第二个地方也要修改，但是你不知道
* 代码要后期可维护，具有适量的注释，高内聚，低耦合
* 代码要有可读性
* 修改代码或变量的时候要注意与其相关的会不会受牵连，如果受牵连，怎么解耦
* 会产生异常的地方一定不能忽视，前面留下的问题，以后要花更多的时间解决
* 注意不要硬编码
* Dry 原则
    不要出现重复的代码，SQL语句等
​
* 程序的运行要遵循一条主线的原则，在一条主线上加入分支，不要多条主线，灵活运用 break，continue
* 墨菲定律：觉得会出问题的地方，一定会出问题！！！（不要容忍破窗户，要严谨编码）
* 一条需求、一项任务，如果能够用语言将其描述，那么代码实现起来应该也不会太难。
* 软件开发规律和人的直觉是相反的。
* Think more ——> code less
* 编码在整个项目中一般只占 10% 左右的时间， 50 % 的时间用于沟通
* 编码之前一定要严格要求自己，建立好的品味
* 一个系统工程师的培养需要至少 8 - 10 年的时间
* 各个模块一定要正交！！！函数、模块、类的正交
* 函数一定要短小：在一屏内完成，适合解耦。写好函数的秘诀：将函数写的短小！！
​
* 代码是一种表达方式，代码是写给人看的！可读性最重要！代码是写给人看的！代码是写给人看的！代码是写给人看的！

* 找到可以优化的地方
找细节
找循环（重复的地方）
​
* 还要考虑的地方
减少访问文件的次数
减少访问数据库的次数
减少请求网络的次数
​
* 优化的玄学
代码质量与代码的整洁程度成正比。如果代码一眼望去，杂乱无章，没有阅读的欲望，那么多半代码的质量也很差。这就提供了一个直觉，如果代码看起来“很丑”，那么多半需要优化了。

* 尽量不要有三层以上的代码缩进
* 命名不能随意，否则后面代码维护的时候自己都看不懂，代码的可读性和可维护性很重要！

1. 德摩根律
    非(p 且 q) == 非p 或 非 q
    非(p 或 q) == 非p 且 非 q
​
2. 先对一些特殊条件进行处理，及时 return，主线原则

* 一个好的命名可以免去了写注释的麻烦，多思考，少重复
* 命名一定不能随意，否则程序可读性非常差，后面可能自己都读不懂。
* 匈牙利命名法：把变量的『类型』缩写，放到变量名的最前面

* 修改后一定要想一想修改会不会引起新的变动。会不会导致之前写的代码不能用，出 bug。
* 修改完 Bug 一定要写文档记录一下，否则后面可能还会重复之前的劳动

* 加注释最好在上一行加，不要在行末加，否则会触发 diff 检查

{
​
}

Basic交接后，出现了某些 URL 访问超时的问题。

/home/work/odp/log/error_log 文件中报错：
2018/08/24 15:49:54 [error] 9830#0: *2233 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.24.128.30, logid: 2984131137, -, server: yq01-yq-qadev-wanshuo.epc.baidu.com, request: "GET /summary/pzeroproblem?productid=all&subproduct=all&stime=2018-01-01%2000%3A00%3A00&etime=2018-08-24%2000%3A00%3A00 HTTP/1.1", -, upstream: "fastcgi://unix:/home/work/odp/var/php-cgi.sock", host: "yq01-yq-qadev-wanshuo.epc.baidu.com:8081", referrer: "http://yq01-yq-qadev-wanshuo.epc.baidu.com:8081/", -, -,

经过测试，在修改开始时间后，例如从 4月1日 开始计算，那么能返回数据。
目前定位到错误应该源自：\baidu\ceqa-mdns\bq\models\service\page\summary\PZeroProblem.php 文件，因为两个接口都调用了该文件。所以问题应该都来自于该文件。
进一步定位发现，耗时操作来源于频繁访问数据库：`$this->product->get_product_name($product_id);`。线上 Basic 之所以没有产生超时的问题，是因为 ODP 服务和 数据库是放在了一台机器上，虽然 ODP 是通过 IP 访问的数据库，但是 IP 报文最终只是在局域网内进行传输，所以传输较快。
​
测试的时候出现该问题，原因在于测试机的 ODP 环境 和 线上数据库 属于不同的局域网，大部分时间浪费在了数据的传输上，实测线上机器运行上一条语句的时间只有不要 1 ms，而测试机需要 7 ms。更进一步的原因在于代码没有针对数据库的访问进行优化，频繁的访问数据库，后期的开发中，如果频繁的访问一张表，可以直接将整张表读取出来，放入内存中进行查询，这样数据只需要传输一次即可。