关于战略架构框架的思考
在做架构设计的过程中,我们经常会提到一个概念——“标准化”。标准化,通过设定最佳实践和创建统一的标准,确保企业在所有业务领域中实现一致的性能。然而,当我们完成了标准化之后,我们应该怎么做呢?下一步又是什么?是否存在一个通用的框架,能够指导架构师和技术负责人进一步优化和发展?经过一番思考,这个框架在我脑海中变得逐渐清晰——从「规范化」到「标准化」再到「平台化」的三段式进阶模式。
在做架构设计的过程中,我们经常会提到一个概念——“标准化”。标准化,通过设定最佳实践和创建统一的标准,确保企业在所有业务领域中实现一致的性能。然而,当我们完成了标准化之后,我们应该怎么做呢?下一步又是什么?是否存在一个通用的框架,能够指导架构师和技术负责人进一步优化和发展?经过一番思考,这个框架在我脑海中变得逐渐清晰——从「规范化」到「标准化」再到「平台化」的三段式进阶模式。
I was at Amazon for about six and a half years, and now I’ve been at Google for that long. One thing that struck me immediately about the two companies – an impression that has been reinforced almost daily – is that Amazon does everything wrong, and Google does everything right. Sure, it’s a sweeping generalization, but a surprisingly accurate one. It’s pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn’t let me show it to anyone, even though recruiting loved it.
随着移动互联网的普及,移动应用逐渐成为人们生活中不可或缺的一部分。为了满足用户对于高品质应用的需求,移动工程师们在不断探索如何提高开发效率、降低开发成本的同时,实现更好的用户体验。本文将从移动应用开发的角度,从 UX 一致性和研发效率出发,探讨设计系统的重要性及其最佳实践。
在前一篇 Kotlin 填坑记之 FunctionReference 中有提到关于如何解决 Kotlin 从 1.3 升级到 1.5 时由 FunctionReference 引发的兼容性问题,其实,Kotlin 的兼容性问题远不只这一个,如何系统性的解决 Kotlin 的兼容性问题呢?
在 Booster 4.15.0 之前,一直使用的是 Kotlin 1.3,之所一直用比较低的 Kotlin 版本,主要的原因还是考虑到 Kotlin 版本的兼容性问题,但要支持 AGP 7.3 就不得不升级 Kotlin 版本,因为 AGP 7.3 就依赖了 Kotlin 1.5,所以,Booster 4.15.0 花了很长的时间来解决兼容性的问题。
最近看了很多工程师写的文档,发现工程师们普通存在的问题,要么通篇都是文字一个图也没有,要么技术规划全是一堆的 task,根本看不清楚这些 task 跟整体的目标是什么关系,等等,即便是高级工程师,有类似问题的也大有人在。
最近有同学问我:“森哥,有什么值得一读的好书推荐吗?”,我抬头扫了一眼书架,还别说,值得一读的书还真不少,还是先从经济学开始吧,为什么会先推荐经济学相关的书呢?相信很多人都听过「天下熙熙皆为利来,天下攘攘皆为利往」,可以说人类的所有一切活动都可以用经济学的原理去解释,搞清楚了经济的本质,就搞清楚了这个世界是如何运行的。
Booster 又双叒叕发布了新的版本—— v4.13.0,本次更新内容如下:
ShadowScheduledThreadPoolExecutor
在 Android 5.1.1 及以下版本的兼容性问题