第一部分 介绍
不需要花太多知识和技术就能让程序跑起来，中学的小孩一直是这么做的。青少年在大学学习数十亿美元的商业课程，写几行PHP或Ruby代码的爬虫。世界各地工作推荐的初级程序员囤积巨大的需求文件，通过庞大的问题跟踪系统，通过纯粹的意志力量使其系统“能用”。1他们的代码虽然能用但可能并不整洁。说它能用因为只用其中一部分能跑一次就行，这没什么难的。
正确的做法完全是另一回事，获得正确的软件是艰难的。它需要消耗知识和技巧，但多数年轻程序员并没有，它需要思考和洞察，但大多数程序员并没有花时间去开发自身，它需要学术和发稿水平，但大多数程序员从没觉得自己需要。但更多的是，它需要匠心的热情和成为专业者的决心。
当你将获得了正确的软件，一些神奇的事将发生：你不必需要用庞大数量的开发者是软件能用，你不必有庞大的需求文档和庞大的问题跟踪系统。你不必需要工作推荐并且天天编程。
当软件正确地完成了，它只需要部分人力资源去创建和维护。改变将是简单迅速的，缺陷将是少之又少，付出最小，但功能性和灵活性是最大的。
是啊，这愿景听起来像是乌托邦，但我经历过，我见证过，我曾经工作的项目，系统的设计和架构就使得如此简单地开发，如此简单地维护。我经历的那个项目只要部分投入的人力资源。我曾经的系统只有极低的缺陷率。我看见过好的软件架构能对系统，项目和团队产生多么巨大的影响。我一一见证过。
但别轻易接受我的描述。你得亲身实践。你有过相反的经历吗？你写的系统有众多错综复杂的耦合，以致每个改变来到时，无论如何实验，花好几周时间都可能导致巨大的风险吗？你有没有经历错误的代码和烂设计的坑？您所从事的系统设计是否对团队的士气，客户的信任以及管理者的耐心产生了巨大的负面影响？你有没有看到团队，部门，甚至公司因为软件结构太糟糕而灭亡？你去过程序的地狱吗？2
我都有 - 在某种程度上，我们大多数人也有。因为糟糕的软件设计而感到挫败，而不是享受好工作的乐趣。
1. Hoards of junior programmers in cube farms around the world slog through massive requirements documents held in huge issue tracking systems to get their systems to “work” by the sheer brute force of will ↩
2. Have you been to programming hell? ↩