你最终会后悔或撤回哪些编程快捷方式?

9
我看到了这个问题,它让我想起了旧版DataGrid中的AutoGenerateColumns。我用过几次之后,最终撤回了这个功能,因为我需要数据格式化超过标准的“输出数据源列”功能。同样地,使用toggle似乎能节省时间,但随后你需要跟踪状态或其他信息,并相应地重写代码。
你是否也有这样的使用体验,认为某些功能会节省你的时间,但最终却因为无法满足需求而撤销使用?

自动生成列只有在脚手架方面才真正有用,我无法想象你会在生产中认真使用它。 - Juliet
8个回答

4

对现有的工作系统进行小幅改进,不要覆盖测试。

很多时候最终都会陷入调试地狱。最糟糕的是,这种地狱会传染给我的同事,而不是我。


2
我认为最令人遗憾的编程“捷径”显然是使用goto语句。但是关于框架,我认为所有框架有时都会成为陷阱。它们并不是不好用,但我认为你不可能找到一个不会迫使你用减少可维护性来换取缩短开发时间的框架。我主要使用Drupal进行工作,每当新版本发布时,我都必须重写至少一些自定义代码...但这是我为了能够快速添加新功能而使用社区模块所付出的代价,对我来说,这是值得的。对于不同的目的或应用程序集,它肯定不值得。

4
不要猛烈抨击goto指令。如果世界是完美的,递归能够在每种编程语言中得到充分实现和支持(栈可以动态扩展、尾递归被优化、协程或续延被支持等),那么任何程序都可以优雅地编写而无需使用goto指令。如果试图避免使用递归,goto通常是实现状态机的最简单方法(请不要告诉我switch/case更好;它更冗长)。我的JSON库在许多函数中使用基于goto的状态机:http://constellationmedia.com/~funsite/static/json-0.0.2/json.c - Joey Adams
1
很多年前我曾在一个地方工作(使用一种基于UNIX的基本样式语言),那里的人们只使用GOTO,从不用WHILE、FOR、REPEAT,也从未声明函数/子程序,尽管该语言确实支持所有这些。不用说,他们的应用程序有很多错误,并引起了很多“事故”,几乎可笑。我试图解释控制结构的重要性,但他们真的是坏的老派。 - KM.
@KM:确实,我同意首先采用结构化编程和递归,并知道何时使用goto是最好的。这是我最喜欢的goto狂野示例:http://www.ticalc.org/pub/89/asm/games/peg_game.zip。 - Joey Adams

2
每个开始具有大量模块化的大型Web项目,最终构建的应用程序范围通常都会过于深入。所以,Web层调用代理接口调用代理实现调用服务接口调用服务实现调用DAO接口调用DAO实现等等。最终,由于您没有在这个级别上进行分布处理,您会注意到所有代理实现都只有一行代码,因此您需要为了清晰度而将它们拆分出来,但事实上在第一次编写100个代理类时损失了一些效率。
或者说:大多数项目在某个时候都会极大地高估应用程序的用户群体规模,不幸的是,他们会为此编写代码,而不是更有效地编写代码。一个有200个用户的菜谱应用程序比每天拥有十万个用户的行业定义应用程序更常见,但开发人员倾向于为不太可能的情况编写部分 - 但不是全部 - 应用程序。如果你正在编写hello world,只需编写代码,并根据需要随着时间推移扩展即可。

1
Dean J,看起来你在描述那些你最终会后悔的“捷径”的相反情况。你提出了很好的观点,但这些似乎是冗长而复杂的方法... - bmb
它们旨在成为长期的快捷方式,使代码整体更易于维护。但它们最终成为了短期和长期的错误。糟糕? - Dean J

1

让Visual Studio进行数据绑定。大多数情况下都可以正常工作,但有时会引入微妙的错误,需要花费比手动进行数据绑定更多的时间来查找和解决。


我了解手动为Web进行数据绑定。但是,噢,如果要为Fat Client应用程序编写数据绑定代码,我简直无法想象。我想如果我不得不一直写数据绑定代码,我会发疯的。 :) - Tony

1

复制/粘贴几行代码,这些代码与您现在需要的代码类似,但并不完全相同,几乎总会导致该代码中出现错误。

最好的方法几乎总是逐个字符地输入它,强迫自己考虑每一个字符。但我仍然会这样做,想着:“可能会有什么问题呢”,之后就会后悔这个决定。


最好将其抽象化,以避免出现重复的代码 :P - Earlz
虽然不能抽象化每一行代码 :p - Emile Vrijdags

1

使用最新和最好的功能从<插入框架名称>,结果失败且需要更长时间。

我支持新功能,但过早使用它们可能会带来问题。


0

过度使用C/C++宏。我认为这是大型项目比小型项目更容易陷入的陷阱。


2
挑战:找出 putchar 在 glibc 中的实现位置。 - Joey Adams

0

不完全是捷径,但是:编写一个C++字符串类,甚至没有考虑过别人已经有了同样的想法。然而,这是一个很好的练习,因为我学到了:

  • 编写库并不意味着所有的编程都会变得轻松。如果库的语义比手动实现功能更难理解,那么这个库可能会变得相当无用。
  • C++有很多非常棒的特性。
  • C++总是缺少我真正需要的那个特性。

经常我会找到一个看起来能够满足我的需求的库,但实际使用起来却很笨重、缓慢等等。等我弄清楚如何修复别人的代码时,我最终还是会放弃它并编写自己的代码。这似乎并不需要更多或更少的时间——无论哪种方式都需要学习曲线和试验,直到达到你想要的效果。 - Kev
@Kev:听起来就像我写JSON库时经历的一样。 - Joey Adams
重新发明一个已经被反复发明的轮子怎么能成为捷径呢? - Victor
@Victor:就像我说的,“并不是一个捷径”。在我编写它时,它似乎对我来说是一条捷径,因为我认为“一旦我编写了这个String类,它就会像Visual Basic一样,一切都会变得更容易!”但现在我知道得更清楚了 :-) - Joey Adams
嘿,不是说我没有做过!在明智起见之前,我以前也写了几次Java和PHP的相同(无用)Web框架。(为自己辩护,那是在Rails之前。 (但在Struts之后...)) - Victor

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接