没完没了的大会小会、啥也不懂的直属领导、流于形式的生产指标——正是这冠冕堂皇的一切扼杀了无数即将诞生的伟大软件。
十五大编程生产力杀手
产品本来昨天就应该搞定出炉。用户们怒吼着质问为什么其中尚存在功能缺失。老板的老板表示你们这帮开发人员***快点行动，不然就准备滚蛋。总之，一切似乎都在朝着最坏的可能发展。
每个人都希望代码都像消防带里的水一样倾泄而出、酣畅淋漓，但却没人愿意为开发人员提供他们完成工作所需要的一切。没错，那些要求提前搞定工作的老板从来不愿意多顾几位技术员工、采购性能更强的设备或者作出哪怕一丁点有利决策，从而帮助程序员们简化工作流程。
在今天的文章中，我们将一同回顾十五大横亘于程序员面前的障碍。由于采用非正式调查形式，因此我们轻松得到了开发人员们的心声——带着同情之心与他们交谈，一切不快与委屈将不再是秘密。
1. 开会
朋友们对哪种状况抱怨最多？毫无疑问就是没完没了的会议。经过我们的调查核实，很多程序员都不得不挤在昏暗的会议室里，呆望顶头上司闲谈那些无关紧要的细枝末节。程序员们一般会把会议失败的原因归结在管理者身上，偶尔也把怨气与指责丢向其他在漏洞、功能或者架构策略上犯了错误的技术同行。
不过即使是会议确实是在讨论软件抽象世界中的深层难题，程序员们一样会对此感到不满。快餐厨师也许能够迅速应对各种不同类型的需要，但切换思维方式从而与抽象算法对接则需要预热时间——而且会议往往令正常工作受到一小时甚至更长时间的耽搁。
2. 回复全部邮件
如果说会议太多令人厌烦，那么另一种状况则更让我们难以承受：无穷无尽、汹涌而来的邮件。光是回复这些邮件就要花上几个小时，而且不过是对方还是我们自己都无法对邮件的结果表示满意。这时，开发人员们往往会以恶劣的态度回复“tl;dr”并产生某种奇特的自豪感。
某些团队正在尝试每周选择一天禁止邮件流通，另一些更加坚决的朋友则主张彻底告别邮件。这虽然解决了处理内容过多的问题，但却同时提高了通信成本。如果人们忽然之间就失去了协作的纽带，这从任何角度来看都不是什么好事。
#p#
3. 试图衡量生产指标
似乎总有管理团队盲目遵从这样一条格言，“你无法管理自己不能衡量的事物”。好吧，他们开始不断统计提交量、软件代码行或者漏洞修复数。他们以为这种数字统计就是衡量，而衡量意味着良好的结果。
不过程序员们都是出色的游戏玩家，而生产力衡量指标则成为他们的追求的分数排行榜。在这种机制的推动下，他们不再将编写优质代码作为***要务，反而专注于编写尽可能多的代码行、解决更多漏洞、***程度增加提交量或者其它任何能够被计入绩效的工作。事实证明，衡量生产力指标确实会让代码质量变得更糟——这相当于鼓励大家开发出体积庞大且塞满功能的文件，其中遍布被过度设计的代码。
对于这一难题，目前还没有切实有效的解决办法。我们需要追踪漏洞、我们需要组织工作流同时协调软件创建。这一切都是只可意会而无法言传的任务，根本不能简单用数字加以评估。
4. 过分自恋的开发者
对于程序员们来说，除了老板之外、另一类同行也是他们打压的重点——即那些创建出***一套迭代就不再负责对应项目的开发者。正如每次找来的家装设计师都会对原先屋子里的工程不屑一顾，程序员们也有能力快速发现前任技术工作者犯下的脑残失误。
事实上，程序员的表达方式几乎要比任何其他行业的继任者都更为激烈。这往往与两代技术人员的技能水平无关，他们只不过偏好不同的开发风格，而且随着时间的推移、风格也会有所变化。上一代程序员可能并不具备我们当下所拥有的代码库，也并不了解如今已经成为***实践的解决方案。
这种极度自恋、抨击他人的态度会拖慢项目进程，因为他们会由于冲动而丢弃大量代码、从而按照自己的想法“从头开始”重新构建整个项目。
5. “稍后修复”心态，或者叫“技术债务”
在项目开发工作当中，没有一天或者没有任何一个阶段能真正为我们提供充裕的时间——需要创建的内容总是多到几乎无法承受。在这样的状况下，我们往往会偷工减料、提供代码补丁并利用这种“虚拟胶带”到处修修补补。睿智的管理者会在对项目进行精密审查后将这些工作称为“技术债务”，而“债务”当然是需要偿还的。即使对编码工作一无所知，他们还是能够弄清“债务”的概念与影响。
每个项目当中都会存在一定的技术债务。有时候我们能快速加以解决，但大多数情况下这些债务会在继任者接手后才开始捣乱，迫使他们面对大量意料之外的难题。只有搞定这些遗留问题，项目才能真正顺畅运作——这有点像国债，只不过规模没那么庞大。
6. 不懂技术的管理者
大家在公司里肯定经常见到这样的家伙，他们热情、积极、面带微笑，能够在各个方面表现出友善的态度——除了与编程项目相关的计算机科学。也许他们是靠裙带关系爬上来的，或者是在正确的时间出现在了正确的地方，总之老板让他们当经理、负责技术事务——即使这帮人连自己的黑莓手机都找不着。
某些程序员喜欢这样的顶头上司，因为他们很容易会能被糊弄过去。如果大家告诉他们Johnson DB没能取得巨大成功，他们往往会信以为真并在公司里到处传播这个“不幸”的消息——这样公司高层就会出现收拾这帮外行了。还有些人发现这类管理者总爱召集会议并妨碍程序员的正常工作。他们几乎拿不出什么指导建议，最出色的发挥也就是些略有实效的质量测试。
#p#
7. 懂技术的管理者
虽然程序员们可能无法忍受与不懂技术的管理者正面交流，但当顶头上司变成真正的技术大牛时，情况也许会更糟。
这些曾经的技术天才们可能会从微观层面着手项目管理，并把整体代码拆分成一个个零散的部分——理由？因为他们有着自己的见解。再有，他们可能会喋喋不休于如何通过一半的代码行数来完成同样的任务，并大谈他们当初在8080、C或者Java编程领域的辉煌历史。无论如何，他们往往更关注技术细节而非宏观形势，虽然后者才是他们的首要任务。
8. 简单粗暴的程序员
程序员们也承认，有些问题确实应该归咎于他们自己。
程序员们往往不擅长沟通，也不太关注其他人的感受或者对自己的行为加以反省。他们对技术问题的纠结程度就像紧盯着骨头的狗。客户们想要什么并不重要；程序员团队本身就会因为设计思路分歧而吵得不可开交。
程序员往往会忽略掉不同合作者的个性与特质，但如果一个团队中的开发者全都过于温顺、项目也会陷入失败。两个人之间存在不同观点非常正常，例如同一个团队也可能会在动态语言和NoSQL之间僵持不下。最终程序员只能以投票的形式解决这类难题——但这并不能从根本上化解危机。团队内部的冲突就像一场百年战争，成员们不是正在争吵就是走在通往争吵的路上。
9. 特立独行的程序员
从他的代码里找到了为空指针？别想让他认错，我们只能自己动手修改。再有，大家***在输入数字0之前认真检查几遍，因为这类程序员绝对不会检查代码中是否存在除以0这类错误。对，这全都是我们自己的工作。
特立独行的程序员看起来很酷、做起工作也是迅如闪电，但这只是因为他们会把大量漏洞和测试任务留给其他同事。只有帮他们认真做好善后、他们的成果才不至于让系统陷入崩溃。
很多团队在发现这种状况时都已经为时过晚。代码块在早期测试当中运行良好，但在向其中导入真实数据后，每个人都发现其实程序根本没有经过认真检查。啊哦，完蛋了！
10. 糟糕的文档说明
我承认编写文档说明很耗时间，但同志们，这也是有工资可领的啊。很多企业都会以代码行数为依据核算程序员薪酬，而编写文档说明正是赚钱的好机会。别担心，领导会把这些记入绩效并按量发工资的。
有时候文档说明量实在太大，但这是为了能让人们在几个月甚至几年之后都能顺利用上当前版本的代码。哦，我提到这些说明数据会被保存在Footable里吗？这已经是前数两代的开发方式了，而且我也没时间重新捋顺这些代码并对陈旧说明加以修正。不过这只是迟早的事情，躲不掉的。
#p#
11. 盲目提交说明文档
虽然缺少文档说明的项目让人血压上升，但那些空话太多而代码太少的项目同样无法获得成功。在调查中，确实有受访者拿出一大堆说明资料并表示“他们就靠这些文档获取报酬。”光是读这些说明就得花上一年。
程序员常常被要求就项目本身撰写评论，就像是根据《太空堡垒卡拉狄加》或者《神秘博士》编写观后感。这类资料往往缺乏总结或者根本没能抓住要点，而只是没完没了地罗列微不足道的细节信息。如果文档不能以抽象形式概括项目作用或者帮助阅读者理解，那么单纯陈述代码作用只会让人心生反感。我只能说这么干的家伙根本没开窍：写说明不是让你把代码翻译成英文。
12. 噪杂的环境令人分心
一位客户坚持让我走进他们的办公室并在里面通过一周时间体验工作状态。事实上，这家公司的技术人员根本没有自己的办公空间，因此我不得不跟屋里的六位实习生打交道，听他们用半天时间讲述头一天晚上发生了哪些新鲜事、再用半天时间展望今天晚上要去哪疯玩。好吧，其实听听这些事情也挺有意思，但结果是我几乎什么正事都没干成。
程序员通常需要像图书馆一样的安静环境。喋喋不休的谈话、令人心烦的敲击声或者电话铃都可能把程序员从抽象的思维活动中揪出来，并狠狠地摔在现实冰冷的地面上。我们往往需要再花几分钟让自己重新进入状态，这对生产力绝对是种毁灭性打击。
我的许多企业希望能用乒乓球桌这样的娱乐设施装点程序员的工作环境——但他们忘了这种噼噼啪啪的声音跟开发者所需要的安静与集中严重冲突。
13. “文化契合”
如果每一位成员都拥有类似的工作风格，那么整个团队就能运作得更好。而无法快速求同存异的团队则会很快陷入失败局面。如果成员之间无法有效沟通，那么各自向目标迈进的状况将把整个部门五马分尸。
人们往往能够轻松勾勒出自己心目中的良好工作环境，但这其实还是得与团队本身结合起来才能发挥效果。在处理底层维护以及基础设施建设时，即使受到其他人的干扰也没什么大碍——毕竟这不算什么需要高度集中的工作。当我们等待某项建设工作完成的时候，即使有人在喊大叫也不至于引发太严重的进度中断。毕竟我们同处一个团队之下，互相喊一喊既能提高效率又能缓和气氛。
不过如果大家正在创建一套复杂的算法，而其中的组件又处于不断变化当中，那么任何谈话、走动乃至键盘敲击都可能让我们偏离思路轨道。在这种情况下，拥有自己的办公室是***的办法。
14. 执着于传统技术
如果大家在Dice.com网站上查找与Cobol相关的岗位，会发现列表中竟然拥有680个结果——相较于网站上的七万多个招聘岗位总量，其比例接近1%。拥护者们坚持认为这是一项卓越的技术，完全能够胜任目前的工作需要。为什么要重新改写已经成熟的解决方案？
这样的说法虽然不是毫无道理，但他们忽略了一大事实——沿用陈旧代码是会带来额外成本的。其中所有内容都需要经过翻译，而翻译过程往往需要借助定制代码。其中一部分代码甚至写于ASCII诞生之前，这意味着连输入与输出内容都可能需要转换。陈旧系统在检查数据库内容时通常会把空格计算进来，要排除这些干扰需要更多转换过程。
程序员们在屏幕截取、重新格式化以及临时性系统对接方面表现出色，但在一段时间之后，他们往往会把主要精力放在更新胶合逻辑而非编写新逻辑方面。
15. 过分追求******的技术
我们都跟某位仁兄打过交道，在他眼中Java就是“我爷爷才爱用的编程语言”。而Node.js——这才是201x年的风格。
***的工具用起来当然很有乐趣，但如果不认真对之前一段时间的工作进行备份、我们根本不敢把它们直接引入工作环境。走在技术前沿的人们总爱全盘否定API整体并加以重写，这就迫使下游开发者不得不随之重写自己的代码。
在很多情况下，新型工具并没有经过时间的检验。Node.js确实能带来令人惊讶的速度表现，但前提是我们得重新了解死锁机制，这将迫使人们首先创建新的线程。通常来说，前沿方案相当于以偷工减料的方式为使用者带来看似很美的结果——也许不会出问题、但也有可能让之前的心血付之一炬。
