哪些程序员圈的幽默段子至今仍让人忍俊不禁？

这段代码是可以正常运行的, 但是至今还没有人能够解释清楚它到底是因为什么原因才跑得通的。

// 这段代码能跑，别动它。

// 我不知道为什么能跑，你也不知道。
// 如果你改了它，然后它不能跑了，
// 那就是你的问题了。

在每个项目里面, 都存在着这样的一小段代码。这些代码是由之前的维护人员所留下的。在它们的注释上面写着“不要触碰”这句话。你充满好奇心地修改了其中的一行。

结果导致整个系统发生了崩溃的现象。你尝试把它修改回原来的状态, 可是它依然在崩溃着。你利用 git 工具将其还原到之前的版本, 但是奇怪的是它依然在崩溃着。

最后经过查实, 是因为你在进行修改操作的过程之中, 不小心多按键了一个空格字符, 进而触发了存在于某个特定的内部设置项之中的针对制表符或是空格的敏感性检测规则。

99 bugs in the code

在墙面上贴着内容, 上面写着有九十九个程序错误在代码中。

进行了一次修补动作。

那个墙面上头, 最后显示出来的情况, 变成了这样一句话: 127 bugs in the code。

注释比代码更漂亮。

// 致未来的我：对不起。

// 当我写这段代码的时候，只有上帝和我知道它在干什么。

// 现在只有上帝知道了。

// 这不是我写的。

// 好吧，是我写的。
// 但那是凌晨三点。

// TODO: 修复这个 bug

// 这条 TODO 写于 2014 年

// 如果这段代码能正常工作，那是 John 写的。

// 如果不能，我不知道是谁写的。

// 我不确定这段代码为什么能工作，但它确实能工作。

// 如果你正在读这段注释，说明你已经被分配来维护这段代码了。
// 我很抱歉。

最后这一条语句, 我在三家不同企业的工程里面都碰到过, 其中的表达方法简直是一模一样的。这说明了某种可能性, 要么就是由同一个写作者所创作, 要么是程序人员的无可奈何的情感存在着共通性。

面试造火箭，入职拧螺丝

在参加求职面试的这个时间段里。

要求使用者用手写的方式来展现一棵红黑树的结构, 描述在TCP三次握手过程中每一个数据包所经历的状态变化, 以及解释JVM的G1垃圾回收器在进行内存划分时所采取的具体的策略。

入职之后：

这个页面的按钮的颜色从#改成了#。接口返回的JSON里面name字段的值改空了。导出Excel的功能里增加了一列数据。

面试官当初问你是不是具备制造航空母舰的能力, 等你真正成功入职之后呢, 却被安排去食堂里负责给大伙打饭。

在处理代码缺陷的过程中, 经历五个不同的阶段。

这与悲伤五阶段的进程是完全一样的。

对方予以否认, 声称那个bug是不可能存在的, 并且强调代码逻辑并没有什么问题。

愤怒: “好吧, bug 确实存在, 但这并不是我的代码所带来的问题。”。

关于这一问题的讨价还价, 其观点是代码方面存在问题, 不过这个漏洞应该是不可能在线上环境中被触发的吧。

抑郁症患者痛苦地认为, 这一代码缺陷在正式运行环境中, 每个自然日内被激活一万回之多。

表示我已经把它给修理完毕了。

然后到了第六阶段, 在修好之后却又出现了三个新的bug, 这让大家又回到了否认的状态。

程序员黑话翻译

这句话的意思其实就是, 这完全是你自己的电脑出了问题, 属于你个人那边的情况, 跟我这边是没有关联的, 与我没有什么关系。

之后, 出现了这样的情况, 导致这句话变得不太灵验了, 具体体现为, 你的电脑所运行的系统和服务器所运行的系统使用的是同一个镜像文件, 因此不要再寻找任何借口来进行辩解。

这个功能下个版本再做, 这句话等于说这个功能永远不会做。

代码这部分工作已经全部结束了, 接下来只需要进行最后的测试环节就可以了。

所谓的“五分钟就能搞定”, 实际上需要消耗五个小时的工作时间。倘若这句话是在周五的时候被说出口的, 那么预计的完成节点就会顺延至下周三。

我打算对现有的内容做一次重新构建, 这通常意味着先把那些目前还能顺利运行的代码部分进行修改, 使之无法继续运行, 然后投入大概三天的时间去把修复好的逻辑还原回去, 最终达到的效果其实是和最初的状态完全一致。

从技术角度来看, 这个需求是可以被实现的, 不过, 由于我主观上并不愿意去执行这项工作, 因此整体效果等同于无法完成。

编程语言群聊

那位 Java 程序员讲, 我们这里拥有相关的技术储备, 同时还具备非常齐全的生态环境体系。

那位搞编程的技术人员讲了一句话, 他说他写的一个单独的行代码能够起到完成对方十行代码所发挥的作用。

Go语言的程序员说道: “我编译的速度快, 而且部署也很简单。”。

那位玩 Rust 程序的从业者, 他讲的话意思是你们的程序代码上面存在有内存方面的安全隐患问题。

C程序的开发者说道, 你们的这些应用程序都是依靠由我所编写的语言所对应的运行环境来执行的。

那位汇编程序员说: “你们这些人都是菜鸡。”。

关于机器码程序员, 其内容显示为 00 01111。

那位干 PHP 编程工作的工作人员, 在把群聊给退出去之后, 人就已经离开了。

时间估算

产品："这个功能要多久？"

这是程序员在心里所进行的估算, 其大致的数值表现为两天这个时间长度。

程序员嘴里头所说的那句话是这么个情况: “一个星期。”。

这事情实实在在花出去的时间, 就是三周的长度。

在业界流传着一个大家都认可的常识性说法, 那就是程序员预估的时间跨度要是真的实施起来, 得先乘以 3 才能得到真正需要耗费的实际时间量。要是程序员那边随口说了一句很快, 那经过这个换算之后的实际观感就变成了不太快。

要是程序员提到项目有点复杂, 那乘以 3 之后就意味着基本上都做不完了。要是程序员明确表示做不了某个事情, 那经过同样的处理之后, 结论依然就是这件事确实没办法完成。

永远不会执行的代码

if (false) {

    // 这段代码永远不会执行
    // 但是删掉它系统就崩了
    // 别问为什么
    launchNuclearMissiles();
}

你虽然笑了, 但是你的项目里面肯定是存在的。你不敢进行删除的操作, 因为你不确定是否存在某些反射机制、字节码增强技术, 又或者是一些神秘的代码片段, 会在工作的时候把 False 这个值改为 True。

is-odd

在 npm 那个地方呢, 有存在着名为 is-odd 的这样一个软件包, 这个软件包它的主要一个功能作用, 它就是在于用来进行判断, 某一个给定的数字, 到底是不是奇数, 这个软件包的每周下载量次数, 它是达到了几十万次之多。

它依赖了名叫 is-的这样一个包, 这个包的用途是用来去判断输入进来的内容到底是不是数字, 在早期的那个版本里面, is-这个包还依赖了其它的一些额外的包, 有一个用来判断奇数还是偶数的函数, 这样的函数的依赖链条会有好几层那么深。

有人把这事儿说成是生态的笑话, 但你要是看过 is-的源码就会明白, 在 里面判断一个值是不是数字, 这件事真的没有表面看起来那么简单, 这里面牵扯到了 NaN, “123”, null 等一系列复杂的判定情形。

所以这到底是笑话, 还是本身就是笑话。

买鸡蛋

一位已经离开了工作岗位的程序员, 在他的配偶的建议之下, 被指派前往超级市场去进行购物的活动。

你需要去买一斤鸡蛋, 另外如果看到了西瓜的话就顺便买两个。

程序员这个人吧, 他购买了两个鸡蛋, 然后把这些东西就带回来了。

为什么只购买两个鸡蛋, 而不是更多?

原因就是有西瓜的。

if (有西瓜) {

    买(鸡蛋, 2);
} else {
    买(鸡蛋, 1斤);
}

那位负责写代码的人他一点错误都没有, 真正的问题在于那一份用自然语言写成的规格说明文档写得太过糟糕, 简直没法看。