摘要：在日常开发过程中，开发者会遇到许多折磨自己的问题，如：安全性问题，工具使用等，这里Andrew C. Oliver为大家总结了公司里最常见的16种折磨开发者的方式，看看你遇到几个？
程序员们被滥用的现象还是能经常见到，Andrew C. Oliver为大家总结了公司里最常见的16种折磨开发者的方式，你碰到过吗？以下是一些常见的情形：
1.地狱性的安全问题
McAfee代理禁止使用HelloWorld.java的Zip文件，这意味着禁止从该文件中下载任何构建工具的样例。McAfee desfktop为了防止恶意代码的出现而扫描每个文件进程，即使这些文件以单线程模式扫描之后未发生任何改变，也就是说成千上万个文件的所有内容都需要通过CPU这个核心处理器操作处理。CPU需要花费30分钟启动IDE，再花费10分钟启动一个构架。
2.酷刑工具
Subversion和 Git两个版本控制系统的存在，让所有其他版本控制/配置管理工具运行的很慢/或很痛苦。ClearCase工具是所有开发人员公认的酷刑工具的始祖。
3.维护团队
目前，依然有些地方存在固定的团队，他们做着自己厌烦的工作。严重地说，但凡他们能找到一个稍微好点的工作都会离开“维护团队”。
4.强迫使用Windows
强迫你的开发人员使用Windows开发环境很扯淡，而且，对于非技术性用户运行项目也会有很多的限制。
5.远离类库
多年以前，我还在IBM工作，当时被告知不要使用第三方库（无论是否开源），除非该库能帮助自己节约至少两个月的开发时间，这是因为使用第三方库需要律师的审核，而审核这一切花费的时间可能会超过所需的两个月。你需要一项政策，规定在何处如何使用库，而无需通过正式的审批程序。否则，你犯了侵权行为，迫使你的项目重新开始。
6.WebSphere
WebSphere在使用过程中总是出问题，令开发人员深恶痛绝，所以尽可能不要安装使用。
7.持续编程至“死”
如果迫使开发人员一成不变进展项目，会让他们感到崩溃。同时，他们也会感觉自己好像是纸片和胶带一样总黏在一起。短期不是问题，如果每个周末都要整理一大堆困境，这显然没人愿意做。相反，让开发人员用较少的时间，效果则会有更好的改善。
8.2010年是个好年头，但已经过去了
你以为标准化的“老爷版”开发环境配置能固住一个程序员，就一直让他们使用已经用了三、四年的IDE，跑在过时的Windows上？别天真了。在激烈竞争的时代，有人会出更大的价钱和更新的工具吸引他们加盟。
9.成为重复编码的机器
我很同情你讨厌 HipsterHacker构架。你不想一个系统被完全的开发成“看起来很炫，我要下载”。另一方面，让开发人员编写同样的没有任何创新思想的代码，会让他们思考自己的职业生涯。综上所述，让开发人员不断接触新的东西，进入一个稳定构架来缓解风险。
10.无止境虚拟化导致漏洞百出
如果你的公司完全是虚拟的，甚至开发环境也是虚拟的。由于硬件资金不足或者没有协调好等原因，而导致一切进程都慢下来，这是很可怕的折磨。有些人是禅宗，不在乎用两个小时来构建这个过程，而我并不是其中的一员。
11.该死的Scrum每日站立会议
有一个最遭罪的会议被称为Scrum每日站立会议，会议是为了更新管理的状态，每个人都被迫发言至少五到六分钟，除了传达出他们自己工作的内容和应该保持现有状态外，并不能传达重要的建设意见。实际上，会议只需他们其中的12个或更多的人，绝大多数的人可以不必参与。会议进行到30~45分钟甚至更长时间时，不发言的人渐渐的都昏昏沉沉的。更糟糕的是，开会之前没有人准备关于会议的内容，因为大家都知道会议的流程。会议结束后，午餐至少要一个小时，就这样，会议让你的团队浪费了整个上午时间，最后一事无成。
12.形式主义
形式主义胜出穿上一套套装，它可能以意想不到的方式出现。很有讽刺意味的来说，由于制定了标准规则，宽松的工作环境对于开发人员来说是比较困难的，同时，开发人员也很努力的反对这种正式的工作环境。宽松的环境，实际上，也是一个多元化人工合成的环境。由于某种形式的存在而强迫开发人员按照规则去做事情，是对开发人员思想和精神上的一种虐待。
13.危机管理
有时一个负载测试也会失败，而管理人员也想了解失败的根本原因，并得到解决方案。他们甚至不顾一切的恢复到之前状态，这是检查偏离轨道发展过程一个很好的路径。管理人员不但有权打断实施和测试的正常迭代过程，而且使开发人员不敢尝试任何新的东西，并对此投入多余的注意力。他们并不了解相关的功能，却采用威胁和直接的破坏性的行为解决问题，充其量也就是把产品推出来而已。
14.吹毛求疵
如果说某人发现一个流氓机器，正试图用它连接Skype上受限制的端口。对此，开发人员并没有留意到，这已然触犯了规则。然而，当被问及有关指导说明时，他提供不出详细的说明。开发人员会因为开发项目过程中出现的含糊不清、无证限制等原因而被处罚。这些都是管理人员寻找漏洞问题的一个最容易的突破点。
15.细节！细节！
一位头发竖起的老板：‘’客户需要一个扭曲功能，你能及时添加实现吗？“
编码人员：”不能。这将需要主体架构的改变。在项目启动之前，我们就询问过，而且当时被告知尽可能的不会花时间做扩展功能。“
项目启动之前，写在需求评估表中的需求量很少，这让了开发人员采取更捷径的方法开发项目，却没考虑到随时可能添加其他的扩展功能，而后添加的扩展功能让开发人员延迟了项目的提交时间。
16.只论结果
有些管理人员要求快速给出解决问题的方案，同时拒绝受理出现问题的推测原因并抵制正确的审查方法。他们只会言语上说：”你不是专家吗？为什么你不能解释或解决它呢？“然而，要得到解决方案，你必须调查出现问题的原因，以及假设原因并对其进行测试。因此，我们不能快速给出解决方案，而需要对其猜测检验！