获得徽章 9
国内三大 AI IDE 里，就只有百度的 comate 在安装时，支持设置 使用 intellij 的快捷键，且启动后，直接使用，点个赞。
评论
1
日常做需求时，代码这块，百分之 80 已经是由 帮忙写的了，当然目前 ai 还无法一下子把所有代码生成出来，但是你可以通过提问的方式，让它一点一点帮忙写和完善。
我用的是通义，还是不错的。最近大老板说我还可以再招一个后端开发，我直接拒绝掉了，一个是我想控制成本，另外一个呢，有了 ai 后，效率提高了蛮多的，不需要加人。
我用的是通义，还是不错的。最近大老板说我还可以再招一个后端开发，我直接拒绝掉了，一个是我想控制成本，另外一个呢，有了 ai 后，效率提高了蛮多的，不需要加人。
展开
5
点赞
日常工作中，你会发现团队里一些刚毕业没几年的开发，写代码的水平已经相当不错了。既能保证代码稳定性，还能考虑代码清晰度，又能考虑代码的扩展性。
对于这样的年轻开发人员，我总喜欢用【潜力股】三个字来形容。为啥呢?因为年纪轻轻，就懂得写【结构化】的代码，他会注重代码的设计，颇有些：
【代码出自我手，就不会差】
对于这样的年轻开发人员，我总喜欢用【潜力股】三个字来形容。为啥呢?因为年纪轻轻，就懂得写【结构化】的代码，他会注重代码的设计，颇有些：
【代码出自我手，就不会差】
展开
4
1
如果25年，要推荐一个技术专栏的话，那我会推荐《郭东白的架构课》，这个课程读完后，真是让人思路大开，如果是想真正了解一个【大架构师】应该是什么样子的，需要具备哪些核心能力，那一定读一下这个专栏。
我对这个专栏的评价是：它是极客时间里最好的技术专栏。
我对这个专栏的评价是：它是极客时间里最好的技术专栏。
2
4
早读：
一个操盘过多个跨国大项目的架构老司机说，他有多个架构信条，其中一个是：
在不了解所有细节时，不要做抽象。
我觉得这是一个务实的架构师，不深入一线的去了解所有细节的情况下做的抽象，只会让系统更加的复杂和难维护。
更倾向于先保证代码稳定和清晰，然后后面再去做【阶段性的重构】，让代码有合理的扩展性和抽象。
一个操盘过多个跨国大项目的架构老司机说，他有多个架构信条，其中一个是：
在不了解所有细节时，不要做抽象。
我觉得这是一个务实的架构师，不深入一线的去了解所有细节的情况下做的抽象，只会让系统更加的复杂和难维护。
更倾向于先保证代码稳定和清晰，然后后面再去做【阶段性的重构】，让代码有合理的扩展性和抽象。
展开
评论
3
有了AI后，阅读文章的效率提高了好多，有时候想偷个懒，不确定某篇技术文章，【是否值得读】，那就扔给AI，提取关键内容，它会用大纲或者脑图展现，同时基于这篇文章，向AI提问。
评论
点赞
用一整大块时间来阅读这种方式，已经完全不合适我了。
用零碎的时间阅读是更合适的方式，高效专注又不累，最关键的是，能认真的读下去。
尤其是哪些一下子消化不了的知识，用零碎时间读，效果更佳。
用零碎的时间阅读是更合适的方式，高效专注又不累，最关键的是，能认真的读下去。
尤其是哪些一下子消化不了的知识，用零碎时间读，效果更佳。
评论
点赞
大家平时工作时，可以多利用一下一些文本软件的【宏】的功能，通过录制【宏】可以极大的提高操作效率。
比如说，我们经常要查询数据库，会使用sql钟的in语法，()里会放入一堆按照逗号分隔的订单号。这个时候，你可以利用像notapad++等文本软件，录制一个宏，然后配置好快捷键，一按下快捷键，多行的订单号就会合并成一行，并且以逗号分隔开。比如说订单号原本是多行的：
D0000000001
D00000000002
一按下快捷键后，瞬间就变成了：
'D0000000001','D00000000002'
虽然是一些小技巧，但是对于后端开发来说，由于经常要使用，无形中也提升了不少的操作效率。
比如说，我们经常要查询数据库，会使用sql钟的in语法，()里会放入一堆按照逗号分隔的订单号。这个时候，你可以利用像notapad++等文本软件，录制一个宏，然后配置好快捷键，一按下快捷键，多行的订单号就会合并成一行，并且以逗号分隔开。比如说订单号原本是多行的：
D0000000001
D00000000002
一按下快捷键后，瞬间就变成了：
'D0000000001','D00000000002'
虽然是一些小技巧，但是对于后端开发来说，由于经常要使用，无形中也提升了不少的操作效率。
展开
3
2
【领域服务要起名为xxxDomainService】吗?
我目前个人的想法是，推荐使用xxxDomainService这种方式。有如下几个原因:
【1】一看名字就知道领域逻辑会封装在里面或者说它是入口。有些人喜欢直接把领域服务起名为类似xxxHandler，xxxxBuilder等，这种就不太好立刻识别到，它们是某个聚合的领域服务，感觉太分散了。当然这里并不是说所有的领域逻辑就一定得全部写在xxxDomainService里，这样会导致它太庞大了。当业务逻辑开始复杂后，你可以在领域层里写一些辅助类，帮忙分摊一些领域逻辑，比如xxxHelper,xxxHandler。共同完成领域逻辑，但是对外的话，就是一个xxxDomainService。
【2】，随着业务需求的不断变化，在应用层跨聚合的操作会越来越多。比如聚合A的应用层去调用聚合B的相关接口。如果聚合B的领域服务不是叫xxxxDomainService，你就得去问同事或者看代码才知道哪些领域服务类的接口是你能调用的。
我目前个人的想法是，推荐使用xxxDomainService这种方式。有如下几个原因:
【1】一看名字就知道领域逻辑会封装在里面或者说它是入口。有些人喜欢直接把领域服务起名为类似xxxHandler，xxxxBuilder等，这种就不太好立刻识别到，它们是某个聚合的领域服务，感觉太分散了。当然这里并不是说所有的领域逻辑就一定得全部写在xxxDomainService里，这样会导致它太庞大了。当业务逻辑开始复杂后，你可以在领域层里写一些辅助类，帮忙分摊一些领域逻辑，比如xxxHelper,xxxHandler。共同完成领域逻辑，但是对外的话，就是一个xxxDomainService。
【2】，随着业务需求的不断变化，在应用层跨聚合的操作会越来越多。比如聚合A的应用层去调用聚合B的相关接口。如果聚合B的领域服务不是叫xxxxDomainService，你就得去问同事或者看代码才知道哪些领域服务类的接口是你能调用的。
展开
6
1
在我自己的开发团队里，我是这么定义垃圾代码的:
【第一，写的代码不在同一种抽象层次里。】
这句话是什么意思呢?比如说，你在DDD的应用层里的某个方法里，比如是下单接口。你做了前端入参的参数校验，这是不行的，这个应该是controller应该做的事情，再比如，你在应用层里，写一些复杂的计算，这些原本应该是领域服务里要做的。
DDD中的应用层是调度和协调的，不应该放以上那些逻辑，这会让人阅读代码的人，觉得你在乱写，很随意的乱写。
【第二，一个方法里代码写的太长了。】
别人阅读你代码的时候，其实不想立刻陷入到细节里的，他是想先知道大概的业务流程，觉得有必要的才深入去看。你一下子就把一坨代码扔出去给别人看，也是不对的。阅读代码的人想看到的是类似下面的结构：
input();
process();
output();
封装成小方法，并体现业务流程，同时确保看起来在同一个抽象层次里。
【第三，只满足刚好能用能跑就以为ok了。】
这个是非常致命的，代码写的又长又乱，还美其名曰，功能没问题呀。那我只能说，你是个没任何技术追求和随意的人，那基本上也就跟成长绝缘了。
你这么做，会让同组的人看不起的，觉得你一点都不专业，写的代码除了维护性差，浪费资源外，没任何好处。基本每写一个功能，都后面维护的人来说，都是灾难。
在周围都是高手的团队里，你是很容易被淘汰的。
【第一，写的代码不在同一种抽象层次里。】
这句话是什么意思呢?比如说，你在DDD的应用层里的某个方法里，比如是下单接口。你做了前端入参的参数校验，这是不行的，这个应该是controller应该做的事情，再比如，你在应用层里，写一些复杂的计算，这些原本应该是领域服务里要做的。
DDD中的应用层是调度和协调的，不应该放以上那些逻辑，这会让人阅读代码的人，觉得你在乱写，很随意的乱写。
【第二，一个方法里代码写的太长了。】
别人阅读你代码的时候，其实不想立刻陷入到细节里的，他是想先知道大概的业务流程，觉得有必要的才深入去看。你一下子就把一坨代码扔出去给别人看，也是不对的。阅读代码的人想看到的是类似下面的结构：
input();
process();
output();
封装成小方法，并体现业务流程，同时确保看起来在同一个抽象层次里。
【第三，只满足刚好能用能跑就以为ok了。】
这个是非常致命的，代码写的又长又乱，还美其名曰，功能没问题呀。那我只能说，你是个没任何技术追求和随意的人，那基本上也就跟成长绝缘了。
你这么做，会让同组的人看不起的，觉得你一点都不专业，写的代码除了维护性差，浪费资源外，没任何好处。基本每写一个功能，都后面维护的人来说，都是灾难。
在周围都是高手的团队里，你是很容易被淘汰的。
展开
32
12
如果你做过的需求多了，慢慢就会一种意识。需求里总有一些稳定的部分，比较少改。对于稳定的部分，在代码实现这块，就需要下沉，并保护起来。
而对于经常变化的部分，你要么用配置的方式，要么在代码设计时，通过一些合理的代码组织(比如用一点设计模式)等，让它易改易扩展。
一点小心得哈。
而对于经常变化的部分，你要么用配置的方式，要么在代码设计时，通过一些合理的代码组织(比如用一点设计模式)等，让它易改易扩展。
一点小心得哈。
展开
评论
1
【如果你网络上找关于DDD的文章，里面总会提到，领域服务不是必须的。】
这个我是持否定观点的，我觉得领域服务是必须的。虽然你的聚合根（实体的一种）写了很多业务逻辑，但是你总得暴露出接口给应用层去调用，这个时候就需要使用领域服务，封装好后暴露出去的。
直接让应用层去调用聚合根的方法，团队的人超级不习惯的，总觉得非常怪。且他们也认为破坏了分层。
目前团队的所有使用DDD的项目，都是有领域服务的。
这个我是持否定观点的，我觉得领域服务是必须的。虽然你的聚合根（实体的一种）写了很多业务逻辑，但是你总得暴露出接口给应用层去调用，这个时候就需要使用领域服务，封装好后暴露出去的。
直接让应用层去调用聚合根的方法，团队的人超级不习惯的，总觉得非常怪。且他们也认为破坏了分层。
目前团队的所有使用DDD的项目，都是有领域服务的。
展开
评论
点赞
在DDD中，千万不要认为领域模型最重要，其实应该是（应用层+领域层），在日常使用DDD开发时，你会发现，业务流程基本体现在应用层，也即是说，核心业务流程，由领域层和应用层共同完成。
应用层它是负责协同和编排的，调用仓储层存储数据库，调用其他聚合根或者内部RPC接口/外部接口，都是它干的。
在六边形架构或者洋葱架构中，需要把领域层和应用层，圈在一起的。
应用层它是负责协同和编排的，调用仓储层存储数据库，调用其他聚合根或者内部RPC接口/外部接口，都是它干的。
在六边形架构或者洋葱架构中，需要把领域层和应用层，圈在一起的。
展开
9
2