这绝对是主观的,但我想尽量避免它变成争论。我认为如果人们恰当地对待它,这将是一个有趣的问题。

这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上,但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。

那么,你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如,大括号放置),但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。

请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点,不管你是否恰好同意这些观点。


当前回答

设计模式对优秀设计的伤害大于帮助。

IMO软件设计,尤其是优秀的软件设计,变化太大,无法在模式中有意义地捕捉,特别是在人们实际能记住的少量模式中——而且它们太抽象,人们实际上只能记住少数几个。所以他们帮不上什么忙。

另一方面,太多的人迷恋于这个概念,并试图在所有地方应用模式——通常,在生成的代码中,你无法在所有(完全没有意义的)单例和抽象工厂之间找到实际的设计。

其他回答

我有争议的观点:面向对象编程绝对是软件工程领域发生过的最糟糕的事情。

面向对象编程的主要问题是完全缺乏一个每个人都能认同的严格定义。这很容易导致实现中存在逻辑漏洞,或者像Java这样的语言坚持这种关于OOP含义的奇怪的宗教教条,同时迫使程序员做所有这些扭曲和“设计模式”,只是为了绕过特定OOP系统的限制。

因此,OOP欺骗程序员,让他们认为他们正在获得这些巨大的生产力收益,OOP在某种程度上是一种“自然”的思考方式,同时迫使程序员输入大量不必要的样板文件。

然后,由于没有人知道OOP的真正含义,我们浪费了大量的时间在争论语言X或Y是否“真正的面向对象”,什么奇怪的语言特性对于一种语言被认为是“真正的面向对象”是绝对“必要的”。

与其要求这种语言或那种语言是“真正的面向对象的”,我们应该看看实验显示了什么语言特性,以实际提高生产力,而不是试图强迫它成为某种想象中的理想语言,或者强迫我们的程序符合某种“真正面向对象的程序”的柏拉图式理想。

与其坚持我们的程序符合“真正面向对象”的柏拉图式理想,不如我们专注于坚持良好的工程原则,使我们的代码易于阅读和理解,并使用一种语言的高效和有用的特性,而不管它们是否足够“面向对象”。

我有两个:

设计模式有时是糟糕程序员编写糟糕代码的一种方式——“当你有一把锤子时,整个世界看起来都像钉子”的心态。如果有什么我讨厌听到的是两个开发人员通过模式创建设计:“我们应该使用命令与facade…”

不存在所谓的“过早优化”。你应该在你觉得这样做太痛苦之前对你的代码进行分析和优化。

WordPress是一个CMS(从技术上讲,确实如此)。

https://stackoverflow.com/questions/105648/wordpress-is-it-a-cms

程序员把他们自己的(有限的)编程语言视为神圣不可侵犯的宗教。

有趣的是,程序员几乎像宗教信徒一样对待这些讨论:不允许批评,(通常)不允许客观的讨论,(通常)基于非常有限或缺乏的知识和信息进行争论。为了确认,只需阅读之前的答案,尤其是评论。

同样有趣的是,另一个确认:根据“给我一个有争议的意见”这个问题的定义,任何有争议的意见都不应该被投反对票——实际上恰恰相反:越有争议越好。但我们的程序员是如何反应的:就像巴甫洛夫的狗一样,对不喜欢的意见投反对票。

PS:为了公平起见,我给其他一些人点了赞。

编码不是打字

编写代码需要时间。大多数时候,在编辑器窗口中,您只是查看代码,而不是实际输入。虽然不是经常,但你经常会删除你所写的内容。或者从一个地方搬到另一个地方。或重命名。

如果你长时间敲击键盘,那你一定做错了什么。

推论:每天写的代码行数并不是一个程序员生产力的线性衡量标准,一天写100行的程序员很可能比一天写20行的程序员更好,但一天写5000行的程序员肯定是坏程序员