※ 引述《ManGo1012 (ManGo)》之铭言： : 如题，好奇想问一下 : 基本上在有正常版控的条件下 : 这种情况是不是根本不该发生？ : 尤其是开发周期尚未结束，没有要交接 : 每个人负责的部分 : 最小单位应该直接用档案切开 : 一个档案只会有一个人在维护、push code 不一定，可能合理可能很 suck 要看规模、工作流程、有没有人控场、默契 自己的经验是分工做得好的地方通常会定义 ownership 「这块 code 是拎北/拎母的，要改要先问」 积极的 owner 会对 code 要长成怎样有明确的想法并前进 消极（但合格）的 owner 会让 code...好好活着不要被乱改 甚至有时候不是明文规定，而是「啊，他对这段 code 最熟」 然後就自然演化成「他是 XX 系统扛坝子」 owner 的权限怎麽贯彻就到处都不一样了 有的是如同你说的，只有特定人可以改某个档案/repo 有的是同事可以乱发 PR / MR，但是只有 owner 可以 merge 这种就常常在解冲突，有时候频率跟吃太阳饼掉屑差不多 一但有不只一人改同一堆 code，就会开始有知识的边界的问题 怎麽知道哪段 code 在干嘛，有什麽眉角，跟什麽外部系统有互动 又是哪个客户提这种鸡掰需求所以看起来虽然很怪但是不能改 在没有明确定义 owner 的地方，这种事情会变成吵架的火种 （有定义的地方大概就会走一个「我要告老师(owner)啦哼哼哼」的路线...） 所以有类似制度的地方很多会做 code review，除了看同事 code 写得如何 也很大成分是确保同事间知道彼此在做什麽，不用很熟，依稀有印象就可以了 「干，这段 code 这麽鬼」 「我想起来了，有看过 MR，客户A有这个鸡掰需求...靠北这 MR 你发的耶」 「...干我自己写的自己忘了」 另外是 MR / PR 看多之後同事彼此的 code 会越来越像 之後改彼此的 code 会容易一点，这需要时间磨合就是 （但还是常看到因为「你这 code 写好烂」而吵架的 软体工程里面最 suck 的终究是人类这个要素....） BTW，MR / PR 跟其他所有的同事互动一样 会展现出谁是鸡掰郎，谁是会把事情都整理好再交出去的好孩子 回过头，你碰到的问题不是「很多人改同一段 code」 而是「ownership 不明确」 然後你就觉得「他国军舰驶入我国领海，干林老师」 只是也可能想像出各种让「定义 owner」很麻烦的理由就是 事情只要扯到人跟业务就是各种 suck 而大部分的 code 是人为了业务写的 suck \(^_^)/ suck \(^_^)/ suck : 即使是超庞大Class : 也应该尽量切成不同小Class : 然後利用继承、封装、多型分工出去才对 切小的好处 - 对脑袋比较轻松，一次不用载入这麽多 code - 权限设定比较容易 切小的坏处 - 想想 java 的 stacktrace 为什麽会这麽长一串 这也是程度问题就是... 一千行的 class 也许 suck 也许合理，要看状况而定 一万行的 class 基本上很 suck，不过能不能重构则是另一个问题（泣 另外对外面的人来说，这有点单一窗口 vs 跑好多窗口的差别 前提是介面设计合理不乱七八糟就是 -- 起来，不愿做光棍的人们，把女孩的清纯筑成我们新的长城 萝莉控们到了最危险的时候。每个人被迫着发出最後的吼声。 起来！起来！起来！ 我们万众一心，往着女孩的裙底，前进！ 往着女孩的裙底，前进！前进！前进！进！ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 218.166.77.235 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1679371712.A.067.html ※ 编辑: GALINE (218.166.77.235 台湾), 03/21/2023 12:17:14 对自己的 code 主张所有权通常是个好迹象 比较不会始乱终弃，也比较认同权力带来的责任 不过你们公司该怎麽做比较顺就不一定了 「谁管什麽东西」其实是个政治问题 - 某个 class / 档案全部你管，你认同吗？你同事跟主管认同吗？ - 怎麽决定是哪几个 class / 档案？ - 其他人怎麽知道是哪几个 class / 档案？ - 所有该放进去的逻辑都由你来改，不管案子是不是你的，愿意吗？ - 或每次要改之前都先跟你说一声？ - 如果其他人送 MR，你不会因为自己忙就都放个两天再来看吗？ - 怎麽执行？怎麽避免其他人 merge？（Gitlab / Github 都以 repo 切分） - 整个 repo 你管 - 你有办法处理（或至少认识）整个 repo 的流通业务吗？ - 处理 MR 速度能跟上同事写 code 的速度吗？ - 全部拆掉 - 要花多少人力多少时间 - 该拆成什麽形状？谁决定？整合谁管？（对，又冒出个空 owner） - 如果业务在人之间流动，切的形状要跟着改吗？ - 或者...其他？ 最大的问题： - 能说服有决定权的人认同「解这题付出的成本，值得」吗？ - 能说服业务在客户 / stakeholder / 大老板面前帮你坦吗？ 软体工程很大一部分其实是要处理人的问题 以人为主的问题其实就是政治问题 但写 code 的人(包括我)又很都自觉讨厌处理政治问题... ※ 编辑: GALINE (218.166.77.235 台湾), 03/21/2023 13:35:38 感谢... Orz ※ 编辑: GALINE (114.27.210.82 台湾), 03/22/2023 16:53:43