一年一度的万圣节即将来临，如果大家希望让自己的软件开发者好友们真正感受到恐怖气氛，那就别再搞女巫、鬼魂或者连环杀手那种俗套伎俩了——下面这些状况绝对会把他们吓得魂不附体。
互联网无法回答我的问题
以Stack Exchange为代表的开发者常见问题解答网站已经成为技术从业者们不可或缺的重要资源储备与依赖对象。当然，也有不少其它问答网站及开发者论坛能够帮助软件开发人员解决自己在编程过程中遇到的具体问题。但在少数情况下，开发人员可能仍会遇上那种令自己全身冰冷的可怕状况：网络上看似无穷无尽的编程知识储备依旧没办法解答自己的疑问。
@Jorge Irun：“最可怕的就是打开Stackoverflow网站并看到一篇其他人发布的、与自己想问的问题完全一致的帖子。恐怖的是，这篇帖子已经发布一年多了，而且根本没人做出过回复。”
@Ramchand Rajasekaran：“我害怕的是StackOverFlow上的最佳答案实际上并不起作用（我们也遇上过这种情况）！”
@Steve Traugott：“在谷歌上搜索能解决架构难题的方法，却发现找到的相关信息已经是六年之前的、描述的问题完全相同——而且就是由我自己发表的。”
最重要的键盘按键损坏或者丢失了
不用说，键盘在程序员的日常生活当中扮演着非常重要的角色。但是，并非键盘上的每个按键对于开发人员来说都拥有或者能够创造同样的价值。一部分按键的使用频率要明显高于其它按键，具体情况则视编程语言的类型而定——例如在JavaScript、Perl以及Objective-C当中，分号就意义重大。程序员们还喜欢大量使用快捷键操作，利用这些组合来代替相对繁琐的键盘、鼠标或者触控板操作不仅能够节省时间、也可以避免多次重复动作带来的关节劳损。有鉴于此，我们就能想到当开发人员梦见键盘上一个又一个心爱的按键消失不见、并因此带着一身冷汗从床上惊醒时，内心该有多么恐慌与绝望。
@Ali Akbar：我做过的最可怕的噩梦就是自己的分号怎么按都不起作用。”
@Vivek Patel：空格键失灵”
@Nikesh Shetty：“正在编写一套规模庞大的代码项目，然后突然发现Control键没有反应了……”
@Nirwan Dogra：“CTRL+Z无法正常实现撤消操作 :( :(“
互联网失效——或者出现故障
像Stack Exchange这样的网站因为故障而无法及时应答程序员们的问题是一码事，但互联网本身整体失效则是另一码事——而且后者明显要更加恐怖，甚至足以令人精神崩溃。毕竟除了回答问题之外，互联网也塞满了其它极具实用价值的资源，例如开源软件以及代码片段等等。更不用提在没有互联网的情况下，访问远程或者云端服务器将无法实现、没办法跟分布式团队中的其他成员沟通甚至连最喜欢的流媒体音乐服务也用不了，这实在是一场深重的灾难。因此，如果大家希望真正让自己的编码好友吓一大跳，那就得找点确实震得住他们的理由——例如“互联网挂了，什么网站都上不去了！”对了，如果朋友们因此吓得口吐白沫，记得帮他们擦一擦。
@Mahanthesh Shadakshari：“StackOverflow网站当前正处于停机维护当中。”
@Anonymous：“谷歌服务器陷入永久停机状态。”
@Thoriq Firdaus：“如果互联网与谷歌都没法用了，我们就只能回到过去那个闭塞而恐怖的‘黑暗时代’。我们会被困在原地，不知道在遇上特定问题之后应该如何处理。”
@nanda：“说真的，如果互联网本身崩溃了，那么开发人员们肯定会停止手头的工作并开始闲聊家常。哦我的天哪……这太可怕了！”
一个无法重现的严重漏洞
为了修复一项漏洞，软件开发人员们首先必须有能力在开发或者测试环境中重现引发这一问题的状态。接下来，大家就只能碰运气、希望引发问题的根源能在影响到生产系统之前被诊断出来并在重复测试中不再出现。很多开发人员最害怕的就是那些看似随机出现的漏洞，这类问题在可控制环境下几乎没办法确切重现。要让这类漏洞施展威力，大家最好是能选个最合适的时机——例如在为特别重要的客户进行运行演示之前。相信我，如果能够成功完成上述部署，各位的程序员朋友肯定吓得裤子都湿了。
@Jeremy Friesner：“……漏洞平时根本不出现，而只在当着五百多位与会者的面进行公开演示时发生。”
@Joe Wezorek：“某个无法在内部环境下重现的蓝屏问题却在某位重要客户的设备上反复肆虐。”
@Jaimie Sirovich：“某个只会在我自己的计算机之外出现的错误，而且仅仅发生在生产体系中——无法在测试环境内予以重现。”
@Ankur Agarwal：“在自己本地服务器上完美运行的程序/网站一旦上线就开始变得极不稳定。这给人的感觉是服务器像是无情地玩弄自己，而我们只能让原本兴奋的情绪沉入悲伤的深渊、同时却又无能为力。”
缺乏完善的说明文档
想在不借助完善的说明文档或者代码注释的情况下理解现有代码实在是难如登天。而如果根本不存在任何说明文档或者代码注释，那么内容理解的难度又会更上一层楼。上述情况不仅局限于接手自其他程序员的已编写代码内容，更糟糕的是他们可能是在很久之前编写出相关片段、而且当时并没有保留妥善的文档记录。这种没有说明文档可供参考的代码，无论当初是由谁编写而成的，都是一种非常恐怖的存在。
@Pratyush Kumar：“最可怕的就是在没有适当说明文档或者某些无意义标识符不提供相关注释的情况下对代码进行调试。这就像是在给别人擦屁股，简直没法忍受。”
@Sam Brody：“在项目中扮演继任者的角色最可怕，面对着糟糕的注释来解读另一位编码者的胡言乱语根本就是件不可能完成的任务。”
@Sam Sartor：“最可怕的是维护十几年前没有说明文档可供参考的代码。我在处理这类工作时确实做过噩梦。”
@Alok Sharma：“在几年后的其它项目中发现自己当初编写的无说明代码时，我简直陷入了歇斯底里的狂躁状态。‘当时我为什么要这么干？’‘这代码真是我写的？’这种感觉就像在自己家中迷了路。”
来自地狱的管理者
任何人，包括程序员或者从事其它工作的人士，都不喜欢那种喜欢干涉份外事务或者不够称职的管理者。不过软件开发人员尤其如此，他们最害怕非技术人士向他们打听关于代码的问题。管理者通常会夸大项目本身所能实现的效果，过度低估编码工作所需要的时间并做出一些能让程序员们在睡梦中都不断抱怨甚至唾骂的离谱承诺。
@randcraw：“无能的高层管理人员和无知的决策者们把自己莫名其妙的讨论结果强加给开发者。”
@Anonymous：“我最怕非技术管理者，他们总认为自己有资格来插上一脚——事实上他们关于编码的全部理解都是十几年前的老黄历。”
@Rachit Agrawal：“对我来说，最糟糕的噩梦就是那种喜欢吹毛求疵的管理者，他们总认为自己目前的职位属于大材小用、并希望在限定时间之前满足客户的任何或者全部要求。这类人总把编程人员当成奴隶来看待，而切实起效的代码应该是像孙悟空那样凭空从石头里蹦出来的。”
@RHSeeger：“我最怕的是被迫对整套系统进行重写……再次重写……而且需要使用另一种语言以及完全不同于此前的工作集/框架……一次性完成而非分阶段调整（即一次替换一部分，完成后再替换另一部分）……而这仅仅是因为一部分高层管理者认为自己想出的主意才是最好的、其他人的既定方针都是错的而且需要马上加以全盘否定。”
对其他开发者的代码进行清理
软件开发人员当然不希望处理其他人编写出来的代码; 归根结底，其他程序员的代码永远不可能像自己亲手编写的那么出色，对吧？对于刚刚接手的朋友来说，即使是拥有良好说明文档的第三方代码也足够让他们头痛一阵子的。只要听说需要对其他人编写的代码——哪怕是几个月前刚刚编写完成的——进行调试、重构或者现代化调整，程序员们往往会出现强烈的不适反应，例如心律不齐——而且很明显，这样的决定往往并不明智。
@bta“……我最怕的是老板要求我对所谓‘拥有源代码’的项目进行重写或者现代化调整，因为这种情况下‘拥有源代码’的真实含义往往是‘它是用Fortran语言在这堆杂乱无章且数量庞大的穿孔卡片上编写的’。”
@George Alexander：“……我认为程序员可能面对的最恶劣状况就是负责接手某位前任开发者的源代码——而这些代码根本没有遵循任何标准化或者最佳实践方案。”
@Giovanni Idili：“我最怕的是被要求‘从C++代码中找出某个与什么什么相关的漏洞，而实际可用的素材只是一大摞纸质记录（长达20页的代码，约有2000行命令）而非能够直接进行编译、运行以及调试的代码。 “
@Chip Frank：“如今程序员当中的主力是那些通过‘编码一小时’课程入行的菜鸟，而他们留下的垃圾最终还是得由我负责清理。”
变更项目要求
无论是采用传统的瀑布式项目管理方案还是敏捷环境下以用户为核心的实施方针，软件开发人员最需要的就是一套清晰、可靠、稳定且足以指导编码进程的项目要求。但在现实情况下，这些要求往往会在工作推进过程中出现变更——有时候是出于正当理由，有时候则仅仅是因为愚蠢的项目经理、高层管理者或者客户脑袋一热而导致。无论如何，只要出现这种情况，程序员就会身陷难以摆脱的恐慌情绪当中、特别是害怕项目结束前的最后一分钟出现要求调整。
@Basav Nagur：“就在项目进入冲刺阶段的前一天，通过电子邮件发来要求变更的通知。”
@Kunal Suri：“特别是在要求变更会对数据库规划产生影响的情况下，这实在比给人扭断了脖子更难受。”
@Yinso Chen：“一切都已经测试完毕并准备好迎接第二天的生产环境部署，这时老板通知我们原有要求出现了变更、而所有工作都得在今天之内完成。”
@Dave Cahill：“我最怕那种不知道自己想要什么偏又喜欢定期进行要求变更的客户，他们会盲目地指手画脚直到技术团队彻底崩溃。”
我的代码凭空消失了
无论开发人员在软件编写工作上花了多少时间，如果代码意外消失、那么一切努力都将付之东流。源代码可能出于各种各样的原因而在转眼间灰飞烟灭，包括忘记正确保存文件、某些特别恶劣（也特别残忍）的漏洞以及命运的无情捉弄。无论是何种原因所导致，也不管开发人员多么小心谨慎，事实上程序员们一直生活在恐惧当中、害怕自己长期以来用心经营的工作成果在瞬间消失无踪。
@Philan James：“由于突然停电或者个人疏忽而导致辛苦编写的代码就此丢失。”
@Simon Hayes：“当大家意识到这一点时，糟糕的代码管理习惯已经导致运行中的程序被从文件系统里彻底擦除（也可能还影响到了与我们工作相关的其他开发人员的编码成果）。”
@Sakthi Prasad：“我最怕的是自己急于重启系统，而在面对IDE给出的‘尚有未保存的工作，您是否希望将其保存〈是〉，〈否〉’提示时忙中出错。虽然我们的脑子里想的肯定是〈是〉，但自己的手指有时候会已经点上了〈否〉——这让人恨不得直接把它给剁了。”
@Ayush Sekhari：“我最怕的是在错误的目录当中输入了rm –r *。然后就没有然后了。“
IE浏览器
所有的程序员都有自己最畏惧、最没自信的技术领域，但Web开发人员在这方面的感受却更强烈也更直接——那就是对于在IE浏览器上构建项目的反感甚至抵触。尽管仍然属于目前人气最高的浏览器方案之一，IE同时也成为众多代码编写者的口诛笔伐对象。更糟糕的是，IE旧版本不仅问题更多、让人抓狂的是偏偏还拥有更为庞大的用户群体。为此，开发人员不得不将其纳入支持列表，而且其支持周期往往比其它更具开发者友好特性的浏览器更长。我们不妨打这样一个比方：如果《黑色星期五》电影中的杀人狂杰森想要把一队Web开发人员吓得魂不附体，那最好是在自己的冰球面具上贴一张IE的标志。
@Cem Kaan Kösalı：“最可怕的是：客户使用IE浏览器！”
@Thoriq Firdaus：“开发人员要让自己的Web应用程序能够顺利运行在IE 6浏览器上，花费的时间往往达到为Chrome或者火狐等其它现代浏览器开发应用时的四三倍以上。”
@Arvind M.Raman：“我最怕的是在普通代码已经能够在人类已知的全部其它浏览器上正常运行时，仍然需要利用HTML、CSS以及JavaScript为其编写IE 8特殊版本。”
@Madhu Agrawal：“我最怕的是在只安装了IE浏览器的Windows环境下进行开发工作……需要处理的问题太多了……”
受伤或者生病
编程其实并不是那种对体力要求很高的工作，但与其它大多数需要整天在电脑上敲击的职位一样，如果胳膊、手掌或者手指出了问题，工作也就很难顺利进行了。此外，编程人员的视力与逻辑思考能力如果受到了影响，也会对日常工作造成严重不便。考虑到以上情况，典型的软件开发人员自然也会在噩梦中遇到对应的状况，即自己身体的某个或者某些部分不听使唤、因而没法完成开发任务。
@Aitjcize：“……我最怕的是手指割破了或者眼睛看不见了……那样就没法再写代码了。”
@Daniel Super：“我最怕自己的大脑出现了某种严重的病变，这样我就没办法像原先那样流畅地进行思考、但却又保有自己聪明睿智时的相关记忆——简直太痛苦了。”
@Matt Nicolls：“我最怕腕管综合症、肘管综合症以及其它任何可能让自己没法用手的病变。”
@Kelly Draper：“早上一觉醒来却发现有人在夜里把我的手指给偷走了。用胳膊肘打字真的很费劲。”
我在开发中遗留的漏洞造成危害甚至夺人性命
相信没有哪位软件开发人员希望自己打造的成果当中存在漏洞。当然，也不是所有漏洞都会带来恶性后果——其中一些虽然有点讨厌，但却没什么危害。而有一些则有可能会给企业或者客户造成经济损失，甚至导致相关人士丢掉工作（例如需要为其负责的编程人员）。而程序员们最不想看到的就是，自己所构建的软件方案在实际运行中给用户带来身体伤害甚至夺人性命。
@Kjetil Seim Haugen：“我最怕的就是自己目前正在开发的天然气钻机控制系统出现问题……”
@Jeremy：“我最害怕的是自己软件中的漏洞给其他人造成身体伤害。”
@Mark2008：“我能想到的最严重后果就是某人所编写的交通指示灯程序没能正常起效，由此导致的车祸则造成重大伤亡……又或者某些医学扫描仪辐射量控制不当而致人死亡……包括某些军事GPS系统错误地将飞行员指引到了敌方的空中火力覆盖网之内……”
@Jon Kannegaard：“我最怕的是软件漏洞夺人性格——这种情况之前确实发生过。”
段错误
开发人员的另一大常见噩梦是在运行中发现段错误。这类错误通常是由内在访问冲突所造成，即程序试图访问受限内存或者执行受限操作。一般来讲，这类情况下内存管理单元会向操作系统发出通知，而操作系统往往会反过来向相关进程发出通知并最终导致程序崩溃——而这无疑会令那些尝试找到问题原因的开发人员们倍感头痛。有鉴于此，难怪很多程序员最担心的就是在自己的屏幕上看到这几个字了。
@Samantray：“段错误是最最恐怖的噩梦！” Supratim
@Zeina Shajahan：“除非运行调试工具，否则这类问题可能由上百种原因导致、而我们根本搞不清状况。”
@Gomathi Sunder：“‘段错误。代码已转储。’当我们不小心使用了错误的指针并导致这类问题时，心中像是有无数羊驼奔腾而过。”
@Gaurav Jain：“任何错误都能由经验丰富的程序员在几分钟之内修复完成，但段错误或者无用循环则不行……愿程序员安息！”
网友评论