V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  wangYQ  ›  全部回复第 1 页 / 共 2 页
回复总数  30
1  2  
@XiaoJiang9527 不能抱有敌意,根据对技术喜好看问题。如果你换成 mybatis 也会面临其他的问题,也没有办法保证百分百没有其他的问题。在有限的空间内做最大程度的优化就好,即使就是搞不定了,需要重构,也是需要多人讨论,评审后,再下结论,做选型,做改造。说句不好听的话,接手了屎山,改造就好比屎山雕花,有时候盲目的重构,弄完发现不过是在屎山旁边又拉了一坨。
@XiaoJiang9527 但是这样的成本有点大,
1.老项目,其中业务饱经沧桑,如果有很熟悉业务的完全可以重新改,如果不存在业务完全了解的人,还是不要贸然干,不知道有什么特殊业务的坑藏在细小的地方。
2.SQL 单独执行很快,只是关联查询慢,看能不能把需要的数据通过数据库层面视图,冗余字段,减少一个接口调用太多的 SQL ,减少开销。
3.如果项目后期有更换数据库的需求,Hibernate ,JPA 这种还算是比较方便,换个方言能解决一大部分的事情,要是都是原生 SQL 用了一些特殊函数,改数据库的话工作量特别大
我这很多 40 多的开发,而且还有做售前咨询的
入职之后私下约顿饭可好?没去就送被看见反而不好
147 天前
回复了 fuxinbbit 创建的主题 云计算 大佬们,帮我看个问题
发行版 或者 cpu 方向想想呢;毕竟你们的测试环境都是通用环境
买了霸王
@shinelamla 重构就是比较麻烦,我的想法是首先要看:
1.需要不要做服务,不需要不做,没那么大量不做。
2.把涉及到的业务完全梳理出来,形成文档,多方确认保证业务没有问题。
3.再确定能不能从全局的视角看一下这个模块的东西能做什么样的设计,能从全局视角看问题和只从这个模块的业务出发得到的设计是两个东西。
4.从影响程度比较轻的地方入手,尽量将重构的影响降到最低。
5.重构的东西的测试要更加严格。
能跑着就不要重构,除非必要。除非性能,功能实在没法满足得重构再说,要不然,看屎山代码确实脑袋疼,有得还没有文档传承,有得人都走了,问都没处问
@SuperXRay 你去知乎 搜一下 「我来 wolai 」是可以用了一辈子不用换的笔记软件吗?
就那个老板手撕用户的状态就不想用了
232 天前
回复了 hahaFck 创建的主题 程序员 2023 年了,大家在用 jdk 的哪个版本?
17~
我这做框架的人不喜欢,但是我需要其中一部分功能,我让他去实现,但是现实的不符合需求,最后也得让我引入,但是引也不能全引入,用哪个模块引哪个。
259 天前
回复了 JasonLaw 创建的主题 程序员 Java - 如果根据参数类型调用不同的方法?
可以用个策略模式,用标识不同类型实现不同的策略就可以
数据库其实可以搞 pg 改的,人大金仓,海量,openGuass 还能好用点。但是人大金仓自己那个 SQL 工具是真的难用
284 天前
回复了 vincent7245 创建的主题 程序员 一些疑惑,为什么 rust 干不过 go 呢
rust 上手的难度不小,需要系统的学习,并且写起来艺术感觉很强,但是想流行 需要推广啊。go 的推广多强
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3166 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 34ms · UTC 12:26 · PVG 20:26 · LAX 05:26 · JFK 08:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.