您看看这篇文章，不知能不能解答一些你的问题 https://juejin.im/post/6844903817192947726

@ly4572615 @opengps 实际场景：我们这用的是 mac 系统的 Page，在打开 word 文档时是好几段叠在了一起，而且不是个例，碰到过至少十几次，每天要筛好多简历，基本上碰到这样的就直接过了

您可以参考下 git flow 的流程 https://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html

@laike9m 对，写错了

@laike9m 第一个问题：我们在做一些复杂逻辑处理的时候，增加必要的空行会让代码读起来更清晰些吧，比如下单接口，第一进行库存处理，第二下单处理，第三扣款处理，如果三块没有空行对读代码的人可能不太友好，当然这种复杂类的还是要拆方法；

第二 中文前加 u, 我没有注明是 python2，python3 已经不需了，目前我们还是 python2，编码问题还是比较累

第三条，我写的不太明确

错误：
def test():
# 测试方法

正确：
def test():
"""测试方法"""

感觉这种方法的注释，Numpy 这个包的开发者写的注释非常好

非常感谢您指出的问题

@xiangyuecn 简单的、一次性的项目没有那么多框框，但是针对一些比较中大型的项目，一些规范还是必要的，否则后期维护简直是灾难，就我们现在的项目开发维护了两年，大大小小迭代了十几个版本，研发前前后后小二十人，如果没有规范，维护起来还是很难的，而且好多规范不同语言之间道理是相同的，在看 JAVA 规范的时候发现好多可以借鉴的地方

@renmu123 @aeron 我们团队内部也是要求必须遵守 PEP8 编码规范，而我们这个规则是在 PEP8 规范上的补充，更多的偏向业务方向以及一些小的技巧，目的是为了让大家风格保持一致，提高代码的可读性

@laike9m 多谢指正

@PbCopy111 一部分是自己在实际项目中的经验教训，一部分是参考了大家约定俗称的东西，也参考了阿里 JAVA 编码规范的一些东西，我个人认为编码规范没有对错之分，这更像一个契约，一个自己团队能保持风格一致的规则，如果有利于代码维护，那目的就达到了。

求拉 eWFuZzc5NDI=

1 、建立一张新表，用户编号为主键唯一索引；
2 、业务代码从老表读每一条数据，读到直接往新表插入，能插进去说明新表不存在，插不进去说明已存在，直接跳过
3 、跑完后用新表代替老表
如果不考虑数据实时更新的话这样是否可行？

utc2prc

感觉 B 的兼容性更好些，哪天业务允许 ip 重复了，A 方案的结构就要改掉，对应 A 结构的业务处理代码全都要改，反而用 B 的话对原来代码几乎是没有影响的

分页还可以这样做，提取某个有序字段做排序，让前端传入最后一条的这个字段值，向后取多少条，这样性能应该会好些，比如按分页查询 user 表，有两种方案
方案一 [上文提到的，用的比较多的] ：
SELECT * FROM `user` ORDER BY id ASC LIMIT 100, 10;
方案二 [在数据量较大的情况下性能较好] ：
SELECT * FROM `user` WHERE id > 100 ORDER BY id ASC LIMIT 10;

1、前端调用接口（参数：appid，secret ），给后端，后端调微信换取 openid，然后判断 openId 是否已经绑定账户，没有直接将 openId 返回给前端，走注册流程，存在用户则生成 Token 与用户绑定，设置 Token 有效期，并将 Token 返回给前端；
2、前端在请求其他接口时必须带上 Token，加上当前时间戳，再根据 token 和其他信息按照一定规则生成一个签名 [比如 md5(token+timestamp+xx_key)] , 这些信息可以放 header 里
3、后端接到请求先判断 token 是否存在、有效，判断签名是否正确，判断时间戳是否超过服务器时间太久(比如 5 分钟），根据 token 找到用户并判断用户状态，如果校验通过才可以访问调用的接口

增加签名是为了增加模拟请求的难度，就算知道了 token，不知道签名规则，还是请求不成功；
增加时间戳字段的目的，一是为了验签，二是为了防止一个签名无期限的使用；