这是一个创建于 1770 天前的主题，其中的信息可能已经有所发展或是发生改变。
微服务在大部分以业务为主的小公司就是笑话（个人观点）
1.产品不断的迭代 一个要上线的小版本 没有完整的生命周期 -> 导致 开发同学慢就会压榨了测试同学的时间，版本验收直接无视，只要测试过就行
2.需求文档逻辑没有走通全局 某个地方说这个数据不能复制，但是在上个版本中已经完成了 -> 导致开发效率低下测试同学不明白开发完的功能具体要怎么测试，回归测试为零
3.一个开发同学负责几个模块，但某个模块出现 bug 或者新需求，安排不是负责这个模块开发同学去修改 -> 导致模块内代码风格逻辑混乱,修复的同学还要去了解业务和代码逻辑
4.没有一个较完善 CICD 所有版本上线要手动编译部署 -> 导致常常导错包，注册中心服务混乱
5.需求细节变更和细节说明口头传递，基本要传递 3 次以上 前端 - 后端 - 测试 -> 导致传递中的信息出现不一致
6.没有统一的日志管理，没有监控服务，没有调用链追踪，没有 flywaydb 版本升级数据库修改，没有金丝雀发布流程 -> 导致排错错误难道指数上升，部署时服务不可用
7.权限管理几乎没有，数据库所有获取的都是 root 操作系统也是 root 所有的表都放在一个库中 上百张表 （我知道有些老项目上千张也有，没有外键去死心都有）-> 可能会导致分布式事务的出现，误删表误删文件比比皆是。
8.没有模块技术总结，没有知识分享（好像大部分公司都没有这个习惯) -> 导致 一段段的代码产生
9.需求不断出现和变更（大部分公司都是存在的，但是综上所诉) -> 导致 数据库表很难横向扩展，导致表查询性能低下
大家会遇到这样的场景吗？
如何解决？ 跑路？
望各位大佬指导！
 | 1 MarkLeeyun 2021 年 6 月 19 日  1 尽快跑路。。这公司技术选型就不合理。 |
 | 2 pigspy 2021 年 6 月 19 日 1 别说小公司了，你当大公司没有草台班子嘛？ 1，服务的设计文档，需求文档没有，测试用例全靠开发自己想和积累，旧的代码没有任何单元测试 2，需求文档描述极其抽象，没有任何细节，测试团队全靠 postman 点点点 3，这个还好，目前全是我维护 4，公司有 ci/cd 流程但领导完全不知道怎么运作，他甚至认为可以直接丢个 snapshot 的包到服务器上执行 5，我就没见过变更设计的时候有文档的，就是早会说两句，有时候前后矛盾 6，你说的没错，全部没有 7，jdbc url 里甚至连接的数据库跟用的数据库不是一个数据库 8，甚至之前的代码是安卓端开发负责维护的 9，数据库的设计就离谱，甚至为了存一个键值就维护了一张表 |
 | 3 Jtyczc 2021 年 6 月 19 日 1 赶紧更新简历。。。。 |
 | 4 phytry 2021 年 6 月 21 日 1 都一样的，我以前以为这只是小公司的毛病，最近进了一家上市公司，情况比小公司更恶心，我觉得这个还是看领导对技术团队有多重视，像我现在的公司，运营是老大，能给出好看的流水、能赚钱，老板就开心，至于开发怎么叫都无所谓，毕竟有着上市公司的名头，根本不缺面试的人。 |
 | 5 unco020511 2021 年 6 月 21 日 1 其实大公司也大差不差 |
 | 6 ZnBDPang 2021 年 6 月 21 日 有一说一，虽然我是低贱的外包仔，但是这些问题 大部分在我们这都没有出现。我们基本上有完整的上线流程，脚本管理，权限管理，一个模块如果一个人负责了后续的维护基本也是他，也有日志、告警监控等，即便日志系统是买的。 |
 | 7 eudore 2021 年 6 月 22 日 感受是业务为主+没有运维的正常现象。 1 一般通过流程去规范的，例如周期发布计划。 4 cicd 我这里都是代码交付，模板部署自动更新。 5 文档管理我见过的一般就 jira 或 zentao 。 6 日志健康是运维的事，链路追踪是开发的事，一般由技术开发经理主导建立的，灰度发布一般没啥用，不如多来几套环境。 7 数据库人人都是 root，公司没有运维吧（第四点第六点也是现象）。 8 没有知识分享才是正常现象，对领导又不能赚钱，可能还有要给分享者补助，毕竟分享需要不少时间做准备。 |
Select Language