 |
yesterdaysunV2EX 第 145085 号会员，加入于 2015-10-30 14:03:58 +08:00今日活跃度排名 8675 |
yesterdaysun 最近回复了
35 天前 回复了 williamcc 创建的主题 › Python › Python 大佬帮忙看看，机器人题目 |
@williamcc 摸鱼写了一段, https://gist.github.com/yesterdaysun/ee0bfa5b6d8a54d53c0fe0e79b8e923f
取巧, 用了两次 DFS 回溯, 第一次以分数为目标, 然后重新 DFS 以出口为目标, 分数是最大了, 但是步数可能不是最优的, 懒得搞了
取巧, 用了两次 DFS 回溯, 第一次以分数为目标, 然后重新 DFS 以出口为目标, 分数是最大了, 但是步数可能不是最优的, 懒得搞了
35 天前 回复了 williamcc 创建的主题 › Python › Python 大佬帮忙看看，机器人题目 |
算了, 无聊百度了一下直接搜索答案, 你自己看吧: https://blog.51cto.com/u_13019/7301342
35 天前 回复了 williamcc 创建的主题 › Python › Python 大佬帮忙看看，机器人题目 |
@williamcc 不太清楚你这个题目的要求到底是什么? 如果只是让人外部输入来控制上下左右移动, 那就简单了, 循环接收输入, 判断可不可以前进, 然后上下左右移动, 非常容易
但是如果是要自动找到终点, 那就是不是什么"条件语句和循环语句"的事情了, 必须上算法, 一般来说就是回溯算法, 可以用深度优先搜索(DFS), 或者广度优先搜索(BFS), 你可以了解一下, 网上的代码应该还挺多的, 通关应该比较容易, 但是想要分数最大, 得加点优化手段, 得做全遍历, 得在先找到终点之前把所有的路径遍历完, 最后再走终点路径, 会稍微复杂一点
但是如果是要自动找到终点, 那就是不是什么"条件语句和循环语句"的事情了, 必须上算法, 一般来说就是回溯算法, 可以用深度优先搜索(DFS), 或者广度优先搜索(BFS), 你可以了解一下, 网上的代码应该还挺多的, 通关应该比较容易, 但是想要分数最大, 得加点优化手段, 得做全遍历, 得在先找到终点之前把所有的路径遍历完, 最后再走终点路径, 会稍微复杂一点
36 天前 回复了 williamcc 创建的主题 › Python › Python 大佬帮忙看看，机器人题目 |
dfs 吧, 不过题目好像要求分数越高越好, 要改成 bfs?
个人理解: 敏捷里面, 快速迭代是最核心的价值, 2 周是一个合适的时间, 超出这个时间, 团队整体就会效率低下, 因为大家需要在一个不长不短的时间节点收到反馈, 互相沟通, 改进方案, 重启下一个迭代
所以估算任务也需要确保所有任务的点数在 2 周范围内完成, 如果超出, 就需要拆分任务到 2 周之内, 分解任务是确保估算准确的核心
虽然理论上故事点不该和天数挂钩, 但是确实事实上一定会挂钩, 只不过不同团队标准不一样罢了, 比如我会定每天的人力为 3 点, 一周 15 点, 2 周 30 点, 我会确保所有分解后任务在 15 点以下.
所以如果我估算一个任务 3 点, 意味着要 1 天做完, 估算 10 点, 大概 3 天做完, 15 点一周做完.
估算故事点的难点在于不同团队的任务是不一样的, 如果是维护型的任务或者 CRUD 之类的, 很好估算, 因为有参照, 但是复杂的任务, 非功能性需求, 或者探索性的任务是不好估算的,
这个时候给出的估算基本上就是纯凭经验, 相当于只是给一个截止日期, 想要准确的话就要 leader 参与分析, 给出他的估算, 最后决定, 不知道这算不算"背对背专家估计"
总之敏捷的核心我认为还是在快速迭代中去应对"变化", 即使我个人认同敏捷宣言中的各项价值观, 但是保不齐就是有人更喜欢文档,流程,计划,工具这些, 所以如何和这些人和谐相处合作, 也算是"敏捷"的一部分
所以估算任务也需要确保所有任务的点数在 2 周范围内完成, 如果超出, 就需要拆分任务到 2 周之内, 分解任务是确保估算准确的核心
虽然理论上故事点不该和天数挂钩, 但是确实事实上一定会挂钩, 只不过不同团队标准不一样罢了, 比如我会定每天的人力为 3 点, 一周 15 点, 2 周 30 点, 我会确保所有分解后任务在 15 点以下.
所以如果我估算一个任务 3 点, 意味着要 1 天做完, 估算 10 点, 大概 3 天做完, 15 点一周做完.
估算故事点的难点在于不同团队的任务是不一样的, 如果是维护型的任务或者 CRUD 之类的, 很好估算, 因为有参照, 但是复杂的任务, 非功能性需求, 或者探索性的任务是不好估算的,
这个时候给出的估算基本上就是纯凭经验, 相当于只是给一个截止日期, 想要准确的话就要 leader 参与分析, 给出他的估算, 最后决定, 不知道这算不算"背对背专家估计"
总之敏捷的核心我认为还是在快速迭代中去应对"变化", 即使我个人认同敏捷宣言中的各项价值观, 但是保不齐就是有人更喜欢文档,流程,计划,工具这些, 所以如何和这些人和谐相处合作, 也算是"敏捷"的一部分
75 天前 回复了 yesterdaysun 创建的主题 › MySQL › 问一个复杂的基于产品属性的 SQL 查询 |
@MoYi123 大哥, 能详细说一下这个方案吗? 是不是要换 ES, MySQL 能搞么
76 天前 回复了 xuegy 创建的主题 › Python › 大量操作 dict 内元素时有什么能省略 dict 名字的语法糖？ |
要不用解构的方式导出本地变量计算, 算完再导回 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}
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}
126 天前 回复了 csw3983931 创建的主题 › 程序员 › 奇思妙想，一个想法，不知道是不是可行的 |
我大概能理解 OP 的思路, 很多年前我做一个 C#的项目的时候, 那时候是架构师自己搭的框架, 思路就是所有的 Service 放到一个静态类里面, 比如叫 ApplicationServiceManager, 简称 ASM, 任何时候要用的时候直接 ASM.UserService.GetUser()就行, 其实用起来也挺爽的, 要用的是时候直接 ASM 点 XXX 出来所有的 Service, 当时架构找呢么解决初始化和循环依赖的我已经忘了, 但是至少这条路是可行的
但是我还是觉得这套思路和现行的 Spring 体系不太搭, 就像楼上说的, 现在只要用 lombok 配合构造器注入, 几乎是无感的引入需要的 Service, 感觉挺简洁的, 那套集中式的 Service 管理感觉要自己在底层架构引入很多额外的约定和设计才能做出来, 感觉也比较重, 也不利于代码维护和单元测试
总之相比之下我还是偏向普通 Spring 的注入体系
但是我还是觉得这套思路和现行的 Spring 体系不太搭, 就像楼上说的, 现在只要用 lombok 配合构造器注入, 几乎是无感的引入需要的 Service, 感觉挺简洁的, 那套集中式的 Service 管理感觉要自己在底层架构引入很多额外的约定和设计才能做出来, 感觉也比较重, 也不利于代码维护和单元测试
总之相比之下我还是偏向普通 Spring 的注入体系
135 天前 回复了 dnjat 创建的主题 › 程序员 › 开发中如何提升开发效率? |
有闲心的话, 造一个代码生成器, 比如我正好为了练习 python, 就写一个代码生成器, 定义好基础类的字段, 一键生成实体类, 数据库脚本, dao/service/view/page 等等, 再配上 copilot, 写 crud 直接起飞, 节约下来的时间摸鱼, 或者改进这个代码生成器, 增加各种选项和分支.
152 天前 回复了 iamee 创建的主题 › 程序员 › 我对于代码可读性的理解 |
我觉得得先统一一下, 什么叫"可读性"
我觉得可读性是一个偏主观的指标, 抛却主观的部分, 一定有一些相对"客观"的部分, 否则就变成评价一段代码"美不美"这样纯主观的东西了
就比如你提到有些"大神"的代码, 魔数乱飞、代码格式乱七八糟，还有各种奇技淫巧, 从我看来奇技淫巧我可以接受, 但是魔数乱飞、代码格式乱七八糟这些部分我不能接受, 我可以承认这段代码它能跑, 能得到结果, 写他的人是个高手, 但是你要我承认它"可读".
即使这样, 我也不会要求它"可读", 为什么? 因为可能这个人写这段代码的目的就不是为了可读, 比如曾经看到大神些的计算圆周率的代码, 3 行代码, 一堆 a,b,c,d,e,f 的变量, 各种魔数, 但是就是算出圆周率 1000 位了, 他写这段代码的目的就是为了炫技, 就是为了做到最短代码, 极致的技巧, 这个时候, "可读"是不必要的, 甚至追求的就是不可读, 反而这里的奇技淫巧才是最重要的
但是同样的, 搬砖人有机会写这样的代码吗? 是没有的, 工作环境下, 写出能跑的代码是第一要务, 其次是可维护性高的代码, 而"可读性"能间接或直接的提高"可维护性", 所以我们都在追求可读性, 其中我认为相对客观的指标有不使用魔数, 代码格式整齐, 括号整齐, 含义正确清晰的命名, 职责清晰的接口/类/函数的划分, 正确的数据结构, 相对主观的部分是使用高级的语言技巧(闭包, 生成器函数, 新的语法), 惯用的高级技法, 设计模式, 特定算法等等
我觉得你要对达成什么样的可读性先定义好, 比如我随便写一段算法代码 dp[i][j]=dp[i-1][j-1], 懂算法的人看到这段代码, 立刻知道我是在做动态规划的递推方程, 对他来说这段代码的可读性很高, 你给他换个变量名, 换个写法, 他可能反而认不出来这段代码在干什么, 但是你给一个算法小白看这个, 他只会觉得"可读性"很差.
所以就像你说的"可读性"是和什么人看有很大关系的, 如果只是追求自己"可读", 那就自己定标准, 如果是追求所有团队成员"可读", 那就要用你的影响力, 让他们接受这个标准, 如果是和论坛上的人讨论"可读", 那最好只讨论相对客观的标准, 主观的部分注定辩不出结果
比如我说这个技巧可以 3 行变一行, 又非常简洁, 但是就会有人不认可, 比如我说这个设计模式这样用很好, 但是就有人说你滥用设计模式, 老老实实写不好么, 这些都辩不出个所以然. 但是如果有人使用奇奇怪怪的变量名, 拼错单词的名字, 大量使用魔数, 喷他就没问题, 就算他嘴硬硬杠, 也不用管他, 因为其实我们都知道这样肯定是有问题的, 顶多被甩几句"又不是不能用","能跑就行","我看得懂"之类的
我觉得可读性是一个偏主观的指标, 抛却主观的部分, 一定有一些相对"客观"的部分, 否则就变成评价一段代码"美不美"这样纯主观的东西了
就比如你提到有些"大神"的代码, 魔数乱飞、代码格式乱七八糟，还有各种奇技淫巧, 从我看来奇技淫巧我可以接受, 但是魔数乱飞、代码格式乱七八糟这些部分我不能接受, 我可以承认这段代码它能跑, 能得到结果, 写他的人是个高手, 但是你要我承认它"可读".
即使这样, 我也不会要求它"可读", 为什么? 因为可能这个人写这段代码的目的就不是为了可读, 比如曾经看到大神些的计算圆周率的代码, 3 行代码, 一堆 a,b,c,d,e,f 的变量, 各种魔数, 但是就是算出圆周率 1000 位了, 他写这段代码的目的就是为了炫技, 就是为了做到最短代码, 极致的技巧, 这个时候, "可读"是不必要的, 甚至追求的就是不可读, 反而这里的奇技淫巧才是最重要的
但是同样的, 搬砖人有机会写这样的代码吗? 是没有的, 工作环境下, 写出能跑的代码是第一要务, 其次是可维护性高的代码, 而"可读性"能间接或直接的提高"可维护性", 所以我们都在追求可读性, 其中我认为相对客观的指标有不使用魔数, 代码格式整齐, 括号整齐, 含义正确清晰的命名, 职责清晰的接口/类/函数的划分, 正确的数据结构, 相对主观的部分是使用高级的语言技巧(闭包, 生成器函数, 新的语法), 惯用的高级技法, 设计模式, 特定算法等等
我觉得你要对达成什么样的可读性先定义好, 比如我随便写一段算法代码 dp[i][j]=dp[i-1][j-1], 懂算法的人看到这段代码, 立刻知道我是在做动态规划的递推方程, 对他来说这段代码的可读性很高, 你给他换个变量名, 换个写法, 他可能反而认不出来这段代码在干什么, 但是你给一个算法小白看这个, 他只会觉得"可读性"很差.
所以就像你说的"可读性"是和什么人看有很大关系的, 如果只是追求自己"可读", 那就自己定标准, 如果是追求所有团队成员"可读", 那就要用你的影响力, 让他们接受这个标准, 如果是和论坛上的人讨论"可读", 那最好只讨论相对客观的标准, 主观的部分注定辩不出结果
比如我说这个技巧可以 3 行变一行, 又非常简洁, 但是就会有人不认可, 比如我说这个设计模式这样用很好, 但是就有人说你滥用设计模式, 老老实实写不好么, 这些都辩不出个所以然. 但是如果有人使用奇奇怪怪的变量名, 拼错单词的名字, 大量使用魔数, 喷他就没问题, 就算他嘴硬硬杠, 也不用管他, 因为其实我们都知道这样肯定是有问题的, 顶多被甩几句"又不是不能用","能跑就行","我看得懂"之类的
Select Language