我有一些…凡事都有例外，所以这些并不是一成不变的，但它们确实适用于大多数情况

没有人关心您的网站是否经过验证、是否严格遵守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.

编码不是打字

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

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

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

如果我有争议的话，我不得不说乔恩·斯基特并不是万能的。

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.

观点:显式变量声明是一件很棒的事情。

我永远无法理解让开发人员浪费大量时间追踪由变量名输入错误引起的运行时错误，而不是简单地让编译器/解释器捕捉它们的“智慧”。

没有人能给我更好的解释，“好吧，这节省了时间，因为我不需要写'int I;'。”Uhhhhh……是的，当然，但是追踪一个运行时错误需要多少时间呢?

当为数据访问层创建单元测试时，数据应该直接从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。

然而，我相信在许多情况下这应该是一件有效的事情。