maichael

“在大厂 MySQL 是不能用 Docker 的，为什么？”

关于这种已经带了立场且缺乏上下文的面试题，首先是不要带上你自己的立场去评判它正确与否，你应该做的是合理到位的去阐述你的观点。

无论是面试官还是被面试者也好，都应该知道这不是一道判断题，没有标准答案可言，在不同的环境、需求下会有不同的答案。

所以对于被面试者而言，你应该做的是结合你的经验、理解去阐述清楚，什么时候能，什么时候不能，为什么能，已经为什么不能等。

而对于合格的面试官而言，不应该去纠结被面试者回答的是能或者不能，而应该通过被面试者的回答来评估被面试者的逻辑思维、技术理解深度等方面的能力。

另外，对于被面试者而言，一定不要在面试中全程跟着面试官的节奏走，要大胆的打破节奏，表现出你的能力，面试是个动态的互动过程，不是应试做题，不要限于条条框框。

关于这类工具更换的调整动作，只有两种方式有可能成功完成：
1. 强制更换，忽略任何反对意见
2. 大多数人达成共识，逐步替换

2 这种方式要做的事情很多，首先要换位思考一下，换做是你，这种可得的利益/收获不明显（在他们看来），迁移的代价又不小的事情，如果不是你自己推动/有份推动的，你会很情愿去干吗？

所以，在没法强制推行的前提下，领头/推广的人一定要做好布道的工作，让大家理解迁移的好处；然后要建立好方案、HowTo 、Sop 等，降低迁移的麻烦程度，减少大家对这件事情的反感；甚至还可以通过人际关系来拉拢，等大多数人都接受并且执行了，这件事情也就差不多完成了。

倒是有 bridge 的开发经验

优点就是快，其它都是次要的，对于那些后端业务很轻的应用，AI 的加持下，几天就能搞完。

站在你的角度上的建议：
1. 通过增加单元测试覆盖率要求来减少测试人手这一大目标注定会失败。
2. 既然注定失败，那么你可执行的方案有两种：
2.1. 想通过写单元测试来提高代码质量，完全遵循 TDD （可选），并且编写有逻辑，有思考的“白盒测试”
2.2. 放弃通过写单元测试提高代码质量的想法，面向测试覆盖率编程，编写一大堆毫无逻辑，不用思考，全面覆盖的测试。
3. 可以通过 AI 去先提高代码的可测性/找到一种绕过当前测试困难的方法
4. 先有一个测试案例，然后告诉 AI 参考该案例来编写测试就行

我一般是 40ML/110ML+致死量的冰/冰水，也可以加奶球，你根据你自己的口味调一个合适的比例就好。

直接在交易所换成 SOL 充到你 Solana 地址不就好了

搁这写散文呢？