什么时候抽象和模块化在编程中是一种糟糕的做法？

Question

我在一个“你使用什么JS库”的投票中看到了这条评论

"@Xanti -是的，是的，编程中的模块化和抽象化是一种可怕的做法。调用其他函数的函数?是浪费的。“

这让我很好奇，因为我在PHP中使用Kohana框架，在javascript中使用Jquery库。

为什么有些人认为抽象和模块化是不好的做法？框架和库不是用来简化和加速开发的吗？

这是投票的link

Answer 1

我发现太多的抽象可能会对你的工作效率造成危害：

• 选择不当的抽象可能比根本没有抽象更糟糕。

• 如果你需要阅读四到五个不同的模块来理解一个简单的算法是如何工作的，那么抽象的障碍可能不在正确的地方。也许有一个很好的方法来重构代码，或者只需要移除障碍就可以更容易。

• 如果抽象概念与相对熟悉的想法不一致，新团队成员可能很难学习。

抽象不是“盲目的好东西”；它的存在是为了服务于特定的目的。最常见的目的是

• To of a data structure

保护数据结构的不变量

• To 封装了可能导致change

的设计决策

我在抽象方面最大的经验是使用我们的C研究编译器--(2008年在https://www.cs.tufts.edu/~nr/c--/上的档案快照)。与学生们在编译器类中所看到的相比，这里有更多的抽象：

• 目标机器是抽象代码汇编语言是抽象代码
• 调用约定是抽象代码
• 堆栈框架布局使用了不寻常的“块”抽象代码<

>F234>

每个抽象都为我们的研究提供了一个重要的目的，但总的效果是，对于初学者来说，学习编译器是非常困难的。因此，即使最初的评论是在开玩笑，但在某些地方，抽象可能会导致问题。

Answer 2

当使用有限的资源时，它很容易增加开销。

当然有些东西编译器会优化掉，但是如果你在四个整洁的.c文件中创建了四个整洁的对象，将它们编译成四个整洁的.so文件，然后用一个愚蠢的链接器链接它们，那么可以很容易内联的跨模块函数调用仍然使用完整的状态转储进行，可以完全优化的部分仍然会被执行，依此类推。

我向您保证，如果您使用面向对象语言的最佳实践，使用高级设计模式并创建多个抽象层，开始使用4K RAM和16K Flash对8位PIC微控制器进行编程，您的程序将永远不会运行。“过早优化是万恶之源”是由一个从未为拥有128字节RAM的平台编程的人说的。

Answer 3

我们可能会认为评论者并不是认真的。

我不能想象会有人声称模块化和抽象是糟糕的实践，并且实际上是认真的。