最近又重新看了一遍《这就是软件工程师》，上一次看的时候是去年十二月份，差不多相隔一年了。一刷的时候还是有很多地方看不明白，这次二刷能看明白很多了，主要还是因为这一年经历了很多新事情，经历多了自然就懂了。
下面是我提炼出来的一些新读懂的内容。
关于做测试
大部分情况下，我们写的代码不要用人工进行测试，而是要让机器进行测试。这时因为测试是一件重复的事情，重复的事情就应该给机器做。
测试比写代码难，因为做测试考验的是一个人全面思考的能力。
测试分为：单元测试、功能测试、集成测试、非功能测试（性能优化等）、回归测试（把以前做过的测试以及犯过的错误再测一遍。确保代码或配置的修改、需求的增加不会影响现有的功能）
1. 做测试最好的方式不是用人工，而是写代码。
2. 想要做好测试，先训练自己全面思考的能力。
3. 测试要自己做，尤其不能让用户成为你的测试工程师。
如何改bug
改bug是程序员的家常便饭，但是当你实在改不出bug时，可以试试下面2个方法。
1. 二分法：可以对代码、数据库、数据值、输入场景进行二分，不断缩小范围
2. 小黄鸭调试法：如果你已经知道了某段代码大概率有问题，就可以拿一个小黄鸭放在桌上，把这段代码对着它一行一行地解释，甚至为什么这个地方用数组都要讲得很清楚。
和朋友、高手一起工作
我们在工作时，身边总是坐着我们的朋友，我们可以和朋友互相学习进步。
1. 让高手review自己的代码
2. 和高手一起解决难题。为什么说是“难题”？ 因为只有难题，高手才会拿出真本事去解决，这时你就可以趁机学习到很多。
3. 高手的代码通用性高，且清晰、明确、有自己的风格
4. 和身边的人互相review代码，彼此信任，有问题直说
5. 没思路的时候和对方把整个流程需求说一遍，说不定对方有思路或者自己说完就有思路了
如何面对需求
在设计产品前需要进行需求分析，但注意一定要把需求分析的非常清楚、干净，你才能写出代码来。一下是2个注意点：
1. 明确问题的边界问题。例如发布一篇文章时，需要限制文章的字数，那么这个限制是指最多能有多少字？或者最少不少于多少字？这些都是要关注的点。
2. 关注不可预期案例。例如用户正在进行一场对局，按正常来说我们只需要关注局内的东西即可，但这时如果用户突然断网了怎么办？这就是不可预期，但又必须面对的东西。
团队合作
平衡业务和技术：
业务方不要把技术方仅仅当作需求解决方，而是要真正把技术当作解决问题的参与方，技术的主观能动性就能被调动起来。
业务方不要直接将需求丢给技术，而是要告诉技术真正想解决的核心问题是什么，这样技术就会一起来想办法，还可能会想到更好的方法。
平衡中后台团队：
离业务近的团队叫作前台团队
离业务远的团队叫作中后台团队。
问题用一句话概括就是，离业务近的同学觉得离业务远的同学做的东西都没用，离业务远的同学觉得离业务近的同学做的东西太短视。
这其实是一个长期目标和短期目标平衡的问题。需要大家互相理解，理解对方的诉求是什么、真正的痛点在哪里。
学会下指令：
管理者带团队时，不能简单地把任务分配给下属，直接告诉下属做什么，因为这样并不能说服他。
我们应该告诉他 第一，为什么要做这件事，不做另一件事; 第二，做这件事有什么好的方法。
