条条道路通罗马，能解决问题的都是好办法。
1. 产品需要满足用户需求。
每天都在用windows、ie、word、firefox等，都很好用，但对用户来讲谁关心后面的代码、架构是什么样子。
生产线上的人每天都在用你写的产品，他们只关心产品是否能准确地完成功能，没有故障，操作是否方便。
有很多人觉得架构不好，代码ugly，所以重写产品，下面几个老链接大家可以看看。
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，所以重写产品，下面几个老链接大家可以看看。
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也好，多探讨交流让大家都加深认识就行了，至于实际环境应该采用什么方式，都不能做定论。
不少程序员、开发团队确实是得过且过，对未掌握的东西不大愿意去了解，因陈守旧，也确实是一个方面，有的是本身上进心不够，有的是生活或其它压力太大，工 作的事情只是敷衍。既然是在园子里活跃的，应该大部分不属此列，所以更应该注重的是注意改变自己的视角去分析问题，使自己的技术研究更有针对性方向性，看 待问题更全面。
扫一扫
75万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
