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

开发团队应该更多地按照技术/架构层而不是业务功能来划分。

我来自一个开发者拥有“从网页到存储过程的一切”的普遍文化。因此，为了在系统/应用程序中实现一个功能，他们将准备数据库表模式，编写存储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).

生成文档良好的代码比生成文档不良的代码花费的时间更少

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.

这就是为什么我能很好地编写文档——不是因为我觉得编写适合展示的漂亮代码是一种崇高的使命，也不是因为我是一个纯粹主义者，而只是因为端到端让我在更短的时间内发布高质量的软件。

如果你知道如何编程，你就不适合在表单上放置按钮

这有足够的争议吗?；）

不管我们多么努力，我们几乎不可能对53岁的Doris产生适当的同情，她必须使用我们的订单输入软件。我们根本无法掌握她想象的计算机内部正在发生的事情的心智模式，因为我们不需要想象:我们知道正在发生什么，或者有一个非常好的想法。

交互设计应该由非程序员来完成。当然，这永远不会发生。相反，我对此很高兴;我喜欢UI设计，尽管内心深处我知道我并不适合它。

欲了解更多信息，请阅读《囚犯们在管理精神病院》这本书。请注意，这本书让我心烦意乱，很无礼;如果你是一个关心用户体验的开发人员，这是一篇很难读懂的文章。

当我声称代码只是我的设计的一种表达时，我经常被人大声叫嚷。我非常不喜欢看到许多开发人员在编写代码时“匆匆忙忙”地设计系统。

当其中一个牛仔从马上摔下来时所浪费的时间和精力是惊人的，而且他们遇到的问题十有八九只要前期设计工作就能解决。

我觉得现代方法没有强调设计在整个软件开发过程中的重要性。例如，当你甚至还没有审查你的设计时，对代码审查的重要性!这是疯狂。

软件开发是一门艺术。