16种折磨开发者的方式

标签:虚拟化安全技术模式

访客:16855  发表于:2013-08-29 16:59:22

来源:HTML5中国

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.只论结果

有些管理人员要求快速给出解决问题的方案,同时拒绝受理出现问题的推测原因并抵制正确的审查方法。他们只会言语上说:”你不是专家吗?为什么你不能解释或解决它呢?“然而,要得到解决方案,你必须调查出现问题的原因,以及假设原因并对其进行测试。因此,我们不能快速给出解决方案,而需要对其猜测检验!

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");