2019-11-11笔记
争议项
1 加班累死，代码审查脱慢进度。
2 代码审查做的事无聊。 （改改注释）
3 习惯如此。
价值观差距太大时，换团队。
合适的争论 理越辩越明。
1 个人提升最好途径。
2 团队关系建设，扩大双方影响力。
3 识别设计的缺陷，找到测试不易发现的问题。
4 设立质量标杆。性格习惯。
小技巧
量小
牛人
高于平均
新员工严格
适当委婉
过两遍。
思考题 个人小技巧
1 直接截图，贴上框架代码（为表达意图，往往删掉异常处理）或其它类似实现代码
2 个人习惯，我对一些违背开发原则的事，是和开发同学不断探讨的，
简单如 dry 好判断的，一定让开发把实现抽取出来。
srp dip 这些往往具体问题具体分析，毕竟不能创个变量就上工厂吧，场景是否适合，克制那颗过度封装的心，改为逐步迭代。
3 改完后，会引一些文章。（我一般选开发接受并修改后，一是此刻他心态更平和，二是刚折腾完，手热。这时候方便适当展开。展开作者回复: 👍
1- 2019-11-27第二次读，在一个我主推代码审查总被阻碍，最后出问题了拉我救火，哪天皮了，换团队了，换一个然自己能开心的去努力的地方。
2019-11-14业务和技术缺一不可，说的太对了。
之前一直都是做后端，对前端代码审查感觉有心无力。
只能硬着头皮把前端学起来，没有真正参与开发还是很难提出建设性意见。
2019-11-11提出点个人的理解吧:记得池老师的专利第一季有篇文章<技术leader是否应该写代码>，其实目前技术经理大概有3成的时间在做Code Review。这块曾经和一些同行聊过：就像老师课中所说的，不做基本上上线可能就挂了。
目前Code Review应当有两张方式吧:
一种是强行做规则-违反规则就不让上线，提交不通过，这块可以用工具去实现；
一种就是人为的对比工具和审核，毕竟人写代码的人看不到自己的问题的，除非是公司或者部门这块的把关的，例如：sql代码基本上有DBA审核，DBA自己写的就只能自己反复测，自己挖了坑的话还是要自己填的，这个会做的异常谨慎。
个人觉得Code Review不仅仅重要，不做code review就是挖地雷;自己亲身经历过几次这种事情，这也是为何陈皓老师在他的专栏会去强调这块。好的code review会减少大量的不确定的坑：这个就像我们日常出门上班会确定门是否关好一样。
说个案例吧：从大公司到中小公司做DBA；CTO和我说数据库慢你优化一下，通过索引解决了出现的典型问题。生产上线前我说我把代码检查一遍，PM说我们的代码都测过没问题，我坚持检查一下-为此双休日没休息加班检查；周一我就扔出了不少所谓的慢且没问题的coding，CTO直接全部门发飙-先解决问题再上线。虽历史问题无力解决，不过常规问题减少了不少。
故而觉得不做code review基本山就是背着炸药包前进：什么时候炸了都不知道；只不过这块目前都是技术经理或者公司真正的专业人士在做而已。展开作者回复: 👍