架构重构

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 引言 一般来说，需要 架构 重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。 2. 运筹帷幄 可以想象一下，假如我们拿到一个架构问题列表，其中有50个问题，那我们应该怎么去把这50个问题最终解决呢？ 最简单的做法是每次从中挑一个解决，最终总会把所有的问题都解决。这种做法操作起来比较简单，但效果会很差，为什么呢？ 第一个原因是没有区分问题优先级，所有问题都一视同仁，没有集中有限资源去解决最重要或者最关键的问题，导致最后可能出现做了大半年，回头一看好像做了很多事情，但没取得什么阶段性的成果。 第二个原因是没有将问题分类，导致相似问题没有统筹考虑，方案可能出现反复，效率不高。 第三个原因是会迫于业务版本的压力，专门挑容易做的实施，到了稍微难一点的问题的时候，就因为复杂度和投入等原因被搁置，达不到真正重构的真正目的。 以X系统为例，在我加入前，其实也整理了系统目前存在的问题，大的项包括： 可用性、性能、安全、用户体验等 ，每个大项又包括十几二十个子项

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 引言 架构 重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免的会影响业务功能的开发。因此，要想真正推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通。注意这里我不是指要谈办公室政治，而是指要和利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和争执。 2. 合纵连横 2.1 合纵 道理很简单，但如何做才是关键！ 一般的技术同学谈到架构重构的时候，就会搬出一大堆技术术语：可扩展性、可靠性、性能、耦合、代码很乱。。。。。。但以我的实际经验来看，如果和非技术同学这样沟通，效果如同鸡同鸭讲，没有技术背景的同学很难理解，甚至有可能担心我们是在忽悠TA。例如： 技术同学说：我们系统现在的可扩展性太差了，改都改不动！ 产品同学想：咦，可扩展性，和扩胸运动有关么？。。。。。扩展什么呢，怎么会改不动呢，不就是找个地方写代码嘛。。。。。。 技术同学说：我们的可靠性太差，现在才3个9，业界都是4个9！ 项目经理想：啥是3个9，三九感冒灵？。。。。。。4个9和3个9不就是差个9嘛，和可靠有什么关系。。。。。。 技术同学说：我们系统设计不合理，A业务和B业务耦合！ 运营同学想：咦，耦合，莲藕还是藕断丝连？。。。。。。A业务和B业务本来就是互相依赖的呀。。。。。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 序言 对一个程序员来说，世界上最痛苦的事情是什么呢？ 有的人会说：编码的时候产品改需求！ 有的人会说：看别人不知所云的代码！ 有的人会说：定位一个百年不遇千年难寻的线上不定时偶尔出现的bug！ 有的人会说：找不到女（男）朋友！ 但我要说，这些痛苦其实都不算什么，要么是多花点时间去解决（比如说改需求、看代码），要么是多花点心思（比如说找另一半、定位疑难bug），而我接下来说的这个事情才是最痛苦的，既要说得动老板，也要镇得住同行；既要技术攻关，又要协调资源；既要保证业务正常发展，又要在指定时间内完成目标。。。。。。总之就是十八般武艺要样样精通。 这个事情就是“ 架构 重构”，比“架构重构”还要痛苦的就是“边做业务边架构重构”！我们的产品形象的形容为“给飞驰的法拉利跑车换引擎”，为何这样说呢？ 首先：业务不能停，不能为了架构重构而终止业务的开发，将法拉利停下来换引擎，别人都跑远了； 其次：业务不能出问题，不能因为架构重构导致业务无法运行，法拉利修出问题跑不了，别人也跑远了； 第三：要根本解决问题，而不是修修补补，不是给法拉利引擎加点油，清洁一下就可以了，而是要换上新的引擎。 巧合的是，我加入UC后到现在已经做了3个系统的架构重构了（戏称“救火队长”），而且每个系统的特点都不一样，过程中各种各样的问题都遇到过

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 引言 前面讲了那么多，看起来都是和项目管理相关的的，例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。。。。。 架构 师怎么变成了项目经理了，说好的技术呢？ 真正的架构师，当然必须具备一定的项目经理技能，但更重要的还是技术能力，道理很简单：再好的饼，最后实现不了，都是扯淡！我将“项目管理能力”称之为“文”的能力，“技术能力”称之为“武”的能力，架构师必须文武双全，才能最终把事情搞定！ 2. 文武双全 架构师的“武”体现在很多方面，既有微观层面的，例如如何设计一个高性能的并发框架（可以参考Disruptor，大量的技术细节，例如 CPU cache，cache line，false sharing等 ）；也有宏观层面的，例如采用HBase还是用 MySQL 存储；还有和业务相关的，例如某个功能应该如何设计才能具备可扩展性。业务层面的相关的技术问题，如果没有相关的业务背景，讲起来比较费劲，也不好理解，这里就不展开了。我们讲讲这些重构项目中和业务无关的一些技术。 我被问到的最多的问题其实也是宏观层面的。其中一个主要的问题是“这些系统的业务都不一样，你之前也没有类似业务背景，你怎么识别出M系统重构的目标是数据解耦，S系统重构的目标是高可用呢，X系统重构的目标是系统解耦呢