一幅画不如一千个词。

有些图片可能胜过千言万语。大多数都不是。这句陈词滥调大多是不真实的，是许多懒惰的经理的可悲借口，他们不想仔细阅读创建的报告和文档，说“我需要你在图表中展示给我看”。

我妻子学的是语言学专业，她看到了一些关于图片和标志的令人着迷的证据:它们不能打破语言和文化的障碍，它们通常不能像正确的文本那样传达那么多的信息，它们根本不能取代真正的交流。

特别是，如果线条未被标记且无法解释，并且/或如果每一行都有不同的含义而不是表示相同的关系(除非以某种方式彼此区分)，那么与线条连接的标记气泡是无用的。如果你的线条有时表示关系，有时表示动作，有时表示时间的流逝，你就真的完蛋了。

每个优秀的程序员都知道你使用的工具适合手头的工作，对吗?并不是所有的系统都最好用图片来说明和记录。图形化规范语言可以自动转换为可证明正确的可执行代码或任何东西，这是一个了不起的想法，如果这样的东西存在的话。在适当的时候使用它们，而不是在阳光下的所有事情上。实体-关系图很棒。但并不是所有的事情都可以用一张图片来概括。

注:一张桌子可能值同等重量的金子。但是表格和图片不是一回事。同样，一篇精心设计的短散文段落可能更适合手头的工作。

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

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

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

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

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

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

使用匈牙利符号应处以死刑。

这已经足够有争议了;)

性能确实很重要。

自动更新会导致软件质量更差，更不安全

这个想法

一个系统，以保持用户的软件最新的错误修复和安全补丁。

现实

产品必须在固定期限内交付，这通常是以牺牲QA为代价的。为了在截止日期前发布带有许多漏洞和安全漏洞的软件，他们知道“自动更新”可以在以后用来修复所有问题。

真正让我想到这一点的软件是VS2K5。起初，它很棒，但随着更新的安装，软件慢慢变得更糟。最大的问题是宏的丢失——我花了很长时间创建了一组有用的VBA宏来自动化我写的一些代码——但显然有一个安全漏洞，而不是修复它，宏系统被禁用了。Bang有一个非常有用的功能:记录击键并重复回放。

现在，如果我真的是偏执狂的话，我可以把自动更新看作是一种让人们通过缓慢安装更频繁地破坏系统的代码来升级他们的软件的方法。当系统变得越来越不可靠时，用户就会被诱惑去购买下一个版本，因为它承诺有更好的可靠性等等。

斯基兹

复制/粘贴不是反模式，事实上它有助于避免产生更多的错误

我的经验法则——只输入不能复制/粘贴的东西。如果创建类似的方法，类或文件-复制现有的并更改所需的内容。(我不是在谈论复制应该放在单个方法中的代码)。

我通常从不输入变量名——要么复制粘贴，要么使用IDE自动补全。如果需要一些DAO方法-复制类似的方法并更改所需的内容(即使将更改90%)。对某些人来说，这可能看起来是极度的懒惰或缺乏知识，但我几乎从来没有处理过由拼写错误引起的问题，而且它们通常很难捕捉(如果没有在编译级别检测到)。

每当我偏离我的复制粘贴规则，开始输入东西时，我总是拼写错误(这只是一个统计数据，没有人能立即写出完美的文本)，然后花更多的时间试图找出哪里。