P7将计费模块代码写成天书防裁员？聊聊职场生存与LR字符串交换算法

刚看到一个帖子，内容挺有意思：说一个P7级别的工程师，为了防止被裁员，把团队里核心计费模块的代码写得像天书一样，还自己加了一堆混淆逻辑。更绝的是，代码从不提交到 Git，只在生产服务器上保留一份。他觉得这样一来，公司就不敢动他了。

结果呢？CTO直接招了个外包团队，花了两个月时间把他的模块重新开发了一遍，并行运行验证无误后，当天就让他走人了。赔偿金还是按最低标准给的，理由是抓住了他“违规操作生产环境”的把柄。

这件事吧，我琢磨了一下，本质上可能不是技术问题，而是心态问题。你把核心系统当成人质，老板自然就会把你视为最大的风险源头。技术人的安全感，真的不应该来自于“只有我懂”，而应该来自于：就算别人能接手，也知道我做得既专业又靠谱。

换个角度想，真正有本事的人，敢把文档写清楚、流程跑规范，让谁来接盘都觉得轻松。说到底，职场最稳的护身符，从来不是“别人离不开你”，而是“你走到哪儿都有人要你”。这个话题在关于职场规划与面试技巧的讨论里也常常被提及。

面试题：在 LR 字符串中交换相邻字符

昨天晚上十一点多，我还在公司楼下抽烟，组里的小李突然发微信问我：“哥，这题我看着简单，怎么一写就错啊？” 我一看题名就乐了，“在 LR 字符串中交换相邻字符”，对吧？

规则就是 XL -> LX 和 RX -> XR 这两种交换，你可以想象成L和R是两个人，X是空位，只能在空位旁边“挪动”。写起来感觉像是在挪人，一不小心逻辑没理清，就跟把人挪穿墙了似的。

这题最“坑”的地方在于，很多人第一反应是去模拟交换：循环找 XL 就换、找 RX 就换，直到字符串不再变化为止……你还别说，真有人这么干。然后线上直接卡死，字符串一长，日志里疯狂刷屏，CPU嗡嗡作响。

其实仔细想想，规则已经把“方向”锁死了：L只能往左挪（因为只有XL -> LX），R只能往右挪（因为只有RX -> XR），X就是那个让路的空位。你模拟交换，本质上是在用蛮力做“位置约束检查”，效率自然低下。

所以我一般这么跟新人说：别盯着“交换”这个动作看，要看“人是谁”和“人能不能到那个位置”。

第一步，先看“人”的顺序。把字符串里所有的 X 都去掉，剩下L和R的顺序必须一模一样。不然你怎么换，都不可能把一个 L 变成 R，对吧？比如 start 去掉X是 LRR，end 去掉X是 RLR，那直接可以判死刑，不用再折腾了。

第二步，才是关键的位置约束：同一个字母在 start 里的位置和在 end 里的位置，必须符合它的移动方向。

• 如果是 L，它只能往左走，所以它在 start 里的下标必须大于等于它在 end 里的下标（先在右边，才有机会往左挪过去）。
• 如果是 R，它只能往右走，所以它在 start 里的下标必须小于等于它在 end 里的下标。

就这么两条规则，基本就把这道题拿捏死了。实现上，我习惯用双指针。两个指针分别在 start 和 end 字符串上跑，遇到 X 就跳过，对齐到真正的 L 或 R 字符时，再进行比对和方向判断。这是一种在处理序列比对问题时非常高效的算法技巧。

下面是我常用的一份Java实现，代码不长，思路也清晰：

public class SwapAdjacentInLRString {
    public boolean canTransform(String start, String end) {
        if (start == null || end == null) return false;
        if (start.length() != end.length()) return false;

        int n = start.length();
        int i = 0, j = 0;

        while (i < n || j < n) {
            // 跳过空位 X
            while (i < n && start.charAt(i) == 'X') i++;
            while (j < n && end.charAt(j) == 'X') j++;

            // 两边同时走到头，说明都对齐完了
            if (i == n && j == n) return true;
            // 只有一边到头，另一边还有 L/R，肯定不行
            if (i == n || j == n) return false;

            char a = start.charAt(i);
            char b = end.charAt(j);

            // 人都不是同一个了，还变啥
            if (a != b) return false;

            // 方向约束：L 只能左移，R 只能右移
            if (a == 'L' && i < j) return false; // L 不能从左往右跑
            if (a == 'R' && i > j) return false; // R 不能从右往左跑

            i++;
            j++;
        }
        return true;
    }

    // 你要本地跑一下就加个 main，别老用脑补…我以前就爱脑补，翻车多了
    public static void main(String[] args) {
        SwapAdjacentInLRString s = new SwapAdjacentInLRString();
        System.out.println(s.canTransform("RXXLRXRXL", "XRLXXRRLX")); // true
        System.out.println(s.canTransform("X", "L")); // false
    }
}

这段Java代码干了三件事：一边跳 X、一边对齐 L/R、最后用下标关系卡死方向。很多人会忘了“去掉X后顺序一致”这个本质，但我们这里的逻辑其实隐含做了检查：因为每次对齐都要求 a == b，一旦两个字符串去掉X后的顺序不同，在某个对齐点就一定会对不上。

还有个常见的思维误区顺嘴提一下：有的人拿计数器统计 L 和 R 的数量，觉得数量一样就行。这不行，顺序错了也不行。就像排队，人数一样不代表你能把张三换成李四站到那个位置上。

总之，这题你把它当“交换题”就容易写成低效模拟，把它当“约束题”来解就很顺畅。算法复杂度是 O(n)，字符串再长也不怕。行了，我先不说了，刚刚外卖到了，再聊下去面又该坨了……