项目经验毁了,求教怎么挽救

104 天前
 chenhaobuaixuexi

工作产出低、开发认知负担重、流程冗长..



友友们, 怎么办?

5196 次点击
所在节点    职场话题
22 条回复
corcre
104 天前
"今年以来尝试转换思路, 拓展自己的能力, 开始进行文档和项目的质量以及项目进度管理, 尝试以项目经理的角度去看待项目"🐶
repus911
104 天前
"工作量很重",体现出来啊
craftsmanship
104 天前
世另我
rumengzhenxing
104 天前
项目稳定性建设与系统优化​( 2024-2025 )
​稳定性风险治理体系构建​
主导系统风险评估与防控方案设计,覆盖政策合规、经济风险、环境安全三大维度,输出风险评估文档 12+份,制定技术规范 23 项,推动团队事故响应效率提升 40%

建立上线标准化流程​(技术评审模板、PRD 规范、Checklist 机制),通过自动化工具实现 95%的重复文档生成,降低人工操作风险

​遗留系统重构与技术债务化解​
主导 8 年历史核心系统的稳定性专项治理​:梳理百万级异常日志特征,设计过滤算法剔除 70%无效日志(原 1 分钟数万条降至数千条),定位效率提升 3 倍

重构强耦合模块,采用领域驱动设计( DDD )​​ 解耦业务逻辑与技术实现,消除双向依赖 13 处,核心服务 SLA 从 99.2%提升至 99.98%

​全链路监控与效能提升​
搭建日志分级体系​:基于 ELK Stack 实现 ERROR/WARN/INFO 三级实时告警,关键链路埋点覆盖率达 100%,故障定位平均耗时从 6 小时缩短至 30 分钟

推动研发效能工具链落地​:集成静态代码扫描、自动化测试卡点,千行代码缺陷率下降 62%

​价值量化与关键技术​
​技术栈​:ELK 日志分析体系| DDD 领域建模|自动化测试框架|风险矩阵法( Risk Matrix )
​关键成果​:
▶︎ 输出技术文档 27 份​(单份平均 15 页),覆盖风险预案、技术评审、运维 SOP ,成为团队稳定性操作手册
▶︎ 通过渐进式重构减少历史债务,系统年度重大事故数为 0 (上年同期 5 次)
▶︎ 设计日志 Tag 索引体系,有效信息提取效率提升 300%
Rorysky
104 天前
ai 最适合重构了
kneo
104 天前
八年叫老代码?
charlie21
104 天前
写给谁看? 如果写给一个或几个微不足道的人看,那么干脆别写了
chenhaobuaixuexi
104 天前
@charlie21 从上(X3)到下的指标, 稳定建设|指标建设|流程建设, 没啥业务增长就搞这样....
chenhaobuaixuexi
104 天前
@Rorysky 8 个微服务, 依赖关系是网状, 而且领导不给时间重构, 各种奇怪的小需求时间就花光了
chenhaobuaixuexi
104 天前
@repus911 例如上线一次, 需要横向观测 4 个服务的日志, 而且每个服务还有不少的观测维度, 每周的异常告警是百级别的.. 很烦, 还不少降级。感觉本质上就是这个部门接了太多其他部门的遗留代码了
chenhaobuaixuexi
104 天前
@rumengzhenxing 学会了, 感谢哥
chenhaobuaixuexi
104 天前
@kneo 经手人快 50 多个人, 来来去去, 这个项目在部门间被抛来抛去。 代码风格很乱, 遗留债务很多
quantum00549
104 天前
解决实际问题的思路和方案选择,是远比写代码重要的能力
loryyang
104 天前
我就这么说,现在这种屎山系统比比皆是,你但凡这件事情能出点彩,到处是老板要你。
当然,你要说,自己不想搞屎山系统。那我还是那句话,你有本事找到更好的工作就去找,没本事就忍着
stillsilly
104 天前
项目再复杂也不至于半年 200 行吧……
xwayway
104 天前
@stillsilly #15 可能也没啥需要动的地方,大家也不敢去做重构,每次调整就
else if (xxx = yyy) {
aaaService.bbbFunc();
return zzz;
}
nooneanyone
104 天前
什么行业,要这么多文档?
craftsmanship
104 天前
@loryyang 真理
iloveayu
104 天前
这是转经理的好机会( doge )
catamaran
104 天前
一年来,工作主要围绕项目稳定性建设(其实就是写文档说明系统有哪些坑、如何避免)
~~这个是在填坑,从目标看没啥问题
多从事边边角角的工作,实际开发量极少(半年代码合计量不足 200 行) 。单次开发即便代码仅三四行,也需撰写大量文档: 技术评审、PR 评审、上线 check list 等模板化文档,字数众多。
~~从流程上看也没问题,如果单次开发代码很少,说明不值得开发,比如把每周一次迭代改为半年一次迭代,反正都是走一次流程
项目设计复杂,上线观测耗时久,且系统遗留问题多、债务重,异常日志海量..(一分钟几万条异常日志),需过滤大量历史遗留字段才能查看有效信息
~~正好提需求做一个日志分析系统,一秒钟可以过滤几万条日志
逻辑混乱,导致开发工作压力大、负担重,很烦.... // 8 年老代码了, 改不动; 工作量很重, 也没时间改
~~是把 AI 提上日程的阶段了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1143469

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX