编程中的有害诱惑


97

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

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

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

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

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


19
我很幽默,没人能回答您问题的第二部分-“ [以及如何避免它们?”。
Craige '02

3
有没有人注意到这一直是SE整天的头号问题。
msarchet

我为“ ...花费大量时间更改UI布局...”而为此+1,我经常陷入这个陷阱。
2011年

Answers:


67

过早的概括是我的大错误。而不是解决手头的问题的第一和等待,直到有一个实际需要解决一般情况下,我总是在一般情况下,后去了前面,风写一吨的代码,这比它需要更加复杂。

更新:

有关详细说明,请参见“ 罪过#1-过早概括 ”。


6
当建筑宇航员这样做时,我讨厌它!
ozz 2011年

13
哦,metafactoryfactories的喜悦:(

+1“对优秀设计师的研究发现,他们都擅长预测变更”(代码完成2)。能够分辨出可能发生的变化是很好的。然后,您可以通过尽早解决更一般的情况来决定是否有任何收获-是否可以在以后节省时间。有时这是不值得的,以后修改代码也一样容易。
MarkJ 2011年

1
您是否听说过YAGNI(您不需要)原理?
奥斯卡·梅德罗斯

1
这个。我将责任归咎于创建漂亮的,通用的和可重用的代码非常令人满意,特别是如果问题本身不是非常具有挑战性和/或只是对您以前所做的事情的重新表述的话。例如,通用的CRUD数据库操作(UI,响应用户操作,对DB进行操作等)。
克苏鲁

197

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


16
这是绝对的魔鬼。
alesplin 2011年

6
如果可以的话,我会给你+100。“以后”再也不会发生。第一次做正确或根本不做。
quick_now 2011年

12
这不是花费大量时间重构错误代码的补充吗?我们可以将世界划分为“稍后会修复”但不能修复的程序员,而第一次尝试将其修复的程序员则要花数小时“重构错误代码”。

6
将其改写为“我们将返回并修复下一个迭代 ”,听起来似乎更加有条理
Chris S11年

4
必须这样做。如果您将所有时间都花在使它变得完美上,那么它将永远无法交付。完成项目,然后对其进行抛光。
Zan Lynx

105

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


72
用“ programmers.stackexchange.com”替换“ web” :)
davidhaskins 2011-02-24

1
网络上还有什么值得一读的吗?我忘了还有别的!
James McLeod

3
又名“该死的我的世界”
约翰·约翰逊

1
@david,那只是网络上的起点-问题是您能

同上,由于敏捷,这已不再有效。
vartec

103

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


13
这称为快速应用程序开发;而且它永远不会在商业环境中工作。:)
John Kraft

12
有趣的是,对我来说却是相反的方式—即使只是需要,我也无法让自己编写一次性代码。

6
我从事金融工作,RAD仍然很强势,尤其是VBA / Excel之类的东西。不过有一个诀窍,RAD不必太草率。
伊恩

5
有时,您花了两年时间完善的应用程序最终变成了可丢弃的代码,因为更高级别的某个人决定“哦,我们不能这样做”或“别介意”的其他版本。
PSU

12
这个。我:“这只是我的概念验证。如果您喜欢它,我们将编写生产版本。” 管理员:“您的版本适用,请发货!” 我:“好吧,它并不能涵盖您使用的所有用途,不是吗?”

74
  1. 发布前几天重构部分代码。
  2. 互联网:最大的干扰。
  3. 新技术:不能阻挡新技术。
  4. 优化:优化,优化。..和更多优化
  5. 完美:从未对代码感到满意。
  6. 待办事项:缺少时间的待办事项永远不会做。
  7. 时间估算:许多PM并不将其视为“估算”。他们认为是事实。
  8. 承诺:承诺过多。

1
曾经从事的项目有一个大房间里有100个人,只有2台共享PC可以上网。生产率很高。管理层为所有人提供了互联网,并想知道为什么工作量减少了一半。
quick_now 2011年

2
关于时间估算 ...如此多的经理将其作为谈判的起点(例如讨价还价)。认为它被误导但实际上高于平均水平的人
dbkk 2011年

@quickly_now切断网络可能适用于日常工作,例如数据输入或例行修复,而您无需查找任何内容。对于许多非同寻常的事情(例如,查找API文档/示例代码),Google是您的朋友-自行解决该问题所需的时间增加了5倍。另外,如果人们没有动力并想要分心,他们会找到方法。
dbkk 2011年

@dbkk-是的。全部都在Ada中,没有要查找的API,它是在专用硬件上分类的,并且是国家安全分类的。将未分类的互联网连接机器放入该环境也是一个安全噩梦。
quick_now 2011年

55

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


6
有时,现有的框架和库在IT法律上以红色大写标记为Verboten。
Christopher Mahan

22
当然,这是相反的想法:使用不熟悉的框架或库,并假定它将满足您的需求,并且一切都会顺利进行。
Carson63000

“但它会只需要一个星期来写,我们的框架会做正是我们想要的,免费的网上一个一个可能是充满错误的”

2
@Christopher:那将是重新实现(或找到具有可接受许可的其他库)的一个很好的理由。但是,重新实施的原因常常只是NIH…
Donal Fellows

@Carson:+1 :-)
Macke

48

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

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


10
+1用于过度设计。我曾经为.ini文件,XML文件,数据库表和网络套接字编写了一个带有“配置参数适配器”的完整“配置框架”(因为每个人都希望托管配置Web服务,对吗?)
TMN

8
过早的工程?
Christopher Mahan

@Chris“过早设计”也适用。其他答案中也提到了它。我知道那是我的宝贝。
马修·沙利

如何过早地对大型工程进行过度优化……
Newtopian 2011年

4
这是我的。我将责任归咎于管理,这给了我自由的统治/遥遥无期的期限,而不是给自己特定组件的期限。
克苏鲁

46

过于乐观的估计

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

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


13
当他们问您是否真的需要那么长时间时,只需说“是”,然后静静地坐着直到感到尴尬……
PeterAllenWebb 2011年

4
我的大学教授曾经告诉我,“找出您的最佳估计,然后加倍。” 到目前为止,它对我有用。
zzzzBov 2011年

2
或者,尝试使用SMBC方法
2011年

4
我的一位老老板将开发人员的估算值提高了三倍,然后又与客户进行了协商以使价格翻倍。客户认为他们达成了交易,开发人员获得了所需的时间,即使他们不知道。双赢!
DaveE

2
基于证据的调度可能有助于解决此问题:joelonsoftware.com/items/2007/10/26.html
宫坂丽(Rei Miyasaka)

33

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

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

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


如果我每次都只能投票。幸运的是,一半的解决方案都还不错。一半没有。

或者您还没有学过的一个。只是不要忘了带上马刺,因为这将是一段漫长的旅程。
Evan Plaice




23

特征蠕变

制定计划,坚持并部署。而回去,并添加人都在问的东西。

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


保留规范未冻结并开放作为优惠,因为第一位PM(现已被解雇)对软件开发一无所知,并设计了完全不现实的发布时间表。有史以来最糟糕的想法。
Evan Plaice

20
  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)用更多的程序解决营销问题。

如果人们不了解您在卖什么,那就是营销问题。返回解决方案1并进行旋转。

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

等待。

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

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

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

现在查看替代解决方案:外包,购买现成的解决方案,对此不做任何事情,等等

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

坚持下去。

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

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

8)编写一个肮脏的版本,并承诺您将“以后做得更好”,但是从不回过头来“做得更好”

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

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

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

结束编辑


+1了这个答案,但我觉得很难读。我不太了解前9点的内容。您介意澄清吗?还是不错。

@MattFenwick嗨,谢谢您的+1。第1-5点通常用于创建要销售的产品的场景中,尽管您也可以将其应用于可能找到最佳答案的趋势导致您对现有技术进行广泛研究的场景。例如,在研究中。
Kim Stacks 2013年

第6-9点与程序员的神经质倾向有关。我在某处(找不到)发现设计师总是会遇到设计解决方案中的任何问题。具有营销解决方案的营销人员;和一个有代码解决方案的程序员。是的,可怕的是“当您拥有金锤时,您所看到的只是指甲综合症”。这一点在第6点特别明显)通过更多的编程解决生产力问题
Kim Stacks 2013年

@MattFenwick对不起,如果您对我的名字感到困惑。写下此答案后,我更改了昵称。我发现您的背景更多是研究领域。我的回答很大程度上取决于我开发销售解决方案的经验。但是我敢肯定,由于我们俩都从事编程工作,因此我和您的工作之间存在某些相似之处。
Kim Stacks

17

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


11
等等...你的意思不是吗?(xkcd.com/323
Craige

4
@Craige:在拥有21年的饮酒经验和20年的专业软件工程师经验之后,我仍在从事校准工作。
亚当·克罗斯兰

4
@adam,您花了一年的时间才能成为一名工程师?

17
喝啤酒时编码可帮助您创建非常受欢迎的社交网络,这些社交网络将在几年内价值数十亿美元。没错,我在电影中看到了。
janosrusiczki 2011年

1
@Kitsched:是的!尤其是如果您要盗用他人的现有设计。
梅森惠勒

16

“是的,我可以在一天之内将这行2000行的意大利细面条重构成一团糟……”


13
或者:“新手[谁对软件或其代码结构一无所知]什么也没做,他可以修复它”。奖励指向该家伙甚至从未使用过编写代码的语言。
wildpeaks 2011年

16

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

这是邪恶的兄弟,

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


2
如果很难编写测试,则可能编程不正确:)
Merlyn Morgan-Graham

2
@Merylyn Morgan-Graham,非常正确。但是,有些领域(例如并发性)很难测试。
韦恩·康拉德,

1
@Merlyn:如果您发现自己编写了一个指令模拟器,以便可以在正确的位置强制进行上下文切换,那么您在并发测试中可能走得太远了。:)
Zan Lynx

1
@Zan:我同意-在必要的时候,我会推迟开发人员并尝试让他们重构代码并让我插入模拟。我在研究Big-O的高级语言方面进行工作,优化了瓶颈,主要是为了数据的完整性而不是原始速度来考虑并发性,然后才进行并发(并且通常都不考虑并发性,因为它的速度足够快了)框)。
Merlyn Morgan-Graham

15

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

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


澄清...通过“乐观的任务估计”,您的意思是“狗屎容易综合症”吧?:)
Evan Plaice

@Evan Plaice-完全是。就像“哦,太简单了”,然后在开始实际编码后搜索代码中的每个字母。
Nikita Barsukov 2011年

13

“这是很‘ 容易 ’,以从从头重新实现的功能,而不是理解现有的代码。”


2
是的,c2.com / cgi / wiki?RewriteCodeFromScratch声称这是“不应该做的事情”之一。
大卫·卡里

在开源上工作有助于这种趋势。我个人在交叉眼之前就盯着补丁,然后继续写自己的实现,只是意识到它与补丁几乎相同(即使在改进/重构我的代码之后)。这很有趣。
Evan Plaice

10

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


10

NIH -没有发明这里

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

节省的时间可以是如此巨大,即使9次了10年,应避免第三方的解决方案,我需要客观地认识了一个,将工作。


1
我明白你的意思,必须一直坚持下去。有时我会持相反的意见,以至于应该在您的旁边提供答案。但是,我很难相信一个星期内,我可以比在这件事上已经解决多年的专家小组做得更好。当然,您必须确保所说的第三方背后的人确实是专家。对组件周围环境的深入研究极大地帮助了在采用或编码之间进行正确选择。
Newtopian 2011年

1
@Newtopian的“正确”方式肯定在中间。我对第三方图书馆的问题不是不是我是否可以比一个专家小组在几个月或几周的时间里做得更好,而是我很少,甚至永远找不到一个真正需要的图书馆。人们总是适应做,然后我经常发现自己和其他人花尽可能多的时间摔跤与写一个解决方案,正是我们所需要的。
妮可

来自频谱另一端的我自己很好奇,想知道您如何设法实现这一“中等”水平。对于什么让您不想使用第三方来试图了解什么使我过度使用它们,我也感到好奇,因为我确信两者都同样对生产力有害。
Newtopian 2011年

@Newtopian我上面的解释对为什么有意义吗?我试图达到中间目标的尝试很简单,就是在评估和寻找第三方解决方案时更加客观。
妮可

9

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

在获得真实数据的副本之前,我将永远不会再开始一个项目。


如果还没有产品,将要复制任何数据吗?
Svish

如果没有数据,则总有纸张。公司记录也会在这里有所帮助。
2011年

9

有一定有,做某个地方图书馆综合征。

与...密切相关

插件恋物癖


2
我似乎总是能够找到“做到这一点”的库。我的问题通常是让它们按广告宣传工作。:(
Ben L

容易找到一个库-很难找到一个内置了良好单元测试的库
burnt_hand 2011年

8

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


我想这可能是对的,但是由于这个原因,我从未参与过失败甚至迟到的项目。
PeterAllenWebb 2011年

取决于您如何定义完美以及您的目标水平。
Svish


7

重写而不是重构。


同意。如果您愿意承担重写所需的工作量,那么重构总是更好的选择。它仍然会比您想象的要花费更长的时间,但是您正在逐步进行重构,对吧?您可以在“完美”之前停下来。
PeterAllenWebb

1
作为必然结果。...在其他地方重新编写而不是重构。我们的代码库对相同的事物有太多不同的实现,因此不可能获得任何形式的一致性。
Newtopian

6

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


5

自动化所有操作到点上,与实际工作相比,维护工具花费的时间更多。

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


原则上我可以同意这一点,但实际上我从未见过过度的自动化。不过,那可能只是我的经验。
PeterAllenWebb 2011年

4

您的编程恶魔是什么?

除了其他一些人提到的。

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

您如何避免它们?

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


3

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

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

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

(*主要功能完全不同)

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

我一直都被这个咬住。作为Web开发人员,这是很难避免的。我最好的建议是增加时间,以便您以正确的方式进行更改。


2
采取一项在获得客户签名之前才开始开发的策略。
本L

1
@本:如果那是我们的控制!
sevenseacat 2011年
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.