yesterdaysun 最近回复了
@
MoYi123 大哥, 能详细说一下这个方案吗? 是不是要换 ES, MySQL 能搞么
要不用解构的方式导出本地变量计算, 算完再导回 dict
A, B, C, D, E, F, G, H, I, J, K, L = dict.values()
A = B + C
D = E - F
G = H * I
J = K / L
dict = {"A": A, "B": B, "C": C, "D": D, "E": E, "F": F, "G": G, "H": H, "I": I, "J": J, "K": K, "L": L}
我大概能理解 OP 的思路, 很多年前我做一个 C#的项目的时候, 那时候是架构师自己搭的框架, 思路就是所有的 Service 放到一个静态类里面, 比如叫 ApplicationServiceManager, 简称 ASM, 任何时候要用的时候直接 ASM.UserService.GetUser()就行, 其实用起来也挺爽的, 要用的是时候直接 ASM 点 XXX 出来所有的 Service, 当时架构找呢么解决初始化和循环依赖的我已经忘了, 但是至少这条路是可行的
但是我还是觉得这套思路和现行的 Spring 体系不太搭, 就像楼上说的, 现在只要用 lombok 配合构造器注入, 几乎是无感的引入需要的 Service, 感觉挺简洁的, 那套集中式的 Service 管理感觉要自己在底层架构引入很多额外的约定和设计才能做出来, 感觉也比较重, 也不利于代码维护和单元测试
总之相比之下我还是偏向普通 Spring 的注入体系
有闲心的话, 造一个代码生成器, 比如我正好为了练习 python, 就写一个代码生成器, 定义好基础类的字段, 一键生成实体类, 数据库脚本, dao/service/view/page 等等, 再配上 copilot, 写 crud 直接起飞, 节约下来的时间摸鱼, 或者改进这个代码生成器, 增加各种选项和分支.
我觉得得先统一一下, 什么叫"可读性"
我觉得可读性是一个偏主观的指标, 抛却主观的部分, 一定有一些相对"客观"的部分, 否则就变成评价一段代码"美不美"这样纯主观的东西了
就比如你提到有些"大神"的代码, 魔数乱飞、代码格式乱七八糟,还有各种奇技淫巧, 从我看来奇技淫巧我可以接受, 但是魔数乱飞、代码格式乱七八糟这些部分我不能接受, 我可以承认这段代码它能跑, 能得到结果, 写他的人是个高手, 但是你要我承认它"可读".
即使这样, 我也不会要求它"可读", 为什么? 因为可能这个人写这段代码的目的就不是为了可读, 比如曾经看到大神些的计算圆周率的代码, 3 行代码, 一堆 a,b,c,d,e,f 的变量, 各种魔数, 但是就是算出圆周率 1000 位了, 他写这段代码的目的就是为了炫技, 就是为了做到最短代码, 极致的技巧, 这个时候, "可读"是不必要的, 甚至追求的就是不可读, 反而这里的奇技淫巧才是最重要的
但是同样的, 搬砖人有机会写这样的代码吗? 是没有的, 工作环境下, 写出能跑的代码是第一要务, 其次是可维护性高的代码, 而"可读性"能间接或直接的提高"可维护性", 所以我们都在追求可读性, 其中我认为相对客观的指标有不使用魔数, 代码格式整齐, 括号整齐, 含义正确清晰的命名, 职责清晰的接口/类/函数的划分, 正确的数据结构, 相对主观的部分是使用高级的语言技巧(闭包, 生成器函数, 新的语法), 惯用的高级技法, 设计模式, 特定算法等等
我觉得你要对达成什么样的可读性先定义好, 比如我随便写一段算法代码 dp[i][j]=dp[i-1][j-1], 懂算法的人看到这段代码, 立刻知道我是在做动态规划的递推方程, 对他来说这段代码的可读性很高, 你给他换个变量名, 换个写法, 他可能反而认不出来这段代码在干什么, 但是你给一个算法小白看这个, 他只会觉得"可读性"很差.
所以就像你说的"可读性"是和什么人看有很大关系的, 如果只是追求自己"可读", 那就自己定标准, 如果是追求所有团队成员"可读", 那就要用你的影响力, 让他们接受这个标准, 如果是和论坛上的人讨论"可读", 那最好只讨论相对客观的标准, 主观的部分注定辩不出结果
比如我说这个技巧可以 3 行变一行, 又非常简洁, 但是就会有人不认可, 比如我说这个设计模式这样用很好, 但是就有人说你滥用设计模式, 老老实实写不好么, 这些都辩不出个所以然. 但是如果有人使用奇奇怪怪的变量名, 拼错单词的名字, 大量使用魔数, 喷他就没问题, 就算他嘴硬硬杠, 也不用管他, 因为其实我们都知道这样肯定是有问题的, 顶多被甩几句"又不是不能用","能跑就行","我看得懂"之类的
我支持合并正则的方案, 在以前的类似的案例里面, 把一批 200 个左右的正则合成 1 个, 能够提高 30 倍左右的效率, 当然这个和具体的数据有关系, 但是说明这个方案是可行的.
原理我猜应该就是合并后的正则, 引擎编译时会自动优化形成类似 DFA 的数据结构或者算法, 合并正则可能也要一定的优化, 比如排序, 尽可能让有相同前缀的放在一组, 然后也要优化一些.*这样的写法, 就不同的方案都简单试试, 套入实际数据看看那种效率会变高
感觉抽象一下问题, 把货架从下而上, 从左到右编号, 抽象为数组, 里面的值就是货物重量, 空的就是 0, 比如随便写一个:
2,0,0,0,0,1,0,3,4,5
目标重心最低, 这个其实很简单就是越重的越下面就行, 所以结果就是排个序:
5,4,3,2,1,0,0,0,0,0
但是这里的难点是普通的排序算法不行, 不能像普通排序一样通过额外 temp 变量去交换(swap), 要利用现有的空位交换, 也就是只能和某个 0 交换, 而且进一步的优化是如果是同一层的货物要忽略排序, 比如最下一层原来是 4,5, 没有必要硬是调换成 5,4, 因为是同一层, 重心不会发生变化
是这个意思吗?
感觉上应该是有最优算法的, 但是我想不出来, 我能想到的就是类比冒泡, 结合贪心策略, 从最下面开始按照排序好的结果一点点去交换得到最终结果
隐约记得, 在 Win98 时代, 有一个邪门技巧, 把桌面壁纸设成一个固定的纯色, 是一种特殊的粉红色, 然后用超级解霸播放视频, 视频就会显示在桌面壁纸上, 就像如今的动态桌面一样, 非常神奇, 这个 BUG 或者技巧给我留下很深的印象
select 用户 id,count(订单 id) as 下单量
from 订单表
where 店铺 id=xxx
and 下单时间 between xxx and xxx
group by 用户 id having count(订单 id) between xxx and xxx
看情况再加索引啥的, 应该不算复杂吧