I think the obvious answer for the most regrettable programming "shortcut" would be gotos.
But regarding frameworks, I think all frameworks can be a trap sometimes. They're not bad to use but I don't think you'll find a framework that doesn't force you to purchase reduced development time with reduced maintainability. I work mostly with Drupal, and every time a new version comes out I have to rewrite at least some of my custom code... but that's the price I pay for being able to add new features quickly with community modules, and for me, it's worth it. For a different set of purposes or applications, it certainly wouldn't be worth it.
Every large web project that starts with a huge amount of modularity usually goes too far for the scope of the application that will eventually be built.
So, the web layer calls a delegate interface calls delegate implementation calls service interface calls service implementation calls dao interface calls dao implementation and so on.
And eventually, since you didn't do distribution at this level, you notice that all of your delegate implementations are one line of code, and you pull them out for clarity, after losing some efficiency by writing a hundred delegate classes in the first place.
Or: most projects at one point or another massively overestimate how large the application's userbase will be, and unfortunately, code for that instead of coding more efficiently. A cookbook application with 200 users is a lot more common to write than an industry-defining application with a hundred thousand users every morning, but developers tend to code part - but not all of - their app for the improbable case.
If you're writing hello world, just write the code, and bulk it up later as needed.
让 Visual Studio 进行数据绑定。它在大多数情况下都有效，但有时它会引入微妙的错误，这些错误比手动进行数据绑定需要更多的时间来查找和解决。
Letting Visual Studio do the Data Binding. It works most of the time, but sometimes it introduces subtle bugs that take far more time to find and solve than it would doing the data binding manually.
Copy/pasting a few lines of code that are similar to, but not exactly the same as the code you need right now, will almost always result in a bug in that code.
It's almost always better to just type it character by character, forcing yourself to consider everyone of them. But I keep doing it, thinking: "what could possibly go wrong", and regretting the decision later.
Not exactly a shortcut, but: Writing a C++ String class without even considering the possibility that someone else has had the same idea. However, it was a good exercise, as I learned that:
Writing a library doesn't make all of programming downhill from there. It can be easier to have a library on hand, but if it's harder to understand the semantics of the library than to implement the functionality by hand, the library can turn out to be pretty useless.
C++ has a lot of really neat features.
C++ is always missing that one feature I really need.
发布评论
评论（8）
对现有的工作系统进行一点改进，而不是用测试来覆盖它。
很多时候，它最终都陷入了调试地狱。最糟糕的是，这一切都发生在我的同事身上，而不是我身上。
Make a little improvement in an existing working system and not cover it with tests.
For many times it ended up with debugging hell. Worst of all that the hell went to my colleagues, not me.
我认为最令人遗憾的编程“捷径”的明显答案是 goto。
但关于框架，我认为所有框架有时都可能是一个陷阱。它们用起来不错，但我认为您不会找到一个不会迫使您购买减少开发时间和降低可维护性的框架。我主要使用 Drupal，每次出现新版本时，我都必须重写至少一些自定义代码...但这就是我为能够使用社区模块快速添加新功能而付出的代价，对我来说，这是值得的。对于不同的目的或应用程序来说，这当然不值得。
I think the obvious answer for the most regrettable programming "shortcut" would be gotos.
But regarding frameworks, I think all frameworks can be a trap sometimes. They're not bad to use but I don't think you'll find a framework that doesn't force you to purchase reduced development time with reduced maintainability. I work mostly with Drupal, and every time a new version comes out I have to rewrite at least some of my custom code... but that's the price I pay for being able to add new features quickly with community modules, and for me, it's worth it. For a different set of purposes or applications, it certainly wouldn't be worth it.
每个以大量模块化开始的大型 Web 项目通常都超出了最终构建的应用程序的范围。
因此，Web层调用委托接口调用委托实现调用服务接口调用服务实现调用dao接口调用dao实现等等。
最终，由于您没有在这个级别进行分发，您会注意到所有委托实现都是一行代码，并且在首先编写一百个委托类而损失了一些效率之后，为了清楚起见，您将它们拉出来。
或者：大多数项目在某一时刻都大大高估了应用程序的用户群的规模，不幸的是，为此编写代码而不是更有效地编码。拥有 200 个用户的食谱应用程序比每天早上拥有 10 万用户的行业定义应用程序更常见，但开发人员倾向于针对不太可能的情况编写部分应用程序（而不是全部）。
如果您正在编写 hello world，只需编写代码，然后根据需要将其批量化。
Every large web project that starts with a huge amount of modularity usually goes too far for the scope of the application that will eventually be built.
So, the web layer calls a delegate interface calls delegate implementation calls service interface calls service implementation calls dao interface calls dao implementation and so on.
And eventually, since you didn't do distribution at this level, you notice that all of your delegate implementations are one line of code, and you pull them out for clarity, after losing some efficiency by writing a hundred delegate classes in the first place.
Or: most projects at one point or another massively overestimate how large the application's userbase will be, and unfortunately, code for that instead of coding more efficiently. A cookbook application with 200 users is a lot more common to write than an industry-defining application with a hundred thousand users every morning, but developers tend to code part - but not all of - their app for the improbable case.
If you're writing hello world, just write the code, and bulk it up later as needed.
让 Visual Studio 进行数据绑定。它在大多数情况下都有效，但有时它会引入微妙的错误，这些错误比手动进行数据绑定需要更多的时间来查找和解决。
Letting Visual Studio do the Data Binding. It works most of the time, but sometimes it introduces subtle bugs that take far more time to find and solve than it would doing the data binding manually.
复制/粘贴几行与您现在需要的代码相似但不完全相同的代码几乎总是会导致该代码出现错误。
逐个字符地输入几乎总是更好，强迫自己考虑每个字符。但我继续这样做，想着：“可能会出什么问题”，后来又后悔这个决定。
Copy/pasting a few lines of code that are similar to, but not exactly the same as the code you need right now, will almost always result in a bug in that code.
It's almost always better to just type it character by character, forcing yourself to consider everyone of them. But I keep doing it, thinking: "what could possibly go wrong", and regretting the decision later.
使用<在此处插入框架>的最新和最强大的功能只会失败并需要更长的时间。
我完全支持新功能，但过早使用它们可能会出现问题。
Using the latest and greatest feature from <insert framework here> only to have it fail and take longer.
I am all for new features but to use them too soon can be problematic.
C/C++ 宏的过度使用。我认为大项目比小项目更容易陷入陷阱。
The over usage of C/C++ macros. I think it's a trap big projects fall into more than small projects though.
不完全是捷径，而是：编写一个 C++ String 类，甚至不考虑其他人有相同想法的可能性。然而，这是一个很好的练习，因为我了解到：
Not exactly a shortcut, but: Writing a C++ String class without even considering the possibility that someone else has had the same idea. However, it was a good exercise, as I learned that: