如何成为一个“更快”的程序员?


142

我最近的工作评估只包括一个弱点:及时性。我已经知道我可以做些改进的事情,但是我正在寻找更多。

在提高其输出速度而又不牺牲其质量的情况下,是否有人对它们进行提示或建议?

您如何估计时间表并遵守时间表?您如何做才能在较短的时间内完成更多工作?

非常感谢您提供任何反馈意见,谢谢,


96
如果您愿意,可以在工作上花费更少的时间。
圣哈辛托2009年

52
如果您正在阅读

32
我读了“如何成为一个胖胖的程序员”。让我大笑
marcgg

13
我想问你一个后续问题。是您由于自身绩效不佳而导致要成为“更快的程序员”的愿望(又名,您需要磨练自己的技能,需要集中精力并消除分心的事情(例如SO)等),还是由于开发计划不佳而导致的立场(又名,您有1周的时间做任何理智的人都会知道的事情,将需要1个月的时间)。每个项目都有非常不同的解决方案。

3
不可能有一个正确的答案,因此请将其变成社区Wiki问题,或者让您解决该问题。
多纳研究员2010年

Answers:


190

关闭电脑。拿起铅笔和一些纸。草绘您的设计。与您的同行一起复习。然后编写代码。


9
或者,您可以保持计算机电源打开并打开,即MS Visio
sshow

208
铅笔和纸或白板比我使用的大多数应用程序快。
托马斯·欧文斯

24
在纸上做的事情集中了思想。

100
为什么我不能对visio评论投反对票?不使用visio是加快开发的某种方法!

52
gh .... Visio。每当我被要求“在设计文档中使用Visio”时,我都会先在纸上画出草图,然后在接下来的两天中进行努力,以使Visio中的所有行正确无误。
罗伯特·弗雷泽

149

一些想法...

  • 避免镀金-仅执行要求您的要求(就要求而言)
  • 了解业务需求并在第一时间做到正确
  • 彻底了解您的环境和工具
  • 成为出色的打字员,使用键盘快捷键代替鼠标
  • 采取迭代方法并进行健全性检查,以确保您走上正确的道路
  • 不要重新发明轮子,考虑重用过去的工作和其他人的工作
  • 消除干扰,不要继续检查电子邮件,向外看,与同事交谈等。
  • 不要过度劳累-识别何时需要休息

7
+1表示不重新发明轮子。学习生成可重用的代码,可以将其插入另一个代码中,而无需进行任何小的重写。(例如:带参数的功能,而不是硬编码)

34
+1表示“避免镀金”-这是由于我追求完美/保留肛门的趋势而导致我错过太多截止日期的原因。
迪纳

7
打字-重点。总是惊讶于我遇到的尚未学会打字的编码员的数量...
Paddy

2
+1消除干扰。如我所见,它们是主要的时间食用者。

2
+1以获取微观改进的提示(而不是在计划项目方面进行宏观改进)。

132

您自己想成为“更快”的程序员的愿望值得称赞。但是,不按时交付并不意味着您很慢,这意味着该项目的计划不佳。成为“更快”的程序员无济于事。这只是意味着您可以更快地超过截止日期。

您(和您的团队)正在执行以下错误之一(或所有错误):

  • 低估了需要完成的工作;
  • 在规划过程中遗漏了很大的需求或体系结构部分;
  • 工作估算与日历估算相混淆,而不考虑会议/电话/其他开销等问题;

您可以通过多种方式解决上述三种情况中的任何一种。但是,在对它们中的任何一个进行改进之前,您需要知道事情为什么会如此发展。对最后两个或三个项目的估算值与实际花费时间进行事后检验,找出多余的时间在哪里。

我会再重复一遍- 如果您已经适当计划了这一事实,那么编写代码的速度就不会导致错过最后期限


47
有些开发人员确实太慢了。可能是个问题。

12
是的,这可能是个问题,但这是个人问题。它永远不会成为项目或团队问题。换句话说,它可以影响一个人的事业,但绝不影响项目进度。
弗朗西·佩诺夫09年

12
“不按时交付并不意味着您很慢,这意味着项目计划不周全”-这是无效参数的文本框描述。还有许多其他原因导致您无法按时交付,其中之一很可能是因为您的速度很慢。
肉2009年

15
@flesh-如果您知道自己的速度很慢,为什么不计划时间表以解决这个问题呢?换句话说,如果您知道自己的运行速度不如Usain Bolt,那么您打算在9.7s内运行100m吗?
弗朗西·佩诺夫2009年

5
@Kibbee-在这种情况下,您将剪切功能。当您知道自己无法完成并希望创造奇迹时,您不能承诺在特定时间内完成某些工作。
弗朗西·佩诺夫09年

89

真的,真的要学习您的编辑器。如果使用IDE,请确保使用了它提供的所有功能。获取备忘单,以了解所选编辑器的键盘快捷键。如果您使用的是Shell,请为常用目录设置快捷方式


3
实际上,有时确实可以极大地提高生产力
sshow

6
编写实际代码只是开发人员工作的一部分。花时间学习IDE达到完美是一个重点优化。而且您知道他们对优化的评价,不是吗?-“先测量,然后优化瓶颈”。
弗朗西·佩诺夫09年

1
我完全看不到。如果我将打字时间缩短了50%,一天能节省多少时间?根据我的经验,与实际编写代码相比,我将大部分时间都花在思考/测试/评估/略微修改/等代码上,我认为这最终将不会是什么胜利。

4
它使您无需思考就可以在IDE中导航。任何需要付出一切努力的事情,例如移至带有标记的灰色小按钮或其他所有灰色小按钮旁边的其他按钮,都会打扰您的思维,从而使您减速。按住Ctrl键不动不动是一个巨大的净胜利。
Paul McMillan

5
同样的道理:学习一般的“热”键。例如,在许多Windows程序中...复制:Ctrl + c剪切:Ctrl + x(“ x”看起来像是一把开放的剪刀)粘贴:Ctrl + v(在上面的“ c”和“ x”旁边)转到行首:Home转到行尾:End按单词(非字符)移动光标:[Shift] + Ctrl +左或右转到文档顶部:Ctrl + Home转到文档末尾:Ctrl + End等

38

“有人在提高输出速度而又不牺牲输出质量的情况下,有任何技巧或建议吗?”

许多人以(a)简单,(b)可靠和(c)正确的东西为代价来追求“终极”质量。

加快开发速度的最重要方法是简化您的操作,以使其尽可能地简单。

大多数在按时交付方面存在问题的人都在交付方式,方式太多。给出的原因通常很愚蠢。它们通常只是感知的需求,而不是实际的需求。

我听到很多人告诉我客户的“期望”。这是一个坏政策。

构建最简单的东西。如果客户需要更多,则增加数量。但是首先要构建最简单的东西。


“许多人以(a)简单,(b)可靠和(c)正确的东西为代价,追求“终极”质量。” 您可能会留在那儿,而我会投赞成票。
corymathews

“简化,简化。” 〜亨利·戴维·梭罗

2
是的,这也意味着过早的抽象。如果某个东西只有一个实现,则不要使其成为接口。
罗伯特·弗雷泽

3
在这种情况下,我最喜欢的一句话很合适,即“使事情尽可能简单,但不要更简单”〜释义,阿尔伯特·爱因斯坦
Nemi

保持简单是许多程序员都无法正确实现的:他们容易陷入“过早的优化是万恶之源”的陷阱。通常,最简单的程序是最快的程序或质量最高的程序之一。

32

避免完善代码,仅使其工作即可。这就是企业的期望。

但通常,提高速度意味着要牺牲质量。


10
如果时间允许,我建议您“使它正常工作”!
Preets

28
-1:没有理由牺牲质量。您可以随时牺牲功能。
S.Lott

6
我已经看到它反复发生。开发人员迷上了给定功能的最后1%,然后尝试追赶并落后于尝试完成其余功能。首先完成对您的期望,然后再进行抛光。

3
通常,提高质量意味着提高速度。如果您花一点时间首先解决问题,则可以节省更多的测试和调试时间。
David Thornley,2009年

2
如果您坚持使用一项功能,请进行其他操作。

29

重用-我尝试排除以前项目中的任何巧妙之处,以便在以后的项目中再次使用它们。总是值得问自己:“有一天我可以再使用一次吗?”


从长远来看,完美的思维状态可加快编程速度,尽管起初可能会花费更多时间。

8
+1:不过请注意,我发现自己对某些内容进行了概括和抽象,以便第二天可以再次使用它……错过了当天的截止日期或将错误修复所需的时间加倍了……以便我可以“也许”以后可以节省时间。
史蒂文·埃弗斯

2
拥有“技巧包”是关键。如果这对您来说是一个工作问题,那么值得花费您自己的一些时间来开发可重用的部分(假设您工作的域可以进行代码重用)。

24

把事情简单化。

如果使用TDD,则应遵循“ 红色,绿色,重构 ”:

  1. 编写失败的测试(红色)。(通常出于您的代码尚不具备的功能。)
  2. 犯下可怕的编码犯罪,以使您的测试通过(绿色)。必要时进行硬编码。
  3. 重构,可能会在短时间内破坏测试,但总体上会改善设计。

3
在进行TDD时,您有一个测试运行器,它为每个测试生成一个红色/绿色报告,以指示它们是否通过。

2
@Konstantin:使用TDD编写某些代码可能会花费20%的时间,但是它也会产生更好的代码,并且从长远来看,当系统扩展时,进行更改的速度将保持不变。TDD可帮助您避免因技术债务而减慢您的速度。

3
键入从来都不是编程的缓慢部分。即使您需要使用TDD输入更多内容,它也不会减慢您的速度。它甚至可能会加速你了,因为写一个测试第一个可以帮助你专注于什么考虑之前,需要如何实现它。

1
如果管理层不理解某些关键概念,则应向他们解释。例如martinfowler.com/bliki/TechnicalDebt.html

3
@Konstantin,如果您认为“开发”是编写代码声明的行为,那么我会同意您的观点。但是,如果您认为“开发”包括打包,准备构建说明,部署,测试,生成缺陷报告,检查缺陷并对其进行优先排序,任务分配,调查,调试和修复并重新开始该过程,则需要15分钟编写单元测试要花费的时间超过客户信任度损失的1000倍以上。

22

将您所有的语言/库文档本地下载到计算机,然后拔下网络电缆/关闭Wi-Fi

不想在这里变得有趣。这真的对我有帮助!


我也一样。

无论如何,在线文档和故障排除搜索都被高估了。

安装防火墙并将其配置为阻止几乎所有的Web访问(某些域例外,例如MSDN)
finnw

我真的在考虑这样做(我留下的评论证据足够多的事实)
Ikke

并因此失去?地狱无

20

请注意,当您阅读堆栈溢出时间太长时。“编译”借口只能使用这么长时间。:)


15
取决于编译器的速度。因此,也许“解决方案”是找到速度较慢的编译器,然后在带有128MB内存的Pentium 2上运行它?:-)
弗朗西·彭诺夫

@Franci,甚至可以将交换空间放在软盘上。RAID中的两个。

20

避免过于频繁地切换任务。即使您使用Mylyn之类的工具来管理任务,分心和任务切换也可能会浪费一天的时间。

确定粒度(例如30分钟),然后仅处理与当前任务相关的事情。其他任何问题(新的错误报告,有关其他问题的电子邮件,不相关的程序问题)至少会延迟到“下一个检查点”。确保禁用弹出的电子邮件通知,以免您陷入困境。

如果您的团队中有一个好友,他会告诉您事情是否真的融化并需要您的立即关注,这特别有效。


如果您的老板希望在10分钟之内回复电子邮件,则此方法将无效。
finnw

这实际上是非常相关的。在合理可能的范围内,不要让自己沦为自私的吸引人的受害者,并坚持自己的原始任务。如果您让自己陷入不同的方向,那么最终结果就是您一无所获,无所不能。
AndyUK

14

第一次正确地做最好的方法。如果那意味着您必须停下来思考一下,然后再开始,那么那就做吧。90%的时间有效。


2
+1这是真的。这并不意味着您必须“完美”。我们所有人都会犯错。但是,如果我们第一次就能以最好的方式做事,那么这些错误的后果就会小得多。

+1-我似乎记得在某处读过,好的程序员和坏的程序员之间的区别不在速度上。不同之处在于,好的程序员将保留更多的代码。
杰森·贝克

这是我的座右铭,第一次正确的做法。不要养成必须总是回去修改代码的习惯,因为您没有按照规范正确地进行操作。

“如果您没有时间做正确的事情,您将如何有时间做完呢?”
亚历克斯·费曼

您可能需要从实际经验的软件才能够确定什么最好的方式。在这种情况下,您第一次就无法正确处理。

14

学会尽快打字


2
这是一个不错的奖励……但是我认为这不会对整体产生太大影响。键入代码可能是最省时的部分。(是的,我关注并阅读了链接。我不同意他的

如果编码的限制因素是您输入内容的速度,那么您可能在错误的抽象级别上工作。
Pete Kirkham

+1。有很大的联系,对于那些谁读给结束了一大篇;)我打字很好,但它激发了我切换到程序员德沃夏克键盘布局en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard(但我切换了“”和-_键(使用Microsoft键盘布局创建器),我敢肯定,我很快就会打字得更快了:)另请参见:typematrix.com/dvorak
Roman Boiko 2010年


12

实践和努力。

您需要花费时间和精力。随着您对使用的任何工具变得更加舒适和自信,速度和创造力也应随之而来。

如果您想提高任何特定技能,也可能有助于设计练习,使您可以专门从事此工作。如果您的设计进度很慢,请尝试查找可在线处理的设计问题。重做相同的练习将使您更快地完成练习并加快练习速度。我个人喜欢TopCoder的算法练习,以练习纯粹的编程速度。它们也有设计挑战,但我没有尝试过。


在编程中,实践常常被低估。这应该是最重要的5个答案之一。

哇。不知道为什么它也不高。我从来没有尝试过。我会试一下!
大卫

11

了解有关“区域”的信息,了解如何使自己进入该区域,并学习如何识别自己不在的区域。

一旦我“处于区域内”,我就会变得非常有生产力,并且代码刚从我体内流出,通常我可以在1天之内完成2或3天的编码。但是我发现通常很难到达那个地方,我发现自己拖延,被其他事情分散注意力(例如Stack Overflow)。

引用从什么技巧开始,您就可以在自己的区域中使用


如果您在区域内,则可以不吃午餐...或熬夜... MMMmm该区域。流口水

10

熟悉您的IDE和框架。每件事都必须转向Google,这需要时间。


但是,意识到何时需要Google并能够快速做到这一点也很重要。


8

在开始开发之前:

  • 注销您的邮箱
  • 关闭所有IM客户端
  • 礼貌地请同伴给你时间集中精力
  • 当然,停止上网

每次您被打扰时,您都会放慢脚步,因为它会花费您的时间来使其思想重新回到正轨。我听到的数字显示,每次中断,人的大脑需要5到10分钟的时间才能恢复到中断之前的思维过程。每次中断有这么多时间,浪费一整天并不需要太多时间。

实际上,我们公司的员工已经习惯于推迟日历时间,然后每天搬到空旷的会议室几个小时。


7

内外学习您的开发IDE。了解快捷键。学会少用鼠标。我发现这为我节省了很多时间。


7

您是否比同事慢,或者您的估计是否过于乐观?


7

为了更快地生产软件,我发现最好的方法是尽可能地学习您的运行时API。当LINQ扩展可以使用时,请不要键入列表逻辑。当绑定可用时,不要构建一堆事件监听器,等等。

据估计,这是有经验的。您可以在那里使用估算软件来帮助您确定更好的估算。

就个人而言,我发现与初级开发人员一起,将他们最初的估计数乘以2,然后将其加倍。这将包括所有的学习,会议,浪费的时间等。高级开发人员的工作往往比他们的估计高2倍。

通常,问题不是您的估计是否错误。您的估计是否解释了所有正确的事情?您是根据编码工作量还是日历时间给出估算和时间表?想一想您一天中的所有时间,其中有多少是实际的,富有成效的编码,而不是会议,学习,调试等。


3
“ ...乘以2,然后再乘以两倍。” 由于您有兴趣节省时间,因此我为您提供了一些数学提示,您也许可以使用...

大声笑-我知道你在说什么。但是,您常常会被这种疏忽而忽略,而不是说“乘以4”。

7

可能暗示了两件事,但我尚未看到可提高生产率的答案:

  • 使用某种构建和部署脚本。编译,部署,重新启动应用程序服务器,并且不会浪费时间或精力,这应该是一键式的事情。

  • 有某种版本控制。无需回滚更改就可以编码,就像在踩鸡蛋一样


7

有两个想法:

  1. 从您的估计中获取其他意见-是否有其他开发人员会问类似“嘿,您认为可以在此时间范围内完成这种功能?”的问题。在某些情况下,其他人的输入可能有助于提高准确性,因为有人可能会注意到您在进行估算时错过的一堆东西。

  2. 磨练您的估算技能-开始跟踪您的估算状况如何以及为何中断:其他工作项是否导致无法按时完成?您是否一直低估事物的复杂性?您是否在不可行的情况下给出了完整的时间表,例如,所要求的内容很模糊,以至于仅仅准备一个原型就需要数周的时间,然后应该重新评估要做什么?这样做可能最有助于建立该技能,因此,如果您说某件事将花费x个小时,您将对此充满信心,因为您已经一遍又一遍地重复了。另一种陈述方式是实践,实践,实践。

当然,您可能已经考虑过这些,但我认为值得为那些尚未考虑这些想法的其他人指出这一点。


7
  1. 全面了解技术。
  2. 停止!认为!走!
  3. 架构师可以解决任何可能出现的问题,但是只能执行真正需要的内容。
  4. 吻-保持简单愚蠢
  5. 如果它变得太复杂,则可能不是很好的想法。(回到2和4)
  6. 不要卡在5中。通常需要从头开始(返回2和4)。
  7. 回到1。

7

我认为这里的关键词是“及时性”。他们没有说你太慢,而是说你不及时。

在项目管理中,经理必须能够准确估计何时完成您的工作项目,这一点很重要。我怀疑您的工作不及时的主要原因是您经常遇到未按计划交付且交付时间比计划晚得多的项目。

为了提高您的时效性,您可能需要花费更多的时间来了解在给定您的技能,经验和领域的情况下,完成特定工作项目将花费多长时间。这将使您可以向项目经理提供更好的估计。这里的关键是“更好”……您可以通过用软糖填充所有内容来按时交付,但是您真正想要争取的是更准确的估算。

我将与您的经理讨论此问题,以查看是否确实是问题所在。否则,您可能会以比以前快一半的速度,以两倍的速度完成编程工作,并在以前的一半时间内完成了一些有前途的事情,并且由于估算仍然具有相同的错误系数,因此仍然因其及时性而受到批评。


“ ...根据您的技能,经验和领域,花更多的时间来了解完成一个特定工作项目将花费多长时间。” ->对,这还将帮助您缩小范围并节省更多时间。
Jim G.

它还将帮助您的经理对周围的人看起来很好-还可以与您的项目同步完成诸如营销之类的辅助材料。
汤姆·利斯

7

保持稳定,保持稳定。

构建一些实现少量功能的东西,并确保其端到端有效。然后,在添加新功能时使其保持工作状态。是的,这在某种程度上是TDD的做法,但是即使您不进行TDD也是有道理的。

这样做的理由是,每当我看到有人用两周的代码编写出从未稳定过的代码时,总是需要另外两周才能使其保持稳定。

如果您保持稳定,则可以消除不确定性,并在必要时为自己提供一种在截止日期之前缩小范围的方法。

明显的反论点是,这样做将比编写一次代码花费更多的时间,因为您将做更多的工作来稳定非最终代码。我一秒钟都不会买。当您的代码有效时,您更改了5行,并且发生了中断,您确切知道中断必须发生在哪里。

如果您有10,000行从未使用过的代码,并且必须找到一个中断,那么您就有大量的代码可以搜索。

在始终稳定的FTW的系统上进行小的增量更改。慢走快走。


7

对我来说,获得良好的生产力对您要实现的目标以及如何实现目标有一个清晰的认识。


1
我花30分钟的自行车骑行时间穿越挪威的乡村,这也很能打定主意,并使创作过程不断进行。

6

在这里和其他地方的许多地方,几乎所有答案都被说死了。或者,至少我听说过死刑。学习您的IDE,学习更快地键入内容,使用框架,使用代码生成,等等,等等。当然,这些事情会有所帮助,而且我怀疑有很多程序员是他们的大师。但是作为询问这些问题的程序员类型和像Stack Overflow这样的常见网站,您已经知道这些。您只是想在这里让他们重复一遍,还是只想发泄一下?

但是,如果我们能够达到那种状态怎么办?我的意思是掌握所有这些建议?那会发生什么呢?好。我猜想时间表会进一步减少。再一次,我们将恢复对质量的看法。我的意思是,几十年来,我们的工艺确实取得了进步,并且生产率越来越高。但是,这段时间的质量是否有所提高(当然不包括早期的课程)?

我的答案很简单:优质软件需要时间!您只能以一种换另一种(质量/速度)。但是,是的,我们都知道,但是,我们对折衷往往会在规模的速度方面最终结束的程度并不诚实。在项目初期,我们甚至是更大的骗子!

我说你这里没有错。问题在于人们对优质软件应该使用多长时间的看法。我们自欺欺人,以为我们有能力根据经理甚至是猜测的时间表来创建高质量的软件。我们不生产高质量的软件。我们编写的软件可以正常工作,但有时在应用程序的某些角落会闪烁一些质量。

那么我们该怎么办?我们不能仅仅说服老板,我们需要将每个项目的投资增加一倍或两倍。我说以身作则。创建一个真正出色的软件作为辅助项目。投入自己的时间,不要妥协。始终注意您的进步。记下您似乎不得不花费大量时间的看似无关的任务,并查看是否可以证明其合理性。将此与您工作过的所有其他项目进行对比。要敢说真话与您自己以及此分析的各个方面。您使用质量软件所做的额外工作是否可以在工作中的“真实”项目中忽略?但是也许您的尝试失败了。是什么原因 您是否感到无聊而又急于完成核心功能?我本人还没有做过这样的事情,这就是为什么我会怀疑地结束这种想法的原因-但我打算真正付诸实践。我会及时向大家发布 :)。

最后,我认为大多数(如果不是全部)绩效评估都是错综复杂的,而且极具操纵性。您无法将质量和速度控制在100%。您的老板应根据组织设定的标准给您打分。组织在质量和速度之间进行权衡的标准。假设OrangeSoft Inc.期望33%的质量和66%的速度。因此,如果您编写的代码可能具有单元测试的三分之一,但是应该以更快的速度并缩短交付时间来弥补,则您的评论应获得接近100%的评分!(这些都是粗略的类比,但您明白了)。但是,相反,发生的事情是Bob编写代码的速度非常快,但是臭名昭著的是它的错误。因此,在他的绩效评估中,他的质量得分为3/5,速度得分为5/5。另一方面,Carol编写代码的速度要慢得多,但产生的错误却少得多。她的质量得分为5/5,但速度得分为3/5。鲍勃和卡罗尔无论哪种方式都会加薪。任何员工都有可能获得完美的成绩吗?这公平吗?


5

我使用的技术是进化原型

您可以在Google上搜索更多信息-但是如果需要快速生产某些东西,这是唯一的选择。另外,它的好处是,当用户说他喜欢它时,您就完成了(...并可以开始编写文档)。

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.