技术开发 频道

十五种糟糕方式让编程生产力跌入谷底

        【IT168 技术】没完没了的大会小会、啥也不懂的直属领导、流于形式的生产指标——正是这冠冕堂皇的一切扼杀了无数即将诞生的伟大软件。

  产品本来昨天就应该搞定出炉。用户们怒吼着质问为什么其中尚存在功能缺失。老板的老板表示你们这帮开发人员最好快点行动,不然就准备滚蛋。总之,一切似乎都在朝着最坏的可能发展。

  每个人都希望代码都像消防带里的水一样倾泄而出、酣畅淋漓,但却没人愿意为开发人员提供他们完成工作所需要的一切。没错,那些要求提前搞定工作的老板从来不愿意多顾几位技术员工、采购性能更强的设备或者作出哪怕一丁点有利决策,从而帮助程序员们简化工作流程。

  在今天的文章中,我们将一同回顾十五大横亘于程序员面前的障碍。由于采用非正式调查形式,因此我们轻松得到了开发人员们的心声——带着同情之心与他们交谈,一切不快与委屈将不再是秘密。

  1. 开会

  朋友们对哪种状况抱怨最多?毫无疑问就是没完没了的会议。经过我们的调查核实,很多程序员都不得不挤在昏暗的会议室里,呆望顶头上司闲谈那些无关紧要的细枝末节。程序员们一般会把会议失败的原因归结在管理者身上,偶尔也把怨气与指责丢向其他在漏洞、功能或者架构策略上犯了错误的技术同行。

  不过即使是会议确实是在讨论软件抽象世界中的深层难题,程序员们一样会对此感到不满。快餐厨师也许能够迅速应对各种不同类型的需要,但切换思维方式从而与抽象算法对接则需要预热时间——而且会议往往令正常工作受到一小时甚至更长时间的耽搁。

  2. 回复全部邮件

  如果说会议太多令人厌烦,那么另一种状况则更让我们难以承受:无穷无尽、汹涌而来的邮件。光是回复这些邮件就要花上几个小时,而且不过是对方还是我们自己都无法对邮件的结果表示满意。这时,开发人员们往往会以恶劣的态度回复“tl;dr”并产生某种奇特的自豪感。

  某些团队正在尝试每周选择一天禁止邮件流通,另一些更加坚决的朋友则主张彻底告别邮件。这虽然解决了处理内容过多的问题,但却同时提高了通信成本。如果人们忽然之间就失去了协作的纽带,这从任何角度来看都不是什么好事。、

  3. 试图衡量生产指标

  似乎总有管理团队盲目遵从这样一条格言,“你无法管理自己不能衡量的事物”。好吧,他们开始不断统计提交量、软件代码行或者漏洞修复数。他们以为这种数字统计就是衡量,而衡量意味着良好的结果。

  不过程序员们都是出色的游戏玩家,而生产力衡量指标则成为他们的追求的分数排行榜。在这种机制的推动下,他们不再将编写优质代码作为第一要务,反而专注于编写尽可能多的代码行、解决更多漏洞、最大程度增加提交量或者其它任何能够被计入绩效的工作。事实证明,衡量生产力指标确实会让代码质量变得更糟——这相当于鼓励大家开发出体积庞大且塞满功能的文件,其中遍布被过度设计的代码。

  对于这一难题,目前还没有切实有效的解决办法。我们需要追踪漏洞、我们需要组织工作流同时协调软件创建。这一切都是只可意会而无法言传的任务,根本不能简单用数字加以评估。

  4. 过分自恋的开发者

  对于程序员们来说,除了老板之外、另一类同行也是他们打压的重点——即那些创建出最后一套迭代就不再负责对应项目的开发者。正如每次找来的家装设计师都会对原先屋子里的工程不屑一顾,程序员们也有能力快速发现前任技术工作者犯下的脑残失误。

  事实上,程序员的表达方式几乎要比任何其他行业的继任者都更为激烈。这往往与两代技术人员的技能水平无关,他们只不过偏好不同的开发风格,而且随着时间的推移、风格也会有所变化。上一代程序员可能并不具备我们当下所拥有的代码库,也并不了解如今已经成为最佳实践的解决方案。

  这种极度自恋、抨击他人的态度会拖慢项目进程,因为他们会由于冲动而丢弃大量代码、从而按照自己的想法“从头开始”重新构建整个项目。

0
相关文章