这篇文章是受启发于要求我写一些设计和spec的文档的面试要求。趁这个机会整理整理自己的思路。
什么是软件开发呢，最常见的一种说法是，软件开发是一门艺术。我觉得更现实的讲，软件开发应该是一种生产。跟其他所有的生产一样。要考虑成本和收益。收益这块，跟其他很多外部因素相关，对开发者或者说开发者的管理者来说无法控制，开发者从职业的角度出发更多需要考虑的是成本。这也是我们职业的目标。
软件这种产品的生产，材料本身的损耗也就是电脑，电费，基本属于沉没成本。不会因为咱们任何努力而改变。（也不是完全不能改变，只能是变多。。。。）那么，最大的成本损耗在时间上。一方面，程序员都属于高薪人士（相对，相对）。每一天的损耗都意味着大量的钱打水漂了。另一方面，随着时间的推移，商业价值在降低，风险却在增加。
对软件开发来说，需求实现速度，应该说是很重要的，但是实现速度本身并不是考量的标准单位。作为最大成本考量标准的时间，从对她的消耗来看：除去简单的功能点实现需要，需求的变化浪费的时间则更客观。而无数实例证明，我们在需求分析阶段投入时间诚然可以减少需求的变化，但是并不能达到我们满意的高度，所以对需求变化的反应也是我们的重要标准。
敏捷这个词，我觉得非常好。做为一门方法学，从名字上就说明了软件开发需要关注的两个重要的点：需求实现速度和对于需求的反应速度。当然，说到这里有点虚了。我想，回归到不太实际的本质，能更好的指导我们的实践。Rails框架为什么这么火热，恰恰因为它做到了这两点。我们想想，为什么要设计？我读过让人舒爽的代码，也读过看着让人想吐的代码。抛掉个人的感情因素，这两种代码有什么区别呢？大部分让我想吐的代码里出现的是一些重复的代码，看起来稍有不同，却不肯费点心思除掉这些“坏味道”。重复代码的问题在哪里呢？最大的问题就是随着代码量的增多，工作量的与日剧增。维护量也会增大。而且，复杂度绝对不是O(n)。其实我常常觉得，我们最早学程序的时候要学算法与数据结构。其实这个课程很早就告诉了我们编程最重要的两块：算法，结构。好的设计就是好的结构。可扩展，可维护，最起码，可以分工。
好的设计可以大量的减少代码。减少代码就意味着成本的降低。也就是文初说的，我们职业的目标达到了。但是现实往往不是那么美好，虽然我们有很多OO的设计模式，我们有很多最佳实践。但是在现实中，我们往往需要妥协。一般是三个原因：性能、稳定性、各种接口，在左右着我们。其实，很多时候，这也是最考验一个程序员的功力的地方。如何在这三个沼泽上跳舞，才是软件开发真正可以被称之为艺术的地方。而怎么做，则只能靠一行一行的代码锻炼，一篇一篇文章和文档整理经验，没法一句半句说得清楚的了。