没完没了的会议、什么都不懂的直接领导、仅仅是正式的生产指标——就是这些冠冕堂皇的东西扼杀了无数即将到来的伟大软件。前15名编程生产力杀手产品应该在昨天发布。用户大喊大叫，问为什么还缺少功能。Boss的老板说你们这些开发人员***动作要快，否则你们就要滚蛋了。总之，一切似乎都在朝着最坏的可能发展。每个人都希望代码像消防水管里的水一样倒掉，但没有人愿意为开发人员提供他们完成工作所需的一切。没错，要求提前完成工作的老板们，从来都不愿意花钱多请几个技术人员，买更强大的设备，或者做出哪怕是一丁点有利的决定来帮助程序员简化工作流程。在今天的文章中，我们将回顾摆在程序员面前的15大障碍。因为非正式的调查，我们很容易就得到了开发者的心声——用同理心和他们交谈，任何的不快和不满都将不再是秘密。1.朋友抱怨最多的情况是什么？无疑是没完没了的会议。经过我们的调查核实，很多程序员不得不蜷缩在昏暗的会议室里，呆呆地看着顶头上司聊着无关紧要的细节。程序员一般把会议的失败归咎于管理者，偶尔也会把自己的委屈和指责扔给其他在bug、功能或架构策略上出错的技术同事。但即使会议确实讨论了软件抽象领域的深层问题，程序员也会对此感到不满。快餐厨师可能能够快速响应不同类型的需求，但转换思维方式以与抽象算法交互需要预热时间——而且会议通常会使正常工作延迟一个小时或更长时间。2.回复所有电子邮件如果太多的会议很无聊，还有别的原因：没完没了的电子邮件。回复这些电子邮件可能需要几个小时，收件人和我们自己都不会对电子邮件的结果感到满意。在这一点上，开发人员往往会用令人讨厌的“tl;dr”和一种奇怪的自豪感来回答。一些团队正在尝试每周一天禁止邮件，而一些更坚定的朋友正在倡导完全告别邮件。这虽然解决了处理过多内容的问题，但同时增加了通信成本。如果人们突然失去了合作的纽带，那无论如何都不是一件好事。#p#3。试图衡量生产指标似乎总是让管理团队盲目地遵循格言，“你无法管理你无法衡量的东西”。好吧，他们开始计算提交、代码行或错误修复。他们认为这种统计就是测量，测量就是好的结果。但程序员是伟大的游戏玩家，生产力指标成为他们抱负的记分牌。在这种机制的驱动下，他们不再将编写高质量的代码作为重中之重，而是专注于编写尽可能多的代码行、修复更多的错误、最大化提交或其他任何可以计算的事情。进入表演工作。事实证明，衡量生产率指标确实会使代码质量变差——相当于鼓励大型、功能丰富的文件充满过度设计的代码。对于这个问题，目前还没有切实有效的解决方案。我们需要跟踪错误，我们需要组织工作流程并协调软件创建。所有这些都是只能理解而不能用语言表达的任务，不能简单地用数字来衡量。4、过度自恋的开发者对于程序员来说，除了老板之外，另一类同行也是他们打压的重点——那就是那些创建了上一组迭代，不再负责相应项目的开发者。就像每次聘请家装设计师，他都会把房子里原来的项目打发掉，而程序员也有能力很快地发现之前技术工人犯下的愚蠢错误。事实上，程序员比几乎任何其他行业接班人都更有发言权。这往往与两代技术人员的技术水平无关，只是偏好不同的开发风格，而且风格会随着时间的推移而变化。上一代程序员可能没有我们今天的代码库，也不理解现在最佳实践的解决方案。这种极端的自恋、抨击他人的态度会减慢项目的速度，因为他们会冲动地丢弃大量代码，以按照自己的方式“从头开始”重建整个项目。5.“稍后修复”的心态，或“技术债务”项目开发中从来没有一天或一个阶段真正给我们足够的时间——需要创建的内容量总是几乎无法承受。在这种情况下，我们倾向于偷工减料，提供代码补丁，并使用这个“虚拟磁带”到处修补。聪明的管理者在仔细审查项目后，会将这项工作称为“技术债”，而“债”当然是需要偿还的。即使对编码一无所知，他们也能理解“债务”的概念和含义。每个项目都有一些技术债务。有时我们能够很快解决，但大多数情况下，继任者接手后债务又开始增加，迫使他们面临许多无法预料的困难。只有解决了这些遗留问题，项目才能真正顺利进行——这有点像国债，只是规模小一些。6.非技术经理你一定在公司见过很多这样的人，他们热情、积极、微笑，各方面都能表现出友好的态度——除了与编程项目相关的计算机科学。也许他们通过裙带关系爬上了高位，或者他们在正确的时间出现在正确的位置，老板让他们负责管理和技术——即使他们甚至找不到他们的黑莓手机。有些程序员喜欢这样的老板，因为他们很容易被骗。如果人们告诉他们JohnsonDB并没有取得巨大成功，他们往往会相信并在公司内部传播“不幸”的消息——然后公司的高层管理人员就会来清理外行。其他人发现这样的经理召集会议并妨碍程序员。他们提供的指导很少，他们最好的表现是更实用的质量测试。#p#7。精通技术的管理者虽然程序员可能无法忍受与非技术管理者直接交流，但当顶头上司成为真正的技术高手时，情况可能更糟。这些曾经的技术天才可能会从微观层面开始项目管理，将整体代码拆分成零散的部分——原因？因为他们有自己的看法。同样，他们可能会喋喋不休地谈论如何用一半的代码行数完成同样的任务，并谈论他们在8080、C或Java编程方面的辉煌历史。无论如何，他们往往更关注技术细节而不是大局，而大局才是他们的首要任务。8.粗糙的程序员程序员也承认，有些问题确实是自己的错。程序员往往不善于沟通，他们不太注意别人的感受，也不太反思自己的行为。他们像狗咬骨头一样痴迷于技术问题。客户想要什么并不重要；程序员团队自己也会因为设计思路不一致而争吵。程序员往往会忽略不同协作者的个性和特质，但如果一个团队中的所有开发人员都过于温顺，项目就会失败。两个人有不同意见是很正常的，比如同一个团队也可能在动态语言和NoSQL之间僵持不下。最终，程序员只能通过投票的形式来解决此类问题——但这并不能从根本上解决危机。团队内部的冲突就像一场百年战争，成员们不是在争吵，就是在争吵的路上。9.特立独行的程序员在他的代码中发现了一个空指针？不要让他承认错误，我们只能自己修改。此外，在输入数字0之前一定要仔细检查几次，因为这类程序员永远不会去检查代码中是否有被0除之类的错误。是的，这都是我们自己的工作。特立独行的程序员看起来很酷并且工作速度很快，但这只是因为他们给其他同事留下了很多错误和测试任务。只有帮助他们小心善后，他们的成就才不会导致系统崩溃。许多团队发现这一点为时已晚。代码块在早期的测试中运行良好，但是在将真实数据导入其中之后，大家发现这个程序根本没有经过仔细检查。哦，结束了！10.糟糕的文档我承认写文档很费时间，但是伙计们，这也是要付出代价的。很多公司都是按照代码行数来计算程序员工资的，写文档是一个很好的赚钱机会。不用着急，领导会把这些记入绩效，按量发工资。有时文档的数量太多了，但这是为了人们可以在几个月甚至几年后使用当前版本的代码。哦，我有没有提到描述数据将保存在Footable中？这是过去两代的开发方式，我没有时间重新访问代码并修复陈旧的指令。但这只是时间问题，无法避免。#p#11。盲目提交文档虽然缺乏文档的项目会让您血压升高，但冗长冗长且代码过少的项目同样不太可能成功。事实上，在调查中，受访者拿出了一堆解释材料并说，“他们正在为这些文件付费。”光是看说明文件就需要一年的时间。程序员经常被要求写关于项目本身的评论，有点像写基于《太空堡垒卡拉狄加》或《神秘博士》的事后想法。这些来源通常缺乏摘要或根本没有抓住要点，而只是无休止的琐碎细节列表。如果文档没有以抽象的形式总结项目做了什么，或者帮助读者理解，那么简单地陈述代码做了什么只会让人感到反感。我只能说做这件事的人没有掌握窍门：编写说明并不是将代码翻译成英文。12.嘈杂的环境让人分心一个客户坚持要我去他们的办公室，在他们的办公室里待一个星期，体验一下工作的感觉。事实上，这家公司的技术人员根本没有自己的办公场所，所以我不得不和房间里的六个实习生打交道，半天听他们讲前一天晚上发生的事情，半天看向前。今晚你要去哪里发疯？好吧，听到这些事情实际上有点有趣，但事实证明我几乎没有完成任何真正的工作。程序员往往需要一个安静的环境，比如图书馆。喋喋不休、令人不安的敲门声或电话铃声可以将程序员从抽象思维中拉出来，并将他猛烈地摔到现实的冰冷地面上。我们经常需要多花几分钟才能让自己回到最佳状态，这对生产力绝对是毁灭性的。我的很多企业都希望用乒乓球台之类的娱乐设备来装点程序员的工作环境——却忘记了这种噼里啪啦的声音与开发人员需要的安静和专注是严重冲突的。13.“文化契合度”如果每个成员的工作风格相似，团队就会工作得更好。不能快速求同存异的团队很快就会失败。如果成员不能有效地沟通，他们在实现目标方面取得的进展可能会导致整个部门分崩离析。人们往往可以很容易地在脑海中勾勒出一个良好的工作环境，但实际上它必须与团队本身相结合才能发挥作用。涉及到低级维护和基础设施建设，被其他人打扰也没关系——毕竟不是高度集中的工作。当我们等待一些建筑工作完成时，即使有人大喊大叫也不会造成太多的中断。毕竟我们是一个团队的，互相吼叫既能提高效率又能缓和气氛。但是，如果您正在创建一个组件不断变化的复杂算法，那么任何谈话、走路甚至击键都会让我们偏离轨道。在这种情况下，拥有自己的办公室是最好的解决方案。14.沉迷于传统技术如果你在Dice.com网站上搜索Cobol相关的工作，你会发现列表中有680个结果——与网站上70,000多个职位空缺的总数相比，比例是接近1%。支持者坚持认为这是一项出色的技术，完全可以胜任今天的任务。为什么要重写一个经过验证的解决方案？这样的论点虽然不无道理，但却忽略了一个重大事实——使用旧代码会带来额外的成本。所有这些都需要翻译，通常使用自定义代码。有些代码甚至在ASCII出现之前就已经编写完成，这意味着甚至输入和输出内容也可能需要转换。遗留系统在检查数据库内容时通常会计算空间，并且需要进行更多转换才能消除这些噪音。程序员擅长截屏、重新格式化和临时系统对接，但过了一段时间后，他们往往会专注于更新胶合逻辑，而不是编写新逻辑。15、过分追求最新技术我们都和某个男人打过交道。在他眼里，Java是“我爷爷最喜欢用的编程语言”。还有Node.js——这是201x的风格。最新的工具当然用起来很有趣，但我们不敢在没有对之前的工作进行认真备份的情况下直接将它们带入工作环境。走在技术前沿的人，总是喜欢将API作为一个整体进行彻底的否定和重写，这就迫使下游的开发者相应地重写自己的代码。在许多情况下，新工具经不起时间的考验。Node.js确实可以带来惊人的速度性能，但前提是我们必须重新理解死锁机制，这会迫使人们在第一时间创建新的线程。一般来说，前沿的解决方案相当于偷工减料，为用户带来看似美好的结果——也许不会出现问题，但也可能毁掉之前的努力。原文链接：http://www.infoworld.com/slideshow/129821/the-15-worst-ways-kill-programming-productivity-231450#slide1
