产品是方向，开发是手段，SQL是工具，测试是保障。知识这东西，多了解一点就更专业一点。
开发
1.前端
运行在用户端，普通用户可以直接看得到或直接操作的页面，比如我们看到的微信公众号文章。
哪些内容是前端负责？用户可见的界面，网站前端页面也就是网页的页面开发，比如网页上的特效、布局、图片、视频，音频等内容。前端的工作内容就是将美工设计的效果图的设计成浏览器可以运行的网页，并配合后端做网页的数据显示和交互等可视方面的工作内容。
2.后端
运行在服务器端，你不能直接看到的，通常是与前端工程师进行数据交互及网站数据的保存和读取，比如微信公众号后台数据库里不同大V的公众号文章。相对来说后端涉及到的逻辑代码比前端要多的多，后端考虑的是底层业务逻辑的实现，平台的稳定性与性能等。
哪些内容是后端负责？提供数据，如微信公众号热门词汇，每篇文章的具体内容是什么时机由后端提供给前端进行展示。后端给前端传递信息的通道有接口有消息，前端会根据跟后端约定好的方式将请求参数发给后端，后端返回前端想要的数据。
3.部署/发布/上线
服务端研发，虽然他们是后端开发，但是并不能直接在服务器写代码。只能天天在自己mac的ide上写，写好代码本地自测没问题，再上传到服务器。这里说的服务器，就不是常规意义上的某一台或几台主机了，而是几个或者几十个包含若干服务器主机的机房。这个过程要解决代码上的依赖才能跑通，看是你要的效果，就算部署成功。
4.同步
发送方发出数据后，等接收方发回响应以后才发下一个数据包的通讯方式。
举例：当程序1调用程序2时，程序1停下不动，直到程序2完成回到程序1，程序1才继续执行。
5.异步
异步的概念和同步相对。发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。
举例：当程序1调用程序2时，程序1继续自己的下一个动作，不受程序2结果的影响。
6.配置文件
配置文件的优点是灵活，很多需要经常变换的数据是不能写死在程序里，因为程序在运行过程中无法更改。所以对一些经常变化的配置，比如价格、数量、库存这些经常要调整的参数，这个就适合写在配置文件中开放给产品或采销同学更改，程序需要这些数据，就从配置文件中读取。
7.API接口
Application Programming Interface，即应用程序接。API的作用是信息传递，比如，我们通过京东的API接口获取某笔订单的详细信息：订单号，收货人，订单商品信息，订单金额等。
获取信息的方式有两种：主动调用和被动调用。主动调用是我们通过别人的接口，获取自身想要的信息；被动调用需要我们提供API接口，让别人通过接口获取信息。
API两个核心信息：请求参数和返回参数。
请求参数是获取想要的信息需要告诉对方接口的必要条件。比如想要获取某笔订单的信息，就需要告诉接口对应的京东订单号，接口根据订单号返回这个订单的详细信息。
返回参数是接口能告诉我们的信息，如上面所说订单的收货人、订单金额、订单商品。
8.消息
8.1.主要组成
1）Broker
消息服务器，作为server提供消息核心服务。
2）Producer
消息生产者，业务的发起方，负责生产消息传输给broker。
3）Consumer
消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理。
4）Topic
主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播。
5）Queue
队列，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。
6）Message
消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输。
8.2.交互方式
1）点对点
PTP点对点：使用queue作为通信载体
说明：
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
2）发布/订阅
Pub/Sub发布订阅（广播）：使用topic作为通信载体
说明：
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。
queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。
topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝。
8.3.为什么使用MQ？
有的产品会问，已经有API这种高效及时的交互方式了，为什么还要再有一套MQ机制进行信息交互呢？其实道理比较好理解，API的被调用方作为信息提供方，如果只有一个或几个下游系统进行请求且请求频率不高，可能没有负载问题。但是如果这种下游系统有若干个并且请求频率极高，比如双11、618这种大促活动，作为信息上游的被调用方压力很大。
因此对于一些信息及时性要求不是那么高、多个下游系统均存在使用的场景，MQ方式必不可少。
1）异步。可以将一些非核心流程，如日志，短信，邮件等，通过MQ的方式异步去处理。这样做的好处是多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败。缩短主流程的响应时间，提升用户体验。
2）消峰。这个其实也很好理解，因为MQ的本质就是业务的排队。所以，面对突然到来的高并发，MQ也可以不用慌忙，先排好队，不要着急，一个一个来。消峰的好处就是避免高并发压垮系统的关键组件，如广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况。
测试
1.单元测试：由程序员自己负责，粒度可以是一个类或是一个函数，测试的是某个类或某个函数是否能够正常运行，单元测试属于白盒测试。
2.回归测试：代码已经发布，修改了旧代码发布的时候就需要测试以前的测试用例在新系统上是否能够正常运行。
3.压力测试：测试软件的最大承受能力，比如一个网站最大可以支持多少用户同时访问。平时说的百万并发问题等。
4.AB测试：AB测试就是将用户分为两组，例如A组和B组，当A组访问时，给出的是A页面，当B组访问时给出的是B 页面，测试AB两组用户对AB两个页面不同的行为，再决定最终用那个页面，属于决策层。
5.白盒测试：了解程序内部原理的测试，这部分是由程序员自己搞定的，比如单元测试。
6.黑盒测试：无需了解程序内部原理，根据软件的功能进行测试。比如用一个APP，测试各个功能。
7.测试用例：就是各个测试的场景，测试用例也分单元测试的测试用例和集成测试的测试用例，测试用例需要覆盖各个场景，包括正常产品场景，比如点击输入提交订单按钮，是否会如产品设计的一样跳到支付的页面等，另外测试用例还要覆盖各种极端场景，比如计算机，输入很大的数字的时候会是什么样的结果，除数为0应该是什么样的结果，支付时输入一个极大金额会怎样等等。
8.mock：并非生产环境的真实数据，而是根据测试用例所模拟伪造的数据，这个一般是在开发自测阶段使用的。
数据库
SQL基础：
SQL SELECT 语法：
- SELECT 列名称 FROM 表名称
以及：
- SELECT * FROM 表名称
实例：
数据库订单表
1）遍历语句
举例：查询一个数据库的所有订单情况
select * from settle_trace
说明：这种是最简单的语句，其中*代表所有字段，这种会把所有符合条件的数据都拉出来。
2）带条件的计数
举例：查询流水接收时间晚于2019-09-01的订单流水数量
select count(*) from settle_trace where gmt_creat>’2019-09-01’。
说明：count是计算总数据量，where是条件语句，gmt_creat是条件的主体，>’2019-09-01’约束条件。一般支持大于（>），小于（3）排序
举例：查询一个数据库流水接收时间晚于2019-09-01的订单流水，按照流水创建时间倒序（取最早的10条），并且只取10条。
select * from settle_trace where gmt_creat>’2019-09-01′ order by gmt_creat desc limit 10。
说明：limit是限制返回条数。order by 是排序，按照后面的属性进行排序。其中desc是倒序（就是从大到小），asc是顺序（从小到大）。
