关于java:一次代码评审差点过不了试用期

作者：小傅哥
博客：https://bugstack.cn

积淀、分享、成长，让本人和别人都能有所播种！????

好的代码往往也很难看

代码是给机器运行的，但同样也是给人看的，并且随着上线还须要由人来运维。那么写出 可扩大 、 易保护 、 好读懂 的代码就显得十分重要。

对于新人来说，互联网大厂我的项目开发与平时本人学习的代码还是有很大的差异的。日常学习时候通常只有能运行出后果即可，并不会有其余的要求。也不会说有；PRD 评审、研发设计评审、代码开发、代码评审以及两头一些列的提交物，直到测试实现，上线验证，开量对外等等。

所以很多新人刚从学校毕业或者从小公司进入大厂，在标准制约下会有一些不习惯，甚至犯错误。那么为了让大家更好的通晓这些问题，小傅哥特意整顿了一些例子，欢送参考。

谢飞机，刚刚入职没多久，兴奋的写着 leader 给的需要，???? 码的飞快。凑巧组长走过去：“飞机，带着你的电脑，跟我来码云会议室，做下代码评审。”

leader：飞机，你这代码咋这么粗鲁！

飞机：啊？????

leader：我要不拦着你，我感觉你这代码都能飞。

leader：你看哈，就说这行，这日志打的，上线后出了问题，你能查到起因吗？

飞机：如同 …

leader：还有这，这 idea 都提醒你了，都报黄色了，你怎么不看看。还有，这代码也不格式化，一个月后它意识你，你还意识它吗。

leader：给你发的入职编码标准看了？

飞机：哦，看一些，写的时候忘了。

leader：先别着急写，看会了再写代码，这还有一个不错的工程：《Netty+JavaFx 实战：仿桌面版微信聊天》，能够参考。

写代码不是以实现性能就算完事，还须要写的丑陋。评审后，飞机，坐回工位，收起了躁动的心，安心熟读手册并练习。

日志是整个代码开发过程中十分重要的环节，如果日志打的不好，那么遇到的线上 bug 就没法疾速定位，定位不了问题也就没法疾速解决问题。间接带来的后果可能包含；客诉更多、资损更大、修复更慢。

就像上面这段代码中的日志；

public Result execRule(RuleReq req) {
    try {logger.info("执行服务规定 req：{}", JSON.toJSONString(req));
        // 业务流程
        return Result.buildSuccess();} catch (Exception e) {logger.error("执行服务规定失败", e);
        return Result.buildError(e);
    }
}

看似没什么问题，但在这段异样代码中，没有打办法的入参信息。如果办法异样时只是抛出一些异样栈信息，那么是很难定位具体的由次调用触发的。
另外如果你的系统监控服务，没有相似办法跟踪 ID 的性能，最好还须要在日志中把本次调用具备标识性的 id，作为查问条件打到日志中。

批改后的日志：

public Result execRule(RuleReq req) {
    try {logger.info("执行服务规定 {} 开始 req：{}", req.getrId(), JSON.toJSONString(req));
        // 业务流程
        logger.info("执行服务规定 {} 实现 res：{}", req.getrId(), "业务流程，必要的后果信息");
        return Result.buildSuccess();} catch (Exception e) {logger.error("执行服务规定 {} 失败 req：{}", req.getrId(), JSON.toJSONString(req), e);
        return Result.buildError(e);
    }
}

那么当初这样改成这样打日志，就能够十分不便的查问问题，例如搜寻；执行服务规定 100098921，那么它的一整串对于这次调用的信息就能够都搜寻进去了，不便排查问题。
在异样中打印入参是为了更加不便的定位问题，不须要比对上下文。
打日志还有很多技巧，但所有打的日志目标都为了在出问题时能够疾速定位问题，但也留神不要打太多日志，精简好用即可。

很多时候因为你，走神、忽略、手滑，写进去的错误代码，IntelliJ IDEA，都会给你正告⚠提醒，只是你，没有去看、没有去看、没有去看！

来自 idea 的正告；

Idea 在正告提醒这方面十分优良，只有你能看得见，依照它的提醒批改，就能够缩小很多的谬误。
如果你还心愿有更强的提醒，那么你能够依照 p3c 插件，帮你查看代码谬误。

可能这并不是一个致命的问题，但代码格式化最大的益处是，晋升可读性、规整性、以及能够让整组人都在一个规范下执行。因为很多时候一个组的程序员，会在一个类下开发，有人格式化、有人不格式化除了不难看以外，合并代码有时候也会遇到麻烦。

不格式化的代码短少灵魂；

对于严格要本人的程序员来说，代码没有格式化还是很好受的。
看一段代码，只有发现差一个空格地位，都晓得这是格式化还是没格式化。

单测？覆盖率？写代码不是写完就能够了吗？

当然不是，你写的代码你须要保障它能你跑通你所有的流程节点，确保这份性能是没有问题的，能力提交给测试，否则来回重复，耗时耗力。这也就是写单测的目标！甚至好一点的研发能够通过单测驱动开发，在这个阶段能把一些共用的办法合并、抽离，防止过多的冗余办法。

单测长什么样；

单测残缺根本也就是代码的健壮性更好，能把单测写好，根本提交的代码就不会有那么多测试妹子找你聊天。
在很多公司中个别都会要求单测覆盖率超过多少，否则是不容许编译提交的，这有插件能够和 Jenkins 配合应用。

可能有些人看到 分支标准 基本没有感觉，因为他们开发的我的项目较小，没有多人开发，上线周期也短，也不会开发中增加需要。

但在互联网中并不是这样，往往一个零碎须要几个人保护，并同时进行开发。个别这里会包含；master 分支、test 分支、本次需要的分支，有这么多分支怎么用呢，如下；

master 分支，是主分支，也是上线分支，不容许在下面间接批改代码。
test 分支，是测试环境分支，每个人都须要把本人开发完的分支，提测后合并到 test 分支，交由测试验证。
需要分支，也是集体开发的分支，同一个需要下，大家在这个分支写代码，当然也可能这个零碎模块的分支就一个人在开发。

重点，如果有人不恪守分支标准或者压根没概念，把本人的需要代码写在 test 分支上，并且是屡次批改提交都在 test 分支写。那么就危险了，重大会耽搁上线；为什么？

test 分支，是由大家把本人的代码合并过去共用的，那么这个分支就会蕴含 2 个或者更多的并行需要，当你须要上线的时候，须要把本人的代码合并到 master，但 test 分支代码是不能合并到 master 的，那么多未知的内容，基本没有在上线范畴。
那么你又想上线，又不能避开 test 分支，就须要把你写的代码，从新粘贴过来，这个工夫老本十分大。
test 分支，还随时有删除从新拉的可能，如果有人告诉大家删除从新拉，那你的代码就会失落。

提交测试，但还藏一个需要

研发开发需要代码时候，有时候会额定加一些其余代码，而且这些代码可能跟本次需要并没有关系。那为什么会这样呢？

以前留下来的 bug，想修复下，但遗记告知测试
在开发这个需要时，其余产品又找过去让加性能，并说性能很小，没有发邮件告诉相干测试人员
看到某块以前写的代码太乱了，就想着优化下，自信心很高，不用通知测试

那这时候你提交的代码，如果不在测试范畴又出了问题，只能研发本人抗。并且在所有的研发团队，简直是不会让夹带需要上线的，这样的做完了不算功绩，做出了问题还会被骂。

所以，千万不要擅自夹带！哪怕你是善意！

擦屁屁的纸，80% 的面积都是爱护手的！

这句话是我常常用的，因为咱们编程很多时候都是在解决异样流程，失常流程往往并不难，难的是剖析出这段开发的代码有多少异样流程有没有解决。

那么，会有哪些异样呢？

领取胜利 MQ 音讯发送失败，须要 worker 弥补
PRC 接口调用失败，网络超时，理论胜利
接口幂等性，屡次调用后果一致性

等等，这些都是异样流程，尤其在一些交易提现环节，会呈现各种异样，那么不可能把这些异样都反馈用户展现到界面。而是要有一些十分敌对的提醒，并且在服务端的流程里，有肯定的弥补机制，来保障最终的调用胜利，或者逆反。

CRUD 往往可能是因为你的设计，换集体写兴许不同

很多时候研发写代码，基本不思考是否要扩大，总之一个类 + 几十行 ifelse，能搞定所有需要。等下次在开发相似的，就粘贴过来再修修补补，能用就行。

短少写出良好代码的研发，一方面是经验无限，另外一方面是学了很多实践然而不好落地。比方设计模式，但本人理论写代码的时候还是很晕。

这里举荐一本我写的《重学 Java 设计模式》，全书共计 22 个实在业务场景对应 59 组案例工程、编写了 18 万字 271 页的 PDF、蕴含交易、营销、秒杀、中间件、源码等 22 个实在场景。能够增加小傅哥微信获取：fustack

select * from table where status = 1 limit 200;

这是一段定时工作扫描库表的 SQL，这段 sql 会定时扫库，将库表中状态是 1 的扫描进去进行解决，每次扫描 200 行。你发现有什么问题了吗？

扫描必要字段即可，不须要全副字段
这段 sql 会越来越慢，即便状态字段加了索引。因为 status 并不能大量排掉其余状态字段，随着数据越来越多仍然是全表扫描。

那么怎么优化呢，其实优化也比较简单，须要先依据状态查问到符合条件的最小的 id，之后再 sql 的查问条件中增加id > xx，即可。另外如果你的工作须要多个 worker 扫描，减少效率，能够减少门牌号设计，晋升扫描效率，如下；

评审代码最初这点想说说，陪伴式开发，可能这不是结伴编程，不是独特单干，而是一个研发须要另外一个研发一直的提供帮忙。有时候可能就是很简略的问题，也不想查，或者说没有意识去查，只是问。

业务开发的过程，只有把流程定下来，研发设计评审完，其余的开发过程中遇到的小点并不难，只有查一查就能够搞定。当日也不是说齐全不能问，只不过特地广泛，简略的代码问题，本人搞定就能够了，但这个时候还像保姆似的陪伴，就会连累整个团队的停顿，最终大家都须要扛起那个慢的。

所以，如果你是那个须要陪伴的，要及早断奶，学会本人攻克，疾速成长。而如果你是那个卷纸，可哪擦屁股的，要把卷纸传递给他。一个人擦一次是能力体现，反反复复擦一个人，就惹屎上身了。

以上介绍了代码评审中波及到的比拟常见的点，根本也是很多研发容易疏忽和犯错误的中央。这些问题点但拿出哪一个看，都不大。但运行在代码中，确都有可能产生致命或者麻烦的事件。
想让本人能把代码写好，就不只面试时候造飞机的答复，什么工夫复杂度、什么可重入锁、什么红黑树，什么 DDD，只有你不能正确的落地和使用这些技术，说的再多都是空谈。
多学一些、多看一些、多问一些，没有害处，但要本人能成长，把汲取到的教训心得，使用到业务开发中，写出可扩大、可保护的代码，能力让本人真的升职加薪。也能让既有留下的本事，也有进来的能力。

握草，你居然在代码里下毒！
DDD 畛域驱动设计落地计划
重学 Java 设计模式(22 个实在开发场景)
面经手册(上最快的车，拿最贵的 offer)
字节码编程(非入侵式全链路监控实际)

关于java:一次代码评审差点过不了试用期

一、前言

二、会议室

三、代码评审

1. 日志标准

2. IDEA 提醒

3. 代码格局

4. 单元测试

5. 分支标准

6. 夹带需要

7. 异样流程

8. 代码成坨

9. SQL 性能

10. 结伴编程

四、总结

五、系列举荐