Week 2 - Wed. & Thu.

困,写在开头。


Wednesday

也就是昨天,Elian和Jonathan讲了Mockito,他们故意把mock搞得很有悬念,浪费了不少练习时间。对Mock我们比较熟悉了算是,但是还很不深入,比如annotation在Mockito里的用法及其优劣,准备研究研究。

Kai终于开始讲Database相关的东西了,我可能是头一次写Jdbc的代码吧,不过感觉还算亲切;SQL语句写得还是很顺溜,自己很开心。session开始一小时后,终于讲到Hibernate了,的确是头一次看到Hibernate的代码。原来Hibernate采用了object-relational mapping(ORM)的思想,通过annotation将数据库表和表间关系与对象和对象间关系映射了起来,同时对直接访问数据的底层行为进行了包装,这样我们可以通过操纵对象来访问数据库,不需要自己直接操作数据库连接和写DML(Data Management Language)型的SQL语句。不过台下不少人对数据库都不怎么行似乎,甚至有说从没弄过的,所以Kai一开始还想讨论第三范式,可一看根本不行,就从简单的让连起了。我比较有意见的是,关于Hbernate,这个session的主角,Kai只是不停的说,不停地翻代码,最终也没个practice,搞得大家挺困,我最终甚至连Hibernate在自己的程序中怎么搭起来用都没搞清楚,只有自己请教google了。

6点了,就在我要欢呼回去吃晚饭的时候,pecha kucha开始了。其实挺有意思,每个人20页PPT,串起来讲每页20秒不多不少,内容不限。就准备材料和presentation而言,是挺好的锻炼;对中国人又多了两项:说辞和应对问题,只是因为语言。

 

Thursday

上午Jonathan讲springMVC,dear god,幸好胡凯兄曾经给我们科普过关于spring的知识,我在Jonathan导演的现场剧中扮演spring(当然不是春哥,而是程序中的component),我要指挥其他角色的行为,比如初始化singleton的Services和DB,为controller注入dependencies,从dispatcher那把request引导到相应的Controller那去,在处理完请求后tear down创建的对象等等。Spring 3里的annotation很多(虽然我也只是看到old school代码里的spring没这么些东西),感觉annotation越来越受欢迎了,如JUnit 4、Mockito、Hibernate和现在的Spring。

比较遗憾的是课堂上我发现mac上的wireless network挂了,很彻底的,搞得没办法当堂完成tutorials,只能眼巴巴跑去pair看Tom在他那实现。中午吃了饭跑去求助IS那帮人,下午3点时伤愈出院的mac终于被送回来了。

今天和BA一起做Estimation联系,总共有两个,一是BA拿出一堆stories让dev来估计难度,标准是已经设定好难度的几张参照卡;二是假设共9对pair,拿出一部分stories让dev安排进三个Iteration。采用的方式很奇怪,圆桌边6把椅子,只坐5个人,只要有另一个人坐第六把椅子,那就得有个原来坐着的人站起来离开椅子。

我开始对这些事十分不明白,于是去问trainer们。

Elian告诉我椅子相当于token,持有token才能正式讨论,不过她没解释到底token轮转的规则是什么,事实上大家在应该谁站起和谁坐下的问题上确实很混乱。

我对第一次Estimation的依据很不明确,Julie提醒了我两个词:release estimation和iteration estimation。确实,这只是个release estimation,它的目的是让team过一遍所有stories,试图去scope将为这些story花费的effort,只给一个高中低难易度的区分。我原以为我们需要知道些story细节,或者推理stories之间的依赖关系,以此做为依据来断定stories的难易度,但不是这样的,Julie说release estimation时不需要考虑那么许多(那需要考虑什么呢?只是简单比比看?!)。我觉得这些stories都是比较固定functionality的story,对它们的估计其实并不能估算出我们将做出的effort,因为当project开始后客户会基于已完成的情况提出story更改或新的story,JK同意这种看法,他说等项目中间会re-estimate,这样应该能解决问题,于是我更觉得他们现在正在做的这种estimation不需要花太多时间了(他们讨论了1个半小时,在午饭时间,饿的我呀)。

我对第二次Estimation其实也不明白,我觉得这种为几个iteration而做estimation和plan需要考虑三方面的因素:customer values,stories dependencies 和 stable velocity。而他们似乎只是为了9对pair安排不同难易程度的stories到三个iterations里,有什么因素在考虑呢,问Errol,答曰只是试图去估计各个iteration做哪些story比较平衡,不是在为三个iteration里以什么顺序、做哪些stories而plan,好吧,我忍,不知道这些BA凭空想出来的story名字卡有什么好排的。问Elian他们BA怎么编出来的,她说还真有client,原来是Sumeet,Sumeet又哪来的需求呢?事先计划好,再对着BA们照着facebook当例子提出来的。唉,1个小时之后…… 看!外面暴雨好大,哗啦哗啦……

和Kai聊了下周项目的dbdeploy脚本的事,起因是发现项目里写了几十delta SQL脚本了,怎么最初安装时还得手动拷两行脚本去mysql执行以建立数据库?一定是当初脚本没建立在0基础之上,于是问题有了:如果项目做了半个月了,写了50个delta sql脚本文件了,突然发现种最初的相当于setup的工作忘记放进脚本之中,那应该怎么办?显然不能去把50个脚本文件重名个名(文件名都是以递增编号为前缀的,常常是连续的),然后在最开始加上一个“001_*"文件了事儿。Kai的答案是,database migration,我有点好奇,如何呢?和dbdeploy有什么区别呢? 唯一的两点线索来自与formula migration和ROR里的数据库版本控制有个命令带migration,显然第一点没可能(废话),第二点其实是和dbdeploy很类似的但文件内容不同的东西(不是单纯的SQL脚本)。还是求助google大神吧,不过没能立刻找到什么简单明了的,决定研究ROR里的吧。另一个问题是production code如果客户上周的需求是删掉columnA,比如觉得Age对Student这个表没用处了,但这周后悔了,又要加上,那么那些原来的数据找不回来了不说,现在的Student表中Age列还不得不重新填,咋整?他的答案太简单了,我光荣的脸红下:首先不推荐在project online之后删除表的列;如果非要删,那别真删,那是死心眼,做个列的mapping就行了,把不要的列放在mapping之外,对用户就不可见了。不过这个情况还真是少的,哪个客户会轻易对自己的数据开刀呢?

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页