邱郁惠老师的<UML和OOAD快速入门>
     我出于瞧瞧架构师,设计师们的门道的目的买了此书.当然这批书单不仅仅只有这本,还有许多其他方面的.

     在平时的项目中,我很难抉择到底该如何下手,虽然数据库建了,但是感觉无根无据,后面肯定要乱七八糟的改,而用例图和流程图很大程度上都没能束缚编码,因为流程图和用例图实在是太大了,而数据库设计只能作为实体类的一个依据,根本无法提供编码依据,所以很多时候都是依靠程序员自己的修为,来决定代码的质量.只有一个人还好,但是超过三个人我就感觉这不像商品而像是艺术品了,多种不同的风格夹杂在项目里,不易维护不说,这样的代码能够正常维护下去都难.所以需要一些东西来帮助我们开发,于是我想到了UML.
     知道了用例图,类图和序列图搭配在一起,就能够很好的指挥代码.用例图给与了响应的场景与不同的参与者,序列图则更一步细化了流程图,详细了代码框架,指出实现的类该是接受哪些参数取得那些结果,包括命名也都一并给出来了.只差一些私有帮助函数没有明确指出.
     这样就有一个好处,给与了基本的大体框架,而且在这三图中,能够想到业务的很细部分,从而三图一并修改,就像三个齿轮,缺一不可.他们是联动的.
     以前拿捏不准到底是该从界面做起,还是从底层数据做起,虽然各有各的道理,但是很容易出现短截的现象,界面做到下面会发现很多重复的东西,从底层做到上面会突然发现忘记了当时约定好的界面需要的某些要素.但是有了这些图的帮助,基本上都能并行开发,因为有了图约束,项目能够很流畅的进行,出现问题的时候也有了查找是哪个环节出错的依据.可以说是设计到编码的沟通桥梁.

     但是缺点是显而易见的,整书只有一个案例,几个场景,我几个钟头的功夫就看完了,大呼不过瘾.不过书名就叫"快速入门",我这确实"快速"了,可感觉UML的门道应该远不止如此,所以这"入门"还是有待商榷.总之不失为一本拓展视野的好书.

         同样的一瓶饮料，便利店里2块钱，五星饭店里60块。很多时候，一个人的价值取决于所在的位置。

    求索是一门艺术，放弃更是一种艺术，在这中间，唯一的目标是找到自己的位置。 

    朋友跟我抱怨，说他不知道现在该怎么办才好，是该坚持下去呢，还是就此放弃，寻一条新路。我知道他在说什么。他放弃了自己以前的工作，费了好多力气进了一家报社，可是每个月他的发稿量少得惊人，奖金很低，现在生活都成了问题，这就是他这段时间以来的处境。 

    我没有跟他绕圈子，我说，你还是放弃吧，有些事情是靠天赋的，不是说光凭后天的汗水就能达到的，我们承认它，不是意味着我们的怯弱，而是说我们比较理智地对待我们自身的局限。 

    我们受到太多的教育和劝导——只要努力就一定会成功，也似乎有许多事例向我们证明，要取得成功，要让自己的人生变得更有价值更值得尊重，就需要更多的汗水。看起来，这真的像是一条颠扑不破的真理，因为没有人能够随便就成功的，要达到目标当然就要作一番努力。可是残酷的现实又告诉我们，取得了成功的人是何其少啊，很多人甚至付出了多倍的努力却依然没有达到自己的目标。当然我们还可以坚持下去，也有好多的理由来催眠，比如说“胜利就在前方了，再坚持一点点，事就成了”。我们总会说自己的努力不够，而从不愿意想想自己合适不合适我们所选择的方向。 

    求索是一门艺术，放弃更是一种艺术，在这中间，唯一的目标是找到自己的位置。 “一个人应该知道自己希望做什么，应该做什么，必须做什么”，要知道自己的界限，知道什么该坚持，知道什么该放弃，知道怎么样更合适自己的特点。于是，我们就不需要做一个成功的人，只需要做一个找准了自己位置的人，成功就成了附属品了。 

    还记得赖斯吗，一个完全的草根，凭借自己的努力成了华盛顿“最有权力的女人”。从一个在种族歧视下长大的黑人到美国现国务卿，没有人否认她的努力，可是我们是否更应该看到她在16岁那年所作的决定呢？她小时候想成为钢琴家，她钢琴的确也弹得不错。16岁那年她进入丹佛大学音乐学院学习钢琴，梦想成为职业钢琴家。但是，在著名的阿斯本音乐节上，她受了打击。“我碰到了一些11岁的孩子们，他们只看一眼就能演奏那些我要练一年才能弹好的曲子，”她说，“我想我不可能有在卡内基大厅演奏的那一天了。”于是她重新设计自己的未来，所幸她找到了自己的新目标，她投身于国际政治中，经过一番努力取得了今天的成就。 

    美国国务卿与钢琴家相比，哪个更有价值些，似乎没有绝对的可比性，可是对赖斯来说，成为美国国务卿与成为钢琴家，哪个更有可能性些，这个就很容易判断了。哪个更适合她成功的道路，哪个就是她赖斯的位置。 

    找准自己的位置，不要以为这很容易。现在的好位置不代表正确的位置，“认识你自己”从来都是难的。只有坚持认清自己，找到一个最适合自己发展的位置，像螺丝钉一样深入下去，才能取得最后成功。

     这本该是半年以前该做的事了.

     这个项目前前后后折腾了近半年.在项目开始的时候,我在弄一个比赛,在那比赛的时候挺2的,没能夺魁.回来后项目也进行了近一个月.可丝毫没有进展的样子.还只是模模糊糊的画出了数据库设计.
     项目分为三组,开始定好每组五人,结果因为童鞋们兴趣挺浓,就每组多了一人.整整十八个人,花了半年时间,就折腾出这么个东西,也只想到欲哭无泪这个词儿来形容了.
     项目一开始我也是满心欢喜的参加,由于参加比赛的原因,不能一开始带领大家,于是组长的位置放给了另外一名童鞋.比赛结束之后,因为我个人的一些主张,以及从事风格和他大相径庭,最后是不欢而散,他退出了.他也是一个学习成绩不错的孩子,只可惜还停留在填鸭式的教学上去学习编程.每天完成老师布置的任务,几道哄小孩的题上面,然后看电影,玩游戏荒废光阴.这是题外话了.总之各组之内也出现了人员的调整,这一个小调整就为后面项目的进行造成了不小的阻力.

     项目的进度,十月份开始项目,我十一月过半比完赛参加,中间断断续续的,因为都是鼓捣.Net的,而需求方要求使用J2EE,然后是一些框架的堆砌,Struts2+Hibernate3,这里没有用到Spring,需求方也没提,可能是出于降低项目难度的原因吧,因为依赖倒置之类的抽象理念对于为什么还要使用类都没琢磨透的童鞋们老说是有那么一点儿不可及.十一月十二月做需求,放寒假的时候还额外留了童鞋们半个多月,半个月前项目都没出来,半个月后都已经定型了,可以说主要的进度都是在这半个月里面出来的.之后来年三月四月修补BUG,最后交稿.

     项目中的问题:
     1.环境问题,说实话,我现在在Eclipse(MyEclipse)下写代码还是有那么些力不从心,各式各样的插件,遍布到处的报错,让人纠结的代码提示(是的,我是被VS惯坏了的孩子),奇怪的调试方式.种种种种的不适.首先是要去找各式各样的插件,而且这些插件由于是开源社区在维护,质量参差不齐,而且由于是在Windows环境下,表现得很是蛋疼.比如说Eclipse下的SVN插件,我已经忘记他的名字了,但是永远都忘不了新接触他的那几天,也让我见识了Xunix下的百家齐放,这个插件可能需要依赖那个插件,而那个插件可能也需要依赖那个.如此往复.版本控制在那时是块心病,就怕哪次更新代码之后错误不断,又要重新来过.不过在几次失败的提交之后导致项目重建,大家都学乖了,要先更新,再提交.这也是一个沟通问题,这点稍后再讲.
     2.态度问题.在项目结束的时候,还有童鞋对HTTP上的交互搞得云里雾里,还对于Session望而生畏.这些在某些培训机构几乎是只教其形而根本不教其意的东西,在他们来说会其形都有困难.打个小差,我在组中也过足了当老师的瘾,因为可以将自己当了十五年学生的经验反馈在我的教学上,好不过瘾,以前看不惯老师的某些手段,在我这里就得意充分更正.对于Session这些我通常是从HTTP无状态的这个设计着手,然后切开,继续深入,最后到为什么需要Session这个东西,在浏览器差异中也从当年的浏览器大战着手,讲的我自己都炮沫横飞,不过却过足了老师的瘾,要是老师们都能有我这样饱汉深情的讲下去何愁朽木不可雕呢?不过后面想想也是,一个老师通常要带两个甚至三个班,教育产业化,将一个东西讲重复一遍两边有可能三遍,而且一年一个循环,谁能受得了,也只有那些园丁们了.这个差有点远了,我们言归正传.在项目中,有很多自以为是的问题,这也许就是程序员们的根病吧.但是倘若没有了这股干劲,又怎样才能从无中生有,作出一个几万行的软件呢?在项目进行时,用了一些管理手段,比如一天一结,然后又是展望,当然计划无限好(其实还有很多其他模仿着大牛们的例子,但都难以奏效,往往是东施效颦,落得个吃饱了没事干的评价),只是领导有些小.这些规定对于童鞋们很难有实施的机会,往往他说好了今天完成的任务,其中有些自身无法估计问题大小的原因,还有确实编码能力不够的原因(我已经把模版代码写好了,这下您也懂了,他们是如何"编码"了的吧),可是一周之后可能问题依然没进展,最流行的词儿是"基本上没问题了","快可以了","只差几个小模块(小函数)就可以了".唉,我觉得这都能让爱吹的南郭先生笑掉大牙了.
    3.项目起因问题,因为这是一个教学案例项目,这个项目的根本目的不是在于项目是否能成,而且项目本身也只是用于申报国家们的一些"计划",项目只是让童鞋们学习的,我这里就有些急功近利了,老是觉得自己不该为这样的项目编码那么多,说到底是个心里问题,不过念到自己又通过这个项目掌握了这么多,也不好说些什么,只能是说鱼与熊掌不可兼得吧,可我总觉得如果我把半年时间花在其他的地方上面可能就不是如今这样的了,话说回来谁又没有个"要是当年"呢.项目没有一个好的老师指导,整个进度也就凭我们几个说话没份量的童鞋约束.总而言之,言而总之.这就是一出没谱的戏儿,拿来给戏子们作秀的试验品.
    4.贪大喜新.这是我们这组的问题,在前端页面上先独自用上了ExtJS.虽然使用的时候坎坎坷坷,但的出来的效果却是大受好评,而且引得另一组前来学习,不过因为框架学习难度的原因,导致基本上就我们组两个人会用,其他童鞋只能干看着,话说项目开始的时候还是ExtJS3.0,到结束的时候发现更新到了3.1了,直接换框架发现不行,不能兼容,尝试新东西总是要付出代价的.使用ExtJS作为后端表现后,唯独第三组(我们是一组,二组后来也换这个框架了,因为界面问题,始终让人头疼)不愿意更改原来的代码,这里又有一个沟通问题,待会再说.所以导致界面风格迥异,在我们这组的时候可能是标准的ExtJS组件,一旦跳转到三组的页面时,可能就是朴素的HTML了.
    5.沟通问题.这也是最根本的问题,如果说依靠我们几个组能写代码的人,加上近半年的时间,而且项目也不是很大,如果沟通良好的话,绝对不是问题.一组擅长前台脚本,二组擅长文档,三组擅长后端编码.这不是配好了的三个桩么.可惜事与愿违.在前面定数据库的时候,我们都能为一个字段的存在与否争个面红耳赤,在后来为了一个接口的问题还差点儿罢了工,只能说年轻气盛,没地方发泄啊.互相也是彼此看不起彼此,觉得自己的观点和主见才是正确的.我记得最好笑的是,三组的童鞋把一些验证,以及数据之间关系的绑定都写在了一个Action里,我就指出这有悖分层,表现的逻辑都没分开,实体数据如果不是Hibernate帮忙分离下场可能是JDBC直接写到了Action中.三组的童鞋却一口咬定"这是面向领域编程,和面向对象编程不同".我当时不懂什么叫"面向领域",我就说"我不懂什么叫领域,但总不该把这些基本的操作写到页面上去吧."他却一口咬定.我只能作罢.要是如今碰到,肯定骂他个狗血淋头,"领域你妹啊,那只是一个开发模式,你妹的都把这些八杆子打不着一起的对象写在一起,以后改死你丫的.做三十年代码工人,而且次次项目都重头来过没沉淀.".唉,年轻气盛.

    故事的最后,项目流产了,需求方发现同时操作的项目太多,无暇兼顾,所以就没了下文,我手抖着把项目用QQ邮箱发过去的时候,确实是勾了"回信短信通知"的.可能是没通知到吧.哎哟喔.....