一次软件编程技术的探讨之旅

软件研发的轮回

我们现在正在经历软件研发的轮回，一方面我们在维护着越来越糟糕的软件，不断对自己说，下次开发新的软件时，一定要好好设计，规范编码；但另一方面，当我们真的开始一个新的项目时，却举足无措、千头万绪，不知道该怎样去分析与设计，一切只有靠经验，以及那些不可捉摸的灵光一现。最后，当软件经历了几轮需求变更和维护以后，我们被打回了原形，甚至那最后的一块遮羞布都不曾保留。软件重新回到了那种糟糕与难于维护的状态，多么令人沮丧啊。

我们为什么总是在这样的软件轮回中挣扎呢？回答这个问题，我自认为比别人体会更深，因为在过去的十年时间里，我读了更多别人的代码，维护了更多别人开发的系统，可谓是阅人无数。我总是在分析这些设计的问题，优化这些糟糕的系统，使它们越来越易于维护。总体来说，我感到，我们太缺乏对软件设计理论的研究了。

其实我想说，中国的软件之所以总是不能提高，那是因为中国的程序员都在关注那些新技术，海侃那些新概念，海搜那些新框架。试问，有多少人不知道spring、hibernate开源框架？有多少人没有聊过ISO、云计算、BI？还有那些一版一版的JDK，各大公司的新产品发布……然而，我们那些基本的软件设计编程理论却常常被人淡漠，甚至是不屑一顾。在被我面试过的无数人里，很少有人能说得清楚什么是工厂模式（仅有的模糊认识都来源于大学时代的教科书），甚至从来没有写过一个工厂。什么是开放-封闭原则？什么是单一职责？怎样运用建模技术来分析和规划我们的系统？

难怪有网友感慨，开发程序多年，其实就是在拼凑各种开源框架，成了开源框架的组装工人，这就是我们的业态。而所谓的系统架构师，就是特别能搜、特别能拼、特别能侃的那一类人。还有那些刚刚踏出校门的同学们，满腔热情地投身IT洪流中，却被那些新概念搞得头昏脑胀、无所是从。没人告诉他们应该怎样去编程，怎样才能编好程，编写优秀的代码。

这就是软件研发轮回的本质：我们太缺乏对编程理论的关注，关注的没有学明白，想问的却找不到老师。所以，我说，我们大家静心坐下来，进行一次软件编程技术的探讨之旅吧。嗯，我想，就从最基本的面向对象开始吧。

一次软件编程技术的探讨之旅
重新理解一切皆对象
重新审视代码复用

（续）

会java的人千千万，真正理解OOP的却是少数。。。

设计模式那本书好像只有200多页，一个月的时间应该可以看完了吧！（需要多长时间才能熟练呢？）
工厂模式和switch case有什么不同吗，只是返回一个对象而已。
封装private，继承protected，多态abstract。
mvc好像一开始是一个叫smalltalk的语言提出的，现在好像哪里都用。（我不知道spring的mvc，只知道eclipse的contentprovider）。

（环境重要还是知识重要，在说oop的时候，为什么是oop，oop能做什么，然后才是oop是什么吧）
（能出点思考题吗？请别只是罗列知识）

你着嘛急呀，一篇一篇地来，别噎着！

的确啊，想精通一门语言不是那么容易

看来楼主准备分享自己的宝贵经验了，期待，搬板凳

我关心两点，希望楼主在文章中能给出可能的答案，谢谢！
1. 既然下决心下次好好做一个比较完善的项目，为什么还是和以前一样呢？哪些地方出问题了？我感觉不仅仅是软件架构与设计的问题
2. 对于新人来说，看到太多的技术名词简写会选择盲从。如何选择有效的方式来减少过多的弯路呢？我们一直没听过老人教导我们的良言，而不断犯错，同时又期望给年轻人划条正确的路，这个轮回怎样打破？

只要是个程序猿都懂什么是面向对象，甚至能说得头头是道。但真正把面向对象应用到实际工作中却寥寥无几。

究其原因，本人认为有以下因素：
1、没有真正理解面向对象的所要达到的目标；
   设计模式只是达到目标的招式，我们热衷于招式的学习而忽视了要到达目标。  
2、只面向对象，不考虑对象的消费者；
   “面向”是有主体的，缺少主体就不成立。
3、架构；
   目前的J2ee普遍用Service、dao等分层架构，这是没有错，但开发的人没有真正理会应该在Service下提供业务对象来处理各种逻辑。

没有问题，相信文章的推进，可以给你一个满意的答案。按照我的写作计划，我首先从基础理论开始，从我们普遍存在的设计问题着手，一步一步引入设计理论，最终告诉大家应当怎样去分析，怎样去设计我们的软件系统。