• 丁丁历险记
    2019-12-20
    正在重构一个运营七年的盈利项目,举步维艰

    作者回复: 一起加油💪

    
     7
  • Geek_88604f
    2019-12-28
    最近在考虑云服务计费功能的重构,服务资源的计量依赖资源的状态,而状态是由业务控制的,业务状态变更的时候需要刷新计费相关的数据,因此计费的功能就和业务耦合了。目前的重构思路是这样的:起一个定时任务,按照一定的周期调用业务接口查询资源的状态,所有的计费逻辑都在定时任务中。避免对核心业务的影响。后续可以进一步优化成基于事件的机制。不知道这个思路是否可行,许老师?

    作者回复: 非常好的一个经典案例。不妨多思考几种解决思路,客观对比一下彼此的优缺点。

     1
     2
  • 东方华尔街
    2020-01-06
    刚刚参加了ECUG 大会,许老师的个人魅力和架构能力杠杠的

    作者回复: 多谢支持

    
     1
  • reverse
    2019-12-31
    许神的架构课重要部分笔记已记录,github地址:https://github.com/xiaomiwujiecao/KongFuOfArchitect/blob/master/part1/README.md

    欢迎拍砖!欢迎丢香蕉
    
     1
  • leslie
    2019-12-21
    引用老师课程中关于重构的一句经典话语"架构设计(未来架构应该是什么样的)、资源规划与调度(与新功能开发的优先级怎么排)、阶段规划(如何把大任务变小,降低内部的抵触情绪和项目风险)以及持久战的韧性与毅力的庞大工程。”体现了老师一直强调的架构与业务的理解。
            软件架构的老化与重构参与不多:不过数据库架构这块的事情经历过不少。虽范围有所缩小,不过核心思路大致相同。对于老师的这个总结拆分简析一下;
             首先是架构设计:1.需要梳理出当前的现状,对于整体现状做出分析;目的是再烂的架构都有其合理性,其中那些可能会被将来做为最小原子使用这是需要做的;2.针对分析的结果再权衡利弊的基础上想出改进方案,毕竟重构升级的过程还是有许多关联性的数据;3.未来的短、中、长期规划大致是怎样,怎样才能可扩展或后期升级。
           其次是资源规划与调度:个人觉得这块内容应当属于项目经理的知识;1.资源规划:要做的就是拆分,需要对于团队/项目有足够的了解才能更好的明白和了解有什么样资源以及可以用到什么样的程度
    2.资源调度:任何一个项目会有固定资源和非固定/调用资源,固定和非固定的使用程度和时间完全不同的且了解不同,这个协调能力是一个项目经理所需的能力。
           最后是阶段规划以及持久性:格局观和可持续性,即通常所说的CI/CD特性;对于整体的了解越明白、格局观与弹性越好,规划和持续性就越好。其实还涉及到产品中常用的MVP特性,试错中找到最佳持续方案。
            以上是我对于老师今天分享的思考和理解以及梳理;一路学习、一路实践、一路反思、一路收获。感谢老师的付出,让我在学习中能不断收获到不一样的知识;期待老师的后续分享,谢谢。
     
    展开

    作者回复: 挺好的思考与总结

    
     1
  • Aaron Cheung
    2019-12-20
    许老师的讲解让我明白 talk is really important
    
     1
  • Eternal
    2020-02-02
    "重构的挑战远不只是这些。这是一个集架构设计(未来架构应该是什么样的)、资源规划与调度(与新功能开发的优先级怎么排)、阶段规划(如何把大任务变小,降低内部的抵触情绪和项目风险)以及持久战的韧性与毅力的庞大工程" 总结得太好了,2019年我们2个人重构了一个老系统,本以为花上几个月时间能搞定,结果我们遇到了一堆问题:新需求需要继续做怎么保持兼容?重构任务怎么拆分,?后阶段性完成,回归测试资源不足怎么安排上线时间?外部资源不够(重构需求得优先级容易被打压)

    作者回复: 多谢补充

    
    
  • 义明
    2019-12-24
    “如果伤害值不大,代表耦合在合理范围,做到这一步暂时不再往下走是可接受的。如果耦合过多,那就意味着我们需要站在这个功能本身的业务视角看依赖的合理性了。如果不合理,可以考虑推动局部重构。”由于前期代码设计的强耦合导致整个项目积重难返,很多时候改起来是要考虑到线上维护数据的难易性,我也是尽量引入回调,尽量把核心和业务做了分离,不想再改动之前的逻辑了,在人手不足的情况下,也只能做局部的优化和整理。
    
    
  • 梦醒十分
    2019-12-20
    要多看几遍呀!
    
    
  • 沫沫(美丽人生)
    2019-12-20
    许老师,需求的变化点和稳定点,可以作为判断系统的核心模块和周边模块的依据吗?

    作者回复: 有这个味道在里面

     2
    
  • 沫沫(美丽人生)
    2019-12-20
    许老师,想请教一个核心功能界定的问题,还有一个产品之间差异化的问题。怎么确定一个系统的核心模块呢?作为竞争对手,WPS和office的差异化是什么?怎么在程序架构中抽象这种差异化呢?望您不吝赐教

    作者回复: 需求越稳定的部分,越处于核心的位置。MVC 框架,MV 是核心,C 是周边。M 如果比较大,内部还可以分核心与周边。wps 和 office 的竞争很有意思,从最初的不一样的 office 到后面提一样的 office,你可以感受一下。程序架构不会受此类商业策略的影响。

     1
    
我们在线,来聊聊吧