什么会使开发人员放慢速度?[关闭]


12

什么事情会使开发人员放慢脚步?

请尽量避免发布以下答案:

  • 现在速度很慢,但在功能中很有用。(TDD,重构等)
  • 列出干扰

@马克·特拉普:嗯?根本不是重复的……:-S
Tamara Wijsman 2010年

1
如果这个问题没有用,我会在不久的将来将其删除,人们会列出一些干扰因素,而这已经由我提出的另一个问题解决了。因此,我倾向于寻找无干扰的事物……TheLQ和Bill是很好的示例答案。
Tamara Wijsman 2010年

嗯,网址被弄乱了。重复的是编程期间会发生什么干扰?

选择不公开这个问题,是因为它关乎那些不会让人分心的事情……
Tamara Wijsman

11
Stackoverflow,SuperUser,Programmers ...是的,基本上是这样的站点:)
bedwyr 2010年

Answers:


49

哦,这很容易:

  1. 会议会议
  2. 更多会议
  3. 关于上次会议的会议
  4. 为即将举行的会议做准备的会议
  5. 开发会议的演示文稿
  6. 为会议开发一个Powerpoint演示文稿,讨论尚未实现,不应实现的功能,以及出于某种原因,销售人员将无所不用其极。如果没有互联网连接或无法访问硬盘,我无法根据您当前的位置预测要在应用程序中显示什么文档。不,真的,也要放弃。

4
简而言之:管理?; o)
n1ckp 2010年

11
@ n1ck不,不。良好的管理可以加快开发人员的速度。程序员时间安排不当(即成为经理的一个方面)确实会减慢开发速度。
小麦色

3
当我的公司这样做时,使我丧命的是:会议,更多会议,有关上次会议的会议,要准备的会议,讨论为什么我们无法完成任何事情的会议。为什么我们无法完成任何事情?您有40个开发人员坐在一个房间里听你说话!!
Mike M.

2
请注意,此答案几乎适合Powerpoint幻灯片。

44

这里同样的问题
pramodc84

1
假设公司允许,我会尽快给自己买一台笔记本电脑,然后在这种情况下进行工作。
adamk 2011年

缓慢的计算机往往是造成干扰的根本原因。每次程序员等待时,他们都可能进入分心模式,直到一段时间后才会返回程序。
edA-qa mort-ora-y

他们在几周前更换了我的电脑。它的功能不及它替代的4年老机。真好
MetalMikester,2011年


25

StackOverflow,programmers.stackexchange.com等:)


4
不同意!StackOverflow有助于解决问题,因此可以加快开发速度!
向导

3
令人反感的愚蠢行为。因为我以前就如此“浪费”的每一分钟,这已经给我买回来20
澳门国际机场

11
+1。一点也不冒犯。SO非常适合拖延。这是我的新脸书。:)
back2dos

@ back2dos请不要将SO的出色表现与..那是facebook进行比较。
adamk 2011年


15

任何试图遵循不适合当前任务的过程的尝试。

这可能是各种各样的事情,但是我看到的常见问题包括:

  • 不适合所测试代码的测试方法
  • 比交付保证书更为敏捷或传统的流程
  • 适用于与所选工具集不同的工具集的准则
  • 与项目需求不符的设计原则
  • 使用不适合该任务的工具集

所有这些事情在某些项目或某些情况下都非常有价值,但是某些组织尝试以一种方式完成所有工作,这导致其他项目的适应性很差,这通常会导致生产力下降。



9

其他人的对话

和噪音一般

许多答案都涉及到上下文切换和离开该区域的问题,而噪音,尤其是谈话,是导致我感到沮丧的事情之一。

在我的魔方世界中,我到处都是喧闹和谈话。排成一排的大型机团队在多维数据集行中举行不间断的计划会议。有时,他们会在隔离墙的办公室与顾问会面,这往往会引起喧闹,嘶哑和大笑,我不得不走过去,要求他们关门。

另一方面,Web团队会议桌在我的西方墙的另一侧,所以无论是否喜欢,我都是每次会议的一部分。在南立面墙的另一侧还有一台打印机,这对于那些闲逛等待打印输出的人总是很有趣。

当您想要的是安静时,“ 您不能只买降噪耳机” 这个直接而明显的答案无济于事。

有时,为了进行代码审查,我将一叠文件带到午餐室(当然是在非午餐时间),但是那里通常有一台电视机。如果没人在看,我将其关闭。否则,我将在建筑物另一部分的另一个部门中找到一个空立方体。

如果您希望程序员完成他们需要做的工作(主要是思考,思考和考虑),那么他们需要一个可以做到的环境。


有时候,我所在的地方太安静了。我开始关注每个人的鼠标点击和人们呼吸沉重的情况,等等。这就像躺在床上听板球一样。
kirk.burleson 2011年

8

在没有适当测试的情况下编写了太多行代码。


这是导致我的工作停顿的第一大原因。
Paddyslacker

1
@Paddyslacker:更多测试=更有生产力???只适合那些不应该一开始就参与编程的人。测试可能是有用的,但是“导致磨碎的第一大原因”?你是认真的吗?
n1ckp 2010年

1
@ n1ck:是的,我很认真。代码进入不可维护的状态,并且缺乏代码库的测试和可测试性,这意味着每个新功能都变得越来越难以添加。我觉得这很有趣,您认为您认为编写更多测试的人“首先不应该参与编程”。那么Roy Osherove,Michael Feathers,Bob叔叔,Kent Beck等等等不应该参加编程吗?
Paddyslacker

@Paddyslacker:我不知道。从来没有看到他们的代码。从您的描述来看,也许他们应该在管理方面做得更好?又为什么正是由于缺乏测试而导致代码无法维护?测试可能会通过某种魔术使可怜的代码变得更好吗?
n1ckp 2010年

1
@ n1ck,测试在最初编写代码时并没有付出代价,但是在以后必须维护代码时却产生了巨大的差异。

5

缺乏优质咖啡。


还是缺少好的苏打水。我非常想念不含咖啡因的饮食樱桃可乐!在我的国家/地区,我只能食用低碳可乐或不含咖啡因的可乐,而根本不能食用樱桃可乐:-(
向导

1
@向导-我曾经在一家提供Diet Cherry Coke的公司工作。不知道为什么我离开了。如果感到疼痛。
JeffO 2010年

2
@向导:只要买一瓶黑樱桃樱桃,然后在饮料中加入一些糖浆即可。现在,您可以使它变得更坚固……(香草的相同技巧:真正的香草可乐要比预混合的东西
好得多

@先生。C:问题是我需要节食+不含咖啡因的可乐,这在我的国家中不可用。
巫师

5

必须做出完美的估计,一旦开发开始就不得改变,我认为这是一个鸡蛋的情况


如果您碰到太多,我建议您花一些不平凡的时间来研究估算。然后,您可以回答“如果是估算值,按照定义,不是实际需要的时间”。
MIA 2010年

哦,我以前用过那个,回答总是我不擅长估计,如果
不能分解

5

修复别人的损坏的版本


听起来好像有人没有很好地指导他的同事。
显示名称

@bold:它可以自然地从异步发生。假设每天的构建截止时间是凌晨5点,而您则在上午9点签出最新版本。(换句话说,您不能阻止人们提早上班。)
rwong 2011年

4

没有议程的会议。

慢的机器。

缺少第二台显示器。

有球的旧鼠标,而不是漂亮的新鼠标。

机器上缺乏互联网访问,使得查询MSDN / stackoverflow / etc有点麻烦。


与无议程会议相关的是会议劫持者。您知道的...将它放在日历上一个小时,但是即使主题在20分钟内结束,也有家伙继续寻找其他主题来填补20分钟。我会投票给你,但后来我不得不在“第二台显示器不足”的情况下投票给你,以减慢速度。这很方便,但是偶尔不放慢我的速度。
MIA 2010年

4

花费太多时间进行程式设计

即使您真的很喜欢编程,花太多时间最终也会使您筋疲力尽...


4

避免一切使您脱离“区域”的事情。这意味着您的电子邮件收件箱,Twitter弹出应用程序,公司聊天等。

有一个安静的工作状态来避免桌面噪音太大。


3

如果您事先知道任何变更请求,本来会更容易实现。


“如果将两者冻结,则可以轻松进行规范中的水开发和软件开发”
back2dos

1
愚蠢的报价。在冰上行走并不总是那么容易。
彼得·

1
@Peter Boughton:如果我们选择一个秤,很难根据波动的规格来开发软件,而根据冻结的规格来开发软件就很容易,那么在冰上行走总是很容易的。您可以教一个6岁的孩子去做。但是我想您知道,您只是从智能资产中获得乐趣。
back2dos

您也可以教六岁的孩子使用波动的规范。这不是明智的选择,而是对诸如此类的过度使用感到恼怒,这无济于事。如果冻结规范不正确,则不容易开发(因为它们无法修复),而更改规范则可以,如果您事先知道有哪些零件在变化(可以满足您的需求),就可以了。
彼得·布顿

3

代码不正确。

首先,必须重写可能本可以完成工作的其他人的部分,这是我能想象到的最大时间浪费。


2

很多让您失望的事情是一篇不错的博客文章。

...

许多项目一遍又一遍地重复核心基础结构级别的功能,从而减慢了该业务在提供使该业务与竞争对手区分开来的功能方面的速度。

...

不可避免的是,产品和创新将有助于减少开发人员花在非差异化任务上的时间。问题是这些服务和工具将采用哪种形式。

...


+1:好答案。我辞去工作是因为该公司不愿花时间减少技术债务。开发人员被迫“一遍又一遍地重复核心基础架构级别的功能”。
Jim G.

2

好吧,最近最大的减速是因为我们正在同时开发一些应按特定顺序完成的事情。因此,我一直等到(为了保护无辜者而改名)John完成了我的SSIS程序包所需的组件,而Harry放慢了等待我导入记录的速度,因为他需要一些数据来测试出口(请尝试在任何表中都没有数据的情况下编写复杂的导出报告?),并且由于设计还没有完成,并且尚未完成需要执行任务的数据库表,甚至还没有结束,每个人都被放慢了速度就像他们所说的那样,等等。


1
听起来您正在谈论由于在团队成员之间分散工作而导致的瓶颈。
MIA 2010年

1
团队分布不那么分散,但管理层并没有考虑分配项目时的依赖性。而且,一旦有人尝试实际使用它们,就可以假定在其他人被分配到项目时已经准备就绪的东西。
HLGEM 2010年

2

在stackexchange.com上回答问题,就像这样。


然后,您可以考虑提高触摸打字技能。

2

即使您要求不要列出干扰因素,它们也可能是一个很大的因素。查看他们的工作环境,检查他们是否经常被打扰或被要求做其他与项目无关的事情。

有时,开发人员可能会因为他们正在做以前从未做过的事情,并且不知道在哪里寻求帮助而陷入困境。如果是小型团队或个人,则可能会更加困难。当我们不知道如何做事情时,我们往往会感到骄傲和不愿意承认。此外,我们不喜欢向他人寻求帮助。要让开发人员承认这一点,没有简单的方法,除非询问他们是否可以在截止日期之前完成,或者要求他们在截止日期之前完成什么,然后希望他们会诚实。您可能需要主动提出其他帮助,或者找到可以帮助他们的人。

缺乏明确定义的需求,这导致他们不得不弄清楚事情或做出决定。


2
  • PC等待约15分钟才能进入可用状态
  • 等待PC切换应用程序
  • 作为办公室里唯一必须自己泡茶/咖啡的人。
  • 键盘损坏(已修复!)
  • 在常务董事(美国首席执行官)办公室外面(也不在办公室)工作,中间只有一个分区(尤其是开会时)
  • 老板只能通过电子邮件联系,但其他所有人都在大楼内
  • 不允许使用VCS-显然应该在我的脑海中
  • 小萤幕
  • 除了午餐以外,没有时间休息
  • 尽管建筑物中有系统管理员,但仍必须执行远程服务器备份
  • 被告知要做手动备份。
  • 被迫使用不必要的复杂时间管理系统
  • 仅仅两个月就对需求有了一个模糊的想法

我可以继续,但是今天是星期五,我想忘记工作。


听起来您需要离开那里!
adamk 2011年

2
  • 缺少文档(系统,公司等)
  • 缺少注释代码
  • 对系统的不完整理解
  • 政治(例如不必要的会议,文书工作,管理层的障碍...)
  • 需求文档不完整
  • 脸书!
  • 睡得太多吗?

1

该项目上的人员太多。

多次看到,管理层在没有实际数据的情况下决定他们需要向项目中添加更多人员。最终导致知道事件的人要停止一切以握住对事件一无所知的人的手。我已经看到一个以上大小的蘑菇项目,然后从那里迅速进入厕所,而在此之前还不错,尽管可能有点慢。

因此,从您因为速度不够/做得太多而迟到一个月,到根本无法交付,是因为您完全浪费了所有这些额外人员的预算。


0

除了别人提到的事情之外,在决定编译和运行代码与获得肯定/否定结果之间还有很长的路要走。理想情况下,此RTT只需一秒钟,但我已经看到了几个小时的示例。顺便说一句,单元测试试图解决这个问题。

另一个与此相关的是您的工作环境的一般延迟。假设您需要通过令人毛骨悚然的连接,通过远程桌面连接到世界另一端的计算机。我去过那儿。我讨厌这个


0
  • 文书工作过多

  • 对永远不在的人有依赖性(例如您的老板,如果您需要提出问题,但他总是在开会)

  • 工具和设备不足。

  • 人们无缘无故地推起桨(任何UI可见的更改都受此约束),或者只是争论琐碎的事情。

  • 破碎的咖啡机

  • 被分配了错误的任务


0

空调无法正常工作。

因此,办公室的温度在冬天的-5年夏天上升到40度。

-5不适合打字,因为我不能戴着手套打字。40岁,只是放慢了我的思考速度。


0

这是一个非常个人化的观点,也许是有争议的观点,但是始终要对计划进行过多的计划和思考,或者始终编写“质量”代码。有人说“数周的编码可以节省您数小时的计划”,在某些情况下可能是正确的。

但是,我经常看到程序员在开始编码之前试图勾勒出一个好的设计。我发现自己“上手”会更容易,因为在编写程序时,您将学习有关问题和解决方案的更多信息,这将使您能够快速将解决方案重构为一个好的设计。出现的大多数问题在编码开始时几乎是不为所知的(据我所知),因此浪费大量时间进行前期设计只是浪费时间。

这也是为什么我不喜欢TDD的原因,您浪费了太多时间编写测试,这使您不太可能进行重构,或者花费大量时间来重写测试。单元测试在某些情况下和项目的某些阶段都非常有用,但是一个项目的开始并不是其中之一:恕我直言:)

快速获取并改进它。


-1我可以理解您的想法,但是设计阶段的重点是限制重构的需要。它还可以方便地进行单元测试,以确保始终有效的东西不会被破坏和释放。如果您不进行任何计划,那么当其他人不得不维护那些架构不良的代码时,他们将使其他人的工作更加困难。
adamk 2011年

谁说架构不佳?我只是说您不希望过度的设计阶段,而需要在项目期间进行大量的重构和重新架构以获取质量代码。另一方面,要使此方法有效,您必须明确规定代码职责,以防止不同的人在彼此的代码中混为一谈。
2011年

经验表明它将具有不良的体系结构。在开发过程中,在裤子旁边飞行和牛仔编码可能是最糟糕的事情。设计阶段将持续一周,将为您节省数月的编程时间,并使代码首次实现应有的功能。TDD背后的想法是您不必更改测试。这些测试旨在模拟现实世界的可用性,如果您的代码无法完成测试,则您的代码是错误的。
Mike S

我的经验不然,但是我想这取决于牛仔和团队:)经过一周的编程我学到了更多东西,并且做了一些代码来证明。当然,如果您不进行极端和连续的重构,并且拥有足够敏捷的团队/牛仔来跟上,您的架构就会很糟糕。认为您可以进行“设计阶段”,学习所有内容并在第一时间做到正确就太天真了。原型的真正价值在于您可以学习到的教训,将其丢弃并正确完成。多次且快速地执行此操作:)
洪德堡2011年

0

程序员的障碍:与其他速度下降不同,此问题更难解决。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.