技术管理课十
技术人在职场中常见的错误。
如果涉及到了公司层面，那就不存在小事，处处皆大事
比如，当我们在公开的技术论坛上进行讨论的时候，往往是带着公司的身份去的。那么我们无论是在这种场所讨论本公司的技术架构还是使用到的第三方服务，一定要注意措辞，只讨论技术本身，千万不要涉及到任何公司，不然可能会带来公关上的问题。
设计公司内部的人士变动，了解但不要太显摆，不要太在私底下对人士变动进行太多的讨论。
在讨论技术的时候，如果不确定一个答案，就不要随便的给出这个答案
喜欢分享本身没有错，但是对于自己不确定的答案。如果给出的答案是错误的，甚至是模棱两可的，那么会导致失去他人的信任。
最后，最重要的问题是技术失误导致的产品错误。
在当今时代，工程师手握的资产愈发的多。往往一个涉及到产品的决策会导致千万级别资金的盈利和亏损。
就比如在进行AB测试的时候，如果没有发现相关的问题，导致B进行了上线，而上线之后造成了损失。
除此之外，还有一些延伸性质的错误
比如在尝试做能力之外的挑战的时候，因为自身能力和其他条件的束缚，做得不好因而犯的错。而且这类错误没有什么参考项，只能靠不断的进行摸索前行，解决错误。但当解决了这个问题之后，就会发现自身已经升级了，进入了另一个境界了。
当然还有在职场中常见的，因为自我的无知或者粗心大意而犯的错。
对于无知犯的错，常见于对于安全校验边界的不了解，或者没有仔细阅读产品文档。那么在主观上并没有意识到犯错的风险，但归根到底并不是大问题，只是要避免在不同类型上犯相同的错误。而粗心大意，则需要小心，需要在接下来去纠正自己，避免一错再错。
针对这些错误，我们需要去考虑如何规避，以及如何从错误中成长
- 为了避免能力挑战的时候的错误，可以在内部建立一定的培训机制，当面对新领域的挑战的时候，可以利用培训机制，进行相关的指导。
- 为了避免出现无知错误，需要建立一个互通机制，尽可能的将相同的信息传递给所有人。
- 为了避免粗心错误，可以设置一定的复盘机制，多做一些Checklist，做事的过程中多进行对比。
- 最后为了避免高风险问题，尽可能有一个备用方案，从而避免从头错到尾。
那么我们需要针对不同的错误，对症下药，在错误中成长。
如何看待并执行code review
首先我们需要明确一个概念，code review是在程序员间，以同级的身份，进行彼此之间的代码评审，其目的是为了找出软件的错误，提高软件质量而存在的。而非是挑错。
在执行code review的过程中，是为了对整个项目整体好。
那么再次基础上，我们可以先看下Code Review的具体益处，并在之后看看需要注意的项。
Code Review可以增加团队的整体性，在项目开发中，我们更期望大家的代码具有相似性，最好具有一致的风格，那么Code Review之中，我们可以了解并查看他人的代码风格，并对代码风格进行学习。其次Code Review可以更友好的带新人。虽然Code Review可能会花费比直接修改他人的代码更长的时间，但是在长远来看，一定程度上可以复制你的生产力，也就是提升他人的生产力。毕竟自己去绕过一个坑，告诉他人如何去绕过一个坑更重要。
那么其次，我们可以看下Code Review的注意事项
- 在Code Review他人的PR的时候，一定要注意他人的PR原因是否书写的清楚，最好越详细越好。
- 其次是一个PR，尽量保证只有一个功能，也就是目标的单一性，不要引入非这个PR目的改动。如果出现多个改动一个PR，不仅会导致阅读困难，还会在出现问题后难以回滚。
- 找谁去审核，一般来说，都是去找本组的人审核，如果涉及到跨组的时候，才会考虑引入外部人员。
- 在审查他人的PR的时候，如果可以有人分摊自己的压力，那么可以让自己只关注希望关心的点，比如只查看算法方面，或者只关心最外层API格式方面。
- 更加细节的Code Review，可以从代码格式方面，可读性方面（比如是否具有嵌套太多层的语句），业务上的死角方面，错误是否正确处理了。是否测试用例书写完整。是否将代码段合理抽出。
最后作为一个技术管理者，应该对Code Review这件事本身持鼓励态度。
并且应该教导大家使用同样的工具
鼓励大家彼此审查代码
指定统一的编码规范，从而帮助大家减少争端。
最后当他人对自己的PR提出意见的时候，也不要情绪化，毕竟都是日常工作。应该虚心查看他人的意见，并对自己的代码进行合理化修改。