为什么无法面向对象
条条道路通罗马，能解决问题的都是好办法。
1. 产品需要满足用户需求。
每天都在用windows、ie、word、firefox等，都很好用，但对用户来讲谁关心后面的代码、架构是什么样子。
生产线上的人每天都在用你写的产品，他们只关心产品是否能准确地完成功能，没有故障，操作是否方便。
有很多人觉得架构不好，代码ugly，所以重写产品，下面几个老链接大家可以看看。
说说: http://blog.joycode.com/demonfox/archive/2007/03/21/98381.aspx
Things You Should Never Do, Part I: http://www.joelonsoftware.com/articles/fog0000000069.html
里面提到NetScape的重写等，甚至微软的word也曾打算过重写，好像是这些文章还是别的什么地方提到过一个ftp代码重写了3、4年才完成。
我们每天面对着一行行代码时，是否能多想想这些代码怎样方便的帮助用户完成想要的工作？它们怎样才能帮助公司实现更多的利润，帮助客户实现更大的价值？新的设计思想的运用、代码中隐藏的每个错误会给项目带来什么影响，会给客户造成什么损失？
这些不仅仅是老板、架构师、项目经理的责任，项目中的每个人应该有比较深刻的认识，才能做出好产品。程序员的职业生涯想要往高处走，哪怕是升为一个高级程序员、架构师，都需要不断的将目光关注在这些方面。所以不要一天到晚只盯着代码看问题，总跟代码过不去。
2. 产品需要满足市场需求，满足市场运作策略。
很多程序员出身的，后来做项目经理了，做销售了，不少已经在做老板了，多了解一下他们面临的问题，他们的想法。也许不久之后你也打算创业做老板了。
没有多少项目能够像暴雪那样，动不动写个6、7年，产品推出来还能保证巨大的市场成功，Vista写了5年已经很长，再写个几年可能要失控。尤其国内这种激烈的竞争环境，慢个半拍人家就已经把它做的很好了。
所以老板有市场压力，项目经理需要承担项目周期与质量压力，需要处理各种技术、未知故障风险。
很多时候老板的要求并不是错的，客户的要求并不是不合理的，只是你没有理解，所以都被你宣判为无理的、搞笑的、不适合产品开发的要求。所以心里开始抵触，不能全面的配合老板、经理实现目标，有时候做出来的东西牛头不对马嘴。最后老板说程序员不可思议，程序员说老板真差，double-lose！
3. 不要盲从。
"不要迷失在技术的海洋中"应当也是这个意思。
看《领域驱动设计》，作者开始就说了这种方法不是万能药，他的不少项目使用这种方法都失败了。看《企业应用架构模式》，作者并不会告诉你你的项目应该用领域模型、事物脚本还是表模块，要根据实际状况选择。最近刚开始看《分析模式》，每一种模式都从简单到复杂讲述，但一开始作者就提出了根据需求具体选择采用简单方式还是复杂模型，正确实现需求的就是好模型，不要盲目的为产品做过多假设。
尽管Martin Fowler和Eric Evans都受敏捷思想的影响，这不是关键，其它书籍也差不多如此。他们提供的只是一种方法、思想，具体环境具体运用，开篇不起眼的一些话，在理解了这些思想之后，这些话才是最重要的。
一个经理如果总能按园子里大家的想法来管理、开发产品，极有可能是一个彻底失败的经理。
4. 产品需要积累。
产品的成熟并不是指代码多漂亮，架构多完美，这些东西只占据比较小的分量。产品成熟更多的是指产品功能、性能、稳定性、用户使用性，以及从业务功能、运营部署要求面看起来一定的灵活、扩展性。
很多时候会听到这种话：这个项目这么简单，真搞不懂他们怎么花了那么长时间；这么简单一件事，想不透为什么写的这么复杂。
仔细看过上面推荐的两个链接，结合自己的经验很容易理解，很多非常ugly的代码中隐藏了不少疑难杂症的修复知识，这是一个方面。
另外一个方面，将需求一步步收集起来，将产品从无到有做起来，能够满足用户要求在生产线上运行起来，不是件容易的事情，这个里面很多困难你想不到，交给你重做一次未必比前人做的好。
很多人在学习设计模式，很多人每天都在不断的重构代码，有没有人实际的去关注过，你做的这些工作，真的给产品、给用户带来了多少好处，实现了多少价值。其实脱离实际需求，程序员拍脑袋想的很多东西，花了很大精力去实现，可能从头到尾就没有发挥过作用，或者作用非常有限。
很多时候你发现自己负责的产品很灵活、功能很强，可是到用户那边，到下一个项目/客户，新的需求非常多，不少时候已有架构无法满足。
比较长一段时间内，要象大家讨论的方式来做项目，象不少程序员心中想象的情景去开发一个产品，是不大可能的。我们只能不断的在项目中做小的修改来积累产品，在适当的时候做一些大的调整来改善产品。
如果从产品最开始就采用大家推崇的各种方法、思想来做一个产品，这个产品成功的概率多大？
不要说小公司才有这种烂做法，没有心胸的经理才会否定这种做法，看看Oracle、MS、HP等，看看印度的软件工厂，难道都是采用大家理想的做法？
保证第一个版本可用，第二个版本好用，第三第四个版本能够通用，不是代码层面，而是功能层面的，相信不少公司产品都是这样的战略。这里不仅有市场策略，也有产品项目迭代开发方式，功能的逐步完善、用户反馈等等其它各方面的考量因素。
最后：
看待问题不要太单纯，面向对象也好非面向对象也好，存储过程也好SQL也好，多探讨交流让大家都加深认识就行了，至于实际环境应该采用什么方式，都不能做定论。
不少程序员、开发团队确实是得过且过，对未掌握的东西不大愿意去了解，因陈守旧，也确实是一个方面，有的是本身上进心不够，有的是生活或其它压力太大，工作的事情只是敷衍。既然是在园子里活跃的，应该大部分不属此列，所以更应该注重的是注意改变自己的视角去分析问题，使自己的技术研究更有针对性方向性，看待问题更全面。
1. 产品需要满足用户需求。
每天都在用windows、ie、word、firefox等，都很好用，但对用户来讲谁关心后面的代码、架构是什么样子。
生产线上的人每天都在用你写的产品，他们只关心产品是否能准确地完成功能，没有故障，操作是否方便。
有很多人觉得架构不好，代码ugly，所以重写产品，下面几个老链接大家可以看看。
说说: http://blog.joycode.com/demonfox/archive/2007/03/21/98381.aspx
Things You Should Never Do, Part I: http://www.joelonsoftware.com/articles/fog0000000069.html
里面提到NetScape的重写等，甚至微软的word也曾打算过重写，好像是这些文章还是别的什么地方提到过一个ftp代码重写了3、4年才完成。
我们每天面对着一行行代码时，是否能多想想这些代码怎样方便的帮助用户完成想要的工作？它们怎样才能帮助公司实现更多的利润，帮助客户实现更大的价值？新的设计思想的运用、代码中隐藏的每个错误会给项目带来什么影响，会给客户造成什么损失？
这些不仅仅是老板、架构师、项目经理的责任，项目中的每个人应该有比较深刻的认识，才能做出好产品。程序员的职业生涯想要往高处走，哪怕是升为一个高级程序员、架构师，都需要不断的将目光关注在这些方面。所以不要一天到晚只盯着代码看问题，总跟代码过不去。
2. 产品需要满足市场需求，满足市场运作策略。
很多程序员出身的，后来做项目经理了，做销售了，不少已经在做老板了，多了解一下他们面临的问题，他们的想法。也许不久之后你也打算创业做老板了。
没有多少项目能够像暴雪那样，动不动写个6、7年，产品推出来还能保证巨大的市场成功，Vista写了5年已经很长，再写个几年可能要失控。尤其国内这种激烈的竞争环境，慢个半拍人家就已经把它做的很好了。
所以老板有市场压力，项目经理需要承担项目周期与质量压力，需要处理各种技术、未知故障风险。
很多时候老板的要求并不是错的，客户的要求并不是不合理的，只是你没有理解，所以都被你宣判为无理的、搞笑的、不适合产品开发的要求。所以心里开始抵触，不能全面的配合老板、经理实现目标，有时候做出来的东西牛头不对马嘴。最后老板说程序员不可思议，程序员说老板真差，double-lose！
3. 不要盲从。
"不要迷失在技术的海洋中"应当也是这个意思。
看《领域驱动设计》，作者开始就说了这种方法不是万能药，他的不少项目使用这种方法都失败了。看《企业应用架构模式》，作者并不会告诉你你的项目应该用领域模型、事物脚本还是表模块，要根据实际状况选择。最近刚开始看《分析模式》，每一种模式都从简单到复杂讲述，但一开始作者就提出了根据需求具体选择采用简单方式还是复杂模型，正确实现需求的就是好模型，不要盲目的为产品做过多假设。
尽管Martin Fowler和Eric Evans都受敏捷思想的影响，这不是关键，其它书籍也差不多如此。他们提供的只是一种方法、思想，具体环境具体运用，开篇不起眼的一些话，在理解了这些思想之后，这些话才是最重要的。
一个经理如果总能按园子里大家的想法来管理、开发产品，极有可能是一个彻底失败的经理。
4. 产品需要积累。
产品的成熟并不是指代码多漂亮，架构多完美，这些东西只占据比较小的分量。产品成熟更多的是指产品功能、性能、稳定性、用户使用性，以及从业务功能、运营部署要求面看起来一定的灵活、扩展性。
很多时候会听到这种话：这个项目这么简单，真搞不懂他们怎么花了那么长时间；这么简单一件事，想不透为什么写的这么复杂。
仔细看过上面推荐的两个链接，结合自己的经验很容易理解，很多非常ugly的代码中隐藏了不少疑难杂症的修复知识，这是一个方面。
另外一个方面，将需求一步步收集起来，将产品从无到有做起来，能够满足用户要求在生产线上运行起来，不是件容易的事情，这个里面很多困难你想不到，交给你重做一次未必比前人做的好。
很多人在学习设计模式，很多人每天都在不断的重构代码，有没有人实际的去关注过，你做的这些工作，真的给产品、给用户带来了多少好处，实现了多少价值。其实脱离实际需求，程序员拍脑袋想的很多东西，花了很大精力去实现，可能从头到尾就没有发挥过作用，或者作用非常有限。
很多时候你发现自己负责的产品很灵活、功能很强，可是到用户那边，到下一个项目/客户，新的需求非常多，不少时候已有架构无法满足。
比较长一段时间内，要象大家讨论的方式来做项目，象不少程序员心中想象的情景去开发一个产品，是不大可能的。我们只能不断的在项目中做小的修改来积累产品，在适当的时候做一些大的调整来改善产品。
如果从产品最开始就采用大家推崇的各种方法、思想来做一个产品，这个产品成功的概率多大？
不要说小公司才有这种烂做法，没有心胸的经理才会否定这种做法，看看Oracle、MS、HP等，看看印度的软件工厂，难道都是采用大家理想的做法？
保证第一个版本可用，第二个版本好用，第三第四个版本能够通用，不是代码层面，而是功能层面的，相信不少公司产品都是这样的战略。这里不仅有市场策略，也有产品项目迭代开发方式，功能的逐步完善、用户反馈等等其它各方面的考量因素。
最后：
看待问题不要太单纯，面向对象也好非面向对象也好，存储过程也好SQL也好，多探讨交流让大家都加深认识就行了，至于实际环境应该采用什么方式，都不能做定论。
不少程序员、开发团队确实是得过且过，对未掌握的东西不大愿意去了解，因陈守旧，也确实是一个方面，有的是本身上进心不够，有的是生活或其它压力太大，工作的事情只是敷衍。既然是在园子里活跃的，应该大部分不属此列，所以更应该注重的是注意改变自己的视角去分析问题，使自己的技术研究更有针对性方向性，看待问题更全面。
