工程协作与交付：Git、需求分析与估算

基础知识不只包括计算机原理和设计原则，也包括团队协作方式。因为软件不是一个人写完就结束的，它还要经历协作、评审、合并、发布和需求演化。

flowchart LR
    A["需求"] --> B["分析"]
    B --> C["估算"]
    C --> D["实现"]
    D --> E["Git 协作"]
    E --> F["交付与反馈"]

Git 为什么是团队基础设施

Git 不是“保存代码”的工具，它是团队协作的版本系统。它决定了：

• 怎么分支。
• 怎么合并。
• 怎么回滚。
• 怎么控制提交历史。

SSH 配置

SSH 让 Git 连接远程仓库更安全、更稳定，也更适合长期使用。

ssh-keygen -t rsa -C 'xxx@xxx.com'

Rebase 为什么重要

Rebase 适合整理线性提交历史。它可以让提交记录更清晰，但要谨慎使用，因为它会改写历史。

git rebase -i [startpoint] [endpoint]

使用场景

• 合并本地多个小提交。
• 清理提交记录。
• 保持主干历史整洁。

不常用但实用的命令

• git remote prune origin：清理远程已经不存在的本地跟踪分支。

需求分析为什么比“写代码”更早

需求分析不是文档工作，它是把模糊需求转化成可实现规则的过程。

在复杂系统里，需求不清是最贵的。因为你写错代码可以改，但理解错业务会反复返工。

一个例子

网球计分规则就是很典型的需求建模练习。你需要先分清：

• 发球局和决胜局。
• 15/30/40 和平分。
• Advantage 规则。

这种题目的价值就在于：规则不是代码里直接写死的，而是先被分析清楚。

人月神话为什么还值得读

《人月神话》提醒我们一件事：估算不是把时间凑一凑那么简单。

很多项目失败，不是因为开发慢，而是因为对复杂度、沟通成本和返工成本估计不足。

估算为什么总是不准

因为需求会变，未知会暴露，团队熟练度会变化，系统集成会出现意料之外的问题。

所以估算的目标不是“绝对准确”，而是：

• 让大家对风险有共识。
• 让工作拆得更合理。
• 让计划更可调整。

需求分析和估算怎么配合

一个更稳妥的流程通常是：

1. 先理解业务目标。
2. 再拆需求规则。
3. 然后识别风险和未知。
4. 最后给出估算区间，而不是拍一个精确数字。

flowchart TD
    A["业务目标"] --> B["规则分析"]
    B --> C["风险识别"]
    C --> D["估算区间"]

历史演进

• 早期工程协作依赖人工传递和线下沟通。
• Git 让分布式协作变得可追踪。
• Rebase、分支和合并让历史管理更灵活。
• 需求分析和估算逐渐从“拍脑袋”演化为“规则、风险、节奏”共同驱动。

最佳实践

• SSH 配置好，减少仓库访问摩擦。
• Rebase 用在清理历史，不要滥用在公共分支。
• 需求分析先看规则，再看实现。
• 估算最好给范围，不要把不确定性伪装成确定性。
• 协作效率不是靠加班堆出来的，而是靠沟通和版本管理降低返工。