你会后悔或放弃什么编程捷径?[关闭]

对现有的工作系统稍加改进,不要用测试来覆盖它。

很多时候,它都是以调试地狱结束的。最糟糕的是我的同事,而不是我。

我认为最令人遗憾的编程“捷径”的明显答案是gotos。

但是关于框架,我认为所有的框架有时都是一个陷阱。它们的使用并不坏,但我不认为你会找到一个框架,不强迫你购买减少的开发时间和降低的可维护性。我主要和Drupal一起工作,每次有新的版本出现,我都必须重写至少一些自定义代码…但这是我为能够快速添加社区模块的新功能而付出的代价,对我来说,这是值得的。对于一组不同的用途或应用程序,这肯定是不值得的。

每一个以大量模块化开始的大型web项目,对于最终将要构建的应用程序的范围来说,通常都会走得太远。

所以,web层调用一个委托接口调用委托实现调用服务接口调用服务实现调用dao接口调用dao实现等等。

最后,由于您没有在这个级别上进行分发,您注意到所有的委托实现都是一行代码,在第一次编写了100个委托类而失去了一些效率之后,为了清晰起见,您将它们取出。

或者:大多数项目在某一点上都高估了应用程序的用户基础有多大,不幸的是,为其编写代码而不是更有效地编写代码。一个拥有200个用户的菜谱应用程序比每天早上拥有10万个用户的行业定义应用程序更容易编写,但是开发人员倾向于为不可能的情况编写部分(但不是全部)应用程序。

如果您正在编写hello world,只需编写代码,然后根据需要将其放大。

让visual studio进行数据绑定。它大部分时间都在工作,但有时它会引入一些细微的错误,这些错误比手工进行数据绑定要花更多的时间来查找和解决。

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

最好是一个字一个字地打出来,强迫自己考虑每个人。但我一直这样做,心里想:“可能出什么问题”,后来后悔了这个决定。

使用<在此处插入框架>中最新和最棒的功能,结果失败并花费更长时间。

我完全赞成新功能,但过早地使用它们可能会有问题。

C/C++宏的过度使用。不过,我认为这是一个陷阱,大项目不只是小项目。

不是一个快捷方式,而是:编写C++字符串类,甚至不考虑其他人有相同想法的可能性。然而,这是一个很好的练习,因为我了解到:

• 编写一个库并不能使所有的编程都从那里走下坡路。手边有一个库可能更容易,但是如果理解库的语义比手工实现功能更难,那么这个库可能会变得非常无用。
• C++有很多非常简洁的特性。
• C++总是缺少我真正需要的一个特性。