2720QM(可以购买)+2520DR(不推荐购买)+小米 34 曲面(不推荐)+iMac 27(不推荐)

我手头没有 Mac, 不过建议你去这个插件的 GiHub 仓库浏览器一圈. 还有写代码使用背景图片不会严重干扰注意力吗? 表示疑惑!

一般, 有些坑, 除非你的后端业务非常大而且复杂, 协作人员多, 否则自己从头到尾搭建反而简单一些. 不过这种 Admin Template 对没啥要求的后端业务系统, 也没啥坏处!

换主题, 但是每个主题也有一个自己的高亮颜色, 为了可访问性, 必须要一个高亮颜色!

@gowk 我啥都做, 什么技术合适用什么, Android/iOS//Java/Python DL/ 微信小程序, 看公司的需求, 什么乱七八糟都要学一点. 不过终究还是在.NET 技术栈花的时间最近. 我在做的属于传统行业, 业务逻辑复杂, 但并发有限, 项目需要常年维护, 我现在做的项目已经开发了快 15 年了, NET 还是有很多存量应用, 主要是 Core 出来后, 原来想要转型的项目现在也没有动力了.

@frank1256 凡事都有代价, 没有银弹, 学习一门技术, 重要的是理解它解决了什么问题, 带来了什么问题, 这样才能在项目中合理使用, DDD 适合业务特别复杂, 模型众多, 模型行为丰富, 重行为而非重数据的项目. 很多互联网公司的业务一点也不复杂, 只是规模庞大罢了, 那些项目用 DDD 可能没啥好处, 反而为了追求极致的性能, 使用事务脚本, 甚至裸写 SQL 这样反而更加合适.

@frank1256 DDD 的好处是通用语言可以保持业务一致性(这个就是第一道门槛, 越复杂的项目中, 很多术语大家没有天然形成共识, 是需要需求方, 业务专家, 开发者多方探讨, 最终达到一致性的: 说人话就是对同一个概念大家表述的是同一个东西, 这一点小项目看不出来啥优点, 但项目越复杂, 概念就会越不清晰). 子域(领域上下文)会强迫你思考如何将不相关的业务的实体分离到不同上下文, 这样你就没办法使用强一致性的方式直接操作这个对象, 而是必须去思考如何平衡 CAP. 另外他也会让你逐步学会思考使用关系模型(E-R)构建的面向对象模型是否合理, 如果你一开始就是使用的 MongoDB 这种数据库, 你就会更加深入理解对象的相互引用关系(引用即依赖, 依赖是重度耦合, 会带来很多问题). 这个话题太大, 不是几句话就可以说的清楚的....

@frank1256 可以多多交流, 我现在按照 DDD 这套写了也快 5 年了, 蒙蔽的地方还是很多, 但目前刚好能 HOLD 住现在的项目的复杂度. 如果你的项目不是长期维护, 使用 DDD 写是不值得的.

回到面向对象最初的初衷, 而不是将面向对象写成流程处理模式的事务脚本.
如果你的业务 CURD 能 hold 住用 CURD 的事务脚本模式也没啥问题!
DDD 需要较高的成本, 而且再没有任何基础设施的情况下, 很容易写偏.
不过它的战略模式还是很有用的, 对大部分项目都有一定的参考价值.
我们使用 DDD 写过几个项目了, 框架使用的是 ABP, 团队也在自己重现构建内部 DDD 框架.
主要是团队的人都习惯了强事务一致性的事务脚本, 将多个模型的操作糅合到一个 Service, 导致 Service 变成了大杂烩, 越来越难以维护, 最终不得不研究使用 DDD 做切分, 后来又不得不上 CQRS, 前期阻力比较大, 现在再稳定维护期后, 大家就很爽, 添加功能也变得比原来容易多了.

如果有大量的字典类型的需要处理的, 可以使用 easydict, 最好还是将数据清洗一下, 这样效率高一点
import json
from easydict import EasyDict;

genre_movie = '{"genres":[{"id":28,"name":"动作"},{"id":12,"name":"冒险"},{"id":16,"name":"动画"},{"id":35,"name":"喜剧"},{"id":80,"name":"犯罪"},{"id":99,"name":"纪录"},{"id":18,"name":"剧情"},{"id":10751,"name":"家庭"},{"id":14,"name":"奇幻"},{"id":36,"name":"历史"},{"id":27,"name":"恐怖"},{"id":10402,"name":"音乐"},{"id":9648,"name":"悬疑"},{"id":10749,"name":"爱情"},{"id":878,"name":"科幻"},{"id":10770,"name":"电视电影"},{"id":53,"name":"惊悚"},{"id":10752,"name":"战争"},{"id":37,"name":"西部"}]}'

movies=EasyDict(json.loads(genre_movie)).genres
genre_ids = [80, 9648, 53]
genre_names = [movie.name for movie in movies if movie.id in genre_ids]
print(genre_names)

机器学习本质上就是拟合分布, 你需要保证你需要预测的数据符合分布. 因此机器学习只能预测共性, 没法预测它没学到的未知的东西, 而测量恰好就是未知数据! 我之前也研究过给雷达点云按照历史数据预测不存在的点来尝试补齐物体的轮廓, 后面发现效果不好, 没啥用, 纯粹属于浪费时间和算力!

@ray5173 你要补上的目的是什么干什么? 机器学习又不是什么魔法, 这种拟合出来的数据没啥用

你最好将数据先全部先备份,数据库以页为存储, 索引和页数据都在页上, 我怀疑物理某些页在磁盘扇区上物理损坏了.

@theklf4 做旁路有太浪费了, 有啥大的毛病没有?

@theklf4 什么配置, 出不?

@FrankHB 他去看源代码, 当然任何实现细节都会被发现!

另外你说的 Spring 的抽象设计在它的体系中是没啥问题的! 官方团队即便重构大差不大还是这个样子, 除非需求发生了重大变化, 软件设计就是尽量让代码贴近需求的自然抽象, 越是自然, 则未来越是容易维护和扩展!

@BlackZhu 如果你的项目中, 你无法搞清楚抽象的目的, 就不要抽象. 每个人都只能试图看的稍微远一点, 预测非常永久的事情纯粹是赌运气. 抽象是有代价的, 你需要了评估你项目的复杂度, 没有一个放之四海而皆准的办法, 设计就是平衡矛盾的需求, 平衡的好, 就是有效设计.

因为计算机科学中, 没有什么问题是通过添加一个抽象无法解决的, 如果不行, 就再加一个抽象. 所以后来有了: 如无必要、勿增实体. 而什么是必要就是一个哲学问题了! 每一个添加的抽象都是为了某个切面需求概率的抽象.