实习心得-链家网

六月中下旬，以Java研发实习生身份，入职链家网，截止已有一月有余，就目前从事的工作及学习心得进行记录与分享。

1、工作性质：
侧重应用服务开发，以编写增删改查的接口为主，但却不只是基础的增删改查，看似简单，却要在编写接口之前，充分考虑代码的可扩展性，细节的处理，以及及时的单元测试
　　1.1 细节
　　 try-catch异常的捕获处理，不能因为一个普通的空指针异常就让整个程序停止运行。
　　 Null值判断，每一次的查询，或者每一次从request获取值，在使用前都需要进行非空判断和处理。
　　 重视设计，接口的设计第一要求是快速响应，因此，需要尽可能的减少与数据库的连接次数（打开连接-查询-关闭连接），打开一次连接之后，应尽可能多的将后期业务逻辑所需要的数据一次性查询出来，在内存中用list或者map等几个常见的集合接口进行存储，而不是反复的连接数据库去查询。
　　 在保证响应速度的前提下，尽可能少的减少代码的重复率，即代码重构，定期review自己写的代码。
　　 这里补充一句，大多数人进入公司时，可能并不是接到一个从0开始起步的系统，更多的是接手已经有一定基础，且经过几次迭代但尚未稳定的系统，这时候，review code的时候，很多时候就有了参照依据，多去对比，多反思前辈写的代码，为何留有各种伏笔，举个简单的例子。
　　 当前需求，明明只需要查询指定的一条记录，却仍将记录用list进行存储，并将整个list传入下一个所需要的方法中。即前文考虑的从代码可扩展性考虑，需求变动时，力求代码改动最少。
　　 1.2 增、删处理
　　 增，即向表中插入一条记录，一句话，看似很简单，但在实际的场景中，需要考虑的问题很多。
　　 比如，当前系统A与系统B有通信需求，且消息从B—->A，利用Kafka消息队列做通信媒介，这里A就是典型的客户端消费者。
　　 系统A Pull到记录并准备写入数据库时，如何做防重处理？
　　 1、对表指定联合主键（底层表设计），则写入数据表时，交由底层数据库自动做防重处理（出现重复记录，最多反馈一个插入失败的异常，完全可由业务逻辑进行处理）
　　 2、无法对单表中的记录指定联合主键，可能需要配合其他表才能唯一确定一条记录。则需要一张中间表，unique表进行记录，每次写入时，先遍历该表，是否已存在记录。
　　 3、逻辑外键维护，若在数据库设计阶段就指定大量的外键关系，则底层数据库将需要花费极大的代价去维护这些外键关系，因此，更多的策略是，在实际设计表时，不指定其外键关系，而交由业务系统进行处理。
　　 优点：底层数据库省去维护外键的时间和代价
　　 隐患：对设计者代码把控能力要求更高，因为全部交由业务逻辑实现，因此需要在业务逻辑中进行维护，不能出现遗漏。
　　 事务的控制，由于某表新增了一条记录，导致其它表也需要新增关联记录，此时应将这一系列操作视为原子操作，需要添加事务控制，出现异常时，进行回滚操作。
　　 删，处理逻辑跟增总体一致，注意事务控制。
2、工作节奏
公司整体节奏较快，但仍可以找到一个自己舒适的工作节奏，按部就班进行工作，最好指定周计划和目标，估算好工时。每周末定期review既定任务完成情况，出现delay，则需要思考哪些方面安排上出现失误。
3、工作中的学习习惯
刚入职，自己所接受的知识量是非常大的，尤其是在面对以往不熟悉的领域，需要尽快消化，抓住别人讲解的时候，尽可能多的思考，提问，保持注意力高度集中，别人给安排的任务，不知道如何入手时，开口问，因为自己尚未形成合理高效的工作习惯，尽可能多的请教是唯一的解决方式。不要等着别人主动过来给你讲，这不可能。
4、其他实际问题处理
AMQ切换Kafka，上周任务，之前对消息队列完全没有概念，只有一周时间将AMQ进行切换。

1、排期
1d
理解消息队列，收集学习相关AMQ、Kafka基础知识
1d
疑问，为何需要将AMQ切换成Kafka，Kafka较AMQ而言，有什么优势，有什么劣势，进一步理解Kafka使用方式及特点（依赖Zookeeper，为何要依赖Zookeeper？broker的无状态机制，新版本Kafka已和Zookeeper解耦）
2d
熟悉原有AMQ如何实现消息通信，并作为消费者，如何处理AMQ中传过来的消息，理解其AMQ配置文件中的各个bean含义。
上网查阅如何集成Kafka+spring。开始着手改造
集成时，需要注意以下几个问题：
1、添加Maven依赖时，注意版本是否完美兼容，最好的方式，查阅官方文档，
2、添加完jar包之后，需要进行排包，新的jar包容易引入之前重复的包，比如最典型的就是log4j，slf4j这几个日志包，需要进行排包。
3、理解Kafka配置文件中，几个bean及其bean中属性的具体含义

结合原先AMQ配置文件，思考切换时，代码改动代价最小的情况下，将AMQ切换为Kafka（其实本质上就是修改配置文件和属性文件，无奈前期踩了许多坑，加上时间紧张，磕磕绊绊，难免焦虑）
处理焦虑的最好方式，就是。。。啥都不想，上个厕所安静安静。