这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
世界需要更多的goto
人们虔诚地避免goto，除了“我的教授告诉我goto不好”之外，没有其他理由。它们有一个目的，可以在很多地方极大地简化生产代码。
也就是说，在你所编写的99%的代码中，它们都是不必要的。
远离Celko!!!!
http://www.dbdebunk.com/page/page/857309.htm
我认为使用代理主键比使用“自然”主键更有意义。
@ocdecio: Fabian Pascal给出了(在他的书《数据库管理中的实际问题》的第三章中，引用于你链接的页面的第3点)作为选择键的标准之一，那就是稳定性(它总是存在并且不会改变)。当一个自然键不具有这样的属性时，必须使用一个代理键，原因很明显，您在注释中暗示了这一点。
你不知道他写了什么，你也懒得去检查，否则你会发现你实际上同意他的观点。这里没有什么争议:他说的是“不要教条主义，根据情况调整一般的指导方针，最重要的是，思考，用你的大脑，而不是教条主义/食谱/大师的话”。
尊重单一责任原则
乍一看，你可能不认为这是有争议的，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做所有事情时，他们通常会拒绝……所以对于孩子们，请不要再用我们经常看到的“什么都做”的方法了。
I work in ASP.NET / VB.NET a lot and find ViewState an absolute nightmare. It's enabled by default on the majority of fields and causes a large quantity of encoded data at the start of every web page. The bigger a page gets in terms of controls on a page, the larger the ViewState data will become. Most people don't turn an eye to it, but it creates a large set of data which is usually irrelevant to the tasks being carried on the page. You must manually disable this option on all ASP controls if they're not being used. It's either that or have custom controls for everything.
在我使用的一些页面上，页面的一半是由ViewState组成的，这真的很遗憾，因为可能有更好的方法来做到这一点。
这只是我在语言/技术观点方面能想到的一个小例子。这可能会引起争议。
顺便说一下，你可能想在这个帖子上编辑投票，它可能会被一些人热得很;)
你应该一直使用的唯一“最佳实践”是“动动脑子”。
太多人跳上了太多的潮流车，试图把方法、模式、框架等强加到不值得他们去做的事情上。仅仅因为某事是新的，或者因为受人尊敬的人有意见，并不意味着它适合所有人:)
编辑: 澄清一下——我认为人们不应该忽视最佳实践、有价值的意见等。只是人们不应该盲目地扑向某样东西，而不去思考为什么这个“东西”这么棒，它是否适用于我正在做的事情，它会带来什么好处/缺点?
我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能，买更多的机器。
我真的不喜欢当人们告诉我使用getter和setter而不是使变量公共时，你应该能够获得和设置类变量。
我完全同意如果是改变对象中的一个变量在你的对象中，你不会得到这样的东西:a.b.c.d.e = something;但我更愿意使用:a.x = something;然后a.setX(东西);我认为a.x =某物;实际上，在同一个例子中，它们都更容易阅读，而且比设置/获取更漂亮。
我不明白为什么要这样做:
void setX(T x) ｛ 这个->x = x; ｝
T getX () ｛ 返回x; ｝
这就需要更多的代码，需要更多的时间，你要一遍又一遍地做，这只会让代码更难阅读。
我不明白为什么人们认为Java绝对是大学里最好的“首选”编程语言。
首先，我认为第一种编程语言应该强调学习控制流和变量的必要性，而不是对象和语法
另一方面，我相信没有在C / c++中调试内存泄漏经验的人无法完全理解Java带来的好处。
同样，自然的进展应该是从“我怎么能做这个”到“我怎么能找到做那个的库”，而不是相反。
好吧，我说过我会更详细地阐述我的“密封类”观点。我想有一种方法可以展示我感兴趣的答案，那就是给我自己一个答案:)
意见:在c#中，默认情况下类应该是密封的
推理:
There's no doubt that inheritance is powerful. However, it has to be somewhat guided. If someone derives from a base class in a way which is completely unexpected, this can break the assumptions in the base implementation. Consider two methods in the base class, where one calls another - if these methods are both virtual, then that implementation detail has to be documented, otherwise someone could quite reasonably override the second method and expect a call to the first one to work. And of course, as soon as the implementation is documented, it can't be changed... so you lose flexibility.
C# took a step in the right direction (relative to Java) by making methods sealed by default. However, I believe a further step - making classes sealed by default - would have been even better. In particular, it's easy to override methods (or not explicitly seal existing virtual methods which you don't override) so that you end up with unexpected behaviour. This wouldn't actually stop you from doing anything you can currently do - it's just changing a default, not changing the available options. It would be a "safer" default though, just like the default access in C# is always "the most private visibility available at that point."
通过让人们明确表示他们希望人们能够从他们的类中派生，我们将鼓励他们更多地思考这个问题。这也可以帮助我解决我的懒惰问题——虽然我知道我应该密封几乎所有的类，但我很少真的记得这样做:(
对方观点:
我可以看到这样一种说法:可以相对安全地派生没有虚方法的类，而不需要额外的灵活性和通常需要的文档。目前我不确定如何应对这个问题，只能说我相信意外打开类的危害比意外密封类的危害更大。
我有争议的观点是，“While”结构应该从所有编程语言中删除。
你可以很容易地复制而使用“重复”和一个布尔标志，我只是不相信这是有用的，有两个结构。事实上，我认为同时拥有“重复……”直到”和“While..”一种语言中的EndWhile”会让新程序员感到困惑。
更新-额外说明
新程序员在使用While时常犯的一个错误是，他们认为一旦测试条件标记为false，代码就会中断。因此，如果While测试在代码进行到一半时标记为假，则假定While循环爆发。使用Repeat时就不会犯这么多错误。
只要只有一个循环类型，我实际上并不关心这两个循环类型中哪一个被保留。我选择Repeat而不是While的另一个原因是“While”功能用“Repeat”写比用“While”写更有意义。
第二次更新: 我猜，我是目前唯一一个得分为负的人，这意味着这实际上是一个有争议的观点。(不像你们其他人。哈!)
设计模式对优秀设计的伤害大于帮助。
IMO软件设计，尤其是优秀的软件设计，变化太大，无法在模式中有意义地捕捉，特别是在人们实际能记住的少量模式中——而且它们太抽象，人们实际上只能记住少数几个。所以他们帮不上什么忙。
另一方面，太多的人迷恋于这个概念，并试图在所有地方应用模式——通常，在生成的代码中，你无法在所有(完全没有意义的)单例和抽象工厂之间找到实际的设计。
应该禁止调试器。这将迫使人们编写可通过单元测试测试的代码，最终将导致更好的代码质量。
从所有编程ide中删除复制和粘贴。复制和粘贴代码是非常糟糕的，这个选项应该完全删除。然后程序员可能会懒得重新输入所有的代码，所以他会创建一个函数并重用代码。
无论何时使用单例，都要给自己一个耳光。单例几乎从来没有必要，大多数时候只是全局变量的花哨名称。
getter和setter被过度使用
我见过数百万人声称公共字段是邪恶的，所以他们将它们设置为私有字段，并为所有这些字段提供getter和setter。我相信这与公开字段几乎是一样的，如果你使用线程(但通常不是这样)或如果你的访问器有业务/表示逻辑(至少有些“奇怪”)，可能会有点不同。
我不赞成公共字段，但反对为每个字段创建getter/setter(或Property)，然后声称这样做是封装或信息隐藏……哈!
更新:
这个答案在评论中引起了一些争议，所以我会试着澄清一下(我不会动原文，因为这是许多人点赞的)。
首先，任何使用公共场地的人都应该坐牢
现在，创建私有字段，然后使用IDE为每个私有字段自动生成getter和setter，几乎和使用公共字段一样糟糕。
很多人认为:
私有字段+公共访问器==封装
我说(自动或非自动)为字段生成getter/setter对有效地违背了您试图实现的所谓封装。
最后，让我引用Bob叔叔在这个主题中的一句话(摘自“干净代码”的第6章):
我们保持沉默是有原因的 私有变量。我们不想要 没有人可以依靠他们。我们想要的 自由地改变他们的类型或者 心血来潮地执行 冲动。那么，为什么要这么多呢 程序员会自动添加getter 和对象的setter，暴露 他们的私人领域，就好像他们是 公众吗?
我也认为在源代码控制中使用二进制文件并没有什么错。如果有充分的理由的话。如果我有一个程序集，我没有源代码，并且可能不一定在每个devs机器上的相同位置，那么我通常会将它放在“二进制”目录中，并使用相对路径在项目中引用它。
相当多的人似乎认为我应该被烧死在火刑柱上，因为我甚至在同一个句子中提到了“源代码控制”和“二进制”。我甚至知道一些地方有严格的规定，说你不能添加它们。
代码中的大多数注释实际上是一种有害的代码复制形式。
我们花了大部分时间维护别人(或者我们自己)写的代码，糟糕的、不正确的、过时的、误导性的注释肯定是代码中最令人讨厌的工件列表的顶部。
我想最终很多人会忘记它们，尤其是那些花盒子里的怪物。
最好集中精力使代码可读，必要时进行重构，并尽量减少习惯用法和奇怪之处。
另一方面，许多课程告诉我们注释几乎比代码本身更重要，这就导致了下面这一行添加了一个注释到invoiceTotal风格。
1)商业应用程序闹剧:
我认为整个“企业”框架都是烟雾和镜子。J2EE、。net、大多数Apache框架和大多数用于管理这类事情的抽象所产生的复杂性远远大于它们所解决的问题。
以任何常规的Java或。net ORM，或任何所谓的现代MVC框架为例，它们都能“神奇”地解决乏味而简单的任务。您最终会编写大量难看的XML样板文件，难以快速验证和编写。你有大量的api，其中一半只是为了集成其他api的工作，不可能回收的接口，以及只需要克服Java和c#的灵活性的抽象类。我们根本不需要那么多。
那些拥有自己的描述符语法、过于复杂的数据库和群件产品的不同应用程序服务器呢?
这里的重点不是复杂性==坏，而是不必要的复杂性==坏。我曾经在大型企业安装中工作过，其中一些是必要的，但即使在大多数情况下，一些自制脚本和一个简单的web前端也足以解决大多数用例。
我会尝试用简单的web框架、开源数据库和简单的编程结构来取代所有这些企业级应用。
2) n年工作经验要求:
Unless you need a consultant or a technician to handle a specific issue related to an application, API or framework, then you don't really need someone with 5 years of experience in that application. What you need is a developer/admin who can read documentation, who has domain knowledge in whatever it is you're doing, and who can learn quickly. If you need to develop in some kind of language, a decent developer will pick it up in less than 2 months. If you need an administrator for X web server, in two days he should have read the man pages and newsgroups and be up to speed. Anything less and that person is not worth what he is paid.
3)常见的“计算机科学”学位课程:
The majority of computer science and software engineering degrees are bull. If your first programming language is Java or C#, then you're doing something wrong. If you don't get several courses full of algebra and math, it's wrong. If you don't delve into functional programming, it's incomplete. If you can't apply loop invariants to a trivial for loop, you're not worth your salt as a supposed computer scientist. If you come out with experience in x and y languages and object orientation, it's full of s***. A real computer scientist sees a language in terms of the concepts and syntaxes it uses, and sees programming methodologies as one among many, and has such a good understanding of the underlying philosophies of both that picking new languages, design methods, or specification languages should be trivial.
并不是所有的程序员都生而平等
管理人员经常认为DeveloperA == DeveloperB仅仅是因为它们具有相同的经验水平等等。事实上，一个开发人员的性能可能是另一个开发人员的10倍甚至100倍。
谈论它在政治上是有风险的，但有时我想指出，即使几个团队成员可能看起来具有相同的技能，但情况并不总是如此。我甚至见过这样的情况:首席开发人员“毫无希望”，而初级开发人员承担了所有实际工作——尽管如此，我还是确保他们得到了荣誉。：）
如果你只知道一种语言，无论你多么精通，你都不是一个伟大的程序员。
似乎有一种态度认为，一旦你真的擅长c#或Java或其他你开始学习的语言，那么你就只需要这些。我不相信——我学过的每一种语言都教会了我一些关于编程的新东西，我能够把这些东西带回到我的工作中。我认为任何把自己限制在一种语言上的人都永远不会达到他们本可以达到的水平。
对我来说，这也表明缺乏好奇心和实验意愿，这并不一定符合我期望在一个真正优秀的程序员身上找到的品质。
当我声称代码只是我的设计的一种表达时，我经常被人大声叫嚷。我非常不喜欢看到许多开发人员在编写代码时“匆匆忙忙”地设计系统。
当其中一个牛仔从马上摔下来时所浪费的时间和精力是惊人的，而且他们遇到的问题十有八九只要前期设计工作就能解决。
我觉得现代方法没有强调设计在整个软件开发过程中的重要性。例如，当你甚至还没有审查你的设计时，对代码审查的重要性!这是疯狂。
你不需要编写所有的程序
我厌倦了所有的事情，但所有的事情都需要塞进一个程序，这样总是更快。一切都需要基于网络，一切都需要通过计算机完成。请用你的笔和纸。它更快，更少维护。
代码==设计
我不喜欢复杂的UML图和无穷无尽的代码文档。在高级语言中，您的代码应该是可读和可理解的。复杂的文档和图表对用户来说并不友好。
这里有一篇关于代码即设计的文章。
观点:单元测试不需要预先编写，有时甚至根本不需要。
推理:开发人员不擅长测试他们自己的代码。我们所做的。这就是为什么我们通常有测试团队或QA团队。
大多数情况下，我们编写的代码与其他需要单独测试的代码交织在一起，因此我们最终会跳过模式框框来提供可测试性。并不是说这些模式不好，而是它们有时会增加不必要的复杂性，所有这些都是为了单元测试……
．.． 这通常是行不通的。编写一个全面的单元测试需要大量的时间。通常是我们不愿意付出的时间。测试越全面，如果测试对象的接口发生变化，就会变得越脆弱，迫使重写不再编译的测试。
偶尔写一些垃圾代码是可以的
有时，一段快速而肮脏的垃圾代码就是完成特定任务所需要的全部。模式、orm、SRP等等……抛出一个控制台或Web应用程序，写一些内联sql(感觉不错)，然后抛出需求。
手动停止程序是一种有效的、经过验证的查找性能问题的方法。
可信吗?对大多数人来说并非如此。真的吗?绝对的。
程序员的判断比必要的要多得多。
看看这些帖子中所有被认为是“邪恶”或“可怕”的事情吧。
程序员喜欢数据结构。
见证所有关于类、继承、私有与公共、内存管理等以及如何分析需求的讨论。
没有“放之四海而皆准”的发展方法
我很惊讶这是一个有争议的观点，因为在我看来这是常识。然而，在热门博客上有许多文章都在推广“一刀切”的开发方法，所以我认为我可能只是少数。
我所见过的被吹捧为任何项目的正确方法的东西——在了解任何关于它的信息之前——像使用测试驱动开发(TDD)、领域驱动设计(DDD)、对象关系映射(ORM)、敏捷(大A)、面向对象(OO)等等，等等，包括从方法到架构到组件的一切。当然，这些都是很有市场价值的首字母缩写。
人们甚至似乎在他们的博客上贴上徽章，比如“我是测试驱动的”或类似的东西，就好像他们严格坚持单一的方法，不管项目的细节是什么，实际上是一件好事。
它不是。
选择正确的方法、体系结构和组件，等等，是应该在每个项目的基础上完成的事情，不仅取决于您正在从事的项目的类型及其独特的需求，而且还取决于与您一起工作的团队的规模和能力。
通过断章取义地编写伟大的程序，以狂热者的热情和错误的假设，这些都是铁定的规则，这真的让我很恼火。例如，“过早的优化是万恶之源”。
在我看来，许多技术问题和解决方案都是非常上下文敏感的，全球最佳实践的概念是一个谬论。
这里有一个多年来对我来说似乎是显而易见的，但对其他人来说却是一个诅咒:在“发布”版本中使用NDEBUG关闭C(或c++)断言几乎总是一个错误。(唯一的例外是时间或空间惩罚是不可接受的)。
原理:如果断言失败，则程序进入了一种状态
从未被检验过 开发人员无法为恢复策略编写代码 开发人员有效地将其记录为不可思议的。
然而，在某种程度上，“行业最佳实践”是，当涉及到客户数据的实时运行时，事情应该只是敷衍了事，期待最好的结果。
意见:框架和第三方组件只能作为最后的手段。
我经常看到程序员立即选择一个框架来完成一项任务，而不学习它工作所需的底层方法。有些东西不可避免地会被打破，或者我们会发现我们没有考虑到的限制，我们会立即陷入困境，不得不重新思考系统的主要部分。只要经过仔细考虑，框架是可以使用的。
如果你是一个开发人员，你应该会写代码
去年我做了很多面试，在我的面试部分，我应该测试人们的思维方式，以及他们如何在白板上实现简单到中等的算法。我一开始的问题是:
假设可以使用函数4 *(1 - 1/3 + 1/5 - 1/7 +…)来估计圆周率，使用更多的项来获得更高的精度，编写一个计算圆周率的函数，其精度为小数点后5位。
这是一个应该让你思考的问题，但对于一个经验丰富的开发人员来说不应该是遥不可及的(它可以用大约10行c#来回答)。然而，我们的许多候选人(应该是中介机构预先筛选的)甚至无法开始回答这个问题，甚至无法解释他们将如何回答这个问题。所以过了一段时间，我开始问一些更简单的问题，比如:
给定圆的面积是π乘以半径的平方，写一个函数来计算圆的面积。
令人惊讶的是，超过一半的候选人不能用任何语言编写这个函数(我可以阅读大多数流行的语言，所以我让他们使用他们选择的任何语言，包括伪代码)。我们有“c#开发人员”，他们不能用c#编写这个函数。
我对此感到很惊讶。我一直认为开发人员应该会写代码。现在看来，这似乎是一个有争议的观点。当然是在面试中!
编辑:
在评论中有很多关于第一个问题是好是坏的讨论，以及你是否应该在面试中问这么复杂的问题。我不打算在这里深入研究这个问题(这是一个全新的问题)，除了说你在很大程度上错过了文章的重点。
是的，我说过人们在这个问题上无法取得任何进展，但第二个问题很琐碎，许多人在这个问题上也无法取得任何进展!任何自称为开发人员的人都应该能够不假思索地在几秒钟内写出第二个问题的答案。很多人做不到。
观点:显式变量声明是一件很棒的事情。
我永远无法理解让开发人员浪费大量时间追踪由变量名输入错误引起的运行时错误，而不是简单地让编译器/解释器捕捉它们的“智慧”。
没有人能给我更好的解释，“好吧，这节省了时间，因为我不需要写'int I;'。”Uhhhhh……是的，当然，但是追踪一个运行时错误需要多少时间呢?
That (at least during initial design), every Database Table (well, almost every one) should be clearly defined to contain some clearly understanable business entity or system-level domain abstraction, and that whether or not you use it as a a primary key and as Foreign Keys in other dependant tables, some column (attribute) or subset of the table attributes should be clearly defined to represent a unique key for that table (entity/abstraction). This is the only way to ensure that the overall table structure represents a logically consistent representation of the complete system data structure, without overlap or misunbderstood flattening. I am a firm believeer in using non-meaningful surrogate keys for Pks and Fks and join functionality, (for performance, ease of use, and other reasons), but I beleive the tendency in this direction has taken the database community too far away from the original Cobb principles, and we jhave lost much of the benefits (of database consistency) that natural keys provided.
那么为什么不两者都用呢?
观点:SQL是代码。这样对待它
也就是说，就像c#、Java或其他喜欢的对象/过程语言一样，开发一种可读且可维护的格式化样式。
我讨厌看到草率的自由格式SQL代码。如果您在页面上看到两种样式的花括号时都尖叫，那么当您看到自由格式化的SQL或模糊JOIN条件的SQL时，为什么不尖叫呢?
web的MVC应该比传统的MVC简单得多。
Traditional MVC involves code that "listens" for "events" so that the view can continually be updated to reflect the current state of the model. In the web paradigm however, the web server already does the listening, and the request is the event. Therefore MVC for the web need only be a specific instance of the mediator pattern: controllers mediating between views and the model. If a web framework is crafted properly, a re-usable core should probably not be more than 100 lines. That core need only implement the "page controller" paradigm but should be extensible so as to be able to support the "front controller" paradigm.
下面是我自己的框架的核心方法，它成功地应用于一家财富100强的网络硬件制造商为一家财富50强的媒体公司生产的嵌入式消费设备。我的方法被一位前Smalltalk程序员和Oreilly一本关于有史以来最杰出的Java web框架的书的作者比作Smalltalk;此外，我已经将相同的框架移植到mod_python/psp。
static function sendResponse(IBareBonesController $controller) {
$controller->setMto($controller->applyInputToModel());
$controller->mto->applyModelToView();
}
源代码控制:除了SourceSafe
另外:排他锁定是邪恶的。
我曾经在某个地方工作过，他们认为排他锁意味着您可以保证当您签入时，人们不会覆盖其他人的更改。问题在于，为了完成任何工作，如果文件被锁定，开发人员只会在有机会时将本地文件更改为可写，并合并(或覆盖)版本的源代码控制。
默认情况下，数组应该基于1，而不是基于0。系统实现语言不一定是这样，但是像Java这样的语言吸收了更多C语言的奇怪之处。“元素1”应该是第一个元素，而不是第二个，以避免混淆。
计算机科学不是软件开发。毕竟，你不会雇佣一个只学过物理的工程师。
尽可能多地学习数学。您不会使用大部分的知识，但是您需要能够以这种方式思考才能擅长软件。
目前标准化的唯一最好的编程语言是Common Lisp，尽管它很冗长并且有从零开始的数组。这很大程度上是因为它被设计成一种方式 来写计算，而不是抽象的冯·诺依曼机器。
至少90%的对编程语言的比较批评可以归结为“语言A有C特性，而我不知道如何在语言B中实现C或类似的功能，所以语言A更好。”
“最佳实践”是我所见过的“平庸”最令人印象深刻的拼写方式。
默认情况下，所有变量/属性都应该是只读/final。
这个推理有点类似于Jon提出的类的封闭论证。程序中的一个实体应该有一个任务，而且只有一个任务。特别是，对于大多数变量和属性来说，改变值是绝对没有意义的。基本上有两个例外。
Loop variables. But then, I argue that the variable actually doesn't change value at all. Rather, it goes out of scope at the end of the loop and is re-instantiated in the next turn. Therefore, immutability would work nicely with loop variables and everyone who tries to change a loop variable's value by hand should go straight to hell. Accumulators. For example, imagine the case of summing over the values in an array, or even a list/string that accumulates some information about something else. Today, there are better means to accomplish the same goal. Functional languages have higher-order functions, Python has list comprehension and .NET has LINQ. In all these cases, there is no need for a mutable accumulator / result holder. Consider the special case of string concatenation. In many environments (.NET, Java), strings are actually immutables. Why then allow an assignment to a string variable at all? Much better to use a builder class (i.e. a StringBuilder) all along.
我意识到，今天的大多数语言并没有默认我的愿望。在我看来，由于这个原因，所有这些语言都有根本性的缺陷。如果将它们更改为默认将所有变量视为只读，并且在初始化后不允许对它们进行任何赋值，那么它们的表达性、功能和易用性将不会受到任何损失。
单元测试不会帮助你写出好的代码
进行单元测试的唯一原因是确保已经工作的代码不会崩溃。首先编写测试，或者为测试编写代码都是荒谬的。如果在编写代码之前编写测试，您甚至不知道边界情况是什么。您的代码可能通过了测试，但在不可预见的情况下仍然会失败。
此外，优秀的开发人员会保持较低的内聚性，这将使新代码的添加不太可能对现有内容造成问题。
事实上，我将进一步推广，
软件工程中的大多数“最佳实践”都是为了防止糟糕的程序员造成太大的破坏。
他们的作用是指导糟糕的开发人员，防止他们犯愚蠢的错误。当然，由于大多数开发人员都很糟糕，这是一件好事，但优秀的开发人员应该得到通过。
我的一个:
长开关语句是你的朋友。真的。至少在c#中是这样。
人们倾向于避免和不鼓励其他人使用长switch语句，因为它们“不可管理”和“具有糟糕的性能特征”。
好吧，在c#中，switch语句总是自动编译为哈希跳转表，所以如果你需要简单的分支到多个分支，实际上使用它们是性能方面的最佳选择。同样，如果case语句被智能地组织和分组(例如按字母顺序)，那么它们就不是无法管理的。
软件开发只是一份工作
不要误解我，我非常喜欢软件开发。在过去的几年里，我写了一篇关于这个主题的博客。我在这里花了足够的时间获得了5000声望点。我在一家初创公司工作，通常每周工作60个小时，工资比我作为承包商的工资要少得多，因为团队很棒，工作很有趣。
但从大局来看，这只是一份工作。
它的重要性低于许多事情，如家庭、女朋友、朋友、幸福等，也低于其他如果我有无限的现金供应，我宁愿做的事情，如骑摩托车、驾驶游艇或滑雪。
我认为有时候许多开发者忘记了开发只是让我们拥有生活中更重要的东西(通过做一些我们喜欢的事情来拥有它们)，而不是最终目标本身。
单身人士并不邪恶
There is a place for singletons in the real world, and methods to get around them (i.e. monostate pattern) are simply singletons in disguise. For instance, a Logger is a perfect candidate for a singleton. Addtionally, so is a message pump. My current app uses distributed computing, and different objects need to be able to send appropriate messages. There should only be one message pump, and everyone should be able to access it. The alternative is passing an object to my message pump everywhere it might be needed and hoping that a new developer doesn't new one up without thinking and wonder why his messages are going nowhere. The uniqueness of the singleton is the most important part, not its availability. The singleton has its place in the world.
罗布·派克写道:“数据占主导地位。如果你选择了正确的数据结构，并且组织得很好，算法几乎总是不言而喻的。数据结构，而不是算法，才是编程的核心。”
由于现在任何重要的数据都在数百万条记录中，我认为良好的数据建模是最重要的编程技能(无论是使用rdbms还是sqlite或amazon simpleDB或谷歌appengine数据存储)。
当所有的数据都存储在这样的数据存储系统中时，就不再需要花哨的搜索和排序算法了。
初级程序员在被允许实际编写或修改代码之前，应该被分配做几个月的对象/模块设计和设计维护。
太多的程序员/开发人员在工作了5年或10年之后，还没有理解好的设计的要素。当他们想要超越编写和维护代码时，这可能会让他们陷入瘫痪。
(未命名)元组是邪恶的
如果您使用元组作为具有唯一含义的多个对象的容器，请改用类。 如果您使用它们来保存几个应该通过索引访问的对象，请使用列表。 如果您使用它们从一个方法中返回多个值，请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分，那就继续使用它们!
我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。
后藤很好!(这足够有争议了吗) 有时……所以给我们选择吧!例如，BASH不需要去。也许有一些内部原因，但仍然。 此外，goto是汇编语言的构建块。没有if语句!：）
System.Data.DataSet岩石!
在我看来，对于大多数业务应用程序，强类型数据集比自定义DDD对象更好。
推理:我们在自定义对象、LINQ to SQL、实体框架上绞尽脑汁地寻找工作单元，这增加了复杂性。使用一个好的代码生成器来生成数据层，工作单元位于对象集合(DataTable和DataSet)上——这并不神秘。
我曾经因为在公共场合发表这些观点而受到批评，但现在我要说的是:
动态类型语言中编写良好的代码遵循静态类型约定
在使用过Python、PHP、Perl和其他一些动态类型语言之后，我发现用这些语言编写的良好代码遵循静态类型约定，例如:
Its considered bad style to re-use a variable with different types (for example, its bad style to take a list variable and assign an int, then assign the variable a bool in the same method). Well-written code in dynamically typed languages doesn't mix types. A type-error in a statically typed language is still a type-error in a dynamically typed language. Functions are generally designed to operate on a single datatype at a time, so that a function which accepts a parameter of type T can only sensibly be used with objects of type T or subclasses of T. Functions designed to operator on many different datatypes are written in a way that constrains parameters to a well-defined interface. In general terms, if two objects of types A and B perform a similar function, but aren't subclasses of one another, then they almost certainly implement the same interface.
虽然动态类型语言当然提供了不止一种解决难题的方法，但这些语言中大多数编写良好的惯用代码都密切关注类型，就像用静态类型语言编写的代码一样严格。
动态类型并不会减少程序员需要编写的代码量
When I point out how peculiar it is that so many static-typing conventions cross over into dynamic typing world, I usually add "so why use dynamically typed languages to begin with?". The immediate response is something along the lines of being able to write more terse, expressive code, because dynamic typing allows programmers to omit type annotations and explicitly defined interfaces. However, I think the most popular statically typed languages, such as C#, Java, and Delphi, are bulky by design, not as a result of their type systems.
我喜欢使用带有真正类型系统的语言，比如OCaml，它不仅是静态类型，而且它的类型推断和结构类型允许程序员省略大多数类型注释和接口定义。
ML语言家族的存在表明，我们可以享受静态类型的好处，同时也享受动态类型语言的简洁。实际上，我使用OCaml的REPL来编写临时的、一次性的脚本，就像其他人使用Perl或Python作为脚本语言一样。
代码布局很重要
也许双括号位置的细节应该保持纯粹的宗教争论-但这并不意味着所有的布局风格都是平等的，或者根本没有客观因素!
问题在于布局的超级规则，即:“保持一致”，尽管听起来不错，但被许多人用作拐杖，从不尝试看看他们的默认风格是否可以改进——而且，这甚至无关紧要。
几年前，我正在学习快速阅读技术，我学到的一些东西是关于眼睛如何在“固定”中获取信息，如何最优地扫描页面，以及潜意识中拾取上下文的作用，这让我思考如何将其应用到代码中——尤其是在编写代码时牢记它。
它使我形成了一种本质上倾向于柱状的样式，在可能的情况下对标识符进行逻辑分组和对齐(特别是我严格要求每个方法参数都在自己的行上)。然而，与一成不变的长柱结构相比，以块为单位改变结构实际上是有益的，这样你最终会得到眼睛可以在一个固定装置中接受的矩形岛屿——即使你没有有意识地阅读每个字符。
最终的结果是，一旦你习惯了它(通常需要1-3天)，它就会变得赏心悦目，更容易理解，对眼睛和大脑的负担也更少，因为它的布局方式更容易接受。
几乎无一例外，我邀请的每个尝试这种风格的人(包括我自己)一开始都说，“啊，我讨厌它!”，但过了一两天就说，“我喜欢它——我发现很难不回头用这种方式重写我所有的旧东西!”
我一直希望有时间做更多的对照实验，以收集足够的证据来写一篇论文，但一直忙于其他事情。然而，这似乎是一个向那些对有争议的技术感兴趣的人提及它的好机会:-)
(编辑)
我终于抽出时间把这件事写在博客上(在“意义”阶段停留了很多年之后):第一部分，第二部分，第三部分。
创建类似于带有疯牛病的椒盐卷饼的UML图的能力实际上并不是一种有用的软件开发技能。
图代码的全部意义在于可视化连接，看到设计的形状。但是一旦你通过了一个相当低的复杂水平，想象就太多了，无法在精神上处理。只有在坚持使用直线的情况下，图形化地建立连接才比较简单，这通常会使图表比沿着基本方向巧妙地分组和路由连接更难阅读。
仅在广泛的交流目的下使用图表，并且仅当它们被理解为谎言时使用。
SQL可以而且应该做得更好。由于其原始规范有限，多年来各种厂商一直在向不同方向扩展该语言。为MS-SQL编写的SQL与为Oracle、IBM、MySQL、Sybase等编写的SQL不同。其他严肃的语言(以c++为例)都经过了仔细的标准化，因此在一个编译器下编写的c++通常可以在另一个编译器下编译而无需修改。为什么SQL不能被更好地设计和标准化呢?
HTML作为浏览器显示语言是一个严重的错误选择。我们花了数年时间通过CSS、XHTML、Javascript、Ajax、Flash等进行扩展，以制作一个可用的UI，但结果仍然不如你的基本厚客户端windows应用程序。此外，一个称职的web程序员现在需要了解三到四种语言才能制作一个像样的UI。
噢,是的。匈牙利符号令人厌恶。
全局变量和/或单例变量本身并不邪恶
我来自更多的系统管理员，shell, Perl(和我的“真正的”编程)，PHP类型的背景;去年我被派去做Java开发工作。
单身是邪恶的。全球人太邪恶了，他们甚至不被允许。然而，Java有像AOP这样的东西，现在还有各种“依赖注入”框架(我们使用谷歌Guice)。AOP就不是这样了，但是DI的东西肯定会给你什么?全局变量。啊,谢谢。
实现IDisposable的类库指南是错误的。
我不经常分享这一点，但我相信IDisposable的默认实现的指导是完全错误的。
我的问题不是Dispose的过载，然后从终结器中删除项目，而是我鄙视终结器中释放托管资源的调用。我个人认为应该抛出异常(是的，在结束器线程上抛出异常会带来很多麻烦)。
其背后的原因是，如果您是IDisposable的客户端或服务器，那么您不能简单地将对象放置在那里等待最终确定。如果您这样做了，这是一个设计/实现缺陷(取决于它是如何放置的和/或它是如何暴露的)，因为您没有意识到您应该意识到的实例的生命周期。
我认为这种类型的错误/错误是在竞争条件/资源同步的水平上。不幸的是，通过调用Dispose的重载，该错误永远不会实现。
编辑:我写了一篇关于这个主题的博客文章，如果有人感兴趣的话:
http://www.caspershouse.com/post/A-Better-Implementation-Pattern-for-IDisposable.aspx
SESE (Single Entry Single Exit)不是法律
例子:
public int foo() {
if( someCondition ) {
return 0;
}
return -1;
}
vs:
public int foo() {
int returnValue = -1;
if( someCondition ) {
returnValue = 0;
}
return returnValue;
}
我和我的团队发现，在很多情况下，一直遵守这一点实际上会适得其反。
Null引用应该从OO语言中删除
从Java和c#的背景来看，从一个方法中返回null来表示失败是很正常的，我已经得出结论，null会导致很多可以避免的问题。语言设计者只要从代码中消除空引用，就可以删除与nullrefernceexception相关的一整类错误。
Additionally, when I call a method, I have no way of knowing whether that method can return null references unless I actually dig in the implementation. I'd like to see more languages follow F#'s model for handling nulls: F# doesn't allow programmers to return null references (at least for classes compiled in F#), instead it requires programmers to represent empty objects using option types. The nice thing about this design is how useful information, such as whether a function can return null references, is propagated through the type system: functions which return a type 'a have a different return type than functions which return 'a option.
观点:数据驱动的设计本末倒置。它应该立即从我们的思想中消除。
绝大多数软件不是关于数据的，而是关于我们试图为客户解决的业务问题。它是关于一个问题域的，涉及对象、规则、流程、案例和关系。
当我们从数据开始设计，并根据数据和数据之间的关系(表、外键和x-to-x关系)对系统的其余部分建模时，我们将整个应用程序限制为如何在数据库中存储数据和如何从数据库中检索数据。此外，我们将数据库体系结构公开给软件。
数据库模式是一个实现细节。我们应该可以自由地改变它，而不需要对我们的软件设计进行任何显著的改变。业务层不应该知道表是如何设置的，或者是从视图中提取还是从表中提取，或者是从动态SQL或存储过程中获取表。这种类型的代码永远不应该出现在表示层中。
软件是用来解决业务问题的。我们要处理用户、汽车、帐户、余额、平均值、摘要、转账、动物、消息、包裹、购物车、订单和其他各种真实的有形对象，以及我们可以对它们执行的操作。我们需要根据需要保存、加载、更新、查找和删除这些项。有时候，我们必须以特殊的方式来做这些事情。
But there's no real compelling reason that we should take the work that should be done in the database and move it away from the data and put it in the source code, potentially on a separate machine (introducing network traffic and degrading performance). Doing so means turning our backs on the decades of work that has already been done to improve the performance of stored procedures and functions built into databases. The argument that stored procedures introduce "yet another API" to be manged is specious: of course it does; that API is a facade that shields you from the database schema, including the intricate details of primary and foreign keys, transactions, cursors, and so on, and it prevents you from having to splice SQL together in your source code.
把马放回马车前面。思考问题领域，并围绕它设计解决方案。然后，从问题域导出数据。
打印语句是调试代码的有效方法
我相信用System.out.println(或任何适用于您的语言的打印语句)来调试代码是完全没问题的。通常，这比调试要快，并且可以将打印输出与应用程序的其他运行进行比较。
只要确保在进入生产环境时删除打印语句(或者更好的做法是将它们转换为日志语句)
我认为在c#中使用区域来折叠你的代码是完全可以接受的，而在vs中，太多的人试图说它隐藏了你的代码，让你很难找到东西。但如果你正确地使用它们，它们对识别代码段非常有帮助。
To Be A Good Programmer really requires working in multiple aspects of the field: Application development, Systems (Kernel) work, User Interface Design, Database, and so on. There are certain approaches common to all, and certain approaches that are specific to one aspect of the job. You need to learn how to program Java like a Java coder, not like a C++ coder and vice versa. User Interface design is really hard, and uses a different part of your brain than coding, but implementing that UI in code is yet another skill as well. It is not just that there is no "one" approach to coding, but there is not just one type of coding.
不是很有争议，但是… AJAX早在这个术语被创造出来之前就已经存在了，每个人都需要“放手”。人们用它做各种各样的事情。但是没有人真正关心它。
然后突然嘣!有人创造了这个术语，每个人都加入了AJAX的潮流。突然之间，人们成了AJAX的专家，好像动态加载数据的“专家”以前并不存在似的。我认为这是导致互联网被残酷摧毁的最大因素之一。还有“Web 2.0”。
要成为一名程序员，你必须会打字。
这在那些不知道如何打字，但坚持认为他们可以像任何打字员一样用两根手指搜索和啄的人之间存在争议，或者他们真的不需要花那么多时间打字，或者智能感知减轻了打字的需要……
我从来没有遇到过会打字的人，但坚持认为打字没什么区别。
参见:编程中最肮脏的小秘密
在开始构建电子系统之前，每个开发人员都应该花几周甚至几个月的时间来开发基于纸张的系统。他们还应该被迫使用他们的系统。
开发一个好的基于纸张的系统是一项艰苦的工作。它迫使你考虑人性(繁琐的过程会被忽略，过于复杂的过程往往会崩溃)，并教会你欣赏简单的价值(新工作放在这个托盘里，QA工作放在这个托盘里，存档放在这个盒子里)。
一旦你弄清楚如何在纸上构建一个系统，构建一个有效的计算机系统通常会容易得多——一个人们实际上想要(并且能够)使用的系统。
我们开发的系统并不是由一群训练有素的自动机控制的;真实的人使用它们，真实的人由经理培训，经理也是真实的人，没有太多的时间浪费在培训他们如何跳过你的圈子。
事实上，关于我的第二点:
每个开发人员都应该被要求进行交互式培训课程，向用户展示如何使用他们的软件。
“谷歌一下”是可以的!
是的，我知道这冒犯了一些人，他们多年的密集记忆和/或辉煌的编程书籍开始在一种任何人都可以在几秒钟内访问的资源中倒下，但你不应该反对使用它的人。
我经常听到有人用谷歌搜索问题的答案，但这确实毫无意义。首先，必须承认每个人都需要参考资料。你不是什么都知道，你需要去查资料。我承认，你从哪里得到的信息真的重要吗?你是在书上查到的，还是在谷歌上查到的，还是从你幻觉中的会说话的青蛙那里听到的，这有关系吗?不。正确的答案就是正确的答案。
重要的是你理解这些材料，将其作为成功编程解决方案的手段，并且客户/雇主对结果感到满意。
(虽然如果你是从幻觉中会说话的青蛙那里得到答案，你可能还是应该得到一些帮助)
如果你知道如何编程，你就不适合在表单上放置按钮
这有足够的争议吗?；）
不管我们多么努力，我们几乎不可能对53岁的Doris产生适当的同情，她必须使用我们的订单输入软件。我们根本无法掌握她想象的计算机内部正在发生的事情的心智模式，因为我们不需要想象:我们知道正在发生什么，或者有一个非常好的想法。
交互设计应该由非程序员来完成。当然，这永远不会发生。相反，我对此很高兴;我喜欢UI设计，尽管内心深处我知道我并不适合它。
欲了解更多信息，请阅读《囚犯们在管理精神病院》这本书。请注意，这本书让我心烦意乱，很无礼;如果你是一个关心用户体验的开发人员，这是一篇很难读懂的文章。
不要在数据库中使用stored proc。
它们最初的优点——安全性、抽象性、单一连接——都可以在集成了许多其他优点的orm的中间层中实现。
这无疑是有争议的。每次我提起这件事，人们就把我撕成碎片。
QA应该比开发人员更了解代码(间接地)。QA通过发现开发人员不希望发生的事情而获得报酬，他们经常这样做。(顺便说一句，我是一名非常看重优秀QA人员的开发者。很少)。
那些不在业余时间编写代码取乐的程序员永远不会像那些在业余时间编写代码的程序员一样优秀。
我认为即使是最聪明和最有才华的人也永远不会成为真正优秀的程序员，除非他们不只是把编程当成一份工作。这意味着他们在业余时间做一些小项目，或者只是在业余时间摆弄各种不同的语言和想法。
(注意:我并不是说优秀的程序员除了编程什么都不做，而是说他们比朝九晚五的编程做得更多)
软件架构师/设计人员被高估了
作为一名开发人员，我讨厌软件架构师这个概念。他们基本上不再全职编码，阅读杂志和文章，然后告诉你如何设计软件。只有那些真正以全职编写软件为生的人才应该这样做。我不在乎5年前你在成为架构师之前是不是世界上最好的程序员，你的观点对我来说毫无用处。
这有争议吗?
编辑(澄清一下):我认为大多数软件架构师都是出色的业务分析师(与客户交谈，编写需求，测试等)，我只是认为他们在设计软件方面没有一席之地，无论是高级的还是其他的。
尽管我完全支持测试驱动开发(TDD)，但我认为在开发人员开始对问题的解决方案进行原型化的整个开发周期之前，还有一个至关重要的步骤。
我们经常陷入试图遵循我们的TDD实践来寻找一个可能被误导的解决方案，因为我们对这个领域不够了解。简单的原型通常可以阐明这些问题。
原型是很好的，因为与首先编写测试相比(有时)，您可以快速地浏览和丢弃更多的代码。然后，您可以开始开发过程，在空白的石板，但更好的理解。
“Java烂透了”——是的，我知道不是所有人都这么认为:)
我有这样的观点，因为我所见过的大多数Java应用程序都是内存占用，运行缓慢，用户界面糟糕等等。
探员
Python方法声明中的显式self是糟糕的设计选择。
方法调用有语法糖，但声明没有。这是一个有漏洞的抽象(故意的!)，会导致令人讨厌的错误，包括运行时错误，在报告的参数数量中明显少了一个错误。
原始数据类型是不成熟的优化。
有些语言只使用一种数据类型，即标量，它们做得很好。其他语言就没有这么幸运了。开发人员只是把“int”和“double”扔进去，因为他们必须写一些东西。
What's important is not how big the data types are, but what the data is used for. If you have a day of the month variable, it doesn't matter much if it's signed or unsigned, or whether it's char, short, int, long, long long, float, double, or long double. It does matter that it's a day of the month, and not a month, or day of week, or whatever. See Joel's column on making things that are wrong look wrong; Hungarian notation as originally proposed was a Good Idea. As used in practice, it's mostly useless, because it says the wrong thing.
我们在这里使用我们构建的模型-视图-控制器框架进行了大量的开发。我经常告诉我的开发人员，我们需要违反MVC设计模式的规则，以使网站运行得更快。这对开发人员来说是很难接受的，他们通常不愿意牺牲设计良好的代码。但是性能是我们构建web应用程序的首要任务，所以有时我们不得不在框架上做出让步。
例如，视图层永远不应该直接与数据库对话，对吗?但是，如果你要生成大型报告，应用程序将使用大量内存来通过模型层和控制器层传递数据。如果你有一个支持游标的数据库，它可以让应用程序更快地直接从视图层访问数据库。
性能胜过开发标准，这是我有争议的观点。
我认为使用try/catch异常处理比使用简单的返回代码和相关的公共消息传递结构来传递有用的错误消息更糟糕。
用try/catch块乱扔代码不是解决方案。
只是将异常传递到堆栈上，希望上面的内容会做正确的事情或 生成信息错误并不是解决方案。
认为您有机会系统地验证适当的异常处理程序可以解决透明对象或opague对象中可能出现的任何错误，这是不现实的。(还要考虑到后期绑定/外部库以及随着系统的发展，调用堆栈中不相关函数之间不必要的依赖关系)
返回代码的使用很简单，可以很容易地系统地验证覆盖范围，如果处理得当，就会迫使开发人员生成有用的错误消息，而不是太常见的堆栈转储和模糊的I/O异常，即使对最聪明的最终用户来说，这些异常也“异常”毫无意义。
--
我最后的反对意见是使用垃圾收集语言。不要误会我的意思。在某些情况下，我喜欢它们，但在服务器/MC系统中，它们在我看来没有位置。
GC并不是绝对正确的——即使是设计得非常好的GC算法也可能基于依赖关系图中不明显的循环引用而在对象上停留太长时间，甚至永远停留。
遵循一些简单模式并使用内存计算工具的非GC系统不会有这个问题，但在设计和测试方面需要比GC环境做更多的工作。这里的权衡是，在非GC测试期间，内存泄漏非常容易发现，而找到与GC相关的问题条件则要困难得多。
内存是便宜的，但当你泄露昂贵的对象，如事务句柄、同步对象、套接字连接……在我的环境中，如果不对软件描述进行重大的基本更改，那么您可以坐下来让语言为您操心，这种想法是不可想象的。
PHP文件中过多的HTML:有时是必要的
PHP文件中Javascript过多:触发猛禽攻击
虽然我很难弄清楚在echo和?>< ?php 'ing html之间的所有切换(毕竟，php只是html的处理器)，但添加的一行又一行javascript使它完全无法维护。
人们必须明白这一点:它们是两种独立的编程语言。选择一种作为你的主要语言。然后继续寻找一种快速、干净、易于维护的方法，使你的主要语言包括第二语言。
你之所以总是在PHP、Javascript和HTML之间切换，是因为你对这三种语言都不在行。
好吧，也许这并不是很有争议。我的印象是，这是一个普遍的沮丧发泄话题:)
Web应用程序糟透了
我的网速很慢。我使用几乎所有不是谷歌的网站的经验至少是令人沮丧的。为什么现在没人写桌面应用了?哦，我明白了。没有人愿意学习操作系统是如何工作的。至少，不是Windows。上次你不得不处理WM_PAINT，你的头爆炸了。创建一个工作线程来执行一个长时间的任务(我的意思是，用Windows的方式来做)完全超出了你的能力。回调是什么鬼?哦，天哪!
垃圾收集糟透了
No, it actually doesn't. But it makes the programmers suck like nothing else. In college, the first language they taught us was Visual Basic (the original one). After that, there was another course where the teachers pretended they taught us C++. But the damage was done. Nobody actually knew how to use this esoteric keyword delete did. After testing our programs, we either got invalid address exceptions or memory leaks. Sometimes, we got both. Among the 1% of my faculty who can actually program, only one who can manage his memory by himself (at least, he pretends) and he's writing this rant. The rest write their programs in VB.NET, which, by definition, is a bad language.
动态类型糟糕透了
当然，除非您正在使用汇编程序(这是一种值得称赞的动态类型)。我的意思是动态解释性语言带来的开销让它们很糟糕。不要用不同的工具适合不同的工作这种愚蠢的论点。C语言是几乎所有事情的正确语言(它快速、强大、可移植)，当它不是(它不够快)时，总有内联汇编。
我可能会提出更多的咆哮，但那将是以后，不是现在。
Never make up your mind on an issue before thoroughly considering said issue. No programming standard EVER justifies approaching an issue in a poor manner. If the standard demands a class to be written, but after careful thought, you deem a static method to be more appropriate, always go with the static method. Your own discretion is always better than even the best forward thinking of whoever wrote the standard. Standards are great if you're working in a team, but rules are meant to be broken (in good taste, of course).
c++是有史以来最糟糕的编程语言之一。
它具有委员会设计的所有特征——它不能很好地完成任何给定的工作，而且某些工作(如面向对象)做得很糟糕。它有一种“厨房水槽”的绝望，不会消失。
它是学习编程的可怕的“第一语言”。你(从语言中)得不到优雅，得不到帮助。取而代之的是陷阱和雷区(内存管理、模板等)。
它不是一种学习面向对象概念的好语言。它表现为“带有类包装器的C”，而不是一种合适的OO语言。
我可以继续讲下去，但现在就讲到这里。我从来不喜欢用c++编程，虽然我是在FORTRAN上“磨砺”的，但我完全喜欢用C编程。我仍然认为C是最伟大的“经典”语言之一。在我看来，c++肯定不是这样的。
欢呼,
-R
EDIT: To respond to the comments on teaching C++. You can teach C++ in two ways - either teaching it as C "on steroids" (start with variables, conditions, loops, etc), or teaching it as a pure "OO" language (start with classes, methods, etc). You can find teaching texts that use one or other of these approaches. I prefer the latter approach (OO first) as it does emphasize the capabilities of C++ as an OO language (which was the original design emphasis of C++). If you want to teach C++ "as C", then I think you should teach C, not C++.
但就我的经验而言，c++作为第一语言的问题在于，这门语言太大了，无法在一个学期内教授，而且大多数“介绍”文本试图涵盖所有内容。在“第一语言”课程中涵盖所有主题是不可能的。在我看来，你至少要把它分成两个学期，然后它就不再是“第一语言”了。
我确实教c++，但只是作为一种“新语言”——也就是说，你必须精通一些先前的“纯”语言(不是脚本或宏)，然后才能注册这门课程。在我看来，c++是一种很好的“第二语言”。
-R
另一个编辑:(对康拉德)
I do not at all agree that C++ "is superior in every way" to C. I spent years coding C programs for microcontrollers and other embedded applications. The C compilers for these devices are highly optimized, often producing code as good as hand-coded assembler. When you move to C++, you gain a tremendous overhead imposed by the compiler in order to manage language features you may not use. In embedded applications, you gain little by adding classes and such, IMO. What you need is tight, clean code. You can write it in C++, but then you're really just writing C, and the C compilers are more optimized in these applications.
I wrote a MIDI engine, first in C, later in C++ (at the vendor's request) for an embedded controller (sound card). In the end, to meet the performance requirements (MIDI timings, etc) we had to revert to pure C for all of the core code. We were able to use C++ for the high-level code, and having classes was very sweet - but we needed C to get the performance at the lower level. The C code was an order of magnitude faster than the C++ code, but hand coded assembler was only slightly faster than the compiled C code. This was back in the early 1990s, just to place the events properly.
-R
有很多糟糕的教学。
当Joel说大脑中有一部分是用来理解指针的，而有些人生来就没有指针时，我们开发人员就会沾沾自喜。我们许多人在这里讨论和热衷的话题都很深奥，但有时这只是因为我们把它们弄得如此深奥。
最好的代码通常不是你写的。作为程序员，我们希望通过编写一些很酷的方法来解决每个问题。任何时候，我们都能在解决问题的同时满足用户80%的需求，而无需引入更多代码进行维护和测试，我们已经提供了更多的价值。
C(或c++)应该是第一种编程语言
第一语言不应该是简单的，它应该是建立学生的思想，为严肃的计算机科学做准备的语言。 C语言是完美的，它迫使学生考虑内存和所有低级别的东西，同时他们可以学习如何构造代码(它有函数!)
c++有一个额外的优势，它真的很糟糕:)这样学生就会明白为什么人们必须想出Java和c#
库克的格言随意收集……
The hardest language to learn is your second. The hardest OS to learn is your second one - especially if your first was an IBM mainframe. Once you've learned several seemingly different languages, you finally realize that all programming languages are the same - just minor differences in syntax. Although one can be quite productive and marketable without having learned any assembly, no one will ever have a visceral understanding of computing without it. Debuggers are the final refuge for programmers who don't really know what they're doing in the first place. No OS will ever be stable if it doesn't make use of hardware memory management. Low level systems programming is much, much easier than applications programming. The programmer who has a favorite language is just playing. Write the User's Guide FIRST! Policy and procedure are intended for those who lack the initiative to perform otherwise. (The Contractor's Creed): Tell'em what they need. Give'em what they want. Make sure the check clears. If you don't find programming fun, get out of it or accept that although you may make a living at it, you'll never be more than average. Just as the old farts have to learn the .NET method names, you'll have to learn the library calls. But there's nothing new there. The life of a programmer is one of constantly adapting to different environments, and the more tools you have hung on your belt, the more versatile and marketable you'll be. You may piddle around a bit with little code chunks near the beginning to try out some ideas, but, in general, one doesn't start coding in earnest until you KNOW how the whole program or app is going to be layed out, and you KNOW that the whole thing is going to work EXACTLY as advertised. For most projects with at least some degree of complexity, I generally end up spending 60 to 70 percent of the time up front just percolating ideas. Understand that programming has little to do with language and everything to do with algorithm. All of those nifty geegaws with memorable acronyms that folks have come up with over the years are just different ways of skinning the implementation cat. When you strip away all the OOPiness, RADology, Development Methodology 37, and Best Practice 42, you still have to deal with the basic building blocks of: assignments conditionals iterations control flow I/O
一旦你能真正地把自己包围起来，你最终会到达你想要的那个点 看(从编程的角度来看)编写库存应用程序之间的差别很小 一个汽车零部件公司，一个图形实时TCP性能分析仪，一个数学模型 一个恒星核心，或者一个约会日历。
初级程序员处理小块代码。随着经验的积累， 他们处理越来越大的代码块。 随着经验的增加，他们开始处理小块代码。
根据我得到的大量反馈，我最具争议的观点显然是，程序员并不总是读他们声称读过的书。这紧跟着我的观点，一个受过正规教育的程序员比一个自学成才的程序员更好(但不一定比另一个自学成才的程序员更好)。
在编程中使用的进程越多，代码就会变得越糟糕
I have noticed something in my 8 or so years of programming, and it seems ridiculous. It's that the only way to get quality is to employ quality developers, and remove as much process and formality from them as you can. Unit testing, coding standards, code/peer reviews, etc only reduce quality, not increase it. It sounds crazy, because the opposite should be true (more unit testing should lead to better code, great coding standards should lead to more readable code, code reviews should improve the quality of code) but it's not.
我认为这可以归结为我们称之为“软件工程”的事实，而实际上它是设计而不是工程。
以下数字可以证实这一说法:
From the Editor IEEE Software, November/December 2001 Quantifying Soft Factors by Steve McConnell ... Limited Importance of Process Maturity ... In comparing medium-size projects (100,000 lines of code), the one with the worst process will require 1.43 times as much effort as the one with the best process, all other things being equal. In other words, the maximum influence of process maturity on a project’s productivity is 1.43. ... ... What Clark doesn’t emphasize is that for a program of 100,000 lines of code, several human-oriented factors influence productivity more than process does. ... ... The seniority-oriented factors alone (AEXP, LTEX, PEXP) exert an influence of 3.02. The seven personnel-oriented factors collectively (ACAP, AEXP, LTEX, PCAP, PCON, PEXP, and SITE §) exert a staggering influence range of 25.8! This simple fact accounts for much of the reason that non-process-oriented organizations such as Microsoft, Amazon.com, and other entrepreneurial powerhouses can experience industry-leading productivity while seemingly shortchanging process. ... The Bottom Line ... It turns out that trading process sophistication for staff continuity, business domain experience, private offices, and other human-oriented factors is a sound economic tradeoff. Of course, the best organizations achieve high motivation and process sophistication at the same time, and that is the key challenge for any leading software organization.
请阅读文章，了解这些首字母缩写词的解释。
Xah Lee: actually has some pretty noteworthy and legitimate viewpoints if you can filter out all the invective, and rationally evaluate statements without agreeing (or disagreeing) based solely on the personality behind the statements. A lot of my "controversial" viewpoints have been echoed by him, and other notorious "trolls" who have criticized languages or tools I use(d) on a regular basis. [Documentation Generators](http://en.wikipedia.or /wiki/Comparison_of_documentation_generators): ... the kind where the creator invented some custom-made especially-for-documenting-sourcecode roll-your-own syntax (including, but not limited to JavaDoc) are totally superfluous and a waste of time because: 1) They are underused by the people who should be using them the most; and 2) All of these mini-documentation-languages all of them could easily be replaced with YAML
继承是邪恶的，应该被摈弃。
事实是，在任何情况下，聚合都更好。静态类型的OOP语言不能避免继承，它是描述方法想从类型中得到什么的唯一方法。但是动态语言和鸭子类型可以没有它。Ruby mixins比继承强大得多，也更可控。
一旦发现缺陷就改正。不仅仅是“严重程度1”的缺陷;所有的缺陷。
建立一种部署机制，使用户可以立即使用应用程序更新，但允许他们选择何时接受这些更新。与用户建立直接的沟通机制，使他们能够报告缺陷，将他们的经验与更新联系起来，并提出改进建议。
With aggressive testing, many defects can be discovered during the iteration in which they are created; immediately correcting them reduces developer interrupts, a significant contributor to defect creation. Immediately correcting defects reported by users forges a constructive community, replacing product quality with product improvement as the main topic of conversation. Implementing user-suggested improvements that are consistent with your vision and strategy produces community of enthusiastic evangelists.
计算机科学学位不会——也不应该——教你成为一名程序员。
编程是一门手艺，计算机科学是一个研究领域。你可以是一个伟大的程序员，也可以是一个糟糕的计算机科学家，也可以是一个伟大的计算机科学家，也可以是一个糟糕的程序员。了解其中的区别是很重要的。
如果你想成为一名程序员，学习Java。如果你想成为一名计算机科学家，至少要学习三种几乎完全不同的语言。例如(汇编语言，c语言，lisp语言，ruby语言，smalltalk语言)
Web服务绝对很糟糕，也不是未来的发展方向。他们的效率低得可笑，而且他们不能保证订单交货。Web服务绝不应该在同时编写客户端和服务器的系统中使用。它们对于米老鼠混搭类型的应用程序非常有用。它们绝对不应该用于任何类型的面向连接的通信。
这种立场让我和同事们进行了一些非常热烈的讨论，因为web服务是一个非常热门的话题。任何强制使用web服务的项目都是注定要失败的，因为它显然已经从管理层那里得到了荒谬的要求。
我有争议的观点:面向对象编程绝对是软件工程领域发生过的最糟糕的事情。
面向对象编程的主要问题是完全缺乏一个每个人都能认同的严格定义。这很容易导致实现中存在逻辑漏洞，或者像Java这样的语言坚持这种关于OOP含义的奇怪的宗教教条，同时迫使程序员做所有这些扭曲和“设计模式”，只是为了绕过特定OOP系统的限制。
因此，OOP欺骗程序员，让他们认为他们正在获得这些巨大的生产力收益，OOP在某种程度上是一种“自然”的思考方式，同时迫使程序员输入大量不必要的样板文件。
然后，由于没有人知道OOP的真正含义，我们浪费了大量的时间在争论语言X或Y是否“真正的面向对象”，什么奇怪的语言特性对于一种语言被认为是“真正的面向对象”是绝对“必要的”。
与其要求这种语言或那种语言是“真正的面向对象的”，我们应该看看实验显示了什么语言特性，以实际提高生产力，而不是试图强迫它成为某种想象中的理想语言，或者强迫我们的程序符合某种“真正面向对象的程序”的柏拉图式理想。
与其坚持我们的程序符合“真正面向对象”的柏拉图式理想，不如我们专注于坚持良好的工程原则，使我们的代码易于阅读和理解，并使用一种语言的高效和有用的特性，而不管它们是否足够“面向对象”。
您不应该停留在您发现的编写“有效”代码的第一种方法上。
I really don't think this should be controversial, but it is. People see an example from elsewhere in the code, from online, or from some old "Teach yourself Advanced Power SQLJava#BeansServer in 3.14159 minutes" book dated 1999, and they think they know something and they copy it into their code. They don't walk through the example to find out what each line does. They don't think about the design of their program and see if there might be a more organized or more natural way to do the same thing. They don't make any attempt at keeping their skill sets up to date to learn that they are using ideas and methods deprecated in the last year of the previous millenium. They don't seem to have the experience to learn that what they're copying has created specific horrific maintenance burdens for programmers for years and that they can be avoided with a little more thought.
事实上，他们似乎甚至没有意识到做一件事可能有不止一种方法。
I come from the Perl world, where one of the slogans is "There's More Than One Way To Do It." (TMTOWTDI) People who've taken a cursory look at Perl have written it off as "write-only" or "unreadable," largely because they've looked at crappy code written by people with the mindset I described above. Those people have given zero thought to design, maintainability, organization, reduction of duplication in code, coupling, cohesion, encapsulation, etc. They write crap. Those people exist programming in every language, and easy to learn languages with many ways to do things give them plenty of rope and guns to shoot and hang themselves with. Simultaneously.
But if you hang around the Perl world for longer than a cursory look, and watch what the long-timers in the community are doing, you see a remarkable thing: the good Perl programmers spend some time seeking to find the best way to do something. When they're naming a new module, they ask around for suggestions and bounce their ideas off of people. They hand their code out to get looked at, critiqued, and modified. If they have to do something nasty, they encapsulate it in the smallest way possible in a module for use in a more organized way. Several implementations of the same idea might hang around for awhile, but they compete for mindshare and marketshare, and they compete by trying to do the best job, and a big part of that is by making themselves easily maintainable. Really good Perl programmers seem to think hard about what they are doing and looking for the best way to do things, rather than just grabbing the first idea that flits through their brain.
如今，我主要在Java世界中编程。我见过一些非常好的Java代码，但我也见过很多垃圾代码，而且我还看到了更多我在开头描述的心态:人们选择了第一个看起来可以工作的丑陋代码块，而不理解它，也不考虑是否有更好的方法。
You will see both mindsets in every language. I'm not trying to impugn Java specifically. (Actually I really like it in some ways ... maybe that should be my real controversial opinion!) But I'm coming to believe that every programmer needs to spend a good couple of years with a TMTOWTDI-style language, because even though conventional wisdom has it that this leads to chaos and crappy code, it actually seems to produce people who understand that you need to think about the repercussions of what you are doing instead of trusting your language to have been designed to make you do the right thing with no effort.
我确实认为你可能会在另一个方向上走得太远:例如，完美主义完全忽略了你的真正需求和目标(通常是你的业务的真正需求和目标，通常是盈利能力)。但我不认为任何人都能成为一个真正伟大的程序员，除非学会投入一些高于平均水平的努力来思考寻找最好的(或至少是最好的一种)方法来编码他们正在做的事情。
Variable_Names_With_Bloody_Underscores
或者更糟
CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES
应该在全球范围内清除……与偏见!CamelCapsAreJustFine。 (全局常数不承受)
GOTO语句仅供11岁以下的开发人员使用
任何不支持指针的语言都名不副实
.Net = .Bloat 微软网站开发的最佳范例(无表情web 2) 是缓慢膨胀的最好的例子cr@pw@re曾经写过。 (可以试试Web Studio)
回应: 好的，让我来谈谈下划线的问题。从你提供的C链接:
-全局常量应该全部大写，用“_”分隔符。 我实际上同意这一点，因为这太明显了
-以NetworkABCKey为例。注意ABC中的C和调音中的K是如何混淆的。有些人不介意这一点，有些人只是讨厌它，所以你会在不同的代码中发现不同的策略，所以你永远不知道该如何调用某个东西。
我属于前者。我选择名字非常谨慎，如果你不能一眼看出K属于Key，那么英语可能不是你的第一语言。
C函数名 在c++项目中应该有很少的C函数。 对于C函数，使用GNU约定的所有小写字母，以'_'作为单词分隔符。
的理由
* It makes C functions very different from any C++ related names.
例子
int some_bloody_function () ｛ ｝
这些“标准”和惯例只不过是随时间而传下来的任意决定。我认为，虽然它们有一定的逻辑意义，但它们使代码变得混乱，使一些本应简短而易于阅读的东西变得笨拙、冗长和混乱。
C被采纳为事实上的标准，不是因为它友好，而是因为它无处不在。我可以用一种语法友好的高级语言用20行代码编写100行C代码。
这使得程序流易于阅读，并且我们都知道，在一年或更长时间后重新访问代码意味着要到处跟踪面包屑。
我确实使用下划线，但只对全局变量，因为它们很少，而且它们很明显。除此之外，一个经过深思熟虑的CamelCaps()函数/变量名还没有让我失望!
Requirements analysis, specification, design, and documentation will almost never fit into a "template." You are 100% of the time better off by starting with a blank document and beginning to type with a view of "I will explain this in such a way that if I were dead and someone else read this document, they would know everything that I know and see and understand now" and then organizing from there, letting section headings and such develop naturally and fit the task you are specifying, rather than being constrained to some business or school's idea of what your document should look like. If you have to do a diagram, rather than using somebody's formal and incomprehensible system, you're often better off just drawing a diagram that makes sense, with a clear legend, which actually specifies the system you are trying to specify and communicates the information that the developer on the other end (often you, after a few years) needs to receive.
[如果有必要，一旦您编写了真正的文档，您通常可以把它塞进组织强加给您的任何模板中。不过，你可能会发现自己不得不添加章节标题和重复的材料。
The only time templates for these kinds of documents make sense is when you have a large number of tasks which are very similar in nature, differing only in details. "Write a program to allow single-use remote login access through this modem bank, driving the terminal connection nexus with C-Kermit," "Produce a historical trend and forecast report for capacity usage," "Use this library to give all reports the ability to be faxed," "Fix this code for the year 2000 problem," and "Add database triggers to this table to populate a software product provided for us by a third-party vendor" can not all be described by the same template, no matter what people may think. And for the record, the requirements and design diagramming techniques that my college classes attempted to teach me and my classmates could not be used to specify a simple calculator program (and everyone knew it).
一幅画不如一千个词。
有些图片可能胜过千言万语。大多数都不是。这句陈词滥调大多是不真实的，是许多懒惰的经理的可悲借口，他们不想仔细阅读创建的报告和文档，说“我需要你在图表中展示给我看”。
我妻子学的是语言学专业，她看到了一些关于图片和标志的令人着迷的证据:它们不能打破语言和文化的障碍，它们通常不能像正确的文本那样传达那么多的信息，它们根本不能取代真正的交流。
特别是，如果线条未被标记且无法解释，并且/或如果每一行都有不同的含义而不是表示相同的关系(除非以某种方式彼此区分)，那么与线条连接的标记气泡是无用的。如果你的线条有时表示关系，有时表示动作，有时表示时间的流逝，你就真的完蛋了。
每个优秀的程序员都知道你使用的工具适合手头的工作，对吗?并不是所有的系统都最好用图片来说明和记录。图形化规范语言可以自动转换为可证明正确的可执行代码或任何东西，这是一个了不起的想法，如果这样的东西存在的话。在适当的时候使用它们，而不是在阳光下的所有事情上。实体-关系图很棒。但并不是所有的事情都可以用一张图片来概括。
注:一张桌子可能值同等重量的金子。但是表格和图片不是一回事。同样，一篇精心设计的短散文段落可能更适合手头的工作。
XML被高度高估了
我认为太多人在使用他们的大脑之前就开始了XML的潮流…… XML对于web来说是很棒的，因为它就是为它设计的。否则，我认为一些问题定义和设计思想应该优先于任何使用它的决定。
我的5美分
“优秀的编码员编写代码，优秀的编码员重用它”这是现在正在发生的事情，但“优秀的编码员”是唯一一个享受代码的人。 和“伟大的程序员”只是为了找出其中的漏洞，因为他们没有时间思考和编码。但他们有时间找出代码中的漏洞。
所以不要批评!!!!!!!!
按照自己的意愿创建自己的代码。
代码的重用与其“可重用性”成反比。因为“可重用的”代码更复杂，而快速的hack更容易理解，所以它们被重用。
软件故障应该使系统崩溃，以便对其进行检查和修复。试图处理失败条件的软件通常比崩溃更糟糕。也就是说，是在崩溃后重新设置系统更好，还是应该因为失败处理程序有一个错误而无限期地挂起系统?
Java并不是最好的东西。仅仅因为它带有“企业”标签并不意味着它就好。也不会让它变快。也不是所有问题的答案。
另外，ROR并不是博客圈所吹嘘的那样。
当我在做的时候，OOP并不总是好的。事实上，我认为它通常是不好的。
观点:大多数代码都很糟糕，因为这是程序员想要的。
间接地，我们一直在培育一种极具创造力的文化。这并不是说我不认为解决问题具有创造性元素——它确实存在——只是它与绘画之类的事情根本不一样(参见保罗·格雷厄姆的著名文章《黑客和画家》)。
If we bend our industry towards that approach, ultimately it means letting every programmer go forth and whack out whatever highly creative, crazy stuff they want. Of course, for any sizable project, trying to put together dozens of unrelated, unstructured, unplanned bits into one final coherent bit won't work by definition. That's not a guess, or an estimate, it's the state of the industry that we face today. How many times have you seen sub-bits of functionality in a major program that were completely inconsistent with the rest of the code? It's so common now, it's a wonder anyone cause use any of these messes.
复杂，复杂，丑陋的东西只会变得更糟，更不稳定。如果我们正在建造一些实体的东西，地球上的每个人都会说我们的东西是多么丑陋和糟糕，但由于它或多或少被虚拟隐藏起来，我们能够逃脱一些我们物种所见过的最糟糕的制造过程。(你能想象一辆车有四个不同的人用四种不同的方式设计了四个不同的轮子吗?)
但可悲的是，这一切中有争议的部分是，绝对没有理由这样做，除了历史上的文化倾向于更多的自由和更少的组织，所以我们保持了这种方式(可能变得更糟)。软件开发是一个笑话，但它是一个笑话，因为这是程序员想要的(但永远不会承认这是真的，“管理层的阴谋”对大多数人来说是一个更好的理由)。
我们还会搬起石头砸自己的脚多久，才会幡然醒悟，意识到我们才是握着枪、指着枪、扣动扳机的人?
保罗。
聪明的程序员很危险
我花了更多的时间试图修复“聪明”程序员编写的代码。我宁愿有一个优秀的程序员，而不是一个特别聪明的程序员，他想通过编写只有他(或她)才能解释的代码来证明自己有多聪明。
如果开发人员写不出清晰、简洁、语法正确的注释，那么他们就应该回去补习英语。
我们有开发人员和(可怕的)架构师不能连贯地编写。当他们的文件被审查时，他们会说“哦，不要担心语法错误或拼写错误——那不重要”。然后他们想知道为什么他们复杂的垃圾文档变成了复杂的bug代码。
我告诉我所指导的实习生，如果你不能口头或书面表达你的伟大想法，那就不如没有它们。
意识到有时候足够好就是足够好，这是你作为程序员价值的一大飞跃。
请注意，当我说“足够好”时，我的意思是“足够好”，而不是碰巧有用的垃圾。但话又说回来，当你时间紧迫的时候，“一些碰巧有用的垃圾”可能被认为是“足够好的”。
意见:不应该有任何编译器警告，只有错误。你应该总是使用-Werror编译你的代码。
原因:要么编译器认为这是一个应该被纠正的错误，要么它不需要修复，在这种情况下编译器应该直接关闭。
大多数“用户友好”的第四代语言(包括SQL)都是毫无价值的、被高估的垃圾，不应该被广泛使用。
4gl通常有一个冗长和模糊的语法。尽管4gl应该允许“非技术人员”编写程序，但你仍然需要“技术人员”来编写和维护它们。
一般来说，4GL程序更难编写，更难阅读，更难优化。
应该尽量避免使用4gl。
不要注释你的代码
注释不是代码，因此当事情发生变化时，不改变解释代码的注释是很容易的。相反，我更喜欢将代码中的垃圾重构到不需要注释的程度。一个例子:
if(data == null) // First time on the page
to:
bool firstTimeOnPage = data == null;
if(firstTimeOnPage)
我唯一一次真正的评论是当它是一个TODO或解释为什么
Widget.GetData(); // only way to grab data, TODO: extract interface or wrapper
如果以后可以节省3倍的时间，那就只写抽象。
有时我看到人们写出这些疯狂的抽象概念，我就会想:“为什么?”
除非抽象真的能在以后节省你的时间，或者它能节省维护你代码的人的时间，否则人们似乎只是越来越多地编写意大利面条式的代码。
我有争议的观点?Java并不糟糕，但Java API很糟糕。为什么java库坚持让简单的任务变得困难?为什么他们不修复api，而是创建框架来帮助管理样板代码?这种观点适用于任何需要10行或更多代码才能从文件中读取一行的语言。
不会编码的架构师是无用的。
这听起来有点苛刻，但并非不合理。如果你是一个系统的“架构师”，但对所使用的技术没有一定的实际参与，那么你如何获得开发团队的尊重呢?你如何影响方向?
架构师需要做更多的事情(与利益相关者会面，与其他团队谈判，评估供应商，编写文档，进行演示等等)但是，如果您从未看到架构师签入代码……小心!
如果您的文本编辑器不能很好地完成代码，那么您就是在浪费每个人的时间。
Quickly remembering thousands of argument lists, spellings, and return values (not to mention class structures and similarly complex organizational patterns) is a task computers are good at and people (comparatively) are not. I buy wholeheartedly that slowing yourself down a bit and avoiding the gadget/feature cult is a great way to increase efficiency and avoid bugs, but there is simply no benefit to spending 30 seconds hunting unnecessarily through sourcecode or docs when you could spend nil... especially if you just need a spelling (which is more often than we like to admit).
当然，如果没有为您的语言提供这种功能的编辑器，或者任务简单到足以在加载更重的编辑器所需的时间内完成，那么没有人会告诉您Eclipse和90个插件是正确的工具。但是请不要告诉我，像1999年那样使用H-J-K-L的能力真的比每次需要方法签名时按escape键节省了更多时间……即使你觉得这样做不那么“黑客”了。
想法吗?
你并不总是需要数据库。
如果需要存储的“东西”少于几千个，而且不需要锁定，平面文件可以工作，而且在很多方面都更好。它们更便于携带，你可以在必要时手动编辑它们。如果你在数据和业务逻辑之间有适当的分离，你可以很容易地用数据库替换平面文件，如果你的应用程序需要它。如果您在设计时考虑到这一点，它就会提醒您在数据和业务逻辑之间进行适当的分离。
-- bmb
分页从来不是用户想要的
If you start having the discussion about where to do pagination, in the database, in the business logic, on the client, etc. then you are asking the wrong question. If your app is giving back more data than the user needs, figure out a way for the user to narrow down what they need based on real criteria, not arbitrary sized chunks. And if the user really does want all those results, then give them all the results. Who are you helping by giving back 20 at a time? The server? Is that more important than your user?
[编辑:基于评论的澄清]
作为一个真实世界的例子，让我们看看这个Stack Overflow问题。假设我有一个有争议的编程观点。在我发帖之前，我想看看是否已经有了一个解决相同观点的答案，这样我就可以给它投票了。我唯一的选择就是点击每一页的答案。
我更喜欢以下选择之一:
请允许我搜索答案(这是一种根据实际标准缩小我需要的范围的方法)。 允许我看到所有的答案，这样我就可以使用浏览器的“查找”选项(给我所有的结果)。
如果我只是想找到以前读过的答案，但再也找不到了，也可以这样做。我不知道它是什么时候发布的，也不知道它有多少选票，所以排序选项没有帮助。即使我找到了，我仍然需要玩猜谜游戏来找到正确的结果页面。事实上，答案是有页码的，我可以直接点击进入十几个页面中的一个，这一点帮助都没有。
-- bmb
我认为使用goto语句是很好的，如果你以一种理智的方式使用它们(以及一种理智的编程语言)。它们通常可以使您的代码更容易阅读，并且不会强迫您使用一些扭曲的逻辑来完成一件简单的事情。
尽可能在任何地方使用类型推断。
编辑:
这是我几个月前写的一篇关于我为什么有这种感觉的博客文章的链接。
http://blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx
c++是一门很好的语言
一两个星期前，我说c++不是一种很好的语言，在另一个问题上我几乎被私刑了。现在我试着反过来说。；）
不，认真地说，我当时想说的是，c++有很多缺陷，现在我还会再试一次。这一点很难否认。它是如此的复杂，以至于学好它实际上是一件你可以奉献一生的事情。它使许多常见的任务变得不必要的困难，允许用户一头扎进未定义的行为和不可移植的代码的海洋，而编译器没有给出警告。
但它并不是许多人试图创造的那种无用、破旧、过时、令人讨厌的语言。它不应该被掩盖和忽视。没有它，世界不会变得更好。它有一些独特的优势，不幸的是，隐藏在古怪的语法，遗留的麻烦，尤其是糟糕的c++老师背后。但是他们就在那里。
c++有许多我在用c#或其他“现代”语言编程时非常怀念的特性。其中有很多c#和其他现代语言可以学习的地方。
它并没有盲目地专注于OOP，而是探索并开创了泛型编程。它允许惊人地表达编译时元编程，生成极其高效、健壮和干净的代码。在c#出现LINQ或lambda表达式之前，它从函数式编程中吸取了近十年的经验教训。
它允许您通过静态断言和其他元编程技巧在编译时捕获数量惊人的错误，这极大地简化了调试，甚至在某些方面胜过单元测试。(我宁愿在编译时捕获错误，而不是在之后运行测试时捕获错误)。
变量的确定性销毁允许RAII，这是一个非常强大的小技巧，使try/finally块和c#使用块变得多余。
虽然有些人指责它是“由委员会设计的”，但我会说，是的，它是，在这种情况下，这实际上并不是一件坏事。看看Java的类库。又有多少类被弃用了?有多少不应该使用?有多少是相互复制的功能?有多少设计糟糕?
C++'s standard library is much smaller, but on the whole, it's remarkably well designed, and except for one or two minor warts (vector<bool>, for example), its design still holds up very well. When a feature is added to C++ or its standard library, it is subjected to heavy scrutiny. Couldn't Java have benefited from the same? .NET too, although it's younger and was somewhat better designed to begin with, is still accumulating a good handful of classes that are out of sync with reality, or were badly designed to begin with.
c++有很多其他语言无法比拟的优点。这是一门很好的语言
计算机科学或其他IT领域的学位确实会让你成为一个更全面的程序员
我不在乎你有多少年的工作经验，读过多少博客，参与过多少开源项目。一个资格证书(我建议超过3年)会让你接触到一种不同的思维方式，给你一个很好的基础。
仅仅因为你写了一些比计算机科学学士更好的代码，并不意味着你比他更好。你所拥有的，他可以在瞬间学会反之则不然。
拥有资格证书表明了你的承诺，你会超越经验，成为一名更好的开发人员。擅长自己的工作并且有资格的开发人员可能会非常令人生畏。
如果这个答案被否决，我也不会感到惊讶。
而且，一旦你有了资格，你就会慢慢停止和其他有资格的人比较(我的经验)。你意识到到最后一切都不重要了，只要你们能很好地合作。
始终仁慈地对待其他开发人员，无论其资格如何。
新的web项目应该考虑不使用Java。
我已经用Java做网页开发超过10年了。起初，与现有的替代方案相比，这是朝着正确方向迈出的一步。现在，有比Java更好的选择。
这真的只是用魔锤方法解决问题的一个具体例子，但它真的很痛苦。
不断测试
您必须编写测试，并且必须首先编写它们。编写测试会改变编写代码的方式。它会让你思考你想要它实际做什么，然后再开始写一些东西，它能做所有事情，除了你想要它做的。
它也给你目标。看着你的测试变绿会让你有额外的信心，因为你完成了一些事情。
它还为您为边缘情况编写测试提供了基础。由于您一开始就针对测试编写代码，因此您的代码中可能有一些用于测试的钩子。
没有理由不测试你的代码。如果你不这样做，那你只是懒惰。我还认为您应该先进行测试，因为这样做的好处超过了编写代码所花费的额外时间。
你的工作就是让自己失业。
当您为您的雇主编写软件时，您所创建的任何软件都应该以这样一种方式编写，即任何开发人员都可以使用它，并且可以用最少的努力理解它。它设计良好，编写清晰一致，格式化干净，在需要的地方有文档记录，按照预期每天构建，检入存储库，并进行了适当的版本控制。
如果你被公共汽车撞了，被解雇了，被解雇了，或者离开了工作岗位，你的雇主应该能够在片刻的通知中取代你，下一个人可以接替你的角色，拿起你的代码，最多在一周内启动并运行。如果他或她不能做到这一点，那么你就失败了。
有趣的是，我发现有了这个目标，我对雇主来说更有价值了。我越努力成为可有可无的人，我对他们就越有价值。
其中一个我已经琢磨了很久了:
数据就是系统。
流程和软件是为数据构建的，而不是相反。
没有数据，过程/软件就没有什么价值。没有流程或软件，数据仍然有价值。
一旦我们理解了数据，它是做什么的，它是如何相互作用的，它在不同阶段以不同的形式存在，只有这样才能构建一个解决方案来支持数据系统。
成功的软件/系统/过程似乎有一个敏锐的意识，如果不是狂热的正念，在任何给定的时刻数据在“哪里”。
未注释的代码是人类的祸害。
我认为注释对于代码是必要的。他们可视化地将其划分为逻辑部分，并在阅读代码时提供另一种表示方式。
文档注释是最低限度的，但是使用注释来分割较长的函数有助于编写新代码，并允许在返回现有代码时更快地分析。
硬编码很好!
真的，在许多情况下更有效，更容易维护!
我看到常数放入参数文件的次数真的非常频繁 你改变了水的冰点还是光速?
对于C程序，只需将这些类型的值硬编码到头文件中，对于java程序，只需将这些值硬编码到静态类中等等。
当这些参数对你的程序行为有巨大的影响时，你真的想对每一个变化做一个回归测试，这似乎是硬编码值更自然。当东西存储在参数/属性文件中时，人们很容易认为“这不是一个程序变更，所以我不需要测试它”。
另一个好处是，它可以防止人们在参数/属性文件中混淆重要值，因为根本没有任何重要值!
Having a process that involves code being approved before it is merged onto the main line is a terrible idea. It breeds insecurity and laziness in developers, who, if they knew they could be screwing up dozens of people would be very careful about the changes they make, get lulled into a sense of not having to think about all the possible clients of the code they may be affecting. The person going over the code is less likely to have thought about it as much as the person writing it, so it can actually lead to poorer quality code being checked in... though, yes, it will probably follow all the style guidelines and be well commented :)
设计模式是石器时代编程语言设计的一个症状
他们有自己的目的。很多优秀的软件都是用它们开发出来的。但事实上，我们需要编写这些心理抽象的“配方”，关于你的代码如何工作/应该如何工作，这说明缺乏足够有表现力的编程语言来为我们处理这种抽象。
补救措施，我认为，在于允许你将越来越多的设计嵌入到代码中的语言，通过定义可能不存在或可能没有普遍适用性，但在你的代码不断处理的情况下真的真的有意义的语言结构。Scheme的人已经知道这一点很多年了，Scheme宏可能会让大多数猴子尿裤子。
对于一个优秀的程序员来说，语言不是问题。
这可能不是很有争议，但我听到很多其他程序员的抱怨，比如“为什么他们不都用delphi?”，“c#糟透了”，“如果他们强迫我用java，我就会换公司”等等。 我所认为的是，一个好的程序员是灵活的，能够用他一生中可能不得不学习的任何编程语言编写好的程序
生成的文档几乎总是毫无价值的。
或者，作为一个推论:您的API需要为维护者和用户提供单独的文档集。
实际上有两类人需要了解您的API:维护者，他们必须了解您的实现的细节，以便有效地完成工作;用户，他们需要高级的概述、示例和关于他们所访问的每个方法的效果的详细细节。
我从未遇到过在这两个方面都成功的生成文档。通常，当程序员为工具编写注释以提取和生成文档时，他们的目标是介于两者之间的某个地方——刚刚足够的实现细节让用户感到厌烦和困惑，但不足以显著帮助维护者，并且没有足够的概述对用户有任何真正的帮助。
As a maintainer, I'd always rather have clean, clear comments, unmuddled by whatever strange markup your auto-doc tool requires, that tell me why you wrote that weird switch statement the way you did, or what bug this seemingly-redundant parameter check fixes, or whatever else I need to know to actually keep the code clean and bug-free as I work on it. I want this information right there in the code, adjacent to the code it's about, so I don't have to hunt down your website to find it in a state that lends itself to being read.
As a user, I'd always rather have a thorough, well-organized document (a set of web pages would be ideal, but I'd settle for a well-structured text file, too) telling me how your API is architectured, what methods do what, and how I can accomplish what I want to use your API to do. I don't want to see internally what classes you wrote to allow me to do work, or files they're in for that matter. And I certainly don't want to have to download your source so I can figure out exactly what's going on behind the curtain. If your documentation were good enough, I wouldn't have to.
无论如何，这就是我的看法。
扩展方法是魔鬼的工作
Everyone seems to think that extension methods in .Net are the best thing since sliced bread. The number of developers singing their praises seems to rise by the minute but I'm afraid I can't help but despise them and unless someone can come up with a brilliant justification or example that I haven't already heard then I will never write one. I recently came across this thread and I must say reading the examples of the highest voted extensions made me feel a little like vomiting (metaphorically of course).
主要原因是增加了可读性、改进了oo性以及更好地连接方法调用的能力。
I'm afraid I have to differ, I find in fact that they, unequivocally, reduce readability and OO-ness by virtue of the fact that they are at their core a lie. If you need a utility method that acts upon an object then write a utility method that acts on that object don't lie to me. When I see aString.SortMeBackwardsUsingKlingonSortOrder then string should have that method because that is telling me something about the string object not something about the AnnoyingNerdReferences.StringUtilities class.
LINQ是这样设计的，链式方法调用是必要的，以避免奇怪和不舒服的表达式，来自LINQ的扩展方法是可以理解的，但一般来说，链式方法调用降低了可读性，并导致我们在混乱的Perl竞赛中看到的那种代码。
因此，简而言之，扩展方法是邪恶的。摆脱撒旦的枷锁，致力于自由扩展代码。
不要太担心学习什么语言，使用业界重量级的语言，如c#或python。像Ruby这样的语言在卧室里很有趣，但在工作场合就没什么用了。像c#和Java这样的语言可以处理小到非常大的软件项目。如果有人不这么认为，那么你谈论的是脚本语言。期!
在开始一个项目之前，要考虑网络上有多少支持和代码示例。再次强调，选择像Ruby这样的语言，与Java相比，Ruby的代码样本在网络上非常少，这只会让你在遇到问题时更加痛苦。
当你的老板问你的代码写得怎么样的时候，你不能在论坛上发了一条消息就指望得到答复。你要说什么?“我在这个论坛上等着有人来帮我”
学习一门语言，并学好它。学习多种语言可能会带来技能和实践，但你甚至只能掌握所有语言。擅长其中一项。有一整本专门讲Java中的线程的书，仔细想想，它只是100多个命名空间中的一个。
精通一门或精通许多门。
这个主要是网络相关的，但是……
在网页布局中使用表格
如果我正在开发一个需要压缩性能的大型站点，我可能会考虑这样做，但是没有什么比表更容易让我在浏览器上获得一致的外观了。我开发的大多数应用程序都是针对100-1000个用户，最多一次100个用户。额外膨胀的表无论如何都不会杀死我的服务器。
意见:没有函数定义和返回类型会导致代码灵活易读。
这种观点可能更适用于解释型语言，而不是编译型语言。需要一个返回类型和一个函数参数列表，这对于智能感知来自动记录你的代码是很好的，但它们也是限制。
不要误解我的意思，我不是说扔掉返回类型，或者参数列表。他们有自己的位置。在90%的情况下，它们是利大于弊的。
在某些时候和场合，这是有用的。
编码不是打字
编写代码需要时间。大多数时候，在编辑器窗口中，您只是查看代码，而不是实际输入。虽然不是经常，但你经常会删除你所写的内容。或者从一个地方搬到另一个地方。或重命名。
如果你长时间敲击键盘，那你一定做错了什么。
推论:每天写的代码行数并不是一个程序员生产力的线性衡量标准，一天写100行的程序员很可能比一天写20行的程序员更好，但一天写5000行的程序员肯定是坏程序员
开发团队应该更多地按照技术/架构层而不是业务功能来划分。
我来自一个开发者拥有“从网页到存储过程的一切”的普遍文化。因此，为了在系统/应用程序中实现一个功能，他们将准备数据库表模式，编写存储procs，匹配数据访问代码，实现业务逻辑和web服务方法，以及web页面接口。
And guess what? Everybody has their own way to doing things! Everyone struggles to learn the ASP.NET AJAX and Telerik or Infragistic suites, Enterprise Library or other productivity and data layer and persistence frameworks, Aspect-oriented frameworks, logging and caching application blocks, DB2 or Oracle percularities. And guess what? Everybody takes heck of a long time to learn how to do things the proper way! Meaning, lots of mistakes in the meantime and plenty of resulting defects and performance bottlenecks! And heck of a longer time to fix them! Across each and every layer! Everybody has a hand in every Visual Studio project. Nobody is specialised to handle and optmise one problem/technology domain. Too many chefs spoil the soup. All the chefs result in some radioactive goo.
Developers may have cross-layer/domain responsibilities, but they should not pretend that they can be masters of all disciplines, and should be limited to only a few. In my experience, when a project is not a small one and utilises lots of technologies, covering more business functions in a single layer is more productive (as well as encouraging more test code test that layer) than covering less business functions spanning the entire architectural stack (which motivates developers to test only via their UI and not test code).
XHTML是邪恶的。编写HTML
无论如何，您都必须将MIME类型设置为text/html，所以为什么要欺骗自己相信您实际上是在编写XML呢?无论谁要下载你的页面，他都会相信这是HTML，所以把它做成HTML。
有了这些，不要关闭你的<li>，这是没有必要的。不要关闭html标签，文件已经结束了。它是有效的HTML，可以被完美地解析。
它将创建更可读、更少的样板代码，并且不会丢失任何东西。HTML解析器工作得很好!
当你完成后，再转向HTML5。这样更好。
关系数据库是在浪费时间。改用对象数据库!
关系数据库供应商试图欺骗我们，让我们相信世界上唯一可扩展的、持久的和安全的存储就是关系数据库。我是一个认证的DBA。你是否曾经花了几个小时试图优化一个查询，却不知道哪里出了问题?关系数据库不允许您在需要时创建自己的搜索路径。你把应用速度的控制权拱手让给了素未谋面的人，他们并不像你想象的那么聪明。
当然，有时在维护良好的数据库中，他们会为复杂的查询提供快速答案。但你为此付出的代价太高了!每次要读取数据项时，都必须选择编写原始SQL，这是很危险的。或者使用Object关系映射器，这会增加更多的复杂性和超出你控制的事情。
更重要的是，你被禁止提出智能搜索算法，因为每次该死的往返数据库花费你大约11毫秒。这太过分了。想象一下，您知道这个超级图算法，它将回答一个特定的问题，这个问题甚至可能无法用SQL表达!，在适当的时候。但是，即使您的算法是线性的，而有趣的算法不是线性的，也不要将它与关系数据库结合起来，因为枚举一个大表将花费您数小时!
将其与SandstoneDb或Gemstone for Smalltalk进行比较!如果你喜欢Java，试试db4o吧。
因此，我的建议是:使用对象- db。当然，它们并不完美，有些查询速度会比较慢。但是你会惊讶的发现很多人会更快。因为加载对象不需要在SQL和域数据之间进行所有这些奇怪的转换。如果您确实需要某个查询的速度，对象数据库有您应该信任的查询优化器:您的大脑。
调试器是一种拐杖。
它的争议如此之大，以至于连我都不像以前那么相信它了。
缺点:我花了更多的时间来跟上其他人的大量代码，所以任何有助于“我是如何到达这里的”和“发生了什么”的事前或事后分析都是有帮助的。
教授:然而，我很高兴地支持这样的观点，如果你不理解你自己开发的代码或你已经熟悉的代码的这些问题的答案，把所有的时间都花在调试器上并不是解决方案，这是问题的一部分。
在点击“发布你的答案”之前，我快速地检查了一下这个确切的短语，结果发现我不是唯一一个持有这种观点或使用这个短语的人。我在Fog Creek软件论坛上找到了关于这个问题的长时间讨论，其中引用了包括Linus Torvalds在内的各种名人作为著名的支持者。
任何足够强大的库都过于复杂而无法使用，而任何足够简单而可用的库都缺乏成为良好通用解决方案所需的功能。
我经常遇到这种情况。穷尽的库，使用起来非常复杂，让我抓狂，简单易用的库，不太能做我需要做的事情。
这不是关于编程的，因为html/css不是编程语言。
表格可以用于布局
CSS和div不能做所有的事情，节省你自己的麻烦，使用一个简单的表，然后在它上面使用CSS。
90%的程序员都是非常糟糕的程序员，实际上我们所有人都没有任何工具来评估我们当前的能力水平(尽管我们通常可以回顾过去并意识到我们曾经是多么糟糕)
我不打算发布这个，因为它会惹恼所有人，我并不是真的想要一个负分或其他什么，但是:
A，这不是问题的重点吗
B)这个帖子中的大多数“答案”都证明了这一点
前几天我听到一个很好的类比:编程能力的差异至少和运动能力一样大。我们当中有多少人可以加入一个职业球队，并真正提高他们的机会?
和这里的大多数人一样，我尽量遵循DRY和不做人工编译器等原则。
我想推广的另一个策略是“告诉，不要问”。而不是混乱的所有对象与getter /setter本质上是他们的筛子，我想告诉他们做一些事情。
这似乎直接违背了具有愚蠢实体对象和较厚服务层的良好企业实践(这需要大量的请求)。嗯,想法?
我们是软件开发人员，不是C/ c# / c++ /PHP/Perl/Python/Java/…开发人员。
After you've been exposed to a few languages, picking up a new one and being productive with it is a small task. That is to say that you shouldn't be afraid of new languages. Of course, there is a large difference between being productive and mastering a language. But, that's no reason to shy away from a language you've never seen. It bugs me when people say, "I'm a PHP developer." or when a job offer says, "Java developer". After a few years experience of being a developer, new languages and APIs really shouldn't be intimidating and going from never seeing a language to being productive with it shouldn't take very long at all. I know this is controversial but it's my opinion.
如果没有远程调试器，就无法编写web应用程序
Web应用程序通常将客户端和服务器端多种语言之间的交互联系在一起，需要用户进行交互，并且通常包括第三方代码，这些代码可以是简单的API实现，也可以是复杂的框架。
我已经记不清有多少次，当我用一个不错的远程调试器进入并跟踪一个复杂的web应用程序中实际发生的事情时，另一个开发人员坐在我身边，看到他们惊讶地发现有这样的工具存在。通常情况下，即使在看到这些工具的实际运行后，他们仍然不愿意费心安装和设置这些工具。
你只是不能用打印语句调试一个重要的web应用程序。如果应用程序中的所有代码都不正确，则乘以10。
如果您的调试器可以逐步检查所有正在使用的语言，并显示正在发生的http事务，那就更好了。
没有Firebug就无法开发web应用程序
同理，一旦你用过Firebug(或非常接近Firebug的东西)，你就会对那些试图开发web应用程序的人既同情又恐惧。特别是Firebug显示计算样式，如果你还记得不使用它，花了几个小时随机更改各种CSS位，并添加“!重要的”在太多的地方搞笑你永远不会回去。
最新的设计模式往往是骗人的。正如之前在这个问题中所说的，过度使用设计模式对设计的危害远大于帮助。
如果我再听到一个人说“每个人都应该使用IOC”(或类似的废话)，我想我将被迫找到他们，并告诉他们他们方法的错误。
前期设计——不要因为兴奋而开始写代码
我见过很多设计糟糕的应用程序，因为开发人员太兴奋了，以至于他们直接打开白页开始写代码。我知道在开发生命周期中事情会发生变化。但是，如果应用程序具有多种不同的布局和开发方法(从一种形式到另一种形式，从一种方法到另一种方法)，则很难处理这些应用程序。
如果没有明确定义任务以及计划如何编写任务，就很难达到应用程序要处理的目标。花点时间(而不是仅仅5分钟)，确保在开始编码之前，你已经尽可能多地布局了它。这样你就可以避免顶替你的人不得不承担的意大利面条般的混乱。
避免压痕。
使用早期返回，继续或中断。
而不是:
if (passed != NULL)
{
for(x in list)
{
if (peter)
{
print "peter";
more code.
..
..
}
else
{
print "no peter?!"
}
}
}
do:
if (pPassed==NULL)
return false;
for(x in list)
{
if (!peter)
{
print "no peter?!"
continue;
}
print "peter";
more code.
..
..
}
我有一些…凡事都有例外，所以这些并不是一成不变的，但它们确实适用于大多数情况
没有人关心您的网站是否经过验证、是否严格遵守XHTML、是否符合标准或是否有W3C标记。
It may earn you some high-fives from fellow Web developers, but the rest of people looking at your site could give a crap whether you've validated your code or not. the vast majority of Web surfers are using IE or Firefox, and since both of those browsers are forgiving of nonstandards, nonstrict, invalidated HTML then you really dont need to worry about it. If you've built a site for a car dealer, a mechanic, a radio station, a church, or a local small business, how many people in any of those businesses' target demographics do you think care about valid HTML? I'd hazard a guess it's pretty close to 0.
大多数开源软件都是无用的、过于复杂的垃圾。
Let me install this nice piece of OSS I've found. It looks like it should do exactly what I want! Oh wait, first I have to install this other window manager thingy. OK. Then i need to get this command-line tool and add it to my path. Now I need the latest runtimes for X, Y, and Z. now i need to make sure i have these processes running. ok, great... its all configured. Now let me learn a whole new set of commands to use it. Oh cool, someone built a GUI for it. I guess I don't need to learn these commands. Wait, I need this library on here to get the GUI to work. Gotta download that now. ok, now its working...crap, I can't figure out this terrible UI.
sound familiar? OSS is full of complication for complication's sake, tricky installs that you need to be an expert to perform, and tools that most people wouldn't know what to do with anyway. So many projects fall by the wayside, others are so niche that very few people would use them, and some of the decent ones (FlowPlayer, OSCommerce, etc) have such ridiculously overcomplicated and bloated source code that it defeats the purpose of being able to edit the source. You can edit the source... if you can figure out which of the 400 files contains the code that needs modification. You're really in trouble when you learn that its all 400 of them.
我可能会因此被炒，但是
在python中使不可见字符具有语法意义是一个坏主意
它会分散注意力，给新手带来很多微妙的bug，在我看来，这是不必要的。我所见过的唯一没有自愿遵循某种像样的格式指南的代码是来自计算机科学一年级的学生。即使代码不遵循“漂亮”的标准，也有很多工具可以将其转换成更令人满意的形状。
意见:在开发领域的持续时间并不总是等同于经验。
许多行业看重一门语言的“多年经验”。是的，5年的c#学习是有意义的，因为你可能会学到新的技巧。然而，如果你在公司工作并维护相同的代码库很多年，我觉得作为一个在不同情况和客户需求下工作的人，你似乎没有获得足够的接触不同情况的机会。
I once interviewed a person who prided himself on having 10 years of programming experience and worked with VB5, 6, and VB.Net...all in the same company during that time. After more probing, I found out that while he worked with all of those versions of VB, he was only upgrading and constantly maintaining his original VB5 app. Never modified the architecture and let the upgrade wizards do their thing. I have interviewed people who only have 2 years in the field but have worked on multiple projects that have more "experience" than him.
因为我的答案有数百个，可能最后都没人读过，但这是我最讨厌的东西。
如果你是一名程序员，那么你很可能不擅长网页设计/开发
对于程序员来说，这个网站是一个非凡的资源，但如果您正在寻找XHTML/CSS帮助，则绝对是一个糟糕的地方。即使是优秀的Web开发人员也在提供90年代很好的资源链接!
Sure, XHTML and CSS are simple to learn. However, you're not just learning a language! You're learning how to use it well, and very few designers and developers can do that, let alone programmers. It took me ages to become a capable designer and even longer to become a good developer. I could code in HTML from the age of 10 but that didn't mean I was good. Now I am a capable designer in programs like Photoshop and Illustrator, I am perfectly able to write a good website in Notepad and am able to write basic scripts in several languages. Not only that but I have a good nose for Search Engine Optimisation techniques and can easily tell you where the majority of people are going wrong (hint: get some good content!).
Also, this place is a terrible resource for advice on web standards. You should NOT just write code to work in the different browsers. You should ALWAYS follow the standard to future-proof your code. More often than not the fixes you use on your websites will break when the next browser update comes along. Not only that but the good browsers follow standards anyway. Finally, the reason IE was allowed to ruin the Internet was because YOU allowed it by coding your websites for IE! If you're going to continue to do that for Firefox then we'll lose out yet again!
如果你认为基于表格的布局和CSS布局一样好，如果不比CSS布局好，那么你不应该被允许谈论这个话题，至少没有我先把你打倒。此外，如果你认为W3Schools是送学生去的最佳资源，那你就大错特错了。
如果你是Web设计/开发的新手，不要去这个地方(这里都是程序员，而不是Web开发人员)。去一个好的网站设计/开发社区，比如SitePoint。
有时候赶时髦是可以的
我厌倦了人们表现出“爷爷综合症”(“你们这些孩子和你们新奇的测试驱动开发。过去十年出现的每一项大技术都很糟糕。在我那个年代，我们写的是真正的代码!”你懂的)。
有时候，受欢迎的事物是有原因的。
如果你只能想到一种方法，那就别去做。
无论是一个界面布局，一个任务流，还是一段代码，都可以停止。做一些事情来收集更多的想法，比如询问其他人他们会怎么做，在你至少有三个完全不同的想法和至少一次信心危机之前，不要回去实施。
一般来说，当我认为某件事只能以一种方式完成，或者认为只有一种方法有任何优点时，那是因为我没有充分考虑应该彻底影响设计的因素。如果我这样做了，其中一些显然会发生冲突，导致混乱，从而做出实际的决定，而不是死记硬背的违约。
成为一个优秀的程序员并不意味着你就是一个优秀的界面设计师
遵循世界上所有的界面指南只会开始有所帮助。如果这是人类可能做到的…人们似乎有一种特殊的嗜好，就是把东西变得“可爱”和“聪明”。
分离关注点是邪恶的:)
如果你有充分的理由，那就分开考虑。否则，不要把它们分开。
我遇到过太多只为分离而分离的场合。Dijkstra的后半句“最小的耦合，最大的内聚”不应该被忘记。：）
很高兴进一步讨论这个问题。
我讨厌大学和研究所向新人提供短期编程课程。这完全是对编程艺术和科学的耻辱和蔑视。
他们开始教C, Java, VB(恶心)给那些没有很好地掌握硬件和计算机基本原理的人。 首先应该通过Morris Mano的《计算机系统体系结构》等书籍来教授机器，然后教授指令机器解决问题的概念，而不是蚀写一种编程语言的语义和语法。
我也不理解政府学校和大学教孩子使用商业操作系统和软件的计算机基础知识。至少在我的国家(印度)，没有多少学生买得起操作系统，甚至打折的办公套装，更不用说开发软件的巨头(编译器，ide等)。这就引发了盗窃和盗版，并使这种从他们机构的图书馆复制和窃取软件的行为成为一种正当的行为。
他们再次被教导使用一些产品，而不是基本的理念。
试想一下，如果你只被教导2x2 = 4，而没有被教导乘法的概念?
或者，如果你现在被教去测量倾斜在学校复合墙上的杆子的长度，而不是毕达哥拉斯定理
程序员把他们自己的(有限的)编程语言视为神圣不可侵犯的宗教。
有趣的是，程序员几乎像宗教信徒一样对待这些讨论:不允许批评，(通常)不允许客观的讨论，(通常)基于非常有限或缺乏的知识和信息进行争论。为了确认，只需阅读之前的答案，尤其是评论。
同样有趣的是，另一个确认:根据“给我一个有争议的意见”这个问题的定义，任何有争议的意见都不应该被投反对票——实际上恰恰相反:越有争议越好。但我们的程序员是如何反应的:就像巴甫洛夫的狗一样，对不喜欢的意见投反对票。
PS:为了公平起见，我给其他一些人点了赞。
软件工程师不应该和计算机科学家一起工作
他们的区别: se关心代码的可重用性，而CSs只关心代码 se关心性能，而CSs只想现在就把事情做好 se关心整个结构，而CSs则不在乎 .．.
牛仔程序员做得更多。
我一生都在创业的氛围中度过。如果没有牛仔编码员，我们将浪费无尽的周期来确保事情做得“正确”。
正如我们所知，预测所有问题基本上是不可能的。牛仔编码员会迎头撞上这些问题，并被迫比那些试图预见所有问题的人更快地解决它们。
不过，如果你是牛仔编码，你最好在其他人维护意大利面之前重构它。,)我所知道的最好的方法是使用持续重构。他们完成了大量的工作，不浪费时间试图预测未来，并通过重构成为可维护的代码。
过程总是阻碍一个优秀的牛仔，不管它有多敏捷。
成员变量不应该声明为private(在java中)
如果你声明了一些私有的东西，你就阻止了任何未来的开发人员从你的类派生和扩展功能。从本质上讲，通过编写“private”，您暗示您现在比任何未来的开发人员都更了解如何使用您的类。当你写“private”的时候，你应该写“protected”。
类永远不应该声明为final(在java中)
类似地，如果您将一个类声明为final(这将阻止它被扩展—阻止它被用作继承的基类)，那么您就意味着您比任何未来的程序员都更了解使用类的正确方法。这从来不是个好主意。你不是什么都知道。有人可能会提出一个完全合适的方法来扩展你没有想到的类。
Java bean是一个糟糕的想法。
java bean约定——将所有成员声明为private，然后为每个成员编写get()和set()方法——迫使程序员在不需要代码的地方编写样板、容易出错、冗长的代码。只要将public成员变量设为public!如果您需要更改实现，请相信您以后有能力更改它(提示:99%的情况下，您永远不会更改)。
代码即设计:Jack W. Reeves的三篇文章
任何软件的源代码都是其最准确的设计文档。其他的一切(规格，文档，有时还有注释)要么是不正确的，过时的，要么是误导性的。
肯定会让你在任何地方被炒。
懒惰的程序员是最好的程序员
懒惰的程序员通常会找到方法来减少花在写代码上的时间(尤其是大量相似或重复的代码)。这通常转化为公司/团队中的其他开发人员可以从中受益的工具和工作流。
当开发人员遇到类似的项目时，他可能会创建工具来引导开发过程(例如，创建一个与公司的数据库设计范例一起工作的DRM层)。
此外，诸如此类的开发人员经常使用某种形式的代码生成。这意味着同一类型的所有错误(例如，代码生成器没有检查所有方法上的空参数)通常可以通过修复生成器来修复，而不是修复该错误的50多个实例。
一个懒惰的程序员可能会多花几个小时来完成第一个产品，但会为你节省几个月的时间。
Tcl/Tk是有史以来最好的GUI语言/工具包组合
它可能缺少特定的小部件，外观也不如新产品好看，但它的模型很优雅，而且易于使用，因此通过交互式输入命令可以比使用可视化界面构建器更快地构建工作gui。它的表达能力是无与伦比的:其他解决方案(Gtk、Java、. net、MFC……)通常需要10到100个LOC才能得到与Tcl/Tk一行程序相同的结果。所有这些都不会牺牲可读性和稳定性。
pack [label .l -text "Hello world!"] [button .b -text "Quit" -command exit]
当涉及到软件设计和开发时，设计模式是一种浪费时间的行为。
不要误解我的意思，设计模式是有用的，但主要是作为一种交流载体。它们可以非常简洁地表达复杂的思想:工厂、单例、迭代器……
但它们不应该作为一种开发方法。开发人员经常使用一系列基于设计模式的类来构建他们的代码，而在可读性和性能方面，更简洁的设计会更好。所有这些都带有一种幻想，即单个类可以在它们的域之外被重用。如果一个类不是为重用而设计的，或者不是接口的一部分，那么它就是一个实现细节。
设计模式应该被用来为组织特性命名，而不是用来规定必须编写代码的方式。
(这本来是有争议的，记得吗?)
管理者无所不知
根据我的经验，经理通常不是通过了解代码来达到这个目的的。不管你怎么跟他们说，它太长了，不对或者太贵了。
还有一个是继第一个之后的:
没有时间把事情做对，但总有时间再做一遍
一位很好的工程师朋友曾经说过，他很生气地描述了这样一种情况:管理层把他的估计减半了，从他那里得到了一个半途而废的版本，然后给了他两倍的时间来返工，因为它失败了。在商业软件世界中，这是一件相当常见的事情。
今天在尝试配置一个只有web接口的路由器时，我想到了一个问题:
网页界面是为傻瓜准备的
上一个固件版本的CLI非常好。这个版本有一个web界面，试图从无知的IT机器人那里隐藏所有网络的复杂性，甚至不能得到正确的vlan。
编写完代码后再编写规格说明。(如果有的话)
In many projects I have been involved in, a great deal of effort was spent at the outset writing a "spec" in Microsoft Word. This process culminated in a "sign off" meeting when the big shots bought in on the project, and after that meeting nobody ever looked at this document again. These documents are a complete waste of time and don't reflect how software is actually designed. This is not to say there are not other valuable artifacts of application design. They are usually contained on index cards, snapshots of whiteboards, cocktail napkins and other similar media that provide a kind of timeline for the app design. These are usually are the real specs of the app. If you are going to write a Word document, (and I am not particularly saying you should) do it at the end of the project. At least it will accurately represent what has been done in the code and might help someone down the road like the the QA team or the next version developers.
在开发代码时牢记优化是一个好主意。
每当我这样说时，人们总是回答:“过早的优化是万恶之源”。
但我并不是说在调试之前进行优化。我甚至没有说优化，但当你在设计代码时，要记住这可能会成为一个瓶颈，并编写它，这样就有可能重构它的速度，而不会撕裂API。
Hugo
这个问题让我感到有趣的是，我刚刚读了答案的第一页，到目前为止，我还没有发现一个有争议的观点。
也许这更能说明stackoverflow产生共识的方式。也许我应该从最底层开始。: -)
vb6可以用来做好事，也可以用来作恶。在编码过于复杂的时代，这是一个快速应用程序开发环境。
我过去非常讨厌VB，现在还在嘲笑VB。NET(可能是开玩笑)作为一种Fisher Price语言，因为我不喜欢经典的VB，但在它的时代，没有什么能打败它完成工作。
依赖管理软件弊大于利
我在Java项目中工作过，其中包括超过100个不同的库。在大多数情况下，每个库都有自己的依赖项，而这些依赖库也有自己的依赖项。
像Maven或Ivy这样的软件应该通过自动获取每个库的正确版本，然后递归获取其所有依赖项来“管理”这个问题。
问题解决了，对吧?
错了。
下载库是依赖项管理的简单部分。困难的部分是创建软件的心理模型，以及它如何与所有这些库交互。
我不受欢迎的观点是:
如果你不能口头解释，在你的头脑中，你的项目中所有库之间的基本交互，你应该消除依赖直到你可以。
同样地，如果列出从某个函数直接或间接调用的所有库(及其方法)所用的时间超过10秒，那么您在管理依赖关系方面做得很差。
您应该能够轻松回答“我的应用程序的哪些部分实际上依赖于库XYZ?”
当前的依赖关系管理工具弊大于利，因为它们很容易创建极其复杂的依赖关系图，而且它们实际上没有提供减少依赖关系或识别问题的功能。
我见过开发人员包含了10或20 MB的库，在项目中引入了数千个依赖类，只是为了消除几十行简单的自定义代码。
使用库和框架是很好的。但成本总是存在的，掩盖成本的工具本身就是有问题的。
此外，有时(注意:当然不总是)通过编写一些小的类来实现您所需要的东西比引入对大型通用库的依赖更好。
对象不应该处于无效状态
不幸的是，许多ORM框架要求所有实体类都使用零参数构造函数，使用setter填充成员变量。在这些情况下，很难知道为了构造一个有效的对象必须调用哪些setter。
MyClass c = new MyClass(); // Object in invalid state. Doesn't have an ID.
c.setId(12345); // Now object is valid.
在我看来，一个对象不可能发现自己处于无效状态，类的API应该在每次方法调用后主动强制它的类不变量。
构造函数和突变方法应该原子地将对象从一种有效状态转换为另一种有效状态。这个好多了:
MyClass c = new MyClass(12345); // Object starts out valid. Stays valid.
作为一些库的使用者，在尝试使用一个对象之前跟踪是否调用了所有正确的setter是一件非常痛苦的事情，因为文档通常没有提供关于类契约的线索。
代码生成很糟糕
我讨厌那些要求你使用代码生成(或复制&粘贴)来处理简单事情的语言，比如JavaBeans的getter和setter。
c#的AutoProperties是朝着正确方向迈出的一步，但是对于具有字段、属性和构造函数参数的dto来说，你仍然需要大量的冗余。
良好的性能VS优雅的设计
它们并不相互排斥，但我不能忍受过度设计的类结构/框架，它们完全不了解性能。我不需要有一个字符串的new This(new That(new Whatever());创建一个对象，它会告诉我现在是凌晨5点哦，顺便说一下，距离奥巴马的生日还有217天，还有两天就是周末。我只是想知道健身房开门了没有。
保持两者之间的平衡是至关重要的。当您需要将所有处理器抽出来做一些密集的事情(比如读取tb级的数据)时，代码就会变得令人讨厌。把优雅留给那些消耗10%资源的地方，这可能超过90%的代码。
微软Windows是软件开发的最佳平台。
推理: 微软用优秀而廉价的开发工具，平台和API都有良好的文档记录，平台正在快速发展，这为开发者创造了很多机会，操作系统拥有庞大的用户基础，这对于明显的商业原因很重要，有一个庞大的Windows开发者社区，我还没有因为选择微软而被解雇。
大多数开发人员对此一无所知
是的. .好了。我说过了。我从我认识的所有开发者身上发现了这一点。只有少数是真正好的。只有少数人明白代码应该被测试……面向对象的开发方法实际上是在帮助你。让我感到沮丧的是，有些人获得了开发人员的头衔，而实际上他们所能做的只是复制和粘贴一些源代码，然后执行它。
无论如何……我很高兴像stackoverflow这样的项目已经开始了。这对开发人员来说是件好事。有没有更好的办法?我做对了吗?也许我可以用这个技巧来加快速度，等等……
但是不行……大多数开发人员只是学习一种工作需要的语言，并坚持使用它，直到他们自己变成了老而暴躁的开发人员，不知道发生了什么。他们得到的只是一大笔薪水，因为他们只是比你大。
好吧……IT界的生活是不公平的，我将采取措施在未来忽略这些人。万岁!
软件开发是计算机科学的一个非常小的子集。
人们有时似乎认为这两者是同义词，但实际上，计算机科学的许多方面是普通开发人员很少(如果有的话)接触到的。根据一个人的职业目标，我认为有很多计算机专业的毕业生如果接受某种软件工程教育可能会更好。
我非常重视教育，拥有计算机科学学士学位，并在业余时间攻读计算机科学硕士学位，但我认为许多获得这些学位的人将学位视为达到目的的手段，受益甚微。我认识很多人，他们上过和我一样的系统软件课程，写过和我一样的汇编程序，但直到今天他们都没有看到他们所做的任何价值。
源文件太20世纪了。
在函数/方法的主体中，将过程逻辑表示为线性文本是有意义的。即使逻辑不是严格的线性，我们也有良好的编程结构(循环、if语句等)，允许我们使用线性文本清晰地表示非线性操作。
But there is no reason that I should be required to divide my classes among distinct files or sort my functions/methods/fields/properties/etc in a particular order within those files. Why can't we just throw all those things within a big database file and let the IDE take care of sorting everything dynamically? If I want to sort my members by name then I'll click the member header on the members table. If I want to sort them by accessibility then I'll click the accessibility header. If I want to view my classes as an inheritence tree, then I'll click the button to do that.
Perhaps classes and members could be viewed spatially, as if they were some sort of entities within a virtual world. If the programmer desired, the IDE could automatically position classes & members that use each other near each other so that they're easy to find. Imaging being able to zoom in and out of this virtual world. Zoom all the way out and you can namespace galaxies with little class planets in them. Zoom in to a namespace and you can see class planets with method continents and islands and inner classes as orbitting moons. Zoom in to a method, and you see... the source code for that method.
基本上，我的观点是，在现代语言中，不管你把你的类放在什么文件中，或者你定义一个类的成员的顺序是什么，那么为什么我们仍然被迫使用这些古老的实践呢?还记得Gmail出来谷歌说的是"搜索，不排序"吗?那么，为什么同样的哲学不能应用于编程语言呢?
永远不要以单例方式实现任何东西。
您可以决定不构造多个实例， 但始终确保您的实现可以处理更多。
我还没有发现任何使用单例的场景 才是正确的选择。
在过去的几年里，我对此进行了一些非常激烈的讨论， 但最后我总是对的。
有用和干净的高级抽象比性能重要得多
一个例子:
我经常看到同行花费数小时编写复杂的spprocs，或者为了“性能”而返回不直观的匿名类型的大量LINQ查询。
它们可以实现几乎相同的性能，但代码更加清晰直观。
“不要从构造函数调用虚方法”。这只是有时PITA，但只是因为在c#中，我不能决定在构造函数中的哪个点调用基类的构造函数。为什么不呢?.NET框架允许它，那么c#有什么好的理由不允许它呢?
该死的!
这是我的:
“你不需要(文本)语法来表达对象及其行为。”
我赞同乔纳森·爱德华兹和他的潜台词项目——http://alarmingdevelopment.org/的观点
人们应该注释他们的代码?这似乎在这里很有争议。
代码只告诉我它实际做什么;这不是它应该做的
当我看到一个函数计算澳大利亚债券期货的点价值时，我想看到一些注释，表明编码器认为计算应该是什么!
人们抱怨将“goto”从语言中移除。我碰巧认为任何类型的条件跳转都被高估了，而“if”“while”“switch”和通用的“for”循环也被高估了，应该非常谨慎地使用。
每次进行比较和条件跳转时，都会增加一点点复杂性，一旦调用堆栈达到几百个条目，这种复杂性就会迅速增加。
我的第一选择是避免条件，但如果不实用，我的下一个选择是在构造函数或工厂方法中保留条件复杂性。
显然，这对于许多项目和算法(如控制流循环)来说并不实际，但这是我喜欢推动的事情。
瑞克
估计是给我的，不是给你的
作为开发部门经理，评估对我来说是一个有用的工具，可以用来计划我的团队正在做什么。
它们不是在特定日期交付特性的承诺，也不是驱使团队更加努力工作的棍子。
恕我直言，如果你强迫开发者做出估算，你就能得到最安全的数字。
例如:
我认为一个专题大概需要5天左右的时间。有很小的可能性出现问题，需要30天。 如果评估只是为了计划，那么我们都将工作到5天，并考虑到出现问题的小概率。 然而，如果满足这个估计是交付承诺的要求，你认为会给出什么样的估计?
如果开发人员的奖金或工作保障取决于是否达到估算值，你认为他们给出的是最准确的猜测还是他们最确定会达到的估计?
我的这一观点与其他管理层存在争议，并被解释为我试图钻出合适的目标，或者我试图掩盖糟糕的表现。每次都很难说服别人，但我已经习惯了。
大多数程序员都不擅长编程
(你刚才说“有争议”)
我坐在家里的办公室里思考一些编程问题，最后我看着书架上的“完整的频谱ROM拆卸”，心想:
“现在有多少程序员能写出Spectrum ROM中使用的代码?”
Spectrum，对于那些不熟悉它的人来说，有一个基本的编程语言，可以在16K的Z80代码(一个< 5Mhz的8位处理器，没有FPU或整数乘)中完成简单的2D图形(线，曲线)，文件IO排序和浮点计算，包括传递函数。今天的大多数毕业生都很难编写一个这么小的“Hello World”程序。
我认为问题在于，能够做到这一点的程序员的绝对数量几乎没有变化，但作为一个百分比，它正在迅速接近于零。这意味着，随着越来越多不合格的程序员进入这个领域，所编写的代码的质量正在下降。
Where I'm currently working, there are seven programmers including myself. Of these, I'm the only one who keeps up-to-date by reading blogs, books, this site, etc and doing programming 'for fun' at home (my wife is constantly amazed by this). There's one other programmer who is keen to write well structured code (interestingly, he did a lot of work using Delphi) and to refactor poor code. The rest are, well, not great. Thnking about it, you could describe them as 'brute force' programmers - will force inappropriate solutions until they work after a fashion (e.g. using C# arrays with repeated array.Resize to dynamically add items instead of using a List).
现在，我不知道我目前所在的地方是否具有代表性，尽管从我以前的职位来看，我认为它是典型的。事后来看，我发现一些常见的模式对任何项目都没有帮助(比如缺少代码的同行评审)。
所以，7个程序员中就有5个是垃圾。
斯基兹
自动更新会导致软件质量更差，更不安全
这个想法
一个系统，以保持用户的软件最新的错误修复和安全补丁。
现实
产品必须在固定期限内交付，这通常是以牺牲QA为代价的。为了在截止日期前发布带有许多漏洞和安全漏洞的软件，他们知道“自动更新”可以在以后用来修复所有问题。
真正让我想到这一点的软件是VS2K5。起初，它很棒，但随着更新的安装，软件慢慢变得更糟。最大的问题是宏的丢失——我花了很长时间创建了一组有用的VBA宏来自动化我写的一些代码——但显然有一个安全漏洞，而不是修复它，宏系统被禁用了。Bang有一个非常有用的功能:记录击键并重复回放。
现在，如果我真的是偏执狂的话，我可以把自动更新看作是一种让人们通过缓慢安装更频繁地破坏系统的代码来升级他们的软件的方法。当系统变得越来越不可靠时，用户就会被诱惑去购买下一个版本，因为它承诺有更好的可靠性等等。
斯基兹
顾客并不总是对的。
在我处理的大多数情况下，客户是产品所有者，也就是“企业”。通常情况下，开发人员只是编写代码，而不试图在产品中提供既定的利益。人们有太多的误解，认为IT部门是“公司中的公司”，这完全是一堆垃圾。
I feel my role is that of helping the business express their ideas - with the mutual understanding that I take an interest in understanding the business so that I can provide the best experience possible. And that route implies that there will be times that the product owner asks for something that he/she feels is the next revolution in computing leaving someone to either agree with that fact, or explain the more likely reason of why no one does something a certain way. It is mutually beneficial, because the product owner understands the thought that goes into the product, and the development team understands that they do more than sling code.
这实际上已经开始引导我们走上提高生产力的道路。如何?由于双方的分歧已经改善了沟通，我们更有可能在过程中更早地走到一起，并就产品定义达成一个互利的解决方案。
这是有可能保护您的应用程序。
每次有人问如何防止用户盗版他们的应用，或者如何保护应用不受黑客攻击，答案都是不可能的。无稽之谈。如果你真的相信这一点，那就不锁门(或者直接把门拿出来!)。也不用去看医生了。你是凡人——试图治愈疾病只是推迟了不可避免的事情。
仅仅因为有人可能会盗版你的应用或入侵你的系统，并不意味着你不应该试图减少这样做的人。你真正要做的是让入侵者/海盗需要比他们愿意做的更多的工作。
就像在你的房子上安装门闩和ADT可以防止窃贼，合理的反盗版和安全措施可以让黑客和海盗远离你的路。当然，他们越想闯入，你就越需要安全保障。
记录器配置是浪费时间。如果这意味着学习一种新的语法，尤其是一种无声地失败的语法，为什么要有它们呢?不要误解我，我喜欢好的伐木。我喜欢日志记录器的继承和向日志记录器的处理程序添加格式化程序。但是为什么要在配置文件中进行呢?
您希望在不重新编译的情况下对日志代码进行更改吗?为什么?如果您将日志代码放在单独的类、文件中，会有什么不同呢?
您是否希望将可配置的日志与您的产品一起分发给客户端?这不是提供了太多信息吗?
最令人沮丧的是，用流行语言编写的流行实用程序往往会按照该语言指定的格式编写良好的api。编写一个Java日志实用程序，我知道您已经生成了javadocs，我知道如何导航。为您的日志记录器配置编写一种特定于域的语言，我们有什么?也许有文件，但到底哪里去了?你来决定怎么组织，我对你的思路不感兴趣。
让您的业务逻辑远离DB。或者至少，保持它非常精简。让DB做它应该做的事情。让代码做它应该做的事情。时期。
If you're a one man show (basically, arrogant & egotistical, not listening to the wisdom of others just because you're in control), do as you wish. I don't believe you're that way since you're asking to begin with. But I've met a few when it comes to this subject and felt the need to specify. If you work with DBA's but do your own DB work, keep clearly defined partitions between your business objects, the gateway between them and the DB, and the DB itself. If you work with DBA's and aren't allowed to do your DB work (either by policy or because they're premadonnas), you're very close to being a fool placing your reliance on them to get anything done by putting code-dependant business logic in your DB entities (sprocs, functions, etc.). If you're a DBA, make developers keep their DB entities clean & lean.
MS Access*是一个真正的开发工具，专业程序员可以毫无羞耻地使用它
仅仅因为某个平台吸引了自认为是程序员的黑客和秘书，就不应该玷污这个平台本身。每个平台都有其优点和缺点。
那些抱怨某些平台或工具或将其贬低为“玩具”的程序员更有可能对自己的手艺知之甚少，而不是他们的自我意识所说服的那样。对我来说，听到一个程序员抨击任何他们自己没有广泛使用过的环境是一种过度自信的表现。
*在这里插入任何恶意工具(VB, PHP等)。
所有源代码和注释都应该用英文编写
用英语以外的语言编写源代码和/或注释会降低可重用性，如果你不理解它们所使用的语言，就更难调试。
SQL表、视图和列也是如此，特别是在使用缩写时。如果它们没有缩写，我可能能够在线翻译表/列名，但如果它们被缩写，我所能做的就是选择并尝试破译结果。
一个编程任务只有在它不可能的时候才有趣，那是在你说服自己能够成功解决它之前。
我想，这就是为什么我的许多项目都在“to_be_continue”文件夹中完成了一半。
开发人员过度使用数据库
通常情况下，开发人员在DBMS中存储的数据应该以代码或文件的形式存在。我曾经见过一个一列一行的表，它存储“系统密码”(与用户表分开)。我看到过存储在数据库中的常量。我见过的数据库足以让一个成年程序员哭出来。
这些讨厌的程序员对DBMS有一种神秘的敬畏——数据库可以做任何事情，但他们不知道它是如何工作的。dba实践一种黑魔法。它还允许责任转移:“数据库太慢了”，“是数据库做的”和其他借口是常见的。
如果不加检查，这些程序员就会继续开发数据库中的数据库，系统中的系统。(这个反模式有一个名字，但我忘了它是什么。)
大多数编程面试问题都是毫无意义的。尤其是那些由程序员想出的。
这是一种常见的情况，至少根据我和我的朋友的经验，吹牛 程序员，问你一些他花了几周时间在谷歌上搜索的棘手问题。有趣的是，你回到家，一分钟内就把它炸飞了。这就像他们经常试图用他们复杂的武器打败你，而不是检查你是否是一个全面的、务实的团队合作者。
在我看来，类似的愚蠢是当你被要求提供高度可访问的基础知识时，比如:“哦，等等，让我看看你是否可以在一张纸上伪代码insert_name_here-算法(sic!)”。在申请高级编程工作时，我真的需要记住它吗?我应该有效地解决问题或谜题吗?
糟糕的IDE会让编程语言变弱
优秀的编程ide确实使某些语言的工作更容易，更好地监督。在我的职业生涯中，我有点被宠坏了，我工作的公司总是有最新的Visual Studio可供使用。
在过去的8个月里，我一直在做很多关于Cocoa的工作，而Xcode编辑器使得使用这种语言变得非常困难。重载很难找到，处理打开文件的整体方式只会让你的屏幕非常混乱，非常快。这真的很遗憾，因为Cocoa是一种很酷且功能强大的语言。
当然死忠的Xcode粉丝现在会投票否决我的文章，但是有很多ide确实更好。
人们正在转向IT行业，而这些人本不该转向IT行业
这是从我去年的一篇博客文章中复制/粘贴的。
我的经验主要是关于荷兰市场的，但也可以适用于任何其他市场。
我们(我将所有软件工程师归为一类)目前处于一个对我们非常有利的市场中。公司正拼命地想要得到软件工程师(从现在开始)，无论价格如何。如果你现在换工作，你几乎可以要求任何你想要的东西。在荷兰，现在有一种趋势，甚至给两辆租赁车一份工作，只是为了让你为他们工作。这有多奇怪?我怎么能同时开两辆车?
当然，这听起来对我们来说很好，但这也造成了一个非常不健康的局面。
例如: 如果你目前正在为一家快速发展的公司工作，你正试图吸引更多的同事，最终从地面得到一些严肃的软件开发，没有人能找到不提供天价薪水的人。寻找优秀的同事是非常困难的。很多人被我们这种工作所吸引，因为高薪，但这也意味着很多没有正确激情的人正在进入我们的市场。
Passion, yes, I think that is the right word. When you have passion for your job, your job won’t stop at 05:00 PM. You will keep refreshing all of your development RSS feeds all night. You will search the internet for the latest technologies that might be interesting to use at work. And you will start about a dozen new ‘promising’ projects a month, just to see if you can master that latest technology you just read about a couple of weeks ago (and find an useful way of actually using that technology).
如果没有这种激情，市场可能看起来很好(因为汽车、金钱，当然还有我们吸引的辣妹)，但我认为，只要是消防员或战斗机飞行员，市场就不会那么有趣。
听起来我是在保护自己的工作，这在一定程度上是对的。但我也在努力保护自己不受我不想共事的人的伤害。我想就我读到的东西进行热烈的讨论。我希望能够与那些对工作有同样“热情”的人进行辩论。我希望同事与我共事是出于正确的原因。
我要找的人在哪里!!
学校教育毁掉创造力
*“废墟”指“潜在的废墟”
当然，上学是需要的!每个人在使用之前都需要学习一些东西——然而，如果我们不小心的话，你所有关于如何为特定的业务领域采取某种策略的伟大想法都很容易被扔进我们的大脑深处。
当你学习新事物、获得新技能时，你也会把自己的思维定势限制在这些新事物和新技能上，因为它们显然是“做事的方法”。作为人类，我们倾向于听从权威——无论是老师、顾问、同事，甚至是你喜欢的网站/论坛。我们应该时刻注意我们思维运作的“缺陷”。听别人说什么，但不要认为他们说的是理所当然的。对你收到的每一个新信息都要保持一种批判的观点。
而不是想“哇，这很聪明。我从现在开始就用它了”，我们应该想“哇，这很聪明。现在，我如何在我的个人技能和想法的工具箱中使用它?”
我不知道这是否真的有争议，但这样如何:方法和函数名是你的代码可以拥有的最好的注释类型;如果您发现自己在写注释，请将注释的代码段转换为函数/方法。
这样做有一个令人愉快的副作用，它迫使你很好地分解你的程序，避免了可能很快与现实不同步的注释，为你提供了一些可以对代码库进行grep的东西，并为你的代码留下了新鲜的柠檬味。
编程还处于初级阶段。
尽管编程语言和方法已经发展了很多年，但我们还有很长的路要走。迹象很明显:
语言文档在互联网上随意传播(stackoverflow在这里有所帮助)。 语言在语法上的进化必然会破坏之前的版本。 调试仍然经常使用printf完成。 语言库或其他形式的大规模代码重用仍然相当罕见。
显然，所有这些都在改善，但如果我们都能同意这是开始而不是结束就好了=)。
没人在乎你的代码
If you don't work on a government security clearance project and you're not in finance, odds are nobody cares what you're working on outside of your company/customer base. No one's sniffing packets or trying to hack into your machine to read your source code. This doesn't mean we should be flippant about security, because there are certainly a number of people who just want to wreak general havoc and destroy your hard work, or access stored information your company may have such as credit card data or identity data in bulk. However, I think people are overly concerned about other people getting access to your source code and taking your ideas.
生成文档良好的代码比生成文档不良的代码花费的时间更少
When I say well-documented I mean with comments that communicate your intention clearly at every step. Yes, typing comments takes some time. And yes, your coworkers should all be smart enough to figure out what you intended just by reading your descriptive function and variable names and spelunking their way through all your executable statements. But it takes more of their time to do it than if you had just explained your intentions, and clear documentation is especially helpful when the logic of the code turns out to be wrong. Not that your code would ever be wrong...
I firmly believe that if you time it from when you start a project to when you ship a defect-free product, writing well-documented code takes less time. For one thing, having to explain clearly what you're doing forces you to think it through clearly, and if you can't write a clear, concise explanation of what your code is accomplishing then it's probably not designed well. And for another purely selfish reason, well-documented and well-structured code is far easier to dump onto someone else to maintain - thus freeing the original author to go create the next big thing. I rarely if ever have to stop what I'm doing to explain how my code was meant to work because it's blatantly obvious to anyone who can read English (even if they can't read C/C++/C# etc.). And one more reason is, frankly, my memory just isn't that good! I can't recall what I had for breakfast yesterday, much less what I was thinking when I wrote code a month or a year ago. Perhaps your memory is far better than mine, but because I document my intentions I can quickly pick up wherever I left off and make changes without having to first figure out what I was thinking when I wrote it.
这就是为什么我能很好地编写文档——不是因为我觉得编写适合展示的漂亮代码是一种崇高的使命，也不是因为我是一个纯粹主义者，而只是因为端到端让我在更短的时间内发布高质量的软件。
.．.“澄清想法”不应该是开发者的唯一责任……是的，XKCD让我用了那个特定的短语…
我们经常会收到一些项目，这些项目都是在伪元类型特定的“代码”中指定的，如果你愿意这样称呼它的话。经常有产品经理为一个项目制定初始需求，并执行接近0%的基本逻辑验证。
我并不是说技术方法不应该由架构师制定，或者具体的实现不应该是开发人员的责任，而是说它应该是产品经理的需求，以确保他们的需求在逻辑上是可行的。
就我个人而言，我参与过太多“简单”的项目，这些项目在这里或那里遇到了一些范围渐变，然后遇到了与之前的需求相矛盾的“小”更改或功能添加——无论是含蓄的还是明确的。在这种情况下，要求做出近乎不可能的改变的人很容易对开发人员无法实现他们的梦想感到愤怒。
优秀的程序员讨厌编码
类似于“优秀的程序员是懒惰的程序员”和“代码越少越好”。但是，通过遵循这一理念，我成功地编写了一些应用程序，否则这些应用程序可能会使用几倍的代码(并花费几倍的开发时间)。简而言之:在编写代码之前先思考。我自己的程序中大部分后来导致问题的部分实际上是我喜欢编码的部分，因此代码太多，因此写得很糟糕。就像这一段。
优秀的程序员是设计师
我发现编程使用与设计相同的概念(在艺术中使用相同的设计概念)。我不确定其他程序员是否也有同样的想法;也许这是左右脑的问题。从代码到命令行用户界面，再到图形用户界面，有太多丑陋的程序，很明显，这些程序的设计者实际上并不是设计者。
尽管在这种情况下，相关性可能并不意味着因果关系，但我注意到，随着我在设计方面变得更好，我在编码方面也变得更好。让事情变得合适和感觉良好的相同过程可以也应该用于这两个地方。如果代码感觉不对，它就会引起问题，因为要么a)它是不对的，要么b)你会假设它以一种“感觉对”的方式工作，然后它又会不正确。
艺术和代码并不是对立的;代码可以用在艺术中，代码本身也可以是一种艺术形式。
免责声明:不幸的是，并非我的所有代码都很漂亮或“正确”。
工具、方法论、模式、框架等等都不能代替一个训练有素的程序员
我厌倦了与那些认为最新的工具、方法、模式或框架是一颗银弹的人(主要是经理)打交道，他们可以消除雇佣有经验的开发人员来编写软件的需求。不过，作为一名以拯救风险项目为生的顾问，我不应该抱怨。
如果你想写出好的软件，那就离开你的电脑
去和最终用户以及想要和需要软件的人一起玩。只有从他们那里，你才能理解你的软件需要完成什么以及它需要如何完成。
询问他们对现有流程的爱与恨。 向他们询问他们的流程的未来，它的方向是什么。 出去逛逛，看看他们现在在用什么，弄清楚他们的使用模式。您需要满足并匹配他们的使用期望。看看他们还经常使用什么，特别是如果他们喜欢它并且可以有效地使用它。匹配。
最终用户根本不在乎你的代码有多优雅，也不在乎用什么语言写的。如果它对他们有效，他们喜欢使用它，你就赢了。如果它不能让他们的生活更轻松和更好——他们讨厌它，你就输了。
站在他们的立场上走一英里，然后去写你的代码。
永远不要让最佳实践或模式困扰成为你的奴隶。
这些应该是指导方针，而不是一成不变的法律。
我真的很喜欢这些模式，GoF的书或多或少也是这么说的，这些东西可以浏览，提供了一个常见的术语。这不是无稽之谈。
编码是一门艺术
一些人认为编码是一门艺术，而另一些人认为编码是一门科学。
“科学”派认为，既然目标是为某种情况获得最优代码，那么编码就是研究如何获得这种最优代码的科学。
“艺术”派认为，有很多方法可以获得最优的代码，这个过程充满了主观性，根据自己的技能和经验做出明智的选择是一种艺术。
如果它不是原生的，它就不是真正的编程
根据定义，程序是由计算机运行的实体。它直接与CPU和操作系统对话。不直接与CPU和操作系统对话的代码，而是由其他直接与CPU和操作系统对话的程序运行的代码，不是程序;这是一个脚本。
在Java出现之前，这只是简单的常识，完全没有争议。突然出现了一种脚本语言，它具有足够大的功能集，可以完成以前专属于程序的任务。作为回应，微软开发了。net框架和一些在其上运行的脚本语言，并设法通过在他们的开发工具中逐渐减少对真正编程的支持，以支持。net脚本来进一步搅浑水。
尽管它可以完成许多您以前必须编写程序才能完成的事情，但任何种类的托管代码仍然是脚本，而不是编程，用它编写的“程序”确实并且总是共享脚本的性能特征:它们运行得更慢，并且比真正的(本机)程序完成相同任务所需的内存要多得多。
人们称其为编程，这是对每个人的伤害，因为他们简化了定义。这会导致整体质量下降。如果你试图让编程变得如此简单，以至于任何白痴都能做到，那么你最终会得到一大堆自以为能编程的白痴。
有时使用正则表达式从HTML中提取一些内容是可以的。严肃地说，与迟钝的解析器争论，或者使用快速的正则表达式，如/<a href="([^"]+)">/?这并不是完美的，但是您的软件可以更快地启动和运行，并且您可能还可以使用另一个正则表达式来验证提取的匹配是否确实看起来像一个URL。当然，这很俗气，而且可能在一些边缘情况下失败，但对于大多数使用来说已经足够好了。
基于大量的“如何使用正则表达式获取HTML?”的问题，几乎每天都在这里发布，而且事实上每个答案都是“使用HTML解析器”，这应该是有足够的争议性的。
清理和重构在(团队)开发中非常重要
A lot of work in team development has to do with management. If you are using a bug tracker than it is only useful if someone takes the time to close/structure things and lower the amount of tickets. If you are using a source code management somebody needs to cleanup here and restructure the repository quite often. If you are programming than there should be people caring about refactoring of the lazy produced stuff of others. It is part of most of the aspects some will face while doing software development.
大家都同意这种管理的必要性。而且它总是被跳过的第一件事!
不是工具的问题，是你的问题
每当开发人员尝试做一些新的事情，比如做UML图，任何类型的图表，项目管理，他们首先寻找完美的工具来解决问题。在无休止的寻找后，他们发现没有合适的工具，他们的动机就会枯竭。剩下的就是对缺乏可用软件的抱怨。这是一种洞察力，在没有软件的情况下，要组织的计划夭折了。
好吧，只有你自己在处理组织问题。如果你习惯了组织，你可以使用或不使用软件来完成(大多数人都不需要软件)。如果你不习惯组织，没有人能帮助你。
所以“没有合适的软件”只是没有组织的最简单的借口。
好的建筑是生长出来的，而不是设计出来的。 经理们应该确保他们的团队成员总是在低于他们的技术水平的情况下工作，无论这个水平是什么。当人们在自己的舒适区工作时，他们就能写出更高质量的代码。
Switch-case不是面向对象编程
我经常看到很多开关情况或可怕的大if-else结构。这仅仅是一个没有将状态放到它所属的位置的标志，并且没有使用已经存在的真正有效的开关例结构:方法查找/虚表
真正有争议的:
你什么都不知道!
换句话说:
我知道我什么都不知道。
(这可以有很多种解释，但我认为你已经明白了。)
在开始计算机开发时，我认为每个人都必须经历三个阶段:
新手: 一无所知(这是事实)
中间: (这是自负)自以为知道些什么/非常多(/所有)
专业: 知道自己什么都不懂(因为作为一个程序员，大多数时候你必须处理你以前从未做过的事情)。 这不是坏事:我喜欢让自己随时熟悉新事物。
我认为作为一个程序员，你必须知道如何学习——或者更好:学会学习(因为记住:你什么都不知道!)))。
编程挣钱通常是对男人时间最糟糕的利用之一。
首先，你是在和埃尔博尼亚人竞争，他们每天只挣25美分。你需要说服你的雇主，你能提供埃尔博尼亚人永远无法提供的东西，而且你的东西值得一份体面的薪水。随着埃尔博尼亚人获得越来越多的海外业务，真正的优势逐渐消失，管理层也明白这一点。
另一方面，你是在花时间解决别人的问题。这些时间你可以用来发展自己的兴趣，或者解决你真正感兴趣的问题。如果你认为解决别人的问题就能拯救世界，那你为什么不让埃尔博尼亚人为你解决问题呢?
最后，软件领域的伟大创新(visicalc、Napster、Pascal等)不是由小隔间农场创造的。它们是由一两个没有预支工资的人创建的。你不能强行重建它。当一个有能力的程序员有一个非常好的想法时，这就是奇迹。
有足够的软件。有足够多的软件开发人员。你不需要被雇佣。节省你的才华，你的时间，你的头发，你的婚姻。让别人把灵魂出卖给键盘吧。如果你想编程，没问题。但不是为了钱。
在产品代码中没有反射的位置
反射破坏了静态分析，包括重构工具和静态类型检查。反射还打破了开发人员对代码的正常假设。例如:向类中添加一个方法(它不会影响类中的其他方法)应该永远不会有任何影响，但是当使用反射时，其他一些代码段可能会“发现”新方法并决定调用它。实际上，确定这样的代码是否存在是很难的。
我确实认为在代码生成器中使用反射和测试是很好的。
是的，这确实意味着我试图避免使用反射的框架。(Java缺乏适当的编译时元编程支持，这太糟糕了)
开发人员不应该测试他们自己的软件
开发和测试是两个截然相反的学科。开发就是建造，测试就是拆除。有效的测试需要一种特定的心态和方法来发现开发人员的错误，找到他们假设中的漏洞，以及他们逻辑中的缺陷。大多数人，包括我自己在内，根本无法将自己和自己的代码置于这样的审查之下，并且仍然保持客观。
许多开发人员对在哪里放置东西没有充分的认识，导致在文件、类和方法级别上源代码组织混乱。此外，相当一部分这样的开发人员基本上对代码组织问题一无所知。试图教导、哄骗、威胁或羞辱他们保持代码干净是徒劳的。
在任何一个非常成功的项目中，通常都有一个开发人员，他有良好的组织意识，非常安静地对代码库进行扫把，以防止混乱。
我有争议的观点是John Carmack(游戏邦注:代表作有ID Software, Quake等)并不是一个优秀的程序员。
不要误解我的意思，在我看来他是一个非常聪明的程序员，但当我注意到quake源代码中的“#define private public”这一行后，我不禁认为他是一个无论如何都能完成工作的人，但在我的定义中，他不是一个好程序员:) 这个观点让我陷入了很多激烈的讨论;)
设计模式是不好的。
实际上，设计模式不是。
您可以编写糟糕的代码，并将其埋没在一堆模式之下。使用单例变量作为全局变量，使用状态作为goto。无论什么。
设计模式是针对特定问题的标准解决方案，但要求您首先理解问题。如果您不这样做，设计模式就会成为下一个开发人员的问题之一。
最简单的方法就是最好的方法
程序员喜欢解决假定的或推断的需求，这些需求会增加解决方案的复杂性。
“我认为这段代码会成为性能瓶颈，因此我会添加所有这些额外的代码来缓解这个问题。”
“我假设用户会想要做某件事，因此我会添加这个非常酷的额外功能。”
“如果我能让我的代码解决这个不需要的场景，这将是一个使用我一直有兴趣尝试的新技术的好机会。”
实际上，满足需求的最简单的解决方案是最好的。如果出现新的需求或问题，这也为您在新的方向上采取解决方案提供了最大的灵活性。
显然我的想法是哈斯克尔有变量。这既是一个“无关紧要”的问题(根据至少8个SO用户的说法)(尽管似乎没有人能就哪个无关紧要的答案是正确的达成一致)，也是一个糟糕的问题(根据至少5个反对者和4个投票关闭它的人的说法)。哦，我(以及计算科学和数学家)错了，尽管没有人能给我一个详细的解释。
您永远不会使用足够多的语言，因为每种语言只适合一小部分问题，而且混合使用语言太难了。
典型的例子:Java应该只在规范经过深思熟虑(因为有很多相互依赖关系，这意味着重构的地狱)和处理具体概念时才使用。Perl应该只用于文本处理。C语言应该只在速度压倒一切时使用，包括灵活性和安全性。键值对应该用于一维数据，CSV用于二维数据，XML用于层次数据，DB用于更复杂的数据。
我相信“让我们重写过去，假装什么都没有起作用，试着修复错误”是绝望情况下有价值的调试咒语:
https://stackoverflow.com/questions/978904/do-you-use-the-orwellian-past-rewriting-debugging-philosophy-closed
软件复用是优化软件开发的重要途径
不知怎的，软件重用一度流行，但后来失去了它的魅力，因为许多公司发现，仅仅写带有重用口号的powerpoint演示文稿实际上并没有帮助。他们认为软件重用“不够好”，无法实现他们的梦想。因此，它似乎不再流行了——它被许多项目管理新手所取代(例如敏捷)。
事实是，任何真正优秀的开发人员都会自己执行某种软件重用。我会说任何不做软件重用的开发人员都是糟糕的开发人员!
我亲身经历过，软件重用在多大程度上可以提高开发的性能和稳定性。当然，一组幻灯片和管理层的半心半意的坦白并不足以在一家公司充分发挥其潜力。
我已经链接了一篇关于软件重用的旧文章(见标题)。它最初是用德语写的，后来被翻译了——所以，如果它写得不好，请原谅。
如果一种编程语言的语法不直观，我也不在乎它有多强大，而且我不能把它放在一边，在不花太多精力刷新细节的情况下再回来使用它。我宁愿语言本身是直观的，而不是神秘但强大的用于创建DSL。计算机语言对我来说是一种用户界面，我希望它像任何其他用户界面一样易于使用。
缺陷和增强请求是相同的
Unless you are developing software on a fixed-price contract, there should be no difference when prioritizing your backlog between "bugs" and "enhancements" and "new feature" requests. OK - maybe that's not controversial, but I have worked on enterprise IT projects where the edict was that "all open bugs must be fixed in the next release", even if that left no developer time for the most desirable new features. So, a problem which was encountered by 1% of the users, 1% of the time took precedence over a new feature would might be immediately useful to 90% of the users. I like to take my entire project backlog, put estimates around each item and take it to the user community for prioritization - with items not classified as "defect", "enhancement", etc.
异常应该只在真正异常的情况下使用
在我最近参与的项目中，异常的使用似乎非常猖獗。
这里有一个例子:
我们有拦截网络请求的过滤器。筛选器调用筛选器，筛选器的任务是检查请求是否具有某些输入参数并验证这些参数。你设置了要检查的字段，并且抽象类确保参数不为空，然后调用一个由你的特定类实现的screen()方法来进行更多的扩展验证:
public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{
//
if (!checkFieldExistence(req)){
return false;
}
return screen(req,resp,filterConfig);
}
checkFieldExistance(req)方法从不返回false。如果所有字段都不缺少，则返回true，如果缺少字段则抛出异常。
我知道这是一种糟糕的设计，但部分问题在于，这里的一些架构师认为，每次遇到意外情况时都需要抛出异常。
此外，我知道checkFieldExistance(req)的签名确实抛出了一个异常，这只是我们几乎所有的方法都这样做-所以我没有想到这个方法可能会抛出一个异常而不是返回false。直到我翻遍代码才发现。
如果语言已经公开了实际类型，就不要为基本类型使用关键字。在c#中，这将指bool (Boolean)， int (Int32)， float (Single)， long (Int64)。'int'， 'bool'等不是语言的实际部分，而只是实际类型的'快捷方式'或'别名'。不要使用不存在的东西!在我看来，Int16, Int32, Int64，布尔值等比'short'， 'long'， 'int'更有意义。
我通常持有相当有争议的、强烈的和响亮的观点，所以这里只是其中的一些:
“因为我们是微软的机构/合作伙伴/专家”从来都不是一个有效的论点。
我现在工作的公司首先把自己定位为微软专家。所以前面提到的论点被抛出了很多次，我还没有看到一个背景下它是有效的。
我不明白为什么要在每一个适用的角落推广微软的技术和产品，而不顾客户和员工的满意度，以及一般的实用主义。
这正是我对软件行业政治深恶痛绝的一个基石。
MOSS(微软Office Sharepoint服务器)就是一坨屎。
有点像第一个观点，但我真的认为MOSS应该被赶出市场。它需要花费大量的授权和设置费用，破坏了web标准，让开发者非常不开心。我还没有看到一个MOSS项目有一个总体积极的结果。
然而，一次又一次，客户找到我们并要求MOSS解决方案。
Linq2Sql并没有那么糟糕
我看到过很多诋毁Linq2Sql的帖子。我知道这并不完美，但什么才是完美的?
就我个人而言，我认为它有它的缺点，但总的来说，它可以很好地用于原型设计，或开发中小型应用程序。当我考虑到它为我从编写枯燥的DAL代码中节省了多少时间时，我不能抱怨，特别是考虑到我们不久前拥有的替代方案。
大于运算符(>，>=)应该被弃用
我试着用“小于”而不是“大于”的偏好编码了一段时间，它卡住了!我不想回去，事实上，我觉得在这种情况下，每个人都应该按照我的方式去做。
考虑常见的数学“范围”符号:0 <= i < 10
这很容易在代码中近似，你已经习惯了在中间重复变量并用&&连接:
if (0 <= i && i < 10)
return true;
else
return false;
一旦你习惯了这种模式，你就再也不会觉得愚蠢了
if ( ! (i < 0 || i >= 9))
return true;
同样的方法。
长序列的关系变得更容易处理，因为操作数倾向于非递减顺序。
此外，操作符<的优先级被铭记在c++标准中。在某些情况下，operator=是根据it来定义的!(a<b || b<a))
函数式编程并不比命令式编程更直观或更容易学习。
函数式编程有很多优点，但我经常听到函数式程序员说，对于没有编程经验的人来说，理解函数式编程比理解命令式编程更容易。据我所知，情况恰恰相反，人们发现琐碎的问题很难解决，因为他们不知道如何管理和重用他们的临时结果，当你在一个没有状态的世界结束时。
应该始终使用基于1的数组，而不是基于0的数组。基于0的数组是不自然的、不必要的，而且容易出错。
当我数苹果、员工或小部件时，我从1开始，而不是0。我也这么教我的孩子。不存在第0个苹果或第0个员工或第0个部件。使用1作为数组的基更直观，也更不容易出错。忘掉加一减一的地狱吧(我们过去常这样称呼它)。基于0的数组是计算机科学发明的一种不自然的结构——它们不能反映现实，而计算机程序应该尽可能地反映现实。
在. net上开发不是编程。它只是把其他人的代码拼接在一起。
我的编码背景要求你了解硬件，这在我的行业中仍然是一个至关重要的要求，我认为高级语言只是简单地组装别人的工作。这并没有什么本质上的错误，但这是“编程”吗?
微软在为“开发人员”提供符号指令语法方面做了很多艰苦的工作。我现在似乎认识了越来越多的开发人员，他们在执行工作时似乎受到类的存在或不存在的限制。
我的观点来自于这样一个概念:作为一名程序员，你应该能够在你的平台允许的最低水平上编程。因此，如果您正在编写。net程序，那么您需要能够埋头苦干并找出解决方案，而不是依赖于其他人为您创建一个类。在我看来，这是一种懒惰，不符合“发展”的标准。
当许多新技术出现时，我对它们的了解只够决定我现在是否需要它们。
如果没有，我就把它们放在一边，直到“早期采用者”把粗糙的边缘去掉，然后每隔几个月/几年再检查一次。
我总是对的。
或者叫它讨论设计。但如果我提出了什么，你最好能证明我为什么错了，并提出一个你可以辩护的替代方案。
当然，这只有在我讲道理的时候才管用。幸运的是，我是。：）
可用性问题从来不是用户的错。
当某些用户做了一些团队中所有人都认为“只是一件愚蠢的事情”时，我无法计算问题出现的频率。像“为什么有人要这么做?”或者“为什么他不做XYZ”这样的短语经常出现。
尽管许多人已经厌倦了听我说:如果一个现实生活中的用户试图做一些事情，要么没有工作，导致一些错误或导致意想不到的行为，那么这可能是任何人的错，而不是用户的错!
请注意，我不是指那些故意滥用软件的人。我指的是软件的假定目标组。
WordPress是一个CMS(从技术上讲，确实如此)。
https://stackoverflow.com/questions/105648/wordpress-is-it-a-cms
我认为Java应该通过精简的本地库包装器来支持特定于系统的特性。
换句话说，从几乎所有人的角度来看，我认为Sun决定要求Java只支持可移植特性是一个巨大的错误。
无数年之后，SWT出现并解决了编写可移植的本机小部件UI的基本问题，但那时微软被迫将Java派生为c#，并且已经编写了大量原本可以用文明Java完成的c++。现在世界运行在c#、VB、Java、c++、Ruby、Python和Perl的混合语言上。除了SWT程序外，所有Java程序的外观和操作都很奇怪。
如果Java在本机库的基础上提供了薄包装器，那么人们就可以完全用Java编写swt等效程序，并且随着事情的发展，我们可以用Java开发可移植的明显的本机应用程序。我完全支持可移植应用程序，但如果这种可移植性是在中间件UI(和其他特性)库的开放市场中实现的，而不是通过简单地将用户菜单减少为垃圾或用Swing伪造UI，那就更好了。
我猜想Sun认为ISV会受到Java的限制，然后世界上所有新的PC应用程序都会神奇地在Sun上运行。不错的尝试。他们最终没有得到应用程序，也没有让语言起飞，直到我们可以将其用于仅逻辑的服务器后端代码。
如果事情做得不一样，也许本地应用程序就不会死掉。
程序员不应该接触Word(或PowerPoint)
除非你正在开发一个文字或文档处理工具，否则你不应该使用只产生二进制blobs的文字处理器，就此而言:
生成的XML文件是二进制blob
程序员应该编写纯文本文档。程序员编写的文档只需要传达意图，而不是格式。它必须能够使用编程工具链进行生产:编辑器、版本控制、搜索实用程序、构建系统等等。当你已经拥有并知道如何使用这个工具链时，使用其他任何文档制作工具都是在浪费时间和精力。
当需要为非程序员生成文档时，应该使用轻量级标记语言，例如reStructuredText(如果您正在编写纯文本文件，您可能正在编写自己的轻量级标记)，并从中生成HTML、PDF、S5等。
软件因为缺乏多样性而糟糕透顶。无意冒犯任何种族，但当一个职业由不同种族和性别组成时，事情就会很顺利。看看过度使用不可再生能源就知道了。这很好，因为每个人都在贡献，而不仅仅是“刻板的人”
垃圾收集被高估了
许多人认为在Java中引入垃圾收集是与c++相比最大的改进之一。我认为最好的介绍是非常小的，编写良好的c++代码在适当的地方做了所有的内存管理(使用像RAII这样的技术)，所以不需要垃圾收集器。
从长远来看，不需要探索所有形式的测试，QA也可以做得很好
很多地方似乎都有一种“方法”，即“我们怎么做”。这似乎隐含地排除了其他方法。
从长远来看，这是一个严重的问题，因为QA的主要功能是将错误归档并修复它们。
如果你不能找到尽可能多的bug，你就不能很好地做到这一点。例如，当您排除方法时，由于过于依赖黑盒，您开始忽略整个可发现的编码错误类别。这意味着，您正在使整个编码错误类无法修复，除非有人偶然发现它。
潜在的问题似乎往往是管理层+员工。有这个问题的管理者似乎对计算机科学和/或他们团队的价值主张有狭隘的想法。他们倾向于创建反映他们的方法的团队，以及测试方法的白名单。
我并不是说你可以或应该一直做所有的事情。让我们面对现实吧，对于给定的产品来说，一些测试方法只是在浪费时间。有些方法在产品成熟度的特定级别上更有用。但我认为，测试组织缺少的是挑战自己学习新事物的能力，并将其应用于整体绩效。
这里有一个假设的对话可以总结:
我:你测试了启动脚本10年，却对shell脚本及其工作原理一无所知?! 测试人员:是的。 我:权限? 测试人员:安装程序会这样做 我:平台，发布特定的依赖? 测试者:我们为此存档bug 我:错误处理? 测试人员:当错误发生时，客户支持会给我们发送一些信息。 我:好吧…(开始考虑在stackoverflow中写帖子…)
详细的设计是浪费时间，如果一个工程师需要它们来做一份体面的工作，那么就不值得雇佣它们!
好的，这里有几个想法:
1) the old idea of waterfall development where you supposedly did all your design up front, resulting in some glorified extremely detailed class diagrams, sequence diagrams etc. etc., was a complete waste of time. As I once said to a colleague, I'll be done with design once the code is finished. Which I think is what agile is partly a recognition of - that the code is the design, and that any decent developer is continually refactoring. This of course, makes the idea that your class diagrams are out of date laughable - they always will be.
2) management often thinks that you can usefully take a poor engineer and use them as a 'code monkey' - in other words they're not particularly talented, but heck - can't you use them to write some code. Well.. no! If you have to spend so much time writing detailed specs that you're basically specifying the code, then it will be quicker to write it yourself. You're not saving any time. If a developer isn't smart enough to use their own imagination and judgement they're not worth employing. (Note, I'm not talking about junior engineers who are able to learn. Plenty of 'senior engineers' fall into this category.)
当为数据访问层创建单元测试时，数据应该直接从DB中检索，而不是从模拟对象中检索。
考虑以下几点:
void IList<Customer> GetCustomers()
{
List<Customer> res = new List<Customer>();
DbCommand cmd = // initialize command
IDataReader r = cmd.ExecuteQuery();
while(r.read())
{
Customer c = ReadFiledsIntoCustomer(r);
res.Add(c);
}
return res;
}
在GetCustomers的单元测试中，对cmd.ExecuteQuery()的调用应该实际访问DB还是应该模拟它的行为?
我认为，如果以下情况成立，您不应该模拟对DB的实际调用:
存在一个测试服务器和模式。 模式是稳定的(意味着您不期望对其进行重大更改) DAL没有聪明的逻辑:查询是简单地构造的(config/stored procs) 去虹膜化的逻辑很简单。
从我的经验来看，这种方法的最大好处是你可以尽早与DB进行交互，体验“感觉”，而不仅仅是“外观”。它为您省去了许多事后的麻烦，并且是熟悉模式的最佳方法。
许多人可能会争辩说，一旦执行流跨越了进程边界，它就会成为一个单元测试。我同意它有它的缺点，特别是当数据库不可用，然后你不能运行UT。
然而，我相信在许多情况下这应该是一件有效的事情。
记事本是一个完美的文本编辑器。(有时是非窗口换行符的写字板)
编辑配置文件 查看日志文件 发展
我知道有人真的相信这一点!然而，他们将使用IDE进行开发，但继续使用记事本进行其他一切!
应该要求所有项目经理都有编码任务
在我工作过的团队中，项目经理实际上是一个程序员，他非常了解代码的技术问题，足以完成编码任务，所做的决策缺乏沟通脱节，而在项目经理不参与代码的团队中经常发生这种情况。
我最具争议的编程观点是 发现性能问题与测量无关，而是与捕获有关。
如果你在一个房间里寻找大象(而不是老鼠)，你需要知道它们有多大吗?不!你要做的就是看。 它们的巨大使得它们很容易被发现! 没有必要先测量它们。
至少从关于gprof的论文开始，度量的思想就已经成为常识 (Susan L. Graham, et al 1982)*，而一直以来，就在我们的眼皮底下，有一种非常简单直接的方法来寻找值得优化的代码。
作为一个小例子，下面是它的工作原理。假设您从调用堆栈中抽取5个随机时间样本，并且恰好在5个样本中的3个样本中看到特定的指令。这说明了什么?
............. ............. ............. ............. .............
............. ............. ............. ............. .............
Foo: call Bar ............. ............. Foo: call Bar .............
............. Foo: call Bar ............. ............. .............
............. ............. ............. Foo: call Bar .............
............. ............. ............. ............. .............
............. .............
它告诉你程序花费60%的时间做指令请求的工作。去掉它就去掉了60%:
...\...../... ...\...../... ............. ...\...../... .............
....\.../.... ....\.../.... ............. ....\.../.... .............
Foo: \a/l Bar .....\./..... ............. Foo: \a/l Bar .............
......X...... Foo: cXll Bar ............. ......X...... .............
...../.\..... ...../.\..... ............. Foo: /a\l Bar .............
..../...\.... ..../...\.... ............. ..../...\.... .............
/ \ .../.....\... / \ .............
约。
如果您可以删除指令(或更少地调用它)，大约是2.5倍的加速。(注意-递归是无关紧要的-如果大象怀孕了，它不会更小。) 然后你可以重复这个过程，直到你真正接近最优。
这并不需要精确的测量、函数计时、调用计数、图表、数百个样本，以及任何典型的分析内容。
有些人在遇到性能问题时就使用这种方法，但他们不明白这有什么大不了的。
Most people have never heard of it, and when they do hear of it, think it is just an inferior mode of sampling. But it is very different, because it pinpoints problems by giving cost of call sites (as well as terminal instructions), as a percent of wall-clock time. Most profilers (not all), whether they use sampling or instrumentation, do not do that. Instead they give a variety of summary measurements that are, at best, clues to the possible location of problems. Here is a more extensive summary of the differences.
*事实上，这篇论文声称gprof的目的是“帮助用户评估抽象的替代实现”。它并没有声称可以帮助用户定位需要替代实现的代码，在比函数更精细的级别上。
我第二个最具争议的观点是这个，如果它不是那么难以理解的话。
软件开发人员、编码员、程序员、架构师之间没有区别……
我在酵母行业工作过10多种，但仍然觉得试图区分这些“角色”是绝对愚蠢的。你写代码?你是开发人员。你整天都在画漂亮的UML图。你是个…嗯. .我不知道你是谁，你可能只是想给别人留下好印象。(是的，我知道UML)。
引用已故的E. W. Dijsktra的话:
编程是应用数学中最难的分支之一;贫穷的数学家最好还是做纯粹的数学家。
计算机科学与计算机无关，就像天文学与望远镜无关一样。
我不明白一个人怎么能声称自己是一个合格的程序员，却不能解决像这个这样非常简单的数学问题。可能是一个CRUD猴子，但不是一个程序员。
“程序员必须把编程作为副业，否则他们永远都不如做编程的人。”
就像kpollock说的，想象一下对于医生或士兵来说……
最重要的不是他们是否编码，而是他们是否思考编码。计算科学是一种智力练习，你不一定需要编写代码来思考使你成为更好的程序员的问题。
这并不像爱因斯坦在他的研究之外还能玩粒子和波。
程序员应该不惜一切代价避免通过继承隐藏方法。
In my experience, virtually every place I have ever seen inherited method hiding used it has caused problems. Method hiding results in objects behaving differently when accessed through a base type reference vs. a derived type reference - this is generally a Bad Thing. While many programmers are not formally aware of it, most intuitively expect that objects will adhere to the Liskov Substitution Principle. When objects violate this expectation, many of the assumptions inherent to object-oriented systems can begin to fray. The most egregious cases I've seen is when the hidden method alters the state of the object instance. In these cases, the behavior of the object can change in subtle ways that are difficult to debug and diagnose.
Ok, so there may be some infrequent cases where method hiding is actually useful and beneficial - like emulating return type covariance of methods in languages that don't support it. But the vast majority of time, when developers use method hiding it is either out of ignorance (or accident) or as a way to hack around some problem that probably deserves better design treatment. In general, the beneficial cases I've seen of method hiding (not to say there aren't others) is when a side-effect free method that returns some information is hidden by one that computes something more applicable to the calling context.
像c#这样的语言通过要求在隐藏基类方法的方法上使用new关键字进行了一些改进——至少有助于避免非自愿地使用方法隐藏。但我发现许多人仍然混淆了new和override的含义——特别是在简单的场景中，它们的行为看起来是相同的。如果像FxCop这样的工具实际上有内置的规则来识别方法隐藏的潜在不良使用，那就太好了。
顺便说一下，通过继承隐藏方法不应该与其他类型的隐藏(例如通过嵌套)相混淆，我认为嵌套是一种有效且有用的构造，潜在问题较少。
有争议的是吗?我认为c++流使用<<和>>。我讨厌它。它们是移位运算符。以这种方式重载它们显然是一种糟糕的做法。这让我想杀了想出这主意并认为这是个好主意的人。叽阿。
匿名函数很糟糕。
我正在自学jQuery，虽然它是一种优雅且非常有用的技术，但大多数人似乎都将其视为最大化匿名函数用户的某种竞争。
函数和过程命名(以及变量命名)是我们在编程中所拥有的最强大的表达能力。将函数作为数据传递是一项伟大的技术，但使它们匿名并因此非自文档化是一个错误。这样就失去了表达代码含义的机会。
I'd say that my most controversial opinion on programming is that I honestly believe you shouldn't worry so much about throw-away code and rewriting code. Too many times people feel that if you write something down, then changing it means you did something wrong. But the way my brain works is to get something very simple working, and update the code slowly, while ensuring that the code and the test continue to function together. It may end up actually creating classes, methods, additional parameters, etc., I fully well know will go away in a few hours. But I do it because i want to take only small steps toward my goal. In the end, I don't think I spend any more time using this technique than the programmers that stare at the screen trying to figure out the best design up front before writing a line of code.
我得到的好处是，我不必不断地处理那些因为我碰巧以某种方式破坏了它而不再工作的软件，并试图找出停止工作的原因和原因。
我有两个:
设计模式有时是糟糕程序员编写糟糕代码的一种方式——“当你有一把锤子时，整个世界看起来都像钉子”的心态。如果有什么我讨厌听到的是两个开发人员通过模式创建设计:“我们应该使用命令与facade…”
不存在所谓的“过早优化”。你应该在你觉得这样做太痛苦之前对你的代码进行分析和优化。
“评论是谎言”
注释不能运行，而且很容易被忽略。最好是用清晰的、由单元测试说明的重构代码来表达意图。(当然是编写TDD的单元测试…)
我们不写注释，因为它们很冗长，而且模糊了代码中真正发生的事情。如果你觉得需要注释——找出代码中不清楚的地方，然后重构/编写更清晰的测试，直到不需要注释……
．.． 我从极限编程中学到的东西(当然，假设你已经建立了清理代码的团队规范……)
编程:这是一份有趣的工作。
我似乎看到了两类开发人员。有些人不喜欢，但他们有能力，薪水也不错。另一组人喜欢它的程度有点令人毛骨悚然。这似乎就是他们的生活。
我只是觉得这份工作薪水高，而且有趣。每一天的每一分钟都有各种各样的学习新东西的空间。我想不出其他我更喜欢的工作了。但这仍然是一份工作。妥协是要做出来的，你生产的东西并不总是那么好。
因为我更愿意在沙滩上喝啤酒或和孩子们一起玩。
你只需要3到5种语言就可以完成所有的事情。C是定的。也许是组装，但你应该知道它，并能使用它。如果你写的是网页代码，可能是javascript和/或Java。一种shell语言(如bash)和一种HLL语言(如Lisp)可能会有用。其他任何事情都会让人分心。
复制/粘贴不是反模式，事实上它有助于避免产生更多的错误
我的经验法则——只输入不能复制/粘贴的东西。如果创建类似的方法，类或文件-复制现有的并更改所需的内容。(我不是在谈论复制应该放在单个方法中的代码)。
我通常从不输入变量名——要么复制粘贴，要么使用IDE自动补全。如果需要一些DAO方法-复制类似的方法并更改所需的内容(即使将更改90%)。对某些人来说，这可能看起来是极度的懒惰或缺乏知识，但我几乎从来没有处理过由拼写错误引起的问题，而且它们通常很难捕捉(如果没有在编译级别检测到)。
每当我偏离我的复制粘贴规则，开始输入东西时，我总是拼写错误(这只是一个统计数据，没有人能立即写出完美的文本)，然后花更多的时间试图找出哪里。
现代c++是一门美丽的语言。
我说出来了。很多人真的很讨厌c++，但说实话，我发现现代c++与STL/Boost风格的编程在大多数时候是一种非常有表现力、优雅和令人难以置信的高效语言。
我认为大多数讨厌c++的人都是基于使用OO的糟糕经历。c++在面向对象方面做得不是很好，因为多态性通常依赖于堆分配对象，而且c++没有自动垃圾收集。
但c++真正的亮点在于泛型库和函数式编程技术，这使得构建难以置信的大型、高度可维护的系统成为可能。很多人说c++试图做所有事情，但最终什么都做不好。我可能同意它在面向对象方面不如其他语言，但它在泛型编程和函数编程方面比任何其他主流的基于c的语言都要好。(c++ 0x只会进一步强调这一事实。)
我也很欣赏c++如何让我在必要时获得底层，并提供对操作系统的完全访问。
加上RAII。认真对待。当我用其他c语言编程时，我真的很想念析构函数。(不，垃圾回收不会使析构函数无用。)
使软件可配置是一个坏主意。
可配置软件允许最终用户(或管理员等)选择太多的选项，这些选项可能没有一起测试过(或者，如果有超过非常小的数量，我可以保证没有测试过)。
因此，我认为将配置硬编码(但不一定回避常量等)为JUST WORK的软件是一个好主意。使用合理的默认值运行，并且不允许更改它们。
一个很好的例子是谷歌Chrome上的配置选项的数量-然而，这可能仍然太多:)
三元操作符绝对糟糕。他们是懒惰编程的典型代表。
user->isLoggedIn() ? user->update() : user->askLogin();
这太容易搞砸了。修订2的一个小变化:
user->isLoggedIn() && user->isNotNew(time()) ? user->update() : user->askLogin();
哦，是的，只是一个“小改变”。
user->isLoggedIn() && user->isNotNew(time()) ? user->update()
: user->noCredentials() ? user->askSignup
: user->askLogin();
哦，糟了，那另一个案子呢?
user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned() ? user->update()
: user->noCredentials() || !user->isBanned() ? user->askSignup()
: user->askLogin();
不不不不。只需要为我们保存代码更改。别再那么懒了:
if (user->isLoggedIn()) {
user->update()
} else {
user->askLogin();
}
因为如果第一次就做对了，我们就不必一次又一次地改变你的垃圾三元组:
if (user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned()) {
user->update()
} else {
if (user->noCredentials() || !user->isBanned()) {
user->askSignup();
} else {
user->askLogin();
}
}
从长远来看，开源软件的成本更高
对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。
当你考虑到质量的不一致性，可变的可用性和UI/UX，互操作性和标准的困难，增加的配置，相关的培训和支持需求的增加，开源的总拥有成本要比商业产品高得多。
精通技术的程序员类型接受开源的解放并与之一起运行;他们“得到它”，可以采用它，并定制它，以满足他们的目的。另一方面，主要是非技术性的，但需要软件来运行他们的办公室、网络和网站的企业正在冒着痛苦的风险，并在时间损失、生产力和(最终)支持费用方面付出沉重的代价，以及/或一起放弃实验的成本。
显然，IDE应该在浪费时间编译之前检查他们是否可以链接他们创建的代码，这是有争议的
但我的观点是，我不应该编译无数行代码才意识到Windows对我试图创建的文件有一个锁，因为另一个程序员有一些奇怪的线程问题，要求他在dll不应该被使用后延迟卸载3分钟。
Java是我们这一代的COBOL语言。
每个人都要学会编码。在大公司中有运行它的代码，这些公司会试图让它运行几十年。与所有其他选择相比，每个人都开始鄙视它，但无论如何都被迫使用它，因为它可以支付账单。
XML和HTML是web的“汇编语言”。为什么还要黑它?
很明显，现在很少有开发人员学习汇编语言/编写代码，因为它很原始，并且使您远离必须在高层解决的问题。所以我们发明了高级语言来封装这些级别的实体，通过我们可以在更高级别上联系到的语言元素来提高我们的工作效率。就像我们可以用计算机做更多的事情，而不仅仅是它的组成部分主板或CPU。
对于Web，在我看来，开发人员仍然在阅读/编写和破解HTML、CSS、XMl、模式等。
我认为这些语言相当于Web或其基础的“汇编语言”。 我们该结束了吗?当然，当出现问题时，我们有时需要破解它。 但可以肯定的是，这是个例外。 我断言，我们正在用等价的web级汇编语言取代机器级的低级汇编语言。
人脑是开启所有锁的万能钥匙。
世界上没有任何东西能让你的大脑运转得更快。相信我，这不是哲学上的，而是实际的。就意见而言，他们就像下面一样
1)永远不要超出编程语言指定的界限，一个简单的例子就是C和c++中的指针。不要误用它们，因为你可能会得到该死的分割错误。
2)始终遵循编码标准，是的，你读的是正确的，编码标准对你的程序有很大的影响，毕竟你的程序是由机器执行的，但要被其他大脑理解:)
汇编程序没有死
在我的工作(复制保护系统)中，汇编程序是必不可少的，我使用了许多hll复制保护系统，只有汇编程序才能真正地利用隐藏在代码中的所有可能性(如代码突变，低级别的东西)。
此外，许多代码优化只有通过汇编程序才能实现，看看任何视频编解码器的源代码，源代码都是用汇编程序编写的，并优化为使用MMX/SSE/SSE2操作码，许多游戏引擎使用汇编程序优化例程，甚至Windows内核也有SSE优化例程:
NTDLL.RtlMoveMemory
.text:7C902CD8 push ebp
.text:7C902CD9 mov ebp, esp
.text:7C902CDB push esi
.text:7C902CDC push edi
.text:7C902CDD push ebx
.text:7C902CDE mov esi, [ebp+0Ch]
.text:7C902CE1 mov edi, [ebp+8]
.text:7C902CE4 mov ecx, [ebp+10h]
.text:7C902CE7 mov eax, [esi]
.text:7C902CE9 cld
.text:7C902CEA mov edx, ecx
.text:7C902CEC and ecx, 3Fh
.text:7C902CEF shr edx, 6
.text:7C902CF2 jz loc_7C902EF2
.text:7C902CF8 dec edx
.text:7C902CF9 jz loc_7C902E77
.text:7C902CFF prefetchnta byte ptr [esi-80h]
.text:7C902D03 dec edx
.text:7C902D04 jz loc_7C902E03
.text:7C902D0A prefetchnta byte ptr [esi-40h]
.text:7C902D0E dec edx
.text:7C902D0F jz short loc_7C902D8F
.text:7C902D11
.text:7C902D11 loc_7C902D11: ; CODE XREF: .text:7C902D8Dj
.text:7C902D11 prefetchnta byte ptr [esi+100h]
.text:7C902D18 mov eax, [esi]
.text:7C902D1A mov ebx, [esi+4]
.text:7C902D1D movnti [edi], eax
.text:7C902D20 movnti [edi+4], ebx
.text:7C902D24 mov eax, [esi+8]
.text:7C902D27 mov ebx, [esi+0Ch]
.text:7C902D2A movnti [edi+8], eax
.text:7C902D2E movnti [edi+0Ch], ebx
.text:7C902D32 mov eax, [esi+10h]
.text:7C902D35 mov ebx, [esi+14h]
.text:7C902D38 movnti [edi+10h], eax
所以，如果你下次听到汇编器死了，想想你最近看过的电影或玩过的游戏(以及它的复制保护)。
编程既不是艺术也不是科学。这是一门工程学科。
这不是艺术:编程当然需要创造力。这并不能让它成为艺术。代码的设计和编写是为了正常工作，而不是为了情感上的感动。除了空格之外，出于美观原因更改代码会破坏代码。虽然代码可以很漂亮，但艺术不是主要目的。
这不是科学:科学和技术是不可分割的，但编程属于技术范畴。编程不是系统的学习和观察;它是设计和实现。
这是一门工程学科:程序员设计和构建东西。优秀的程序员为功能而设计。他们了解不同实现选项的利弊，并选择适合他们正在解决的问题的实现选项。
我敢肯定有些人喜欢解析文字，将艺术和科学的定义扩展到包括编程，或将工程限制为机械机器或硬件。查字典。此外，“计算机编程艺术”是艺术的另一种用法，指的是一种技能或工艺，如“对话的艺术”。编程的产物不是艺术。
不是真正的编程，但我不能忍受css只布局只是为了它。它会适得其反，令人沮丧，并且使维护成为浮动和页边距的噩梦，因为改变单个元素的位置可能会使整个页面混乱。
这绝对不是一个流行的观点，但我在20分钟内就完成了我的表格布局，而css专家们花了几个小时调整行高、页边距、填充和浮动，只是为了做一些基本的事情，如垂直对齐一个段落。
编写大量的规格说明是徒劳的。 编写正确的程序是相当困难的，但是编译器、调试器、单元测试器、测试器等使检测和消除大多数错误成为可能。另一方面，当你像一个程序(例如，伪代码，UML)那样编写具有相当详细级别的规范时，你主要是靠自己。如果您有一个工具可以帮助您正确地处理语法，那么您应该感到幸运。
广泛的规范很可能充满bug。 编写人员在第一次尝试中得到正确答案的可能性，与一个类似的大型程序在没有经过测试的情况下没有错误的可能性是相同的。同行评审可以消除一些错误，就像代码评审一样。
布尔变量只能用于布尔逻辑。在所有其他情况下，使用枚举。
布尔变量用于存储只能有两个可能值的数据。使用它们所产生的问题经常被忽视:
程序员通常不能正确地识别某些数据何时应该只有两个可能的值 指导程序员做什么的人，比如程序经理或编写程序员遵循的规范的人，通常也不能正确地识别这一点 即使一段数据被正确地识别为只有两种可能的状态，这种保证在将来也可能不成立。
在这些情况下，使用布尔变量会导致令人困惑的代码，这通常可以通过使用枚举来避免。
例子
假设一个程序员正在为一家只销售轿车和卡车的汽车经销商编写软件。程序员为他的软件开发一个全面的业务需求模型。由于知道所销售的车辆只有轿车和卡车两种类型，他正确地识别出可以在Vehicle类中使用一个布尔变量来指示车辆是轿车还是卡车。
class Vehicle {
bool isTruck;
...
}
这个软件是这样写的，当isTruck为真时，车辆是一辆卡车，当isTruck为假时，车辆是一辆汽车。这是在整个代码中执行多次的简单检查。
一切都很顺利，直到有一天，汽车经销商收购了另一家同样销售摩托车的经销商。程序员必须更新软件，使其能够正确地考虑到经销商的业务发生了变化。现在它需要识别车辆是汽车、卡车还是摩托车，这是三种可能的状态。
程序员应该如何实现这一点?isTruck是一个布尔变量，所以它只能保存两种状态。他可以将其从布尔类型更改为允许多种状态的其他类型，但这将破坏现有的逻辑，并且可能无法向后兼容。从程序员的角度来看，最简单的解决方案是添加一个新变量来表示车辆是否是摩托车。
class Vehicle {
bool isTruck;
bool isMotorcycle;
...
}
代码更改后，当isTruck为真时，车辆为卡车，当isMotorcycle为真时，车辆为摩托车，当两者都为假时，车辆为汽车。
问题
这种解决方案存在两个大问题:
The programmer wants to express the type of the vehicle, which is one idea, but the solution uses two variables to do so. Someone unfamiliar with the code will have a harder time understanding the semantics of these variables than if the programmer had used just one variable that specifies the type entirely. Solving this motorcycle problem by adding a new boolean doesn't make it any easier for the programmer to deal with such situations that happen in the future. If the dealership starts selling buses, the programmer will have to repeat all these steps over again by adding yet another boolean.
软件的业务需求发生变化，要求他修改现有代码，这不是开发人员的错。但是首先使用布尔变量使得他的代码不那么灵活，也更难修改以满足未知的未来需求(不那么“适合未来”)。当他以最快的方式实现更改时，代码变得难以阅读。使用布尔变量最终是一个不成熟的优化。
解决方案
首先使用枚举就可以避免这些问题。
enum EVehicleType { Truck, Car }
class Vehicle {
EVehicleType type;
...
}
为了在这种情况下容纳摩托车，程序员所要做的就是将Motorcycle添加到evhicletype中，并添加新的逻辑来处理摩托车的情况。不需要添加新的变量。现有的逻辑不应该被打乱。不熟悉代码的人也很容易理解车辆的类型是如何存储的。
悬崖笔记
不要使用只能存储两种不同状态的类型，除非您绝对确定两种状态总是足够的。如果将来可能需要两个以上的状态，则使用枚举，即使布尔值可以满足现有需求。
Don't be shy, throw an exception. Exceptions are a perfectly valid way to signal failure, and are much clearer than any return-code system. "Exceptional" has nothing to do with how often this can happen, and everything to do with what the class considers normal execution conditions. Throwing an exception when a division by zero occurs is just fine, regardless of how often the case can happen. If the problem is likely, guard your code so that the method doesn't get called with incorrect arguments.
自己编写是一个有效的选择。
根据我的经验，当涉及到使用第三方代码来解决问题时，似乎有太多的热情。人们通常不会想到自己解决问题的办法。不要误解我的意思，我并不是要宣扬永远不要使用库。我的意思是:在您正在考虑使用的可能的框架和模块中，添加自己实现解决方案的选项。
但为什么要编写自己的版本呢?
Don't reinvent the wheel. But, if you only need a piece of wood, do you really need a whole cart wheel? In other words, do you really need openCV to flip an image along an axis? Compromise. You usually have to make compromises concerning your design, in order to be able to use a specific library. Is the amount of changes you have to incorporate worth the functionality you will receive? Learning. You have to learn to use these new frameworks and modules. How long will it take you? Is it worth your while? Will it take longer to learn than to implement? Cost. Not everything is for free. Although, this includes your time. Consider how much time this software you are about to use will save you and if it is worth it's price? (Also remember that you have to invest time to learn it) You are a programmer, not ... a person who just clicks things together (sorry, couldn't think of anything witty).
最后一点是有争议的。
在很多情况下，使用正则表达式解析HTML是可以的
Every time someone posts a question on Stack Overflow asking how to achieve some HTML manuipulation with a regex, the first answer is "Regex is a insufficient tool to parse HTML so don't do it". If the questioner was trying to build a web browser, this would be a helpful answer. However, usually the questioner wants to do some thing like add a rel tag to all the links to a certain domain, usually in a case when certain assumptions can be made about the style of the incoming markup, something that is entiely reasonable to do with a regex.
软件就像厕纸。你花的越少，它就越麻烦。
也就是说，外包很少是一个好主意。
我一直认为这是真的，但直到最近我才真正知道它的程度。我最近一直在“维护”(即“修复”)一些离岸代码，这是一个巨大的混乱。我们公司的成本很容易就超过了内部开发的差额。
企业外部的人对你的业务模式了解较少，因此不会很好地为企业内部的系统编程。此外，他们知道他们不必支持它，所以除了半途而废之外，没有动力去做任何事情。
像SharePoint这样的内部网框架让我觉得整个企业世界是一只把头埋在沙子里的巨大鸵鸟
我在这里不仅仅是在谈论MOSS，我也使用过一些其他的企业内部网产品，绝对没有一个是好的，但是SharePoint (MOSS)是目前为止最差的。
Most of these systems don't easily bridge the gap between Intranet and Internet. So as a remote worker you're forced to VPN in. External customers just don't have the luxury of getting hold of your internal information first hand. Sure this can be fixed at a price $$$. The search capabilities are always pathetic. Lots of time other departments simply don't know about information is out there. Information fragments, people start boycotting workflows or revert to email SharePoint development is the most painful form of development on the planet. Nothing sucks like SharePoint. I've seen a few developers contemplating quitting IT after working for over a year with MOSS. No matter how the developers hate MOSS, no matter how long the most basic of projects take to roll out, no matter how novice the results look, and no matter how unsearchable and fragmented the content is:
每个人仍然在继续使用和购买sharepoint，经理们仍然非常努力地假装它不是撒旦的产物。
微格式
Using CSS classes originally designed for visual layout - now being assigned for both visual and contextual data is a hack, loads of ambiguity. Not saying the functionality should not exist, but fix the damn base language. HTML wasn't hacked to produce XML - instead the XML language emerged. Now we have these eager script kiddies hacking HTML and CSS to do something it wasn't designed to do, thats still fine, but I wish they would keep these things to themselves, and no make a standard out of it. Just to some up - butchery!
关联数组/哈希映射/哈希表(无论它在你最喜欢的语言中叫什么)是自切片面包以来最好的东西!
当然，它们提供了从键到值的快速查找。但它们也使动态构造结构化数据变得容易。在脚本语言中，它通常是表示结构化数据的唯一(至少是最常用的)方法。
恕我直言，它们是许多脚本语言成功的一个非常重要的因素。
甚至在c++中std::map和std::tr1::unordered_map帮助我更快地编写代码。
c++是未来的杀手级语言…
．.． 动态语言。
没有人拥有它，它有越来越多的特性，比如编译时(元)编程或类型推断，没有函数调用开销的回调，不强制单一方法(多范式)。POSIX和ECMAScript正则表达式。多个返回值。你可以有命名参数。等等。
编程的过程非常缓慢。JavaScript花了10年的时间才起步(主要是因为性能)，大多数用它编程的人仍然不理解它(JS中的类?来吧!)我敢说c++将在15-20年后真正开始发光。对我来说，这似乎是c++(语言以及编译器供应商)和当今使用动态语言编写的程序员的适当时间。
c++需要变得对程序员更加友好(编译器错误是由模板或编译时间生成的)，程序员需要意识到静态类型是一个福音(它已经在进行中，参见这里断言用动态类型语言编写的好代码就像编写静态类型语言一样)。
关系数据库系统将是自切片面包以来最好的东西……
．.． 那就是当我们(希望)得到它们的时候。SQL数据库太糟糕了，一点都不好笑。
我觉得有趣的是，认证dba认为SQL数据库系统是关系数据库系统。这说明了上述认证的质量。
困惑吗?读c·j·戴特的书。
edit
为什么叫关系?这个词是什么意思?
如今，拥有强大(哎呀，任何)数学背景的程序员(或认证DBA, wink)是例外，而不是常见情况(我也是常见情况的一个实例)。SQL的表、列和行，以及被称为实体/关系建模的笑话，只是在伤害上加了侮辱。难怪有一种误解，认为关系数据库系统之所以这样叫，是因为实体(表)之间的某些关系(外键?)是如此普遍。
事实上，关系源于关系的数学概念，因此与集合理论和函数密切相关(在数学意义上，而不是任何编程意义上)。
[http://en.wikipedia.org/wiki/Finitary_relation][2]:
In mathematics (more specifically, in set theory and logic), a relation is a property that assigns truth values to combinations (k-tuples) of k individuals. Typically, the property describes a possible connection between the components of a k-tuple. For a given set of k-tuples, a truth value is assigned to each k-tuple according to whether the property does or does not hold. An example of a ternary relation (i.e., between three individuals) is: "X was-introduced-to Y by Z", where (X,Y,Z) is a 3-tuple of persons; for example, "Beatrice Wood was introduced to Henri-Pierre Roché by Marcel Duchamp" is true, while "Karl Marx was introduced to Friedrich Engels by Queen Victoria" is false.
维基百科说得很清楚:在SQL数据库管理系统中，这样的三元关系将是一个“表”，而不是一个“外键”(我冒昧地重命名了关系的“列”:X = who, Y = to, Z = by):
CREATE TABLE introduction (
who INDIVIDUAL NOT NULL
, to INDIVIDUAL NOT NULL
, by INDIVIDUAL NOT NULL
, PRIMARY KEY (who, to, by)
);
此外，它将包含(可能在其他中)这个“row”:
INSERT INTO introduction (
who
, to
, by
) VALUES (
'Beatrice Wood'
, 'Henri-Pierre Roché'
, 'Marcel Duchamp'
);
但不是这个:
INSERT INTO introduction (
who
, to
, by
) VALUES (
'Karl Marx'
, 'Friedrich Engels'
, 'Queen Victoria'
);
关系数据库字典:
relation (mathematics) Given sets s1, s2, ..., sn, not necessarily distinct, r is a relation on those sets if and only if it's a set of n-tuples each of which has its first element from s1, its second element from s2, and so on. (Equivalently, r is a subset of the Cartesian product s1 x s2 x ... x sn.) Set si is the ith domain of r (i = 1, ..., n). Note: There are several important logical differences between relations in mathematics and their relational model counterparts. Here are some of them: Mathematical relations have a left-to-right ordering to their attributes. Actually, mathematical relations have, at best, only a very rudimentary concept of attributes anyway. Certainly their attributes aren't named, other than by their ordinal position. As a consequence, mathematical relations don't really have either a heading or a type in the relational model sense. Mathematical relations are usually either binary or, just occasionally, unary. By contrast, relations in the relational model are of degree n, where n can be any nonnegative integer. Relational operators such as JOIN, EXTEND, and the rest were first defined in the context of the relational model specifically; the mathematical theory of relations includes few such operators. And so on (the foregoing isn't meant to be an exhaustive list).
开发80%是关于设计，20%是关于编码
我认为开发者应该将80%的时间用于设计细节，即他们将要构建的内容，而只有20%的时间用于编写他们所设计的内容。这将产生几乎零错误的代码，并在测试-修复-重新测试周期中节省大量时间。
过早地进入金属(或IDE)就像过早的优化，这被认为是万恶之源。深思熟虑的前期设计(我说的不一定是庞大的设计文档，简单的白板图纸也可以)会比编码和修改产生更好的结果。
80%的bug是在设计阶段引入的。 其余80%是在编码阶段引入的。
(这一观点的灵感来自于Dima Malenko的回答。“开发80%是关于设计，20%是关于编码”，没错。“这将产生几乎零错误的代码”，不。)
Python用一半的开发时间就完成了其他编程语言能做的所有事情……谷歌也是!!如果你不同意，请查看Unladen Swallow。
等等，这是事实。它还能回答这个问题吗?
低驼峰是愚蠢和没有语义的
使用lower camelCase使名称/标识符(从这里开始使用“name”)看起来像两个部分。然而，Upper CamelCase给出了清晰的指示，所有的单词都属于一起。
匈牙利符号是不同的…因为名称的第一部分是类型指示符，所以它与名称的其余部分具有单独的含义。
有些人可能会认为小写的驼峰大小写应该用于函数/过程，特别是在类内部。这在Java和面向对象的PHP中很流行。然而，没有理由这样做来表明它们是类方法，因为通过它们被访问的方式，很明显它们只是类方法。
一些代码示例:
# Java
myobj.objMethod()
# doesn't the dot and parens indicate that objMethod is a method of myobj?
# PHP
$myobj->objMethod()
# doesn't the pointer and parens indicate that objMethod is a method of myobj?
Upper CamelCase对于类名和其他静态名很有用。所有非静态内容都应该通过它们的访问方式来识别，而不是通过它们的名称格式(!)
这是我的同质代码示例，其中名称行为由其他事物表示，而不是它们的名称……(另外，我更喜欢用下划线来分隔名字中的单词)。
# Java
my_obj = new MyObj() # Clearly a class, since it's upper CamelCase
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # Clearly an attribute, since it's referenced
# PHP
$my_obj = new MyObj()
$my_obj->obj_method()
$my_obj->obj_var
MyObj::MyStaticMethod()
# Python
MyObj = MyClass # copies the reference of the class to a new name
my_obj = MyObj() # Clearly a class, being instantiated
my_obj.obj_method() # Clearly a method, since it's executed
my_obj.obj_var # clearly an attribute, since it's referenced
my_obj.obj_method # Also, an attribute, but holding the instance method.
my_method = myobj.obj_method # Instance method
my_method() # Same as myobj.obj_method()
MyClassMethod = MyObj.obj_method # Attribute holding the class method
MyClassMethod(myobj) # Same as myobj.obj_method()
MyClassMethod(MyObj) # Same as calling MyObj.obj_method() as a static classmethod
这就是我对camelCase完全客观的看法。
程序员需要与客户交流
一些程序员认为，他们不需要成为与客户交谈的人。对于你的公司来说，这是一种肯定的方式，可以写出一些绝对出色的东西，没有人知道它是用来做什么的，也没有人知道它是如何被使用的。
你不能指望产品经理和业务分析师做所有的决定。事实上，程序员应该在创建模块或特性的1000个(通常是小的)决策中做出990个，否则产品将永远不会发布!所以确保你的决定是明智的。了解你的客户，与他们一起工作，观察他们使用你的软件。
如果你想写出最好的代码，你希望人们使用它。对你的用户群感兴趣，向那些“愚蠢的傻瓜”学习。别害怕，他们会因此爱上你的。
