本周工作思考
最近4个月，通过I18n项目组的巨大努力，以及公司决策层的强大支持和所有产研伙伴们的全力协作，i18n项目集在com和cn上成功完整上线，实现了比较彻底的业务模块拆分及重组，编译构建升级，模板node化，多语能力升级等，这些基础能力的升级为我们的2022的业务迭代，产能提升，到点交卷能力，质量体系建设，web侧的技术架构和业务架构升级打下了比较坚实的基础。
允许我简单回顾下umu web的技术架构发展里程碑事件，2014和215年web端逐渐构建起了angular.js 1.3 + jQuery + zepto + fis + PHP + 基于百度云存储的运行时多语言机制部署发布为底层基础的技术栈，2016年我们在web移动端引入react的swap，2017年我们逐渐研究和引入webpack，同时我们针对课程创建模块基于angularjs采用了完全面向对象的思想和写法，实现了web pc侧的技术架构升级， 2018引入 typescript，2019年我们完成了除考试外的所有课程和小节的typescript化， 至此在web移动端我们构建起了和业界主流技术一致的技术栈，2021下半年到现在完成react技术栈的所有业务模块的拆分和重组；
这次的整体技术架构升级是我认为从 umu web arch 1.0 进入到umu web arch 2.0，当然我们还一些业务近两年没有做技术的重点升级，比如小程序，会议客户端，大屏幕，h5和和客户端融合等，不过随着业务的发展，这些技术也会很快迎来重点升级，有些是规划中，有些待落地中，但是整体i18n的推进都为这些事情打下技术架构和组织建设上的基础；web arch 2.0 相对于umu web arch 1.0，会给我带来什么呢？@duanjun在周报曾经从技术角度阐述过，我今天拾人牙慧，从技术，产品和团队的结合点再重述一下：
1 推动无感知的持续发布的完善
大家都知道，2021年我们基本实现了百度云到腾讯云的切换，这个过程不仅仅是功能资源转移个地方，devops和前后端都在这个项目中对不合理的，不清晰的做了不少基本的梳理，更重要的是，我们比较全面的系统的了解了云在我们这大系统中或大或小的各种依赖，以及我们所面对的一些基本性的问题，比如在私有化可能会遇到的问题，我们知道我们的问题所在和基本的可行性方案，其中一个就是前端的编译部署问题，i18n项目采用微应用和分布式部署的思想，基于业务领域在代码层面实现业务拆分和重组，重新设计页面静态资源的组装方式，静态资源全部上传cdn， 模板全部node化， 使得发布单元更小更可控，可以针对某一具体业务单独实现预览发布，灰度发布，比如搜索相关页面的独立预览发布，使得上线的影响范围最小化
2 逐渐解耦开发生命周期中各技术专业组的依赖
开发生命周期包括产品kickoff，设计，开发，测试，发布等主要环节，其中涉及到产研团队的各个专业小组，如，产品，交互，翻译，UI设计，前端，后端，QA，devops等，各个小组的联动现在还有较多耦合，提高效率的很重要的一个方法是减少各组的耦合，标准化各组的输入和输出，减少不必要的协作，各组专注自己的的专业能力和高质量产出。正式基于这样的原则， i18n项目集会逐渐解耦翻译和前端交互，前端和devops的交互，前端内各pod不同项目组之间的代码依赖，UI及UE和前端的交互，这个背后的逻辑是因为代码的隔离和公共组件的规范化，会减少很多样式污染 ，样式规范的不统一；通过模板node化，web端和服务端主要的依赖就是API接口了，基本实现先前后端专业技术的真正分离；
减少个专业组的不必要的协作，这样的方式也会推动各组在链接上下游的方式，收敛接触面，强化交互效率和交互深度，逐渐完善交付和结果验收的规范
3 支持Pod和业务领域全自治开发模式
模块拆分和重组为Pod机制的深入发展，提供了代码级别的支持，目前按照业务模块和基础功能的层次拆分，大概有20个大业务repo，这些repo会分到对应的pod，由具体的pod对特定的repo的业务的迭代，技术升级，质量保证负责，这些repo除了依赖公共模块，相互之间可以独立发展迭代，解决我们业务多样化对代码的不同要求，比如基础模块可能要严格的质量，需要更深入的设计，它们可以独立发布部署，不要依赖整个项目的上线发布，有些模块需要一些更敏捷的做法，可以灵活的快速开发快速上线；不同的业务代可以使用不同的开发策略和CI/CD策略
需要说明的是，代码级别的隔离不代表权限和基础原则规范的隔离，我们目前是所有的前端伙伴，对绝大部分前端repo拥有查看和提交权限，但是要走统一的code review规范，自治是在统一的基础架构，工程能力，产品开发原则之上的；
4 面临新的问题和挑战
当然我们也会面临这个阶段的问题和挑战，比如多模块的开发发布的管理问题，基础repo和业务repo的依赖管理问题，各repo技术架构各自独立演进的问题，新业务放在哪个repo的问题以repo本身的管理问题等等，但是我也相信这些问题是我们进入umu web arch 3.0的垫脚石；未来几年Web AI，Web 3.0，元宇宙中的技术细项都会逐渐的进入我们的各项业务，我相信我们现在做的是支持它们的最好的基础；
这些重大升级的背后是公司层面对技术的无比重视，公司最早亮点产品大屏幕骨子里就透着对技术的追求和信任，我们相信先进的技术能给公司带来强大的生命力，东朔老师在2017年用户端的一次会议上，针对flutter的引入和推进就表达过这样的思想：新技术的红利会给我们带来更多的成功机会，我们要积极的推动和引入合适的新技术，用技术赋能产品，提升我们在市场上的价值及表现。我们一直是秉承这种思想，flutter，微信小程序，web客户端，nodejs，go，AI等新技术的能快速的引入和落地都是基于这个思想的指引，我们也始终以我们当下的研发能力使用当下条件允许的技术，保证整体技术不落后，重点技术有突破的节奏。其实每次重大技术升级都会面临很多的现实问题和挑战，这个过程从公司决策层到产品和研发都经历了很多的权衡，调整和困难，甚至是汗水和泪水，但是我觉得更多是不懈奋斗的意识，任何从0到1的事情，没有奋斗是绝对完成不了的，从14年到现在我们不断的通过这样的奋斗过程实现了技术上层层升级，公司的可持续发展，未来随着公司业务规模的不断增长，这种升级会越来越有挑战，只要我们坚守这种思想，立足当下，着眼未来，一定能实现技术和产品的可持续同频发展。