yiheweigui 最近的时间轴更新 yiheweigui 最近的时间轴更新 | yiheweiguiV2EX 第 472127 号会员，加入于 2020-02-25 11:42:41 +08:00 |
yiheweigui 最近回复了
347 天前 回复了 lswang 创建的主题 程序员 内网穿透工具(替代 ngrok 和花生壳) |
@m1862897 zhe
2022-08-19 14:53:26 +08:00 回复了 Diod 创建的主题 程序员 坐标深圳找 Java 开发都那么难的吗 |
就是写点你的面试官不会做，但是他知道非常厉害的东西。
2022-08-19 14:49:29 +08:00 回复了 Diod 创建的主题 程序员 坐标深圳找 Java 开发都那么难的吗 |
这简历写的太差了，重新写。
写的什么玩意，一点闪光点都没有，骗骗外行 hr 就行了，技术 leader 一看这简历弱爆了。
通篇都在点题，除了 crud ，啥也不会，只是 crud 花样多。加上学历不高，这也是在深圳，换了其他地方，面试机会都很难得到。
写的什么玩意，一点闪光点都没有，骗骗外行 hr 就行了，技术 leader 一看这简历弱爆了。
通篇都在点题，除了 crud ，啥也不会，只是 crud 花样多。加上学历不高，这也是在深圳，换了其他地方，面试机会都很难得到。
2021-12-08 11:28:44 +08:00 回复了 woduzibue 创建的主题 程序员 spring cloud 服务调用 问题排查 解决方法求教 |
cloud 只会发一个请求，既然发了两个，就是调了两次。
要么就是 a 调了 b 两次，要么就是熔断限流什么的，在补偿的时候多调了一次，估计是用法不当，正常使用也走补偿。
至于你遇到这种问题就想通过幂等性来解决，要看这个业务是不是适合幂等。
至于加锁，就别玩了，动不动就锁，高并发的情况下，人家秒杀的需求就是要并发修改同一行。
搞个分布式，又经常加锁，分布式的意义就是专门花大力气搞得很复杂，只是为了解耦分包开发？什么集群是加倍性能还是减弱性能？
要么就是 a 调了 b 两次，要么就是熔断限流什么的，在补偿的时候多调了一次，估计是用法不当，正常使用也走补偿。
至于你遇到这种问题就想通过幂等性来解决，要看这个业务是不是适合幂等。
至于加锁，就别玩了，动不动就锁，高并发的情况下，人家秒杀的需求就是要并发修改同一行。
搞个分布式，又经常加锁，分布式的意义就是专门花大力气搞得很复杂，只是为了解耦分包开发？什么集群是加倍性能还是减弱性能？
2021-12-06 16:41:53 +08:00 回复了 yuhangch 创建的主题 程序员 controller/service 的负责界限问题 |
自己给自己做的项目：
无 service ，无 dao ，只有 controller 和 util
controller 的 action 访问一切，mybatic 的 mapper 直接放 controller 上或在 controller 手写 sql 。c 井就直接 dapper 放 controller 上访问任意，加入 redis 什么乱七八糟的各种库都在 util 或 controller 的注入上。
如若发现复用的获取数据或其他逻辑，则只把复用的提出来封装 service 或者 bll ，所以这一层顶多是复用的，如果不复用坚决没有这个，就是一个方法在很多地方都在用。
目的：看代码的人打开一个文件，查看一个方法，就能看出到底是在做什么，改动的时候非常方便。
如果一个方法很长，使用代码折叠 region 和详细注释。
如果抽象类确实有多个实现子类，才使用继承，而且一旦使用抽象类，必有多肽，绝对有多个不同子类逻辑会调用。
否则类就是类，基本不用 interface 。
异常统一处理。
给公司做的项目
dao ，service ，controller ，util ，bean ，各种加。
一个方法代码不超过 200 行，各种封装函数。
多使用 interface 和 impl ，管球他基本上只有一个子类。
dao ，service ，bean 什么的，每一层 interface ，impl 起码两个文件。
加的越多越复杂，越提现分层思想，越增加代码行数，文件数量也大，越在 jira ，禅道，tpad 这种东西上可以写工作量。
绝不做统一异常处理，controller 每个都 try catch ，耦合度越大越好。
如若 util 层增加一个接口方法，或者接口方法增加参数，连着 dao ，service ，controller ，bean 等到处修改。
这样在 git 提交的时候，发现改动文件多，在 jira 上工作量就写得漂亮。
关键是，整天开会，开完就这么写，速度也不快，让别人感觉自己非常忙，别人拿代码一看，确实封装方法多，绕来绕去，看一个功能起码打开五六个文件。
以前自己不喜欢这么做，但是公司的规范，企业文化把人逼成这样。
目前被他们搞疯了，已经去精神病院治疗抑郁症。
无 service ，无 dao ，只有 controller 和 util
controller 的 action 访问一切，mybatic 的 mapper 直接放 controller 上或在 controller 手写 sql 。c 井就直接 dapper 放 controller 上访问任意，加入 redis 什么乱七八糟的各种库都在 util 或 controller 的注入上。
如若发现复用的获取数据或其他逻辑，则只把复用的提出来封装 service 或者 bll ，所以这一层顶多是复用的，如果不复用坚决没有这个，就是一个方法在很多地方都在用。
目的：看代码的人打开一个文件，查看一个方法，就能看出到底是在做什么，改动的时候非常方便。
如果一个方法很长，使用代码折叠 region 和详细注释。
如果抽象类确实有多个实现子类，才使用继承，而且一旦使用抽象类，必有多肽，绝对有多个不同子类逻辑会调用。
否则类就是类，基本不用 interface 。
异常统一处理。
给公司做的项目
dao ，service ，controller ，util ，bean ，各种加。
一个方法代码不超过 200 行，各种封装函数。
多使用 interface 和 impl ，管球他基本上只有一个子类。
dao ，service ，bean 什么的，每一层 interface ，impl 起码两个文件。
加的越多越复杂，越提现分层思想，越增加代码行数，文件数量也大，越在 jira ，禅道，tpad 这种东西上可以写工作量。
绝不做统一异常处理，controller 每个都 try catch ，耦合度越大越好。
如若 util 层增加一个接口方法，或者接口方法增加参数，连着 dao ，service ，controller ，bean 等到处修改。
这样在 git 提交的时候，发现改动文件多，在 jira 上工作量就写得漂亮。
关键是，整天开会，开完就这么写，速度也不快，让别人感觉自己非常忙，别人拿代码一看，确实封装方法多，绕来绕去，看一个功能起码打开五六个文件。
以前自己不喜欢这么做，但是公司的规范，企业文化把人逼成这样。
目前被他们搞疯了，已经去精神病院治疗抑郁症。
Select Language