程序员工作中常见问题，你遇到过几个？

在赛博朋克2077玩后感中，我提到，即便是在严谨的机制下，依然可能出现让人匪夷所思或是贻笑大方的问题。

那么今天，就以后端程序员的视角，盘点下从设计开发到上线的常见问题，看看大家中过几个。

01

设计与开发

1.权限控制

如果是暴露到互联网的接口，要控制数据权限，避免被暴力爬库。

例如：getData(Long id)，没有校验当前登录用户是否有查询该数据的权限，结果被对方用程序暴力爬库。

2.熔断

如果上游服务经常故障不可用，可以加入熔断机制。

和业务方确定好熔断规则（失败次数、超时时间等），还可以额外加一个是否启用熔断的开关。

3.任务状态

任务状态扭转时一定要形成闭环，不能有中间状态挂起，同时异常情况需要考虑补偿。

例如：某定时任务逻辑如下，且没有其他补偿任务。

// a.将数据状态从[初始化]->[处理中]
// b.一些业务逻辑
// c.将数据状态从[处理中]->[成功]/[失败]

在任务执行时发生系统崩溃或系统重启，这些数据就停滞在[处理中]了。

4.重试与幂等

任务失败或异常后要有重试，注意重试逻辑要考虑到幂等，保证数据准确性。

例如：上述的定时任务可以拆成两个，保证单个定时任务的职责为仅转换一次状态；或是增加一个补偿任务，用于检索处于[处理中]的异常数据并处理。

另外，幂等性可以通过唯一标识、锁、数据库唯一索引、先查询再操作等方式实现。

5.循环与异常

是一条数据失败/异常就全流程结束并回滚？还是可以忽略掉并继续执行其他数据？根据实际情况确定清楚。

同时，循环要检查好出口，避免死循环。

6.并发

使用多线程要考虑各种极端情况，最好都加上锁。

7.缓存

老生常谈的雪崩与穿透问题，使用缓存+数据库时，避免缓存同时过期造成雪崩，也要避免特殊情况下能绕过缓存打到数据库。

使用缓存锁要设置合理的过期时间，防止死锁。

8.接手新系统

仔细斟酌，不懂多问。

未使用的代码

有些代码看上去没问题，但实际并未在生产运行，调用时要多留个心眼。

例如：一个没有调用者的服务，里面是对一张表的查询。使用这个服务，测试环境没问题，上线就出问题了，原因是线上压根没有这个数据源的配置。（蚌埠住了）

重复的组件或框架

因历史原因，同一个组件或框架在代码里存在多个。

例如：项目中存在两个同名枚举类、AOP 切面、工具类，调用时使用了错误的那个。

9.语言细节

以 Java 为例，String 的比较，BigDecimal 初始化、比较，NPE、集合框架常见问题等等，这块就纯粹是看基础是否扎实了。

10.异常处理

根据业务流程，判断代码中的异常是该往外抛还是自己处理掉。

11.日志打印

不多打

正常请求、文件流，打印出来浪费资源。

不少打

异常时的错误信息、关键字段，打印出来可快速排查问题。

例如：代码上线后，因将文件流打印到日志，且流量较大，过一会儿运维就电话过来了，反馈机器磁盘空间不足。（恐怖故事：上线一段时间后来电话）

12.Tid

多线程下使用 Tid 要额外处理，避免所有线程共用一个 Tid 或 Tid 丢失的问题。

13.单元测试

按规范写单元测试，不要过于随意，例如在 Controller 层写个接口来测试，可能引发安全问题。

14.影响范围

哪怕是一行代码，也可能牵一发而动全身，仔细评估影响范围，并将改动点和测试交代清楚。

例如：改动一行代码，看似已经检查了所有使用者，结果由于其身处设计模式或 Spring Bean 中，还有其他间接使用者，就评估漏了影响范围。

02

CI / CD

1.Maven

依赖问题

Maven采用最短最先声明优先原则，如果随意使用可能会依赖到我们不想要的版本，最好还是手动做依赖排除。

代码推包

在 Deploy 前，确认版本号是否需要升级，避免代码因随意推包而被带上线或是覆盖他人代码。

例如：开发A将某XML文件删除，开发B虽然 Pull 了最新的代码，但本地的 target 文件夹下依然有该XML文件，未升级版本号进行 Deploy ，结果将该文件又推了上去，从而引发问题。

版本控制

当存在多个开发中的需求时，需要特殊处理。

例如：线上版本1.0，正在开发的的版本1.1，此时加入紧急需求并上线使用了1.2，那么在紧急需求上线后，最好将原来开发的版本从1.1直接升到1.3，如果还沿用1.2，可能导致包被带上线。

2.GIT

代码合并

主要看团队的分支管理规范，有时因存在多个开发中的分支，容易误合被带上线。

代码推送

例如：口口声声说合了代码，结果只合并到了本地分支，没有推送到远程仓库。（搞笑呢）

3.启动参数

合理的内存配置
权限

如果应用需要操作文件，那么它启动参数的用户应该要有操作文件的权限。

4.灾备问题

服务对接时，如果一方是双活，一方是单活冷备，需要注意请求是否会走到冷备那边。

例如：某应用作为 MQ 生产者是双活部署，结果 MQ 消费者的应用是单活，那么自然而然其冷备所在环境的 MQ 就没法消费。

03

数据库

1.迁库

通知下游

提前梳理好所有使用方，最好让 dba 看下流量来源，并将这些应用的数据源配置整改好，迁移时直接改数据源地址然后重启。

例如：评估漏了使用方，结果都迁移一周了对方反馈无增量数据才知道。。

代码修改

有些时间函数语法是相同的但是时间单位不同，不会报错也不易发现，迁移时需格外注意。

2.上线 SQL

索引

没有确认 SQL 在线上的执行计划，导致慢 SQL。

评估影响范围

如果会造成锁表、增加主从同步时间等，需要评估对业务和其他读从库的系统的影响，确定好执行时间并通知相关方。

3.修数时

先验证

先修一笔的验证逻辑，确认无误再全量修。

例如：没有验证就全量修数，结果未达到预期并造成了更复杂的局面，花了更多的时间处理。

执行顺序

注意 SQL 执行的先后顺序，以及对当前业务有哪些影响。

例如：先插入了待执行的任务，再修改的其他数据，结果任务插入后立刻被程序执行，但实际其他数据还未准备完毕，又花了更多的时间处理。

04

定时任务

1.路由策略

把分片广播的配置成了单机，效率低下，当然反过来如果没有幂等也一样有问题。

2.阻塞处理策略

单机串行可能重复执行，丢弃后续调度可能漏执行，要根据实际业务逻辑选择。

3.Cron 表达式

时间

例如某些固定在每月某天执行的，可以通过工具确认下次运行时间。

依赖

如果任务有前置依赖，应该在代码里检查前置是否执行完成，或延后任务的执行时间。

4.任务参数

填写错误，例如数字类型填成了字符串类型。

05

配置文件

1.不要手敲

采用手敲而非复制，导致值不正确。

例如：经典 oO0D、2zZ、1Il。

2.确认发布

未发布配置便投产应用，导致应用启动找不到配置。

3.确认值

线上直接使用测试环境的值（测试同学随便配的），开发没有去核实该配置，导致有问题。

最好是规范到产品接入表格里，让业务提供准入参数。

4.配置还原

配置在临时调试、处理问题后，要还原本来正常的值。

例如：扣款时间在9点，由于9点至10点上游异常，临时改动到11点扣款，处理完成之后，忘记将时间改回去。

06

网络

1.确认网络

确认网络策略开通后再发布应用，以免代码提前运行报错影响业务。

2.白名单

通常网络策略和白名单是配套的，注意找网络同学要最新的对外出口白名单。

3.安全访问

HTTPS 访问 HTTP 会被浏览器拦截，导致无法访问。如果代码暂时整改不了可以写一个浏览器配置操作手册发给使用方。

07

文件

1.权限

应用是否有处理文件的权限，有时得到的路径可能是相对路径，权限和路径也挂钩，需要注意。

2.区分

文件要检查是否能通过文件夹或文件名来区分，否则可能只有一个文件在不断被覆盖。测试时可能只测一笔数据，不会测到。

08

上线验证

1.谨慎对待

业务流程、日志、监控告警、数据库多层次验证，不要随便看下没问题就溜了。重大变更要有详细的上线步骤、验证步骤。

文章推荐：程序员工作中常见问题，你遇到过几个？

原创不易，点个关注不迷路哟，谢谢！

文章推荐：

如何提高核心竞争力
读书笔记-《我的互联网方法论》
读书笔记-《银行4.0》
读书笔记-《Spring技术内幕》（一）IoC容器的实现
读书笔记-《当下的力量》
读书笔记-《写给大家看的设计书》