qwe520liao 最近的时间轴更新
qwe520liao

qwe520liao

V2EX 第 449603 号会员,加入于 2019-10-28 16:09:52 +08:00
今日活跃度排名 3695
qwe520liao 最近回复了
10 天前
回复了 Apple2023 创建的主题 iPhone Airpods 2 是否是目前最实惠的蓝牙耳机?
夏新 F9 ,6.2 元包邮,2000 毫安电仓,耳机电量连续使用 5 小时。
19 天前
回复了 kldd529 创建的主题 生活 各位 dalao 平时都有哪些养生习惯
@MIND222 巧了,今天刚看到一个帖子还是在讲这个的,不过我也不确定正不正确,https://bbs.hupu.com/53369394.html
19 天前
回复了 kldd529 创建的主题 生活 各位 dalao 平时都有哪些养生习惯
每天撸一管算不算是一种运动呢,排泄一下应该还是挺有用处的,雄性激素过旺导致我头发溢脂性脱发了,发际线快要变成 M 形状了。
20 天前
回复了 EarthChild 创建的主题 问与答 你们的东西坏了是选择修还是换?
我之前买了一个背包,结果用了一个月之后拉链坏掉了,觉得扔掉之后很可惜,然后我在网上买了十几米的拉链(几块钱包邮),自己一针一线的给换了,除了边角不好缝,其他的还好。花了 3 天时间缝完了,现在使用良好。
事务是基于链接的,也就是说一旦你开启了一个事务,并且希望接下来的调用使用同一个事务,那么就必须使用同一个链接,就必须要把这个链接保存到一个地方,让所有使用数据库的方法都能够以一种相同的方式获取一个链接。

在 Java 中可以使用 ThreadLocal 来保存线程安全的变量,在当前线程的执行过程中,获取到同一个链接实例。如果是异步的,那就必须要考虑到链接的创建与提交,也就是要明确在什么时候开始,什么时候结束,Spring 的注解实现基于 AOP 的拦截,在“同步方法”调用之前开启事务,调用之后结束事务,它在背后实现了我上面第一段说的那些内容。

所以在没有 ThreadLocal 可以使用的时候,你必须要将一个链接进行传递,比如将链接封装到一个 Context 结构中,设计出一套接口标准,让所有使用数据库的代码都遵循这一套接口。不仅如此,还需要考虑到“同步”与“异步”的使用同一个链接将会带来怎样的影响,因为协程本质上也是在一个线程上运行,当多个协程同时运行在不同的线程时,就需要考虑到并发问题,因此不太建议“异步”使用一个事务。我对 Go 不太熟悉,但是背后的逻辑应该是以上这些内容。
看情况

如果大多数情况令牌都足够充裕,第二种实际上是更好的做法,因为直接写了,相比第一种,少了一个读的操作。
如果大多数情况下令牌不够充裕,那么第二种相比第一种多了一个写的操作。

但是很显然,我们大概率无法提前得知哪种情况才是相对常见的,我个人的话会选择第一种。
29 天前
回复了 lotusp 创建的主题 程序员 分层架构,经典却很难做好
你有没有想过,有时候可能并不是单纯的技术原因所导致的,而是一次又一次变形的需求?层层加码,而又没有时间回过头来梳理和重构,必定会导致这些问题。
42 天前
回复了 Envov 创建的主题 问与答 最近失眠比较严重,每天 45 点才能入睡
吃褪黑素+1 ,不过第二天起床感觉有点怪怪的,就感觉大脑空白
50 天前
回复了 frank1256 创建的主题 程序员 DDD 到底啥,有啥用
如果我们的眼光只局限在技术层面,那么 DDD 对你而言有用的就是战术模式那一部分,也就是编码的那一部分。如果我们把眼光放高一些,着手解决整个产品研发生命周期的效率方面,或者 DDD 就能帮大忙。这不仅仅使我们工作更加轻松,更加快乐,也使得我们不会把时间浪费在一些经常反复出现并且很愚蠢的事情上面。当然这个愿望很美好,但是不一定每个人都想做得这么美好。
50 天前
回复了 frank1256 创建的主题 程序员 DDD 到底啥,有啥用
总的来说,DDD 分为两个部分,一个是技术实践的战术模式,一个是工程架构的战略模式。

其中,战术模式仅作为实现的部分参考,总结的是以面向对象范式编程语言的一些常用技巧与原则,提炼出了一些可以跟非技术人员沟通的构建单元,也就是你可以跟产品直接聊的一些东西,比如实体、值对象、仓库等等。

其实最重要的是战略模式,这部分也是大多数接触 DDD 的人觉得云雾缭绕的东西,看不见摸不着。团队规模小了,搞这些觉得繁琐,团队规模大了,面对已经成熟的 CRUD 基本上都有一套成熟的流程方案了。所以这个东西真正有价值的还是回归本质,解决软件核心中的复杂性。

首先你得是一个团队,否则的话一个人还搞什么 DDD 对吧?其次对团队里面的人也要有一定的要求,起码在沟通上,要明确价值。也就是说哪些信息对于不同岗位的人来说是明确的,是可以沟通的和达成共识的,哪些信息对开发或者产品来说就是废话,要把能够体现出真正用意的这部分提炼出来,在整个团队中进行传播和理解。

其次,有了高效的沟通和统一的理解以后,才能对同一个事物进行拓展(研发),需要在前者的基础之上,搭建一套能够迅速有效解决问题的工作流程,对产品进行高效的迭代。DDD 的战略部分就是基于前者,然后再结合一些准则和经验,帮助你如何解决更大规模的软件工程问题。

以上这些当然都是很美好的初衷,但是我个人认为,关键变量不在于每次迭代能否更进一步,而在于对人的管理,什么意思呢?人的不确定性才是最大的不确定性,人这个变量的影响范围如果能够控制住,培训也好,工作范围的划分也好,只要能够达到一种“柔性”的状态,终归会回归正轨。

说得有点多了,尽信书,不如无书,要有自己的思考。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3273 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 05:10 · PVG 13:10 · LAX 22:10 · JFK 01:10
Developed with CodeLauncher
♥ Do have faith in what you're doing.