从0开始学架构
李运华
资深技术专家
立即订阅
38906 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

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

李运华 2018-08-14
在前面的架构重构内功心法“有的放矢”和“合纵连横”中,我提到架构师需要从一大堆问题中识别关键的复杂度问题,然后有的放矢地通过架构重构来解决。但是通常情况下,需要架构重构的系统,基本上都是因为各种历史原因和历史问题没有及时处理,遗留下来逐渐积累,然后到了一个临界点,各种问题开始互相作用,集中爆发!到了真正要开始重构的时候,架构师识别出系统关键的复杂度问题后,如果只针对这个复杂度问题进行架构重构,可能会发现还是无法落地,因为很多条件不具备或者有的问题没解决的情况下就是不能做架构重构。因此,架构师在识别系统关键的复杂度问题后,还需要识别为了解决这个问题,需要做哪些准备事项,或者还要先解决哪些问题。这就需要我今天要和你分享的架构重构内功心法第三式:运筹帷幄。
经过分析和思考,我们可能从最初的 100 个问题列表,挑选出其中 50 个是需要在架构重构中解决的,其中一些是基础能力建设或者准备工作,而另外一些就是架构重构的核心工作。有了这样一个表格后,那我们应该怎么去把这 50 个问题最终解决呢?
最简单的做法是每次从中挑一个解决,最终总会把所有的问题都解决。这种做法操作起来比较简单,但效果会很差,为什么呢?
第一个原因是没有区分问题的优先级,所有问题都一视同仁,没有集中有限资源去解决最重要或者最关键的问题,导致最后做了大半年,回头一看好像做了很多事情,但没取得什么阶段性的成果。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

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

    作者回复: 很好的思路👍

    2018-08-14
    13
  • junwen.luo
    2年?江湖再见!
    2018-08-30
    8
  • 猿码架构
    将两年时间的重构拆分成多个子重构,促使重构快速见效,树立团队信心!

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

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

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

    2018-08-14
    3
  • 成功
    二年的重构要看项目规模,规模不大,就重开发。如果项目本身的规模是3一5年,像雷达,战斗机控制系统等,用2年重构也值得。
    2018-09-07
    2
  • 波波安
    两年时间太久了。有可能公司业务都发生了很大的变化。重构的规划可能并不满足新业务的发展。

    作者回复: 正解

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

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

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

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

    2018-08-14
    2
  • godtrue
    课后思考及问题
    如果一个架构重构项目最后规划要 2 年才完成,你会怎么处理?
    两年时间比较长,期间研发、测试、产品,甚至我自己都可能换环境。太不可控,如果是我,我会这么做:
    第一切割任务,粒度细到可控的范围,比如:每个月应该重点解决的问题有哪些
    第二给任务排个优先级,先重点搞定重要紧急的
    第三人员流动的根本原因一是钱少二是不开心,如果给不了钱要让大家开心点,工作氛围要轻松愉快点,节奏上要有张有驰
    第四做好监控,有些任务如果延期,需要及时调整任务安排
    第五任务安排到合适的人员,这个很关键,发挥每个人的长处,调动大家的积极性,千万不要明显的厚此薄彼,比如:说页面不重要没价值,后端逻辑才是核心,做页面的没啥价值,把人分成得力的和不得力的,当然,领导都会这么分吧!但可以不说出来,想开除谁等开除时再说,不要告诉其他同事,这样会严重影响士气,让人想写不易维护的代码,自己发现bug也不想解决。

    看评论2年周期重构不如重写,重构我的理解是要重写的只是原来的业务要覆盖,自己的代码逻辑变化是对研发来说的,对于业务是解决了他们的问题原来的业务继续支持😁

    本文核心观点
    1-1:将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段,每个阶段聚焦于一个整体的目标,集中精力和资源解决一类问题
    2019-09-05
  • 小超在努力
    2年稍微长了,1年是我们领导最大忍耐极限。
    2019-05-13
  • Sic Pavis
    如果时间预期为两年,这明显已经超出正常重构时间范围了。

    我认为首先应该回头审视一下,重构涉及的范围是否过大,是否可以先集中重构最核心最重要的系统。

    其次就是再确认一下,重构的方案是否有问题,是否可以舍弃一些细节上的优化以节约大量时间。

    如果工作量确实有这么大,而且耦合太厉害无法拆得过细,那只能考虑直接重写了
    2019-04-23
  • petit_kayak
    其实就是要应用敏捷的思路,排优先级,从高风险、高价值的需求开始,小步快跑,用不断更新的小版本代替大而全的“计划”

    作者回复: 不一定,如果技术判断要上大版本,也是可以的

    2018-09-13
  • 文竹
    分阶段实施中,优先级和分类有点不是很清楚。如果A和B类中,具有优先级相同的任务,那么第一阶段是先解决A类问题还是B类问题?

    对于2年的架构重构,已经体现出来系统的复杂性问题很多,这时也会严重影响业务的发展。看看是否阶段分配得不合理,问题太多,是否可以筛选出关键问题来进行重构。在进行重新规划后,如果系统仍需要很长时间进行重构的话,此时可以考虑架构重新设计。

    作者回复: 1. 先解决一类相关问题
    2. 赞同

    2018-08-26
  • 云学
    看来架构重构和代码重构类似,先写测试用例来保证系统稳定,功能不能破坏,然后抽取接口,规范与周边模块的交互,最后对模块内部动手术,风险一直在掌控之中
    2018-08-16
  • 若水清菡
    第三阶段 解耦 那边是业务平台吧,不是业务中台吧

    作者回复: 是中台,当时的规划是把共性的地方抽取出来,其他业务也可以用

    2018-08-15
  • feifei
    2年重构就算了吧!这比新开发时间还长吧?肯定哪里有问题!

    作者回复: 你可以继续分析问题可能在哪里,这样理解更深刻

    2018-08-14
收起评论
16
返回
顶部