04-09-06 技术分歧场景 - 学习笔记章节信息核心主题:技术分歧的本质、避免技术ego、寻找第三选择学习目标:掌握处理技术分歧的方法,在保持技术追求的同时维护团队关系关键要点:分歧背后的真实原因、数据驱动决策、第三选择思维、技术方案对话模板核心概念1. 技术分歧的本质什么是技术分歧?在Android开发中,常见的技术分歧场景:架构选择: MVC vs MVVM vs MVI 语言选择: Java vs Kotlin 技术栈: RxJava vs Coroutines UI方案: XML vs Compose 图片库: Glide vs Coil vs Picasso 架构层级: 单体 vs 组件化 vs 模块化 数据库: SQLite vs Room vs Realm 网络库: Retrofit vs OkHttp vs Volley技术分歧的三种常见误区误区1:认为技术分歧是技术对错之争**错误做法** - 错误认知: MVVM就是比MVC好,这是事实! Kotlin已经是官方推荐,还用Java是落后! 真相: 技术选择没有绝对的对错,只有在特定场景下的合适与否。 - MVVM在某些场景下更好,但不是所有场景 - Kotlin有很多优势,但Java在某些情况下也合理 - 最佳实践往往是有上下文的误区2:认为技术分歧是个人能力之争**错误做法** - 错误认知: 你不同意我的方案,是因为你技术不行 我比你资深,所以应该听我的 你没用过这个技术,你不懂 真相: 技术分歧往往不是能力问题,而是: - 掌握的信息不同 - 关注的优先级不同 - 过往的经验不同 - 对风险的容忍度不同误区3:认为技术分歧只能有一个赢家**错误做法** - 错误认知: 要么用你的方案,要么用我的方案 必须有一个人说服另一个人 只能二选一 真相: 很多时候存在第三选择: - 结合两种方案的优点 - 找到双方都能接受的折中方案 - 分阶段实施,逐步验证 - 根据场景选择不同方案技术分歧背后的真实原因表面上的技术争论,背后往往是这些因素:因素1:优先级不同场景:讨论是否要重构 开发A:必须重构,代码太烂了! → 真实优先级:代码质量、长期维护 开发B:没时间重构,先保证功能上线! → 真实优先级:交付进度、业务目标 冲突本质:不是技术之争,是优先级之争因素2:风险偏好不同场景:是否使用新技术 激进派:用最新的Compose,能大幅提升效率! → 风险偏好:愿意承担新技术的不确定性 保守派:等Compose成熟了再说,现在太冒险! → 风险偏好:倾向于稳定可靠的技术 冲突本质:不是能力之争,是风险偏好之争因素3:视角不同场景:包体积优化 前端工程师:多引入一个库没关系,才500KB → 视角:单个库的增量 架构师:现在50个库,每个500KB,总共25MB! → 视角:整体的累积效应 冲突本质:不是对错之争,是视角之争因素4:过往经验不同场景:是否使用某个第三方库 工程师A:XXX库很好用,我在上个项目用过 → 经验:上个项目成功案例 工程师B:XXX库有问题,我踩过坑 → 经验:某个项目失败案例 冲突本质:不是技术之争,是经验之争2. 避免技术Ego什么是技术Ego?定义:把技术选择和个人身份、能力、地位绑定,把技术讨论变成个人较量。技术Ego的表现:□ 把我的方案和我的能力等同起来 你反对我的方案,就是说我技术不行 □ 用技术高低来判断人的价值 你连XXX都不会,你怎么有资格参与讨论? □ 固守自己的观点,拒绝考虑其他可能 我就是坚持用XXX,不接受其他方案 □ 把同意自己当作忠诚,不同意当作背叛 你是支持我还是支持他? □ 用权威和资历压制不同意见 我做了10年Android,我说用XXX就用XXX □ 赢得争论比解决问题更重要 我一定要让他承认我是对的技术Ego的危害:对个人: - 阻碍学习和成长 - 在团队中失去信任 - 错过更好的方案 对团队: - 制造对立和冲突 - 压制创新和讨论 - 影响决策质量 对项目: - 做出次优决策 - 技术债累积 - 项目成功率下降如何克服技术Ego?心态1:把我的方案和我分离**错误做法** - 技术Ego思维: 这是我的方案,如果被否决,就是否定我 **正确做法** - 健康思维: 这是我基于当前信息提出的方案,如果有更好的方案, 我很愿意采纳。方案的好坏不代表我的价值。心态2:目标是解决问题,不是赢得争论**错误做法** - 技术Ego思维: 我一定要让大家同意我的观点,证明我是对的 **正确做法** - 健康思维: 我的目标是找到最佳方案,不管是我的方案还是别人的方案, 只要能解决问题就好心态3:不同意见是帮助,不是攻击**错误做法** - 技术Ego思维: 他反对我的方案,是在挑战我的权威 **正确做法** - 健康思维: 他提出不同意见,可能看到了我的盲区, 这是帮我完善方案的机会心态4:承认自己也会犯错**错误做法** - 技术Ego思维: 实践经验和能力,不可能犯这种错误 **正确做法** - 健康思维: 我也会有盲区和错误,保持谦逊和开放实践技巧:技巧1:用我们替代我**错误做法** - 我的方案是XXX **正确做法** - 我想到一个方案,我们一起讨论看看是否可行 **错误做法** - 从技术角度看应该XXX **正确做法** - 我们是否可以考虑XXX技巧2:主动邀请挑战这是我的想法,但我可能有盲区, 请大家帮我看看有什么问题 如果你发现我的方案有漏洞,请一定告诉我技巧3:公开承认自己不确定关于XXX部分,我不太确定,有人有经验吗? 我对YYY不太了解,能否请ZZZ分享一下?技巧4:感谢不同意见感谢你指出这个问题,我确实没考虑到 这个角度很好,我之前没想到3. 寻找第三选择什么是第三选择?定义:超越你的方案和我的方案的二元对立,创造一个融合双方优点、更优越的第三种方案。第三选择的思维模式:传统思维(二元对立): 方案A ←→ 必须二选一 ←→ 方案B 你 我 第三选择思维: 方案A ⤵ ⤷ 协同创造 → 方案C(更优) 方案B ⤴如何寻找第三选择?步骤1:理解双方的核心关注点不要只看表面的技术方案,要理解背后的关注点:示例:MVC vs MVVM之争 表面之争: 工程师A:用MVC 工程师B:用MVVM 理解: 工程师A的核心关注: - 团队熟悉MVC,学习成本低 - 时间紧,不想冒险 - 担心MVVM的坑 工程师B的核心关注: - MVVM长期维护成本低 - 代码质量和可测试性 - 团队技术成长 真正的目标: 既要降低短期风险,又要兼顾长期质量步骤2:找到共同目标提问: 虽然我们提出的方案不同,但我们是否在核心目标上 有共识? 示例: 我们是否都认同: 1. 项目要按时上线(短期目标) 2. 代码要易于维护(长期目标) 3. 团队要能驾驭技术栈(能力匹配) 如果这三点我们都同意,那我们的分歧只是如何 实现这些目标,对吗?步骤3:跳出非此即彼的框架**错误做法** - 二元思维: 要么用A,要么用B,没有第三种选择 **正确做法** - 第三选择思维: 如果我们不限于A和B,还有什么可能性? 创造性提问: 有没有一种方式,既能实现A的优点,又能实现B的优点? 能否分阶段?先做什么,后做什么? 能否根据场景选择?哪些场景用A,哪些场景用B? 能否创造一个新方案,比A和B都好?步骤4:共同创造方案态度: - 不是我说服你或你说服我 - 而是我们一起创造新方案 语言: - 我们能否结合两种思路? - 如果我们这样做,能否解决双方的顾虑? - 有没有一种方式,以下都满意?第三选择的常见模式模式1:分阶段实施场景:要不要全面重构? 方案A(激进派):立即全面重构 方案B(保守派):不重构,只修bug 第三选择: - Phase 1:重构最痛的核心模块(2周) - Phase 2:评估效果,决定是否继续 - Phase 3:根据效果逐步推进或调整 优势: - 降低风险(分阶段验证) - 兼顾进度(不是一次性全做) - 有数据支撑决策模式2:并行试验场景:选择图片加载库 方案A:Glide(成熟稳定) 方案B:Coil(新颖Kotlin友好) 第三选择: - 在两个不同的模块中分别试用 - 3周后对比性能、易用性、bug数 - 基于数据做最终决策 - 允许不同模块使用不同库(如果差异不大) 优势: - 用数据而非争论决策 - 两种方案都得到验证机会 - 团队都有参与感模式3:分场景选择场景:网络请求用RxJava还是Coroutines? 方案A:统一用RxJava 方案B:统一用Coroutines 第三选择: - 新代码用Coroutines(面向未来) - 老代码保持RxJava(降低风险) - 建立互操作层,确保兼容 - 逐步迁移,不强制一次性替换 优势: - 兼顾历史包袱和技术演进 - 降低迁移风险 - 给团队学习时间模式4:混合方案场景:用XML还是Compose? 方案A:全部用XML 方案B:全部用Compose 第三选择: - 基础组件用Compose(受益明显) - 复杂业务页面用XML(稳定可靠) - 通过AndroidView互操作 - 建立清晰的使用指南 优势: - 充分利用两种技术的优势 - 降低全面迁移的成本 - 渐进式技术升级Android开发实战案例案例1:架构选型争论 - MVC vs MVVM场景设定:新项目启动,需要选择架构模式Tech Lead Tom倾向MVC(团队熟悉,风险低)你倾向MVVM(长期维护性好,可测试性强)项目要求3个月上线团队5人,其中2人(包括你)用过MVVM错误示范1:技术至上,忽略现实约束你在架构评审会上:我强烈建议用MVVM,理由很充分: 1. Google官方推荐的架构 2. Jetpack组件都是为MVVM设计的 3. ViewModel生命周期安全,避免内存泄漏 4. 数据绑定减少样板代码 5. 单元测试更容易写 6. 业界主流都在用MVVM MVC已经是上个时代的技术了,我们不应该因为 团队不熟悉就不学习。技术人员应该拥抱新技术, 而不是固步自封。学习成本是一次性的,但长期 收益是巨大的。 所以从技术角度看必须用MVVM,这是技术正确的选择。Tom的反应:你说的这些我都知道,但是你有没有考虑过现实情况? 1. 团队只有你和小李用过MVVM,其他3人都不会 2. 项目要求3个月上线,留给学习的时间很少 3. MVVM的学习曲线比MVC陡峭 4. 如果遇到坑,没有人能及时解决 5. MVC已经用了多年,团队很熟悉,风险可控 技术不是越新越好,适合团队的才是最好的。 我还是坚持用MVC,这是对项目负责。后续:会议陷入僵局双方都不肯让步最终Tom用职位权威拍板用MVC你心里不服气,觉得技术上被保守派压制团队氛围受影响问题没解决,关系受损,团队产生分裂错误示范2:过度妥协,放弃技术追求你在会议上:嗯...我理解团队的顾虑,确实MVVM学习成本 比较高,时间也比较紧张。那就用MVC吧, 我没意见。问题分析:过快放弃,没有充分讨论Tom不理解MVVM的价值团队失去了技术成长的机会你自己也可能长期regret这个决定正确示范:第三选择思维你在会议上:Tom,感谢你的坦诚。我理解你的顾虑,这些都是 非常现实和重要的问题。在讨论方案之前,我想先 确认一下我们的共同目标,看看我们是否在基本点上 有共识。可以吗? Tom:好的,你说。 【寻找共同目标】 你:我理解我们的共同目标是: 1. 项目要在3个月内按时上线,这是第一优先级 2. 代码质量要有保障,避免上线后大量bug 3. 长期来看,代码要易于维护和扩展 4. 技术选择要匹配团队能力,风险可控 这些是否是我们都认同的? Tom:是的,我都认同。 【理解双方的核心关注点】 你:很好。那我们的分歧主要在于如何实现这些目标。 让我先理解一下你的核心顾虑: 你担心的主要是: 1. 学习成本:团队大部分人不会MVVM,学习需要时间 2. 时间风险:3个月的deadline很紧,学习可能影响进度 3. 技术风险:MVVM可能有坑,团队没经验解决不了 我理解对吗?还有其他顾虑吗? Tom:对,主要就是这三点。特别是时间风险, 老板对这个项目很重视,不能延期。 【陈述自己的关注点】 你:我理解了。我来说说我为什么倾向MVVM: 1. 长期维护:这个项目会持续维护至少2年,MVVM 的维护成本比MVC低约20-30%(基于我上个项目的经验) 2. 代码质量:MVVM的结构清晰,新人接手更容易 3. 可测试性:ViewModel的单元测试很容易写,能提高质量 4. 技术成长:这是团队学习现代Android开发的好机会 但是,我完全理解你的顾虑。我不想为了技术而技术, 如果确实风险太大,我也接受用MVC。 【提出第三选择】 你:不过,我在想,有没有一种方式,既能降低你担心的 风险,又能获得MVVM的长期收益? 我想到一个渐进式的方案,不知道是否可行: **阶段1:准备期(Week 1-2)** - 我和小李准备MVVM培训材料和项目模板 - 搭建好基础框架(网络层、数据层、ViewModel基类) - 做一个完整的示例模块,包括文档和最佳实践 - 周五下午做3小时的内部培训 **阶段2:试点期(Week 3-6,1个月)** - 选择2个中等复杂度的模块用MVVM实现 (比如:用户信息模块、商品列表模块) - 其他模块先用MVC,保证进度 - 我和小李重点review MVVM部分,快速解决问题 - 每周五review一次,评估效果和问题 **阶段3:评估期(Week 7,1周)** - 评估试点模块的数据: - 开发效率:是否比MVC慢?慢多少? - 代码质量:bug数、代码行数、复杂度 - 团队反馈:大家学习难度如何?遇到什么问题? - 基于数据做决策: - 如果效果好,后续新模块用MVVM - 如果问题多,后续改回MVC - 已有的MVVM模块保留(不影响功能) **阶段4:执行期(Week 8-12,剩余时间)** - 根据评估结果执行 - 已有的MVC模块不强制重构,稳定最重要 **这个方案的优点**: 1. 风险可控:只是部分试点,可以随时调整 2. 有数据支撑:1个月后有真实数据,不是空谈 3. 兼顾进度:不是all-in,MVC作为保险 4. 团队参与:大家都有学习和评估的机会 5. 给我们一个验证机会,不是主观判断 **可能的问题**: 1. 代码库会同时有MVC和MVVM,可能有些混乱 2. 我和小李的工作量会增加(培训、review、答疑) 3. 如果最终选择MVC,前期MVVM的工作有些浪费 但我觉得这些成本是可接受的,特别是能用数据 验证决策,比争论要更客观。 Tom,你怎么看这个方案?它是否能降低你担心的风险? Tom:(思考)...你这个方案考虑得很全面。 我主要的顾虑是时间风险,但你这个方案确实风险可控, 第一个月就能看到效果,如果不行可以及时调整, 不会影响整体进度。 我有几个具体问题: 1. 你说的示例模块和培训,能保证在第1周完成吗? 2. 试点的两个模块,会不会选到特别复杂的? 我担心试点选的太简单,不能代表真实情况。 3. 如果MVVM效果不好,改回MVC的成本有多大? 【继续讨论细节】 你:这些问题很好!让我一一回答: 1. 示例模块和培训时间: - 我和小李可以加班完成,第1周应该没问题 - 如果实在来不及,可以延长到Week 2的周三, 这样周五还能培训,不影响后面的schedule 2. 试点模块的选择: - 用户信息模块:中等复杂,有网络请求、本地缓存、UI更新 - 商品列表模块:中等复杂,有分页、筛选、图片加载 - 这两个模块的复杂度能代表大部分业务场景 - 我们可以一起review选择,确保有代表性 3. 改回MVC的成本: - 如果效果不好,MVVM模块可以保持不变, 不需要改回MVC(功能已经实现了) - 后续新模块用MVC就行 - 所以成本主要是前期的学习时间,但这个时间 不管结果如何,都有团队成长的价值 你觉得这样可以吗?还有其他concerns吗? Tom:我觉得可以试试。不过我有一个要求: 如果第一个月试点后,数据显示效率明显低于MVC, 或者团队反馈学习困难很大,我们要立即切回MVC, 不能为了技术而影响项目交付。你能承诺吗? 你:完全没问题!我承诺: 1. 如果试点数据不好,立即切回MVC,没有任何异议 2. 我和小李会全力支持,确保试点顺利 3. 每周五的review我会准备详细的数据和分析 实际上,我也想用数据验证MVVM是否真的如我预期的好。 如果事实证明在我们的场景下MVVM不合适,我也会调整 认知。技术服务于业务,确保项目成功是第一优先级。 Tom:好!那我们就按这个方案执行。我会和大家 宣布这个决策,强调这是团队共同决定的方案, 不是我强制,也不是你强推。 你:太好了!感谢你愿意给我们这个验证的机会。 我会后整理详细的执行计划,明天发给你review。 【会后团队宣布】 Tom:大家好,关于架构选型,我和XXX经过详细讨论, 达成了一个渐进式的方案...(说明方案) 这个方案的好处是: - 风险可控,不是all-in - 有数据驱动,不是主观争论 - 给大家学习MVVM的机会,但不强制 - 如果效果不好,我们能及时调整 这不是我强制的,也不是XXX强推的,是我们共同创造的方案。 大家有什么问题或建议吗? 团队:(积极讨论,提出具体问题和建议)后续影响:双方的关注点都得到了重视创造了一个第三选择,比单一方案更好用数据而非争论来决策团队有参与感,不是被动接受Tom和你建立了更深的信任和respect团队学习了现代Android开发一个月后,数据显示MVVM效果很好,继续推进项目按时上线,代码质量也很好成功要点:先寻找共同目标,建立共识基础理解对方的核心顾虑(时间风险、学习成本)陈述自己的关注点,但不强推提出第三选择:渐进式方案,降低风险用数据驱动决策,而非主观争论真诚承诺:如果效果不好,立即调整强调共同创造,而非个人胜利案例2:技术栈选择 - Kotlin vs Java场景设定:项目启动2年,一直用Java你提议新代码用Kotlin,逐步迁移Senior工程师Bob反对,认为现在不是时候团队6人,3人想学Kotlin,3人prefer Java需要达成团队共识完整对话:从分歧到共识【第一步:一对一了解Bob的真实顾虑】 你单独约Bob喝咖啡: 你:Bob,想和你聊聊Kotlin的事情。我知道你不太 赞成现在引入Kotlin,能说说你的concerns吗? 我想真正理解你的考虑。 Bob:我不是反对Kotlin本身,Kotlin确实有很多优点。 我主要有三个顾虑: 1. 时间成本:团队学习Kotlin需要时间,现在项目 pressure比较大,我担心影响进度 2. 维护成本:项目已经有10万行Java代码了,引入 Kotlin后代码库会有两种语言,维护起来更复杂 3. 招聘成本:以后招人是招会Kotlin的,还是会Java的? 会不会限制招聘范围? 你:这些顾虑很合理!我之前确实没太考虑招聘的问题。 能再问一下,除了这三点,你还有其他担心吗? 比如对Kotlin技术本身的担心? Bob:技术上我倒不太担心,Google都官方支持了, 肯定没问题。主要就是这三点成本问题。 你:明白了。那我也想问一下,如果这三个成本问题 能够解决或降低,你对引入Kotlin会是什么态度? Bob:如果成本可控,我觉得可以考虑。毕竟Kotlin 确实有很多优点,比如null safety、扩展函数这些。 我不是守旧,只是希望稳妥一点。 你:理解了,谢谢你的坦诚!我会想想有没有办法 降低你担心的成本。 【第二步:团队会议讨论】 你在团队会议上: 关于是否引入Kotlin,我和Bob以及其他几位同事 都聊过了,我想先总结一下大家的观点: 【支持引入Kotlin的理由】: - Null safety,减少空指针crash - 简洁语法,减少样板代码 - Coroutines比RxJava更简洁 - Google官方推荐,长期趋势 - 团队技术成长的机会 【反对或担心的理由】: - 学习时间成本 - 代码库混合Java和Kotlin的维护成本 - 招聘时对技术栈的要求更高 - 当前项目进度压力大 我觉得双方的观点都很有道理。支持方关注的是 长期收益和技术进步,反对方关注的是短期成本和 现实约束。这不是对错之争,而是优先级和节奏的问题。 【寻找共同目标】 我想先问大家:我们是否在这些基本点上有共识? 1. Kotlin作为技术本身是有价值的(长期看) 2. 但引入新技术要考虑成本和时机 3. 我们的首要目标是确保项目稳定和进度 大家认同吗? 团队:认同。 【提出第三选择】 你:很好。那我们的问题就变成了:如何在控制成本 的前提下,逐步引入Kotlin,既获得长期收益,又不影响 短期交付? 我想到一个方案,叫三步走策略: **Step 1:自愿学习(Month 1-2)** - 不强制要求,自愿学习 - 公司提供Kotlin课程和学习资料 - 每两周一次内部分享会,学习者分享经验 - 建立Kotlin最佳实践文档 **Step 2:新代码尝试(Month 3-6)** - 学过Kotlin且有兴趣的同学,可以在新代码中用Kotlin - 但不强制,prefer Java的同学可以继续用Java - 核心原则:团队review通过即可,不限制语言 - 建立Java-Kotlin互操作规范 **Step 3:评估和推广(Month 6)** - 6个月后评估: - Kotlin代码的质量(bug率、可读性) - 团队的学习曲线和接受度 - 维护成本的实际情况 - 基于数据决定下一步: - 如果效果好,鼓励更多使用Kotlin - 如果问题多,保持现状或调整策略 - 不强制迁移老代码,自然演进 **针对Bob的三个顾虑的回应**: 1. 时间成本: - 自愿学习,不影响工作时间(利用业余时间) - 不强制,不给不想学的人压力 - 学习资源公司提供,降低个人成本 2. 维护成本: - Java和Kotlin可以很好地互操作 - 建立清晰的互操作规范 - 不强制迁移老代码,新老共存 - 6个月后评估实际维护成本 3. 招聘成本: - 不强制要求候选人会Kotlin - Java开发可以快速学习Kotlin(1-2周) - 实际上,会Kotlin是加分项,不影响招聘 Bob,你觉得这个方案是否能降低你担心的成本? Bob:我觉得这个方案比较合理。特别是不强制, 这样不会给团队太大压力。而且6个月后有数据评估, 不是盲目推进。我可以接受。 你:太好了!其他同学呢?有什么意见或建议吗? 小李:我很想学Kotlin,但我担心学了之后在项目中 用不上,会不会白学了? 你:不会的!即使6个月后评估决定不大规模推广, 你学到的Kotlin知识也是有价值的,对个人成长有帮助。 而且在新代码中,你完全可以用Kotlin,只要团队 review通过就行。 小王:我对Kotlin没什么兴趣,我就想继续用Java, 会不会以后被边缘化? 你:完全不会!这个方案就是要尊重每个人的选择。 你可以继续用Java,不会因此受到任何不利影响。 项目中评价代码质量,不是评价语言选择。 Bob:对,我支持这个。不能因为语言选择搞派系。 你:没错!我们的目标是写好代码,解决问题, 不是搞语言之争。 那我们就这样定了: - 从下个月开始执行三步走策略 - 我负责整理学习资源和最佳实践文档 - Bob,你能不能帮我一起制定Java-Kotlin互操作规范? 你对Java很熟,这个规范需要你的expertise - 6个月后,我们一起review数据,共同决定下一步 大家还有问题吗? 团队:没有了,我们同意这个方案。后续影响(6个月后):3名同学学习了Kotlin,在新代码中使用Kotlin代码的bug率比Java低15%代码行数减少约20%3名prefer Java的同学继续用Java,没有压力团队review时对两种语言都很友好Bob看到数据后,也开始学习Kotlin招聘时,Kotlin成为加分项,吸引了更优秀的候选人团队技术氛围更开放,愿意尝试新技术成功要点:一对一了解核心顾虑,不在公开场合争论寻找共同目标,建立共识基础提出三步走第三选择,兼顾多方诉求自愿而非强制,尊重个人选择用数据评估,而非主观判断邀请反对者参与方案制定(Bob制定互操作规范)长期看,技术演进和团队和谐双赢案例3:重构时机讨论 - 现在 vs 以后场景设定:某个核心模块代码质量差,技术债严重你认为应该立即重构项目经理说现在没时间,要先做新需求团队被夹在中间,不知道听谁的需要达成共识,否则项目会一直拖延完整对话:用数据和第三选择达成共识【背景调研(你的准备工作)】 你花了2天时间做了详细的调研: 1. 技术债的量化数据: - 这个模块有3000行代码,圈复杂度平均35(正常应该15) - 最近3个月,这个模块的bug占了全部bug的40% - 修复一个bug平均需要4小时(其他模块平均1小时) - 代码review时,新人理解这个模块平均需要3天 2. 重构的成本估算: - 完全重构需要3周(1人全职) - 渐进式重构需要分4次,每次2天 3. 不重构的成本估算: - 每月花在这个模块的bug修复时间:约32小时 - 新需求在这个模块上的开发效率:比正常慢50% - 未来6个月的机会成本:约96小时(4人周) 【第一步:和项目经理的一对一沟通】 你:Linda,想和你聊聊XXX模块重构的事情。 我知道你说现在没时间,我想理解一下你的concerns。 Linda:主要是时间压力。老板要求这个季度要上线 5个新功能,时间本来就很紧,如果现在重构, 新功能肯定会delay。 你:我理解。能问一下,如果新功能delay, 会有什么后果? Linda:老板会不满意,可能影响团队的OKR评分, 也会影响业务目标。所以我不能承担这个风险。 你:明白了。那我想分享一下我调研的数据, 然后我们一起看看有没有两全的办法。可以吗? Linda:好的,你说。 你:我做了一个详细的分析(展示数据): 【当前状况】 - 这个模块的bug占全部bug的40% - 修一个bug平均要4小时,是其他模块的4倍 - 新需求在这个模块上的开发速度慢50% - 最近3个月,我们在这个模块上花了96小时修bug 【重构成本】 - 完全重构:3周(120小时) - 渐进式重构:分4次,每次2天(64小时total) 【不重构的成本】 - 未来6个月预计还要花96小时修bug - 新功能开发效率低50%,额外多花约40小时 - Total:136小时 【关键洞察】 如果用渐进式重构(64小时),在6个月内就能回本, 而且之后每个月都能节省时间。 更重要的是,新功能如果要在这个模块上开发, 现在重构可能反而更快,因为开发效率能。 我想问:这个季度的5个新功能,有几个需要改动 这个模块? Linda:查看...(查看需求列表)5个需求中, 有3个需要改这个模块。 你:如果有3个需求要改这个模块,那么: - 不重构,开发这3个需求预计要60小时 - 先重构(渐进式,16小时),再开发,预计要163046小时 实际上,先重构反而能节省14小时,而且质量更好, bug更少,还不会产生更多的技术债。 Linda,基于这些数据,你觉得是否值得重构? Linda:如果真的是这样,那重构确实有道理。 但我有两个concerns: 1. 你的估算准确吗?会不会实际超时? 2. 重构期间出了问题,谁负责? 你:这两个concerns非常重要!让我回应一下: 1. 估算的准确性: - 我是基于类似模块的重构经验估算的 - 为了保险,我可以加20%的buffer - 渐进式重构的好处是,如果第一次就发现超时, 可以立即停止,已完成的部分也有价值 2. 责任问题: - 我承诺:如果重构超时或出问题,我个人加班补回来, 不影响新功能的交付时间 - 我会每天同步进度,有问题立即报告 - 重构期间会保留旧代码,可以随时回滚 这样你是否能接受风险? Linda:你能做出这样的承诺,我觉得可以试试。 不过我希望用最稳妥的方式,你说的渐进式重构, 具体怎么做? 【提出第三选择:渐进式重构】 你:渐进式重构的方案是这样的: **Iteration 1(Week 1,2天)** - 重构数据层,提取接口,解耦依赖 - 影响范围:只有数据层内部 - 风险:低,单元测试覆盖 - 收益:后续需求1需要改数据层,这个重构后能快50% **Iteration 2(Week 3,2天)** - 重构业务逻辑层,拆分大方法 - 影响范围:逻辑层内部 - 风险:低,有完整回归测试 - 收益:后续需求2、3都要改逻辑层,这个重构后更清晰 **Iteration 3(Week 5,2天)** - 重构UI层,提取ViewMode - 影响范围:UI层内部 - 风险:中,需要UI测试验证 - 收益:UI层代码更简洁,新需求4能受益 **Iteration 4(Week 7,2天)** - 整体优化和文档更新 - 影响范围:整个模块 - 风险:低,之前都验证过了 - 收益:代码质量全面提升,新人容易理解 **关键点**: - 每个Iteration独立,有价值,可以随时停止 - 每次重构后立即回归测试,确保功能正常 - 重构和新需求穿插进行,互不影响 - 每次重构都让后续的开发更快 Linda,这个方案是否让你放心? Linda:你考虑得很细。我觉得可以。不过我还有 最后一个要求:每次重构后,我要看回归测试报告, 确认没有引入新问题。如果有问题,立即回滚。 你:完全没问题!我会每次重构后提交测试报告给你。 另外,我建议我们把这个方案也和团队分享, 让大家知道我们不是为了技术而技术,而是基于 数据和business价值做决策。这样团队也能学到 如何权衡技术债和业务需求。 Linda:好主意!那我们就这样定了。 【第二步:团队会议分享】 你在团队会议上: 大家好,关于XXX模块重构的事情,我和Linda讨论后, 达成了一个方案,想和大家分享。 首先,我们都认同: - 这个模块的技术债确实很严重 - 但项目进度也很重要,不能因为重构delay新功能 所以我们的challenge是:如何在不影响业务的前提下, 逐步偿还技术债? 我做了一个详细的数据分析(展示数据和方案)... 最终我们决定采用渐进式重构方案,分4次进行, 每次2天,总共8天。这样的好处是: - 不影响新功能开发 - 每次重构都有独立价值 - 风险可控,可以随时停止 - 反而能加快后续新功能的开发 我想强调的是:这不是我强推重构,也不是Linda强推需求, 而是我们基于数据,找到的一个兼顾技术和业务的方案。 我希望通过这个案例,让大家学到: - 技术债要量化,用数据说话 - 技术决策要考虑business impact - 遇到分歧时,找第三选择,而非二选一 大家有什么问题吗? 团队成员A:我可以参与重构吗?我也想学习重构的方法。 你:太好了!我正好需要人一起review重构代码, 项目中可以pair programming,你能学到很多。 团队成员B:重构后,我们会更新文档吗?我希望新人 能更容易理解这个模块。 你:必须的!Iteration 4专门包含文档更新, 项目中会把设计思路、关键决策都文档化。 Linda:我补充一下,这个重构方案是经过详细评估的, 不是拍脑袋。我希望大家以后遇到类似的技术债, 也能这样: 1. 量化问题和成本 2. 评估重构的投入产出比 3. 设计低风险的执行方案 4. 基于数据做决策 这样我们就能在技术和业务之间找到平衡。后续影响(2个月后):4次渐进式重构全部完成,实际用了9天(比预估多1天)重构后,新功能开发效率确实提升了约45%Bug率下降了60%,从每月8个降到每月3个新人理解这个模块的时间从3天降到半天团队学到了渐进式重构的方法你和Linda建立了相互信任,之后的技术决策都很顺利老板看到数据后,称赞团队在技术和业务之间找到了平衡成功要点:用数据量化技术债和重构收益理解对方的压力和优先级(业务deadline)提出渐进式重构的第三选择承诺责任,降低对方风险让技术决策和业务价值对齐团队学习,建立技术债评估的文化实用工具工具1:技术分歧讨论检查清单使用时机:准备技术分歧讨论时□ 准备阶段 □ 我量化了问题和影响(数据) □ 我评估了不同方案的成本和收益 □ 我了解了对方的核心顾虑 □ 我准备了第三选择方案 □ 我的心态是解决问题,不是赢得争论 □ 讨论阶段 □ 先寻找共同目标 □ 理解双方的核心关注点 □ 用数据而非主观判断 □ 提出第三选择,邀请共同创造 □ 避免技术ego,保持开放 □ 征询意见,给对方参与感 □ 决策阶段 □ 基于数据和共同目标决策 □ 明确下一步行动和责任人 □ 设定评估节点和调整机制 □ 强调共同决策,而非个人胜利 □ 执行阶段 □ 兑现承诺 □ 定期同步进展 □ 及时处理问题 □ 用数据评估效果工具2:技术方案对比模板使用时机:需要对比多个技术方案时## 技术方案对比:【问题描述】 **背景**: - 当前问题:___________ - 业务目标:___________ - 技术约束:___________ **备选方案**: ┌──────────────────────────────────────────────┐ │ 对比维度 │ 方案A │ 方案B │ 方案C │ ├──────────────────────────────────────────────┤ │ 开发成本 │ ___ 人天 │ ___ 人天 │ ___ 人天 │ │ 学习成本 │ ★★★ │ ★★★ │ ★★★ │ │ 维护成本 │ ★★★ │ ★★★ │ ★★★ │ │ 性能表现 │ ___ms │ ___ms │ ___ms │ │ 包体积影响 │ ___KB │ ___KB │ ___KB │ │ 稳定性 │ ★★★ │ ★★★ │ ★★★ │ │ 团队熟悉度 │ ★★★ │ ★★★ │ ★★★ │ │ 技术风险 │ 低/中/高 │ 低/中/高 │ 低/中/高 │ │ 长期收益 │ ★★★ │ ★★★ │ ★★★ │ └──────────────────────────────────────────────┘ **推荐方案**:【方案X】 **推荐理由**(按重要性排序): 1. ___________ 2. ___________ 3. ___________ **权衡说明**: - 放弃方案Y的原因:___________ - 放弃方案Z的原因:___________ **风险和应对**: - 风险1:___________ → 应对:___________ - 风险2:___________ → 应对:___________ **执行计划**: - Phase 1:___________ - Phase 2:___________ - Phase 3:___________ **评估标准**: - 指标1:___________ - 指标2:___________ - 评估时间:___________工具3:第三选择思维提示卡使用时机:陷入二选一困境时当你面临A vs B的困境时,问自己: □ 我们的共同目标是什么? (寻找背后的真正目的) □ A和B各自的核心优势是什么? (提取精华) □ 能否结合A和B的优点? (融合创新) □ 能否分阶段?先做什么,后做什么? (时间维度) □ 能否分场景?哪些场景用A,哪些场景用B? (空间维度) □ 能否并行试验?让数据说话? (实验验证) □ 能否创造一个完全不同的方案C? (跳出框架) 第三选择的特征: ✓ 比A和B都更能实现共同目标 ✓ 降低双方担心的风险 ✓ 双方都感到被尊重 ✓ 创造而非妥协工具4:技术债量化评估表使用时机:讨论是否要偿还技术债## 技术债评估:【模块名称】 **技术债的表现**: □ 代码复杂度:圈复杂度 ___ (正常15) □ 代码行数:___ 行(单文件500行为过多) □ Bug率:最近3个月 ___ 个bug (占比 ___%) □ 修复成本:平均 ___ 小时/bug (正常2小时) □ 开发效率:比正常慢 ___% □ 新人理解成本:___ 天(正常1天) □ 代码重复率:___% (正常10%) **量化影响**: - 最近3个月花在这个模块的时间:___ 人时 - 未来6个月预计花费:___ 人时 - 对团队士气的影响:___ (1-10分) **重构成本估算**: - 完全重构:___ 人时 - 渐进式重构:___ 人时(分 ___ 次) - 最小优化:___ 人时 **投资回报率**: - 重构成本:___ 人时 - 6个月节省:___ 人时 - ROI:___% - 回本周期:___ 月 **建议**: □ 立即重构(ROI50%) □ 渐进式重构(ROI 20-50%) □ 暂缓重构(ROI20%) □ 重写(技术债太严重) **执行方案**: ___________工具5:技术讨论的黄金句式避免技术Ego的表达方式:【提出观点时】 **错误做法** - 必须用XXX **正确做法** - 我倾向于XXX,因为YYY,大家怎么看? **错误做法** - 这是最佳实践 **正确做法** - 在类似场景下,XXX是常见做法,我们的场景是否适用? 【回应不同意见时】 **错误做法** - 你不懂XXX **正确做法** - 能否解释一下你的考虑?可能我理解不全面 **错误做法** - 这个方案明显不对 **正确做法** - 我有些顾虑,主要是XXX,你怎么看? 【承认不确定时】 **正确做法** - 关于XXX部分,我不太确定,有人有经验吗? **正确做法** - 我可能对YYY的理解有偏差,能否帮我澄清一下? 【邀请挑战时】 **正确做法** - 这是我的想法,但我可能有盲区,请帮我看看有什么问题 **正确做法** - 如果你发现我的方案有漏洞,请一定告诉我 【达成共识时】 **正确做法** - 感谢大家的讨论,我们共同创造了这个方案 **正确做法** - 这个方案融合了大家的智慧,比我最初的想法更好小节总结核心要点回顾1. 技术分歧的本质:不是对错之争,是优先级、风险偏好、视角、经验的差异表面是技术,背后是人的需求和顾虑2. 避免技术Ego:把我的方案和我分离目标是解决问题,不是赢得争论不同意见是帮助,不是攻击3. 寻找第三选择:超越二元对立,共同创造更优方案理解双方核心关注点,找到共同目标用数据驱动决策,而非主观争论4. 常见的第三选择模式:分阶段实施并行试验分场景选择混合方案立即可应用的技巧技巧1:准备技术讨论时,量化数据- 问题的量化指标 - 不同方案的成本收益对比 - 风险评估和应对措施技巧2:讨论中先寻找共同目标虽然我们方案不同,但我们是否在XXX目标上有共识?技巧3:提出第三选择时的句式有没有一种方式,既能实现A的优点,又能实现B的优点? 能否分阶段?先XXX,再根据数据决定YYY?技巧4:避免技术Ego的自我提醒- 我的目标是解决问题,不是证明自己对 - 不同意见是帮实践中发现盲区的机会 - 方案被否决不等于我被否定常见误区误区1:技术分歧必须有一个赢家错误:要么你的,要么我的正确:寻找第三选择,共同创造误区2:技术先进就应该用错误:最新的技术就是最好的正确:适合场景和团队的才是最好的误区3:资历深就应该听他的错误:用权威压制讨论正确:用数据和逻辑说服误区4:为了和谐放弃技术追求错误:过度妥协,不表达真实想法正确:坚持技术追求,但用合适的方式本章总结技术分歧不是战场,而是共同探索最优解的机会。技术讨论中最常见的陷阱是把方案被否定等同于我被否定,从而产生防御和对抗。真正的高手能把分歧变成集体智慧:通过数据说话、寻找第三选择、用小实验代替大争论。技术分歧的最终目的不是谁赢,而是什么方案最好。核心要点速查:分歧阶段关键动作避坑要点分歧出现先找共同目标不要立刻反驳各自陈述用数据案例支撑不用权威压人僵持不下提议POC/灰度验证不陷入无限争论方案确定全力执行,即使不是自己的不在执行中消极抵抗结果复盘用数据验证对错不翻旧账不贴标签第三选择思维公式:A方案优点 B方案优点 → 能否兼得? ↓ 能否分阶段实现?能否混合使用? ↓ 能否用小实验低成本验证?实战心法:讨论技术方案时,把我推荐XXX改成在YYY场景下,XXX的优势是ZZZ——加场景限定,减少对抗自我提醒:方案被否决不等于我被否定,目标是解决问题不是证明自己技术的本质是解决问题,不是证明正确。把ego留在门外,把好奇心带进会议室。