it-swarm.cn

编程中的有害诱惑

很好奇,编程中的哪种诱惑对您的项目真的有害吗?

就像当您真的感到有做某事的冲动,并且相信它将使项目受益时,或者您只是欺骗自己相信它确实如此,而一周之后,您意识到您还没有解决任何问题真实问题,但创建了新问题,或者在最佳情况下,它使您的内在野兽感到愉悦,而没有明显的影响。

就个人而言,我很难不重构不良代码。我处理了许多不良的旧代码,并且当我没有测试证明重构不会破坏任何东西时,需要花一口气才能不碰它。

在用户界面上对我来说,这是另一个恶魔,我可以花几个小时来更改UI布局,只是因为我喜欢这样做。有时我告诉自己我正在研究可用性,但事实是我喜欢四处移动按钮。

您的编程恶魔是什么,如何避免它们?

97
Dan

过早的概括是我的大错误。而不是先解决手头的问题首先并等到有实际需要解决一般情况时,我总是着眼于一般情况结束编写大量比所需复杂的代码。

更新:

有关详细说明,请参见“ 罪孽#1-过早泛化 ”。

67
John Bode

“我们将回到此位置并稍后进行修复。我们只需要它现在就可以工作!”

197
user18041

截止日期很遥远,我有足够的时间来做,所以为什么不花一点时间在网上冲浪呢?

105
user281377

“这只是扔掉的概念验证代码。一旦他们喜欢它,我就会把它做好。”

103
davidhaskins
  1. 重构发布前几天的部分代码。
  2. Internet:所有事情中最大的干扰。
  3. 新技术:无法摆脱新技术。
  4. 优化:优化,优化。 ..和更多优化
  5. Perfection:从未对代码感到满意。
  6. TODO:缺乏时间的待办事项永远不会做。
  7. 时间估计:许多PM并不将其视为“估计”。他们认为是事实。
  8. Promises:给出过多的承诺。
74
Amir Rezaei

在存在现有框架和库的情况下,尝试内部构建所有内容将成为pre脚。

55

我经常遇到的恶魔:过早的优化和过度设计。

而且我仍然无法避免他们100%...

48
Tomas Narros

过于乐观的估计

当您的经理凝视您时,您会感到发烧的感觉要比您的直觉告诉您的要低...不要这样做!

毕竟,您的直觉是可能已经太低了!

46
Nicole

纯粹是因为您刚刚学习过,就可以在项目中使用技术/工具/语言。

试图证明您是一名优秀的开发人员。

考虑您编写的代码是您自己的。

33
biziclop

我休息一下,看看stackoverflow.com;)

32
Richard Miskin

最糟糕的诱惑:

哦,好吧..我猜一个肮脏的小把戏/破解/修复不会受伤。

猜猜是什么,它确实很疼。 :)

goto

31
Goran Jovic
25
Dan

特征蠕变

制定计划,坚持并部署。然后then返回并添加人们要求的内容。

我一遍又一遍地看到了这一点。您坐下来,进行设计,然后开始编码。用户听到一些关于他们最喜欢的功能“丢失”的胡说八道,然后开始游说它。您的老板要求您在第11个小时添加它,这会破坏部署,并在所有地方引入错误,然后3个月后,每个人都安顿下来后,系统要求您删除它,因为没人知道为什么要放置它首先是糟糕的复古功能!您能否说出其余的设计毫无意义?

23
Satanicpuppy
  1. 添加更多功能

  2. 比赛具有此功能。因此,这是必须具备的功能,因此比分析策略,定位等要多编程。

  3. 比赛没有此功能。因此,这是一个与众不同的功能,因此比分析策略,定位等更具编程性。

  4. 通过更多编程解决业务问题。例如,无法通过对更多功能进行编程来获得更好的管理网站托管Linux服务器的专业知识。有时,您只需要学习如何解决问题,而不必将整个过程重新编码为C#.Net

  5. 通过更多编程解决营销问题。例如,滥用Seth Godin的“紫牛”概念,即您通过在产品中编程更多功能使其成为“紫牛”来间接解决营销问题。有时,它只是一个突变怪物。

  6. 通过更多的编程来解决生产力问题,并认为自己编写该脚本所花费的时间将在未来数小时内节省,而不是实际编程真正重要的东西

  7. 计划进行编码但尚未进行编码,因为您想“正确处理”

  8. 编写一个肮脏的版本,并承诺您将“以后做得更好”,但是从不退缩到“做得更好”

  9. 不做模型或站点地图,因为它“太麻烦了”。我可以截取竞争对手的页面以获取模型和徒手绘制的站点地图“以后”,这是从来没有的。然后,直接进入编程的第一页即可。

告白:我个人犯了错误1、3、7、8。我也犯了2、4、5、6,但我常常自欺欺人,我没有。

我目前正在补救9。

[〜#〜]编辑[〜#〜]没有意识到这个问题需要我们提出解决方案。

1)添加更多功能只是不要这样做。与您的企业,市场营销,创始人,顾问等合作,将您的应用程序简化为一件事情。

阅读有关Twitter, Groupon 等的文章,了解他们如何将事情分解为仅一件事,从而促成他们的成功。

如果您认为只有在要建立大公司时才能奏效,请再考虑一下。这行的Ctrl + F“ 此链接 ”中“我添加到软件的功能越多,销售的越差。(不用说,这对大多数软件开发人员来说是非常不直观的。)”

2)比赛具有此功能。因此,这是必须具有的功能

请参阅解决方案1

3)比赛没有此功能。因此,这是一个与众不同的功能

请参阅解决方案1

4)通过更多编程解决业务问题。

如果您需要雇用某人来教您,进行咨询或为您做咨询,然后记录下他的做法,以便下次可以自己进行。去做就对了!!不要重写代码,不要通过GO,不要收取200美元。

5)通过更多编程解决营销问题。

如果人们不了解您所销售的商品,那就等于IS一个营销问题。回到解决方案1并进行调整。

6)通过更多编程解决生产力问题

等待。

等到您感觉自己的生产率受到特定生产率问题的困扰的时间超过2周,并且合理的情况下还会持续2周。

现在,评估对脚本进行编程以解决此问题所花费的时间。切记进行最坏的估计并乘以2。

将您的估算值乘以每小时费用。

现在查看备用解决方案:外包,购买现成的解决方案,不做任何事情等等

选择最具成本效益的解决方案。

坚持下去。

7)计划进行编码,但尚未编码,因为您想“正确处理”

去运动吧。您会感觉到内啡肽的涌动,这会激发您的屁股并让您计划采取行动。我知道这是因为我刚做过5x5卧推和5x5蹲坐。

8)对脏版本进行编码,并保证您将“以后做得更好”,但是从不回过头来“做得更好”

在GTD中设置代码文件系统。并积极跟进。遵守对自己和他人的所有诺言。

9)不做模型或站点地图,因为它“很麻烦”。

花费75美元购买balsamiq样机桌面版。我知道这是因为我3周前买了它。这使我重做了我的模型,因为即使我在现实世界中的绘画很糟糕,我也像艺术家,建筑师和有远见的专家一样合而为一。 balsamiq中使用的字体不自觉地提醒您这只是一个模型,而不是固定在石头上的,这可以帮助您使用RAD。

结束编辑

20
Kim Stacks

几杯啤酒将帮助我更好,更长时间地工作。

17
Adam Crossland

“是的,我可以在一天之内将这行2000行的细面条重现一遍……”

16
Hila

“我可以不用测试就可以通过。这很难测试。”

这是邪恶的兄弟

“无论写作或理解有多艰辛,我都必须对此进行测试。”

16
Wayne Conrad

拖延症乐观任务估计是我最大的罪过。

对第一个进行拉伸,俯卧撑或引体向上(或任何其他体育锻炼),然后对第二个进行估算,然后保持悲观情绪。

15
Nikita Barsukov

“与理解现有代码相比,'更容易'到从头开始重新实现功能太多了。”

13
k3b

我所从事的项目遭受的一项极为有害的诱惑是“内部平台效应”。这是建筑师的一种方法,他们早已不复存在,他们凭借自己的无限智慧建立了一个项目,该项目每年产生约2000万美元,但更新和维护成本为6000万美元(显然,这是一个粗略的数字,问题)。

10
AlexC

[〜#〜] nih [〜#〜] -此处未发明

我很难给第三方解决方案一个公平的机会。每个人都应该自然而然地为并非为他们量身定制的第三方解决方案表示怀疑,但是我很难做到100%客观。

这样可以节省大量时间,即使应避免使用十分之三的第三方解决方案,我也要有足够的客观性来实现one 那可行。

10
Nicole

必须有一个在某处执行此操作的库综合症。

与...密切相关

插件恋物癖

9
Newtopian

针对提供的“样本数据”进行设计,编码和/或单元测试,而不是分析客户实际数据库的副本。截止日期很短,他们一直说即将到来,但从未成功。部署时,爆炸非常壮观。的确,谁期望一个客户有3个父级客户。

在拥有real数据的副本之前,我将永远不会再开始一个项目。

9
dwidel

完美主义会杀死人;项目未成功的最可能原因。

8
Naftuli Kay

重写而不是重构。

7
Dave O.

好吧,有时候编程会把我带到瓶子里。

7
mipadi

认为必须有更好的方法来做到这一点。我不会满足于“足够好”的东西。我正在追求完美!通常,通过与可能对问题有不同观点的其他人交谈或从不同角度看解决方案来避免这种情况。

6
JB King

自动化所有操作的时间要花在维护工具上的时间要多于实际工作。

解决方案:就像代码优化一样,首先发现生产力瓶颈,只有发现它们后,才能通过一些良好的自动化方法加以解决

5
Dan

您的编程恶魔是什么?

除了其他一些人提到的。

优先级:忽略相对于项目的高优先级工作,而首先处理项目中的其他事情,因为它们更有趣!

您如何避免它们?

有更多的自律能力。认真地讲,做事正确的自律和自我动机有助于避免这些“恶魔”的发生。

4
Mahesh Velaga

这个项目使我的大脑筋疲力尽。我将在这个简短的项目上稍作休息,以使其恢复活力。

3
emragins

"There must be a better solution to this."

然后,您最终开始思考和思考,然后让您的思想漂移到一个遥远的地方,直到您意识到自己离开太久了。没问题,但是没有截止日期。

3
gladysbixly

我们尚未得到客户的批准,但是截止日期临近,因此这里有一些初步的建议,以便您可以开始使用...

稍后,在您完成构建项目以匹配伴奏之后...

哦,这是客户的修订,他们只想更改一些小事情*

(*主要功能完全不同)

然后,您将基于原始的缺陷模型继续重构原始代码,而不是仅仅从头开始,因为您面临着期限很短的压力,并假设这些是最新修订版。

我一直都被这个迷住了。作为Web开发人员,这是很难避免的。我最好的建议是多推一些时间,以便您可以正确地进行更改。

3
travis

在代码冻结日期之后编写新代码。

代码冻结日期必须固定。之后编写的任何新代码都必须移至将来的版本,因为它可能需要进行各种回归测试。

3
Mag20

要回答有关避免它们的问题:熟悉 Anti-Patterns ,以便在识别它们时可以将它们叫出来。

3
Lee Kowalkowski

聪明当然,并非总是如此。一些巧妙和简洁的代码将使您的代码看起来非常漂亮且可维护。但是只是因为你可以做

x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;

而不是两行if语句,并不意味着您应该这样做。

顺便说一句,是的,我知道我的示例中有些多余的内容……如果您自己也发现了它,:)

3
Earlz

所有其他功能都带有蠕变:“如果这样做的话,那真的很酷,我知道客户会喜欢它的,如果他们考虑过的话会把它放在规格中”。我试图通过询问实际规格中该真正酷功能的需求来避免这种情况。

再说一次,我很少得到书面规格。

2
PSU

“这只是试验,因此无需使其易于维护或扩展”。

以我的经验,比起将飞行员废弃并将实际产品开发为可投入生产的状态,更常见的是看到飞行员进入生产阶段并认为应该将其作为报废的产品。

2
jwenting

花太长时间来调整编辑器。试图找到最佳的字体和配色方案进行编程。

2
dheerosaur

“我被分配了与[软件/例如:sharepoint]交互的功能。我可能应该知道有关该软件的所有知识。”

然后,您可能需要花数周的时间研究该产品,而一两天之内就可以编写和测试该功能。对知识的渴望有一个黑暗的弱点。拉尔

2
Steven Evers

“我稍后再评论/记录”

这种情况永远不会发生,作者继续前进,然后您发现当工作分配给您时,他们没有注释他们的代码。

2
sunwukung

开始攻击一个新项目时,不了解它,通常我会在真正开始使用它之前先对项目领域进行一些研究,只是为了找到一个好的起点,并证明该项目比我最初是通过它的。

我也有个问题,我喜欢按动按钮,它们太酷了!!但这也许是因为我正在做多媒体系统和用户界面设计...所以对我来说,这个问题的解决方案是将其实际包含在我的课程中并对其进行研究,这样我就可以找到一个有效的借口我经常玩UI。 (其中包括将背景设置为绿色,将文本设置为橙色,并在图标上添加很多黄色。)

1
Coyote21

非常完整的列表: 反模式

1
vartec
/**
* Calculates the return value for humptyDumpty
*
* return int modifiedHumptyDumpty
*/
function awesomeWayToCalculateSomething(int humptyDumpty) {
.. 
}

待办事项:我需要适当地记录下来。

Will _never_ happen

1
András Szepesházi

使用语言功能,习惯用法或设计模式不是因为它是解决问题的最佳方法,而是纯粹是为了使用它。

1
Dima

我想我觉得枚举比Java实际有用得多。我倾向于尝试对它们做太多事情,然后陷入困境,因为它们并不真正支持多态。

1
MattLBeck

过度致力于避免内部开发,90%的轮子并不比发明一个轮子好。

1
M. Utku ALTINKAYA

在未完全了解框架的情况下使用框架。但话又说回来。框架只有其创建者才能完全理解(大多数情况下)。对于该项目,我没有真正的解决方案,但尝试从框架中尽可能多地了解。

1
user18483

修复因“如此简单”而困扰您的错误,但永远不要告诉质量控制和/或客户。

这些修复程序总是使生产崩溃。

1
Scott McIntyre

有人说过早泛化,但是过早泛化可能同样糟糕。通过过早的泛化,您可以获得可以在50%的情况下工作的软件,但是过早的泛化可以在5%的情况下工作,或者没有。最后,管理层宁愿拥有50%而不是5%。

1
MPelletier

在我休假的时候为公司做了无数小时的额外工作,结果才发现“那不是他们想要的方向”。

1
user13280

你的编程恶魔是什么

已经提到的所有内容,尤其是疯狂地重构的渴望。

以及如何避免它们?

在开始任何不重要的编辑之前,请先将我的手从键盘上放下5秒钟,然后快速权衡一下更改与保留更改的可能结果。然后再次提交之前,将相同的结果权衡一分钟。

1
Cheezmeister

为了找到一个舒适的沙发上班或躺在床上工作。

1
kiewic

被“完美”

虽然第一次避免正确使用它是一个问题,但它还不如对完美的不懈追求那么糟糕。 只需完成,就没有完美的东西,如果存在,那纯粹是暂时的,或者已经完成了,不值得再花时间去做。

0
blunders