一笔记 | 这就是软件工程师( 四 ) _测试

①调研做得好不好，和阅读代码的能力高度相关。代码读得越快，意味着你的搜索能力越强，越能快速定位自己想要的东西。
②分析优缺点，结合场景才有效。做技术调研会涉及分析不同方案的优缺点，这时候需要注意,分析优缺点不能泛泛而谈，因为优缺点只有在场景下才成立，如果缺少场景，那么只有特点，没有优缺点。
2.7软件工程：不同的开发模式
①瀑布式开发模式。这是一种传统的软件开发模式，简单来说就是一层一层地开发。先分析需求，产生需求文档;再做概要设计，技术选型等;接着做详细设计，事无巨细地梳理流程和细节;最后编码、测试、上线。它的缺点就是慢。
②敏捷开发模式。它的意思是我在做雕像前,先由一个高手把框架开发出来，然后把后续的任务拆解成一个个小模块，拆得越碎越好,接着让每个团队（甚至每个人)负责其中一块,大家根据协议并行开发，最后拼在一起。它的本质是化繁为简，比较高效。
③班车模式。意思是我的发布每周一次（比如每周二)，如果你能赶得上就跟着一起发，如果赶不上就等下一班。这种模式看上去像是瀑布和敏捷的一种折衷方式。为了控制变更的需求,开发不要太快，也不要太慢,按一定的节奏来。
④分布式微服务开发模式。也就是把代码库、数据库全部分开，每个服务都由一个全功能的小团队（前端、后端、开发、测试、运维、产品）来负责,这样就可以把一个大部门拆分成多个小分队，让代码更容易维护和上线。团队之间也能非常方便和高效地协作。
2.8外部沟通：知道怎么“规训”业务
要告诉业务，不要把技术仅仅当做需求的解决方，只有真正的把技术当做解决问题的参与方，技术的主观能动性才能被调用起来。其次，不要直接将需求丢给技术，而是要告诉技术真正想解决的核心问题是什么。最后，我们面临的所有问题都不是单纯的技术问题,大家一起努力,才能从根本上解决问题。总之，技术只有知道如何和业务沟通，才能把需求实现好。
2.9内部协作：平衡前台团队和中后台团队
在技术团队里，我们通常把离业务近的团队叫作前台团队，把离业务远的团队叫作中后台团队。之所以出现问题，就是离业务近的同学觉得离业务远的同学做的东西都没用，离业务远的同学觉得离业务近的同学做的东西太短视。
这其实是一个长期目标和短期目标平衡的问题。
这时候，就需要大家相互理解，从后向前，中后台要有意识，主动去理解前台团队的需求；从前往后，前台团队也不能仅仅因为业务的压力，就用短期目标来要求中后台团队做不合理的事情。中后台团队要围绕着前台团队去建设，去创造价值，去解决前台的需求和痛点，甚至在前台团队还没有看到之前就预见出一些可能发生的问题,从而给前台团队提供有价值的服务，这样双方都能达到一个比较好的平衡。
2.10搭建体系：用知识树系统学习
①用好知识树。
任何知识，只在点上学是不够的,你需要在面上学，这叫系统地学。系统学习要求你去总结并归纳知识树或知识图。我们以C++为例，看一下知识树是什么样的。对于一棵树来说，“根基”是最重要的,所以，学好基础知识非常重要。
②探索知识缘由。
任何知识都是有缘由的，了解一个知识的来龙去脉和前世今生，会让你对这个知识有非常好的掌握，而不再只是靠记忆去学习。当然并不是所有的知识我们都需要了解缘由，对于一些操作性的知识，比如一些函数库,只要学会查文档就好了。

一 笔记 | 这就是软件工程师( 四 )

一笔记 | 这就是软件工程师( 四 )