debug skill

Author: PegasusWang

codingstyle/codingstyle.rst

@@ -741,11 +741,12 @@ Readme Driven Development:
 
 * `《python docstring》 <http://bwanamarko.alwaysdata.net/napoleon/format_exception.html>`_
 
-Code Review(代码复查)
+Code Review(代码审查)
 --------------------------------------
 笔者认为code review是一件非常重要的事情，可以有效防止代码腐化，同时方便同事了解业务(可以说编码规范、静态分析、代码审查和单元测试是保证代码质量的几个重要工具，没有使用这几个工具之一将来代码都可能难以维护)。可以在公司搭建Phabricator（facebook在用）gitlab 类似工具进行代码review。可惜小公司流程不严格，codereview总是坚持不下去，要不就是被同事吐槽总是给他挑刺。实际上如果是新手能够从code review当中快速学到很多东西，比如编程惯用法，摆脱不良编码习惯，不良设计和难以维护的代码等。review的时候对事不对人，代码如果有明显缺陷快速记录个TODO等待review后修正，以一种开放和学习的心态看待review，慢慢整个团队的实力和代码质量就会提高。review就是个互相学习进步的过程，正规的团队都应该严格遵守，而不只是走走流程。
 (没有 review 过的代码可能很快就会成为一坨shit)
 
+- 一次检查代码在 200-400 行比较适合，不要一次提交太多代码，应当合理分配每一次提交的代码量和功能点
 - 建立 review 检查表，防止不合理、过于复杂、明显缺陷、可读性差的代码。眼睛足够多，bug 无处藏。越早修复缺陷，成本越低。
 - 建立提交模板，每个提交是需求、bugfix还是啥一目了然，同时贴上需求、jira 等地址，方便追溯。
 - 对事不对人，review 和被 review 的人都要以一种开放和学习的良好心态看待 review，共同进步。新手或者新加入项目的人不要过度吹毛求疵(会有很大心理负担和反感情绪)，共事久了步调和代码风格慢慢趋同了。

debug/index.rst

@@ -11,7 +11,7 @@ Debug 调试技巧
 一开始的负责会为以后协作和维护带来极大便利（当然你想干两天就走让其他人擦屁股就当我没说）。
 最后，很多东西我也在摸索，上面的玩意你就当小白的踩坑记录，随着理解和经验的加深我会不定期更新本篇内容。另外我发现网上大部分是教程性的东西，对于python相关的工程性的东西很少，我很疑惑难道大部分公司的python项目都写得相当规范？没人吐槽？反正我是踩过坑，希望看到过本章的人能把python代码质量重视起来。
 
-如何定位和修复 bug：复现和定位。定位需要找到 bug 出现时候的上下文信息，可以用 log，sentry，kibana 日志系统等查看。确认之后通过走查代码、断点调试等方式寻找代码逻辑错误。
+如何定位和修复 bug：复现和定位，大胆假设，小心求证。定位需要找到 bug 出现时候的上下文信息，可以用 log，sentry，kibana 日志系统等查看。确认之后通过走查代码、断点调试等方式寻找代码逻辑错误。
 
 - 第一步是复现，偶尔才复现的代码是很难排查错误的。如果不好复现但是有 sentry 之类的记录工具也是极好的，sentry 会记录当前栈信息和变量信息，非常有利于排错。
 - 走查代码。使用 pylint 等静态检测工具排除低级错误(你应该把它集成到开发工具里)。
@@ -63,10 +63,11 @@ Debug 调试技巧
 
 - 拼写错误。不要笑，这个错误其实很常见，推荐打开编辑器的拼写检查，可以消除一些类似问题。
 - 类型错误。在动态语言和弱类型语言当中比较常见的一种错误(动态语言确实更容易出 bug)，可以借助类型强转，type hint 工具。
-- 资源没有关闭。打开的文件等资源一定要关闭，防止资源泄露。go 的 defer 和 python 的 with 最好用上
+- 资源没有关闭。打开的文件/IO流/连接等资源一定要关闭，防止资源泄露。go 的 defer 和 python 的 with 最好用上
 - 深浅拷贝问题。不同语言可能又不同的拷贝模型，确定你的参数是深拷贝还是浅拷贝，能否修改，修改了之后是否有副作用。
 - 数组越界错误。注意涉及到数组的时候使用的下标是否会越界。越界了 python 抛出异常，go 直接 panic 掉。
-- 参数校验。一般来自用户的输入都要假设参数可能是错误甚至是恶意参数，后台必须要进行类型，长度等检查
+- 数值截断错误。注意强制类型转换是否会发生截断，损失精度，结果是否符合期望。
+- 参数校验。一般来自用户的输入都要假设参数可能是错误甚至是恶意参数，后台必须要进行类型、大小、范围、长度、边界等检查
 - 参数单位是否匹配。比如 go 需要时间的参数 time.Duration 有没有乘以对应的 time.Second/MilliSecond 等。
 - 路径错误。编写一些脚本需要处理文件的时候，推荐使用绝对路径比较不容易出错。
 - 空值错误。比如直接赋值一个 go 里边的 map 会 panic，你需要先给 map make 一个值，很多 go 新手会重复犯这个错(go slice 却可以直接声明之后 append)
@@ -89,6 +90,7 @@ RPC/Web 框架
 - 查询参数非法。查询数据库的时候可能因为一些不合理参数导致数据库慢查询,比如过量查询导致慢查询。可以在入口处做一下限制。比如限制limit 大小
 - 查询参数类型不匹配。注意如果传入类型不对，可能导致数据库没法利用索引导致慢查询，注意查询的参数类型和数据库类型匹配
 - 连接池跳涨。除了不当使用连接池之外，如果是启动了大量的服务容器也可能有这个问题，注意限制单服务连接池的大小
+- 连接池过大。连接池数量设置太大效率反而可能降低，应该根据实际压测结果设置一个比较合理的值
 - 主写从读。很多采用最终一致性模型，但是对于一些对时延敏感的场景要考虑是否会有主从延迟问题
 
 并发问题

go-note/web.rst

@@ -233,7 +233,7 @@ Go 常用框架(工具)
 - mongodb: mongodb/mongo-go-driver
 - id生成器: rx/xid, satori/go.uuid, bwmarrin/snowflake
 - cache(in memory): patrickmn/go-cache, golang/groupcache(分布式)
-- 并发/协程池(star 数排序)：
+- 并发/协程池(star 数从低到高排序)：
 
   - https://github.com/rafaeldias/async
   - https://github.com/Jeffail/tunny