你们公司会有这样的场景吗？

[heheda11]

微服务在大部分以业务为主的小公司就是笑话（个人观点）

1.产品不断的迭代 一个要上线的小版本 没有完整的生命周期 -> 导致 开发同学慢就会压榨了测试同学的时间，版本验收直接无视，只要测试过就行

2.需求文档逻辑没有走通全局 某个地方说这个数据不能复制，但是在上个版本中已经完成了 -> 导致开发效率低下测试同学不明白开发完的功能具体要怎么测试，回归测试为零

3.一个开发同学负责几个模块，但某个模块出现 bug 或者新需求，安排不是负责这个模块开发同学去修改 -> 导致模块内代码风格逻辑混乱,修复的同学还要去了解业务和代码逻辑

4.没有一个较完善 CICD 所有版本上线要手动编译部署 -> 导致常常导错包，注册中心服务混乱

5.需求细节变更和细节说明口头传递，基本要传递 3 次以上 前端 - 后端 - 测试 -> 导致传递中的信息出现不一致

6.没有统一的日志管理，没有监控服务，没有调用链追踪，没有 flywaydb 版本升级数据库修改，没有金丝雀发布流程 -> 导致排错错误难道指数上升，部署时服务不可用

7.权限管理几乎没有，数据库所有获取的都是 root 操作系统也是 root 所有的表都放在一个库中 上百张表 （我知道有些老项目上千张也有，没有外键去死心都有）-> 可能会导致分布式事务的出现，误删表误删文件比比皆是。

8.没有模块技术总结，没有知识分享（好像大部分公司都没有这个习惯) -> 导致 一段段的💩💩代码产生

9.需求不断出现和变更（大部分公司都是存在的，但是综上所诉) -> 导致 数据库表很难横向扩展，导致表查询性能低下

大家会遇到这样的场景吗？

如何解决？ 跑路？

望各位大佬指导！

[MarkLeeyun]

尽快跑路。。这公司技术选型就不合理。

[pigspy]

别说小公司了，你当大公司没有草台班子嘛？

1，服务的设计文档，需求文档没有，测试用例全靠开发自己想和积累，旧的代码没有任何单元测试
2，需求文档描述极其抽象，没有任何细节，测试团队全靠 postman 点点点
3，这个还好，目前全是我维护
4，公司有 ci/cd 流程但领导完全不知道怎么运作，他甚至认为可以直接丢个 snapshot 的包到服务器上执行
5，我就没见过变更设计的时候有文档的，就是早会说两句，有时候前后矛盾
6，你说的没错，全部没有
7，jdbc url 里甚至连接的数据库跟用的数据库不是一个数据库
8，甚至之前的代码是安卓端开发负责维护的
9，数据库的设计就离谱，甚至为了存一个键值就维护了一张表

[Jtyczc]

赶紧更新简历。。。。

[phytry]

都一样的，我以前以为这只是小公司的毛病，最近进了一家上市公司，情况比小公司更恶心，我觉得这个还是看领导对技术团队有多重视，像我现在的公司，运营是老大，能给出好看的流水、能赚钱，老板就开心，至于开发怎么叫都无所谓，毕竟有着上市公司的名头，根本不缺面试的人。

[unco020511]

其实大公司也大差不差

[ZnBDPang]

有一说一，虽然我是低贱的外包仔，但是这些问题 大部分在我们这都没有出现。我们基本上有完整的上线流程，脚本管理，权限管理，一个模块如果一个人负责了后续的维护基本也是他，也有日志、告警监控等，即便日志系统是买的。

[eudore]

感受是业务为主+没有运维的正常现象。

1 一般通过流程去规范的，例如周期发布计划。
4 cicd 我这里都是代码交付，模板部署自动更新。
5 文档管理我见过的一般就 jira 或 zentao 。
6 日志健康是运维的事，链路追踪是开发的事，一般由技术开发经理主导建立的，灰度发布一般没啥用，不如多来几套环境。
7 数据库人人都是 root，公司没有运维吧（第四点第六点也是现象）。
8 没有知识分享才是正常现象，对领导又不能赚钱，可能还有要给分享者补助，毕竟分享需要不少时间做准备。