@Felldeadbird 不是人人去应聘保安都会应聘得上的。别想当然保底

你看看，楼主当保安后，闲下来了，都可以开始作诗一首了。
我们却每天在群里回复收到收到的

@thatlazyman 怎么广东拖沓呢，广东领失业金是真的高效便捷。粤省事 app 一键操作。

@weijancc 像一些后台管理类的代码，很多是简单的 curd ，不超过 5-10 行的，直接在 controller 写问题不大的，要 controller 与 service 里面跳来跳去更烦。

@weijancc service 不是必要的，看业务复杂度。1.去掉 service 接口，直接用 service 类 2.大多数接口在 controller 写了，因为逻辑并不复杂，只有遇到逻辑很多的才在 service 写。所以 service 的代码其实很少也很好看。

@hxzhouh1 实际开发中确实是你这样操作的。

我的最佳实践，直接将 feat_2 代码 merge 回 develop

35 岁前，本来最大的限制就不是年龄，而是专业，以及是否是应届。
另外，非应届计算机是有岗位的。

失业一个月，楼主改行做了自媒体

没看出有啥奇耻大辱啊。切换新系统，让旧系统的技术人员和新系统的技术人员对接迁移事宜，有啥问题啊。

信息孤岛应该是着重数据没法共享的问题。
我觉得要是我会偏向打造数据中台、数仓之类的实现各分公司之间的数据互联互通

整个行业都不行了，如果一定要卷，建议卷 java 后端吧，反正你会 java

还是继续写代码吧？看你这段文字不太顺畅

多引入一些自己的私有工具库。

我比较喜欢的方案是做个类似防泄密的软件，上传到云盘的文件都统统加密。类似 cryptomator

要是在企业，你这样做，出问题了，你就准备捡包袱走人吧。
在学校，网管为了安全封闭了 22 ，只允许 443,80 ，就是说只允许 web 开放，你别作死，擅自改 22 端口，出问题可大可小的。

1 万-1.5 万，去外地，你折腾呢！

go 更适合写中间件吧，写业务代码感觉好难受。

如果后端开发就 3,5 个人的话写微服务拆分得太细会很痛苦。对于小公司，从公司角度还是建议一个单体 jar 走天下。
但对于个人发展，当练手吧。