7月13日到上海,16日开始上班,到现在将近两个月了,感觉还是挺充实的,甚至有点累,可能是我给自己加了太多的任务,定下太高的目标,真的好累,我决定要好好休息一段时间,顺便把个人主页更新一下,否则chinaren就要把我踢出去了.

其实今年以来一直没怎么写代码，也就是上半年3月-4月之间写过一段时间，东西都忘得差不多了。基础不牢的后果很快体现出来，以前图方便一般用的是MFC，好多Windows的特性都是一知半解甚至一点都不清楚，上个月开始重新用VC++的时候真有点一筹莫展的感觉，代码改来改去，总是不理想或存在bug，那个时候我很想去买一本houjie写的《MFC深入浅出》彻底学学MFC的，后来一想算了，MFC即使还没有到灭亡的时候，我现在也对WINDOWS环境下的编程深恶痛绝，我渴望能在一个非常自由的环境下做一些贴近底层的、有挑战性的工作，而不仅仅是懂得搭积木式的coding，于是我打消了买书的念头，老老实实的捧着《Thinking in C++》看了起来。

前不久认识了一位在公司工作了三年的朋友，他也是一位coding好手，有一次和他讨论软件内部各个模块如何组织的问题，收获挺大的。

先说我的看法吧，今年初我开始持一种在软件开发中采用类似于MS DNA结构开发模式的观点，把软件内部的各个模块分为表现层，逻辑层，数据层（注意：我说的只是一个软件内部各个C＋＋类的组织形式，而不是一个大型系统方案的结构，大型系统方案当然都会采用三层结构），这是当时我看三星的基站网管软件文档忽然得来的一个想法。那时候我挺激动的，想着自己经历了一年多的coding生活，总算由量变到达质变，我先是在水木清华软件工程版或者是VISUAL C++版或者是Programming版上抛出这个论点，马上有网友响应我这个观点，后来好像还收进了精华区（hehe，记不清了，找不到不要骂我哦），然后我开始动手把去年底在教研室做的一个GPS-GSM车载终端监控软件按照这个思路重写一遍，把所有的逻辑处理从各种各样的View/Wnd/FrameWnd里抽离出来，形成写成一个个专用于逻辑处理的类，与文件存储有关的则被我归结到数据层上去，与用户界面有关的当然就是表现层了，这样一来，整个软件结构显得清晰很多，代码易读很多。

写完那个软件之后，我对这个想法愈加深信，我开始全面的在自己的软件开发中通盘考虑这种做法，甚至有些过了头走向极端。有一段时间，我无论拿到什么样的project都要从三层上来考虑，A层负责与用户交互，B层负责逻辑处理，C层负责数据存储，几个逻辑模块B1，B2，B3之间还存在一个通信队列，B1负责写队列，B2负责读队列......一开始我就把一个小软件的框架设计得非常庞大吓人，到了动手开始写代码后，我发现自己渐渐无法控制代码了，尽管开始我认为自己的软件结构定的很好了，但还是有很多意想不到的事情，一方面是实际情况很复杂，并不是我设计那么几个表现层、逻辑层、数据层所能解决的；另一方面是过于追求模式，什么样的东西都往三层上套，一个很小的功能，一个类就能解决的，我很硬性的分为两/三层结构，用了好几个类，尽管每个类只有一两个函数，而且这几个类之间的功能并不象所谓的三层那样区别非常明显......我热衷于模式设计，却陷入了形式主义。

有天晚上，我把自己的这个想法和那位同事交流了一下，他和我的想法差别较大，在软件内部模块组织上，他不象我那样非要以某种模式来组织软件，他并不看重软件内部模块划分的是否鲜明，他只是讲究某个类所实现的功能具备好的内聚性和耦合性，比如一个属性表，要是以我的想法，必定是一个专管逻辑处理的类，负责判断用户设置了那些属性，把这些属性存储到那个设置文件中，然后再把结果返回到表现层以反馈给用户；而我的同事的想法非常直接，就是一个类，既用于界面表现又用于逻辑处理，他认为这个类的最小功能单位就是这个，没必要再分了。又比如我写了一个显示实时曲线的模块，需要把它给别的用户用，我的第一想法就是只给用户一个逻辑接口，负责计算坐标，添加实时数据，然后用户要通过这个接口去绘图，不再另外给用户与表现层的接口绘图，我的理由是接口功能统一便于编程。我的同事对此表示不解，他认为，这个功能模块就是一个实时曲线窗口，让用户直接从这个窗口类派生出自己的类，用户想干什么就干什么，这样更好。

我开始有点赞同他的想法了，我觉得自己的问题在于有时把软件划分的过于复杂，软件设计的目的之一在于划分好清晰的功能模块，而我却为了所谓的模式把功能分得过细，七零八落的，我们开发的目的是实现软件的功能而不是为了设计模式。不过话又说回来，我觉得这可能是另一方面的原因，并不一定是自己追求设计模式的错，再过一段时间，一年或者两年，再回过头看看，也许认为这种做法是对的，这种模式是对的，只不过自己在编码经验上不足。我一直认为，一个成功的软件就是应该在设计阶段严谨、规范、全面，框架定的大，正表明考虑周到，目前遇到这么多的问题只是因为经验有限，或者说这是必然的，我想经验再丰富的编码人员也不可能面面俱到。