※ 引述《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 跑好多窗口的差别
前提是接口设计合理不乱七八糟就是

他国军舰驶入我国领海确实很符合我的感觉XD，所以我才问说会有这种感觉是不是我太龟毛

虽然说看得懂就好但我还是想吐槽suck不是形容词…

推这篇

推，专业

推推

推推

stakeholder

推 很贴切XD

外来语镶嵌之后文法要重新算，例如在英文里用rendezvous是跟英文文法还是法文？