https://en.wikipedia.org/wiki/Rounding
可选的舍入方式有 6 种, 常说的四舍五入对应 infinity 这种, 在 c#里面也叫 AwayFromZero, 但是这个会有统计学误差, 所以另一种常见的舍入方式是 even, c#里叫 ToEven, Java 里叫 HalfEven, 也就是上面有人提到的银行家舍入

不同的语言, 不同的函数使用的舍入规则都是不一样, 比如 toFixed 和 Math.round 用的就是不一样的, MySQL 的 decimal 和 float 规则不一样, 如果追求 100%精确的话就得去看文档他们用的到底是哪一种方案, 或者 Java/c#这种可以有选项让你控制使用哪一种舍入规则

之前有段时间研究过数独, 如果像第五版里说的用类似穷举的方法解数独没有问题, 可以解出来, 顶多一些难题要花费好几秒钟, 但是即使是一些简单的题, 没有经过优化, 计算机最终的步骤数都在千到万这个级别, 这样出结果没有问题, 但是要输出可以给人看的步骤太粗犷了一点.

说白了, 这里的穷举只是相当于应用了基本的唯一余数技巧和候选数加回溯的算法, 要真的生成可以给人看的步骤, 需要实现人所用的技巧, 比如 https://hodoku.sourceforge.net/en/techniques.php 这里列出的几十种从简单到复杂的解题技巧, 但是这样算法逻辑就会大大复杂了

不过这个 HoDoKu 是开源的, 可以用他的 C#算法复刻一遍转成文字再输出, 大概可以

@williamcc 摸鱼写了一段, https://gist.github.com/yesterdaysun/ee0bfa5b6d8a54d53c0fe0e79b8e923f

取巧, 用了两次 DFS 回溯, 第一次以分数为目标, 然后重新 DFS 以出口为目标, 分数是最大了, 但是步数可能不是最优的, 懒得搞了

算了, 无聊百度了一下直接搜索答案, 你自己看吧: https://blog.51cto.com/u_13019/7301342

@williamcc 不太清楚你这个题目的要求到底是什么? 如果只是让人外部输入来控制上下左右移动, 那就简单了, 循环接收输入, 判断可不可以前进, 然后上下左右移动, 非常容易

但是如果是要自动找到终点, 那就是不是什么"条件语句和循环语句"的事情了, 必须上算法, 一般来说就是回溯算法, 可以用深度优先搜索(DFS), 或者广度优先搜索(BFS), 你可以了解一下, 网上的代码应该还挺多的, 通关应该比较容易, 但是想要分数最大, 得加点优化手段, 得做全遍历, 得在先找到终点之前把所有的路径遍历完, 最后再走终点路径, 会稍微复杂一点

dfs 吧, 不过题目好像要求分数越高越好, 要改成 bfs?

个人理解: 敏捷里面, 快速迭代是最核心的价值, 2 周是一个合适的时间, 超出这个时间, 团队整体就会效率低下, 因为大家需要在一个不长不短的时间节点收到反馈, 互相沟通, 改进方案, 重启下一个迭代

所以估算任务也需要确保所有任务的点数在 2 周范围内完成, 如果超出, 就需要拆分任务到 2 周之内, 分解任务是确保估算准确的核心

虽然理论上故事点不该和天数挂钩, 但是确实事实上一定会挂钩, 只不过不同团队标准不一样罢了, 比如我会定每天的人力为 3 点, 一周 15 点, 2 周 30 点, 我会确保所有分解后任务在 15 点以下.
所以如果我估算一个任务 3 点, 意味着要 1 天做完, 估算 10 点, 大概 3 天做完, 15 点一周做完.

估算故事点的难点在于不同团队的任务是不一样的, 如果是维护型的任务或者 CRUD 之类的, 很好估算, 因为有参照, 但是复杂的任务, 非功能性需求, 或者探索性的任务是不好估算的,
这个时候给出的估算基本上就是纯凭经验, 相当于只是给一个截止日期, 想要准确的话就要 leader 参与分析, 给出他的估算, 最后决定, 不知道这算不算"背对背专家估计"

总之敏捷的核心我认为还是在快速迭代中去应对"变化", 即使我个人认同敏捷宣言中的各项价值观, 但是保不齐就是有人更喜欢文档,流程,计划,工具这些, 所以如何和这些人和谐相处合作, 也算是"敏捷"的一部分

@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

看情况再加索引啥的, 应该不算复杂吧

感觉像是精确覆盖问题(Exact Cover), 可以搜一下相关的算法试试

为啥没有评论, 我看完了, 觉得写的还挺好的, 虽然内容比较基础, 但是整体感觉是经过精心编排的, 提到了 SOLID 设计原则, 也精选了常见实用的几个设计模式.

提点建议, 现在设计模式这块太卷了, 各种书啊文章啊, 想要出彩得来点特别的干货, 比如举的代码例子, 面向初学者, 这些普普通通的实现类就够了, 但是要进阶的话, 最好结合各个知名框架, 讲它们是怎么使用设计模式的, 比如 Spring,MyBatis 里的, 或者 Apache Commons 里的设计模式, 或者 JDK 里的设计模式, 不过这样可能每个模式都要 2.5w 字了.

或者也可以在设计原则上加深一下, 初学者一般重点会在 23 个设计模式上, 但其实在我看来各个设计原则才是根本, 以设计原则的视角去深入剖析各个设计模式的原始初衷, 使用场景和设计妥协应该会很有帮助

还可以结合不同的语言, 反正标题也没写必须 Java 嘛, 不同语言对设计模式有不同程度的支持, 静态语言和动态语言的不同也会导致有些设计模式不需要写的那么繁琐了