从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

47 | 架构重构内功心法第三式:运筹帷幄

效果和成果
阶段划分和目标
效果和成果
阶段划分和目标
降低风险
高效并行
明确目标
循序渐进
先易后难
问题分类
优先级排序
处理长期项目的方法
分阶段推进的技巧
S系统的重构
X系统的重构
好处和优势
分段实施的策略
运筹帷幄的意义
架构重构的条件
架构重构的原因
总结和思考
实施案例分析
架构重构内功心法第三式
架构重构的背景和问题
架构重构内功心法第三式:运筹帷幄

该思维导图由 AI 生成,仅供参考

在前面的架构重构内功心法“有的放矢”和“合纵连横”中,我提到架构师需要从一大堆问题中识别关键的复杂度问题,然后有的放矢地通过架构重构来解决。但是通常情况下,需要架构重构的系统,基本上都是因为各种历史原因和历史问题没有及时处理,遗留下来逐渐积累,然后到了一个临界点,各种问题开始互相作用,集中爆发!到了真正要开始重构的时候,架构师识别出系统关键的复杂度问题后,如果只针对这个复杂度问题进行架构重构,可能会发现还是无法落地,因为很多条件不具备或者有的问题没解决的情况下就是不能做架构重构。因此,架构师在识别系统关键的复杂度问题后,还需要识别为了解决这个问题,需要做哪些准备事项,或者还要先解决哪些问题。这就需要我今天要和你分享的架构重构内功心法第三式:运筹帷幄。
经过分析和思考,我们可能从最初的 100 个问题列表,挑选出其中 50 个是需要在架构重构中解决的,其中一些是基础能力建设或者准备工作,而另外一些就是架构重构的核心工作。有了这样一个表格后,那我们应该怎么去把这 50 个问题最终解决呢?
最简单的做法是每次从中挑一个解决,最终总会把所有的问题都解决。这种做法操作起来比较简单,但效果会很差,为什么呢?
第一个原因是没有区分问题的优先级,所有问题都一视同仁,没有集中有限资源去解决最重要或者最关键的问题,导致最后做了大半年,回头一看好像做了很多事情,但没取得什么阶段性的成果。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

架构重构内功心法第三式:运筹帷幄 架构重构是软件开发中至关重要的一环,而在进行架构重构时,需要采取有序推进的策略。本文介绍了“运筹帷幄”的策略,强调了识别关键复杂度问题并分阶段有序推进的重要性。作者提出了分段实施的策略,将问题根据优先级、重要性和实施难度划分为不同阶段,以集中精力和资源解决一类问题。这种策略有助于明确目标、提升团队士气,降低总体风险,并可以更高效地进行架构重构。文章还分享了制定“分段实施”策略的经验,包括优先级排序、问题分类、先易后难、循序渐进等方法。通过这些策略,读者可以更好地理解架构重构的重要性,并学习如何采取有序推进的技巧,以取得阶段性成果,提升团队士气,降低总体风险。 这篇文章为读者提供了架构重构中分阶段有序推进的技巧,帮助他们更好地理解架构重构的重要性,并学习如何采取有序推进的策略。通过分段实施的策略,读者可以更高效地进行架构重构,取得阶段性成果,提升团队士气,降低总体风险。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • 空档滑行
    2年的重构周期太长了,基本等于重新设计实现一个系统,就算架构师的沟通能力再强,也很难说服公司。 我觉得首先要看下自己的项目是不是计划做的太大,先把非关键功能重构砍掉;第二步剩下的功能拆分成最多半年一个周期,计划详细程度递减。一年后的计划都不需要对外公布,然后半年的计划一个里程碑,按文章里说的划分优先级,划分难易度然后推进。

    作者回复: 很好的思路👍

    2018-08-14
    3
    59
  • 陶邦仁
    将两年时间的重构拆分成多个子重构,促使重构快速见效,树立团队信心!

    作者回复: 通常如果说要重构两年,我的建议是重写可能更快😄😄

    2018-08-14
    3
    19
  • 凡凡
    两年时间太久,在互联网更新迭代这么迅速的场景下更加不适合,尤其创业公司,生命或许都维持不到两年。一般都要罗列重构点,按照难度从小到大,效果从大到小排列,然后安排合适的迭代计划。迭代过程中逐步建立信心,信任,适当调整计划。如果真的心里有个两年的计划,一定不要一下子全抖出来🤔

    作者回复: 这算是厚黑术么?😄😄我建议还是说出来,真要两年重构,那就直接重写了

    2018-08-15
    15
  • 何磊
    如果一个项目真的需要两年重构。要么是评估有问题,要么是这个项目不适合重构,只能重写。

    作者回复: 英雄所见略同😄😄👍

    2018-08-14
    14
  • 波波安
    两年时间太久了。有可能公司业务都发生了很大的变化。重构的规划可能并不满足新业务的发展。

    作者回复: 正解

    2018-09-05
    2
    8
  • 小神david
    内功心法讲得非常好~ 收益很多~ 👍

    作者回复: 架构的事情,不单单是写代码,也不单单是就技术论技术,很多人之所以觉得架构难,就是没有意识到这一点。

    2021-03-14
    6
  • wmg
    两年的时间用于重构,时间太久了,对于这个瞬息万变的时代,不确定因素太多。即便一个系统真的烂到要两年时间重构,我倒觉得不如重建,那样还会省去很多约束,也许周期会更短。

    作者回复: 是的,两年重构还不如重建

    2018-08-14
    4
  • 初见
    2年重写吧,我经历过2次,都是原来系统是外包的,代码不规范,功能只是能用的程度,用户一多基本就垮了,做法是梳理业务后,进行重写,逐个拆分出业务重写,仅保留业务入口在老系统上,慢慢的,新系统建成,老系统只剩前端入口,最后直接切走,整体换到了新系统。

    作者回复: 这样的经历很难得呀,可以思考总结一下经验

    2022-06-30
    2
  • Jun
    先易后难也要慎重权衡。很多时候简单的方案都是hacky的,不利于长期目标。

    作者回复: 你要是能一眼看出长期目标是什么,而且确信你的判断一定准确那当然是直接考虑长远好了,但很多时候复杂度就在于你无法准确判断

    2019-12-22
    2
  • 方人其
    将问题按照性质分类 ?? 一般分成哪些类?参考下

    作者回复: 一级的常见分类有:性能类,可用性类、可扩展类、管理类、流程类、测试类等,还可以继续分类,例如性能类可以分:数据库类、缓存类、外部系统依赖类等

    2022-02-15
    1
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部