#工程思考

7 篇文章

系统可维护到底指的是什么

在美团一些大型业务开发中,经常会出现大家觉得系统维护不下去了,一个反复被提及的词就是代码复杂度高。但是后台业务确很少有类似的声音,其实后台业务的复杂度也不低,但是为什么会有类似的情况发生呢,其实我认为对是否可维护不完全是客观的,比如考虑以下几个 case 有人接手前人的项目后,会觉得可维护性差,然后进行重构工作,但是…

小程序工程化思考

和传统工程化对比 先看下传统前端工程化关注的事情 (from umi) image.png image.png 小程序可做的就相对很少,源于技术本身的约束性,我们做一个对比: 框架角度:目前市面上有 kbone,taro,remax/r2m,mpvue,mpx等等选择,从优选业务场景覆盖的移动设备角度看均有明显的体验…

系统可维护到底指的是什么

引言:可维护性是主观的还是客观的? 在大型业务开发中,经常听到这样的声音:“系统维护不下去了,代码复杂度太高了!” 但有趣的是,后台业务很少有类似抱怨,尽管它们的复杂度也不低。这让我开始思考:可维护性到底是主观感受还是客观标准? 考虑以下几个常见场景: 接手他人项目:新人觉得前任代码不可维护,要重构;但前任开发者当时…

关于基建工作的思考

基建工作本身 业务中做基建很难,美团现在对技术的态度基本就是做事必先谈收益,但是这个以客户为中心的思想其实对于做基建的同学来讲来说并不是那么合适。这样做事情会有以下的问题: 从归纳出发建设:在业务上线后我们根据已有的情况进行归纳,然后提炼出来一套方案其实这时候已经太晚了,基建同学会成为一个为业务腐败的代码擦屁股的人,…

什么是耦合(共生),什么是内聚

为什么需要理解耦合和内聚? 在架构设计讨论中,“高内聚,低耦合”几乎是所有人的共识。但在实际项目中,我发现很多同学对这两个概念的理解还停留在朴素认知层面: 对耦合的误解:认为任何依赖都是不好的,要尽量避免 对内聚的模糊:知道要”高内聚”,但不知道如何衡量 实践中的困惑:不知道什么是合理的耦合,什么是不合理的耦合 最近…

关于基建工作的思考

技术债务评估 对于技术债务,它的利息表现为系统的不稳定性,以及由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断攀升的维护成本。 —— 《架构师应该知道的 97 件事》 如 Robert Nord 提出的 “技术债务全景图”(Tech Debt Landscape) 所示: 技术债对于软件的影响:可维护性(M…

微前端思考

引言:为什么需要微前端? 在前端工程化快速发展的今天,单体前端应用面临着越来越多的挑战: 团队协作问题:多个团队在同一个代码库中开发,代码冲突频繁 技术栈限制:整个应用必须使用相同的框架和技术栈 部署耦合:一个模块的变更需要整个应用重新部署 维护复杂度:应用规模增长带来的复杂度呈指数增长 这些问题的本质是什么?集成、…