【工作中最大的难点是什么？】这是一个非常好的用于自评的问题。通过这个问题可以对自身的项目经验、问题解决能力、团队协作能力、态度与价值观进行反思，寻找到潜在改进点。
我在工作中的最大难点核心是三个字：不兼容。包括：规范不兼容、组件升级不兼容和设备不兼容。
规范不兼容
规范不兼容最难办，因为会涉及到与外部客户、合作方或者用户的规范。所以稳定是规范的最重要职责之一。它一般对扩展开放，对修改关闭。就是说新添加内容可以，不要影响现有的使用。
墨守成规最安全，改革会有巨大风险。但是固步自封可能会慢慢走向衰落，大刀阔斧会开辟新的生机。所以有时候不兼容的大修改也是避不开的。
这时候一般的做法是在规范中引入版本号的概念。比如V1.0和V2.0，提供服务方自己去做适配维护两套，长期共存，直到老版本无用户使用。这会付出巨大的代价。比如在《监控系统怎样做？》里提到的两码一态，这种规范会带来巨大的收益，但是如果之前使用的是一码一态（返回值里只有1个状态码，有可能是系统状态也可能是业务状态），那就涉及监控系统要兼容两套，也有成本。所以做不做这种大升级也和公司所处的阶段以及对未来发展的预期有极大的关联。
组件升级不兼容
K8S近十年来做了很多大的升级，维护人员虽然每次升级都很想跨版本升，但是出于兼容性的考虑还是一个版本一个版本的升级。尽管如此，每次升级都是一个巨大的风险。某滴升级时出现问题导致晚高峰打不到车是一个血淋淋的例子。
这是技术上的问题，相比规范的不兼容还好解决。可以通过充分的线下测试、充分的场景覆盖来规避。像K8S升级这种可能涉及全公司，是需要各个部门来配合进行线下验证的。如果是大规模的公司，全公司的应用数可能在十万级别，每个应用的问题都暴露出来几乎是不可能的。这就要考验架构师的功力了。
首先架构师要梳理全公司所有应用的特性分类：比如普通无状态的spring业务，有没有哪些业务有特殊性；公司还维护着很多组件，这些组件怎样分类，是否需要测试时全覆盖到。
测试阶段需要和各个使用方做好沟通：是使用即时通信，把每个部门都选代表进行信息同步还是什么机制？
升级阶段为了保证稳定，要一个K8S集群，一个集群的升级，升级期间和升级后需要使用方做好观测和业务巡检。
公司规模大的话，升级4个月搞定就不错了。
设备不兼容
在前端开发中，遇到的不兼容问题主要包括浏览器兼容性问题、操作系统兼容性问题以及应用在不同设备和平台上的兼容性问题。这些问题可能会影响到用户体验和应用的正常运行，因此解决这些兼容性问题是非常重要的。
浏览器兼容性问题：
字体大小调整：在移动端设备上，需要根据屏幕尺寸调整字体大小。解决方法是使用rem等相对单位来设置字体大小，并在页面加载时动态计算rem基准值1。
1px边框问题：在高分辨率的移动设备上，1px的边框可能会显得过于粗细。解决方法是使用伪元素和transform来实现0.5px的边框1。
操作系统兼容性问题：
iOS端兼容input光标高度：在安卓手机上显示正常的input输入框光标，在苹果手机上可能会与父盒子的高度一样，导致视觉效果不佳。解决方法是通过调整高度和行高，使用padding来撑开内容2。
应用兼容性问题：
非SDK接口使用：在Android开发中，直接使用底层的非SDK接口可能会绕过一些安全和隐私保护，且可能在新的Android版本中无法运行或产生不符合预期的行为。建议仅使用Android SDK中的公开接口进行应用开发，以保证未来的兼容性3。
解决这些兼容性问题的方法包括但不限于使用响应式设计、兼容性更好的代码实践、以及及时更新和维护应用程序以适应新的设备和系统要求。此外，跨浏览器测试和模拟不同设备和操作系统进行测试也是确保兼容性的重要步骤。
设备不兼容总体就一句话：具体问题具体分析。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
