2023年工作初体验

23年终于正式入职，参与了正式上线的电商平台、crm平台等项目的研发，公司规模较小，气氛融洽，没有任何勾心斗角、末位淘汰，几乎没什么压力。虽然是我的第一家公司，但实际是个适合养老的公司（笑
总结下今年工作学到的实践经验

交流方面

多交流、多沟通，老员工知道哪个地方有现成的接口。重点还有多与需求方沟通，不要觉得自己刚来不好意思交流。
刚来在业务流程上的问题尤其要大胆说，说错了也没问题，新人本来就不熟悉业务，说出一个错误选项让师兄或业务部排除，比自己去看不熟悉的代码要省时间。
一定要会砍需求！我tm直接砍砍砍！其实和运营部门和产品经理关系还挺好的。网上互怼的段子也有不少。如果不砍需求做了无用功，还是自己吃亏，绩效也受影响。

工作流程

公司使用阿里云效进行需求管理，类似gitlab
用github比喻的话，“需求/任务”对应issue；可以在对应的需求/issue上建立有对应编号的分支；
提交到自己分支，然后在jenkins测试环境选中自己的分支构建，就可以让需求的提出者/测试人员也线上测试效果了；

测试通过的话就可以提交到master分支。同github相同，新建请求合并（pr）时可以选择评审人，由评审人负责code review

经验方面

idea 提取函数;比起复制粘贴老代码，还是提取为函数，方便以后统一修改（dry原则，don’t repeat yourself，避免同一功能重复使用）；如果只记得修改一个地方，那其他几处就成了bug；
代码风格：给我做code review的这位，指出了使用stream 和 lambda表达式代替for循环赋值hashmap的问题。过去我比较喜欢朴素的写法，今后要保持风格一致。

性能

在遍历中最好不要有跨服务、跨接口、数据库的操作。我曾写过一个在遍历中调用dubbo远程接口查询订单的程序，耗时非常长；可以利用缓存"空间换时间"的思路，把数据取过来缓存在hashMap中。
之前开发的时候我只知道在For循环里查询数据库可能会对性能造成影响，现在知道了参与微服务开发后，在循环里遍历远程接口同样会对性能造成压力；而且接口都是设置了超时时限的，可能导致调用失败。

数据库

谨慎添加新字段。我刚入职添加了好多新字段，因为当时临近节假日，技术经理又放婚嫁去了，时间紧任务重，又是个性格内向的新人，进来没有好好了解需求和曾经的表结构。导致在数据库里加了不少多余字段（另一位师兄也很忙来不及细看）。一定要认真和产品经理（或类似提需求的职位，本文统称产品经理）好好交流那些内容需要哪些不需要；另外也要早点儿熟悉公司代码和表结构，有些冗余字段其实没必要加，可以用多表查询，同其他表的字段保持一致。

测试

公司唯一的测试妹子离职了，现在是自测+产品经理测，很多时候我这个不熟悉业务的新人测不出问题\bad
在实践中终于学会了打断点，并且再断点中改变数据进行测试。

postman测试

请求头中content type以填写的请求体为准，不能更改，要去选请求体的格式

测试的直接把验证码相关的校验给我注释起来口牙！

本地与开发环境配置

虽然.gitignore文件可以使git忽略一些文件，但在环境方面却有些难用，比如刚修改.gitignore后git默认还会追踪之前的那些文件；开发者本地开发时需要修改本地/测试/开发环境配置文件中的信息（比如有的开发者不会把开发环境放在本机127.0.0.1或是常用端口），需要提交时忽略这些更改，但此时的.gitignore确是公有库中大家都在使用的，不论是新增忽略文件、暂时忽略某些配置文件都挺难办；
师兄的解决办法是每次提交时在idea手动忽略；
我的办法是在idea的启动参数中指定环境，那里优先级高，覆盖掉配置文件的内容；这样每次启动时就会用本地环境，而且不用动任何文件；
在这里插入图片描述

规范与习惯

git提交消息：以需求编号开头
跟随前人的习惯写：项目新老代码交替，代码风格和技术栈多变。有的导出Excel功能用poi，有的用easyExcel;有的判空用==null三元表达式，有的用Objects.isNull()，还有的写if/else。我们代码好用==的三元表达式，那用同一个文件里统一用，不要一会if/else一会儿三元表达式。

不要用魔数，不要写这么复杂，有Objects.nonNull这个方法

    public boolean equals(Object obj) {
        if (obj instanceof Integer) {
            return value == ((Integer)obj).intValue();
        }
        return false;
    }

instanceof是不会空指针的

interface中定义常量

contains用List不如Set

分布式事务

找一个中间的一致性管理？成本和复杂性太高，金融之类的强制要求可能需要

A调用B，B也有事务，A还没提交，B只能读老数据
要么A搞个接口让B读，也挺麻烦
要是改隔离级别，可能产生脏数据。
可以搞个job晚上自动核对数据，甚至发个报警让人工处理。每天几千笔极小交易的公司也是这么处理。
多表的update保持一致要加事务，但是分布式事务成本很高，所以用消息队列？主要还是为了异步吧，事务该被拆开还是拆开了。