#19 楼 @yedingding 听过的,很受用。是这期:http://teahour.fm/2013/10/21/talking-remote-work-with-allen-wei.html。想远程工作的话必听。
谬论!!!!过程不用呀,包子要擀皮,不放馅,皮大一点厚一点,蒸出来接近面嘎达但也不是馒头。南方人做的馒头小,但是也不擀皮,对吧。。。
啊啊哈哈哈哈哈。。。。解释的好科学。
还能再科学点不?
#17 楼 @yedingding 这是敏捷开发很好的总结。当然不敏捷,又如何,毕竟代码能正确工作,谁还能说它什么呢。
一天,客户说,我们订书的系统,对于 VIP 用户,订购满 30 元免运费。快加上这个功能,我们明天用。
那么技术团队怎么应战????
首先这个需求,PM 必须拆解,比如 1,我们改动那个 model,2,我们改动那个 controller 的那个方法,增加哪个判断,3,这次改动对应的流程有调整,按照 xxx 流程图补充测试,4,我要跟客户确认:如果它买了一个冰箱,再买了 1 本书,还免运费么?
至于代码细节大家也都编程,或许都能想到了,不过像 4 里面的问题,如果在 coding 的时候才发现,再去找客户,恐怕就来不及了。还有,对于一个不了解需求的“新”人或者刚睡醒的“老”人,拿到拆分好的 issue 是很幸福的,完成快,测试人员也不会打回 issue。
要知道在华为,issue 被退回两次是要被调岗或者停职的。。。。。。
#13 楼 @ZombieCoder 我觉得,对于评审的人也是自身学习的过程,协同开发,每个人都要从别人那了解各自的思路,思路太独特,就要用业务流程和设计规范来约束下。 我认为 manager 的很重要的事情就是设计开发思路。约束开发行为。
#8 楼 @raven 我记得 teahour 的采访里讲,他们团队是互相看的,一个人的代码要另外两个人看。但是那些都是形式。
讲讲我的思路: 首先,业务逻辑的 code,需求 ticket 要拆分成技术点,每个技术点如何实现写到 issue 里,这样,写的人和分配到 issue 的人,都清楚要干什么。 然后就是按照技术点去 review 是否符合要求。这个工作很耗时但是从团队协作和质量控制上,这个时间是要投入的。 至于测试,这个可以有专人维护(如果人力够的话,我是建议专人维护的,这样可以保证测试用例的连贯和测试覆盖程度高),如果个人维护,review 先从测试开始,再看代码,方便理解如何实现的。
review 测试我更看重的是逻辑覆盖程度。当然,具体情况具体分析。
如果是 rails view 的改动,因为单元测试意义不大,view 的测试在回归测试时重点检查。
我非常看重 code review 这个环节,可以让团队更行动一致。也可以阻挡一下需求对 code 的直接影响。毕竟太多人的坏习惯是跟着需求做,最后一团乱麻。当然啦,赶工的除外。。。。赶工的东西一定要找时间重构的。
话说 image 加个 100% 没啥意义呀。。。。
image_tag "home_slider/1.jpg", :width => '100%'
= image_tag "1.jpg" 看这里看这里 width:'100%'
木有逗号
@Victor 速来。。。。
近期不想找工作的人纠结死。。。。。。
要是能再午睡一小时就好了。。。。
招远程工作的一定吃香。。。。
这。。。。。。
http://railser.cn/ 能访问了,原来在 master 下放 CNAME 这个文件。。。我之前放到 gh-pages 下,不行滴。。。
用 pages 弄完了,还得再改进一下颜色,这个式样太难受了。。
请在 24 小时内点击此链接以完成注册 点完那个连接说“玩脱了”,页面竟然删除了。。。。。
一个还活着的技术问答社区,好样的。。。。
适应下,再决定。。。。去年应聘的 rails,之后做了一年的 erp,也蛮不错的。
重构(ruby 版),看一次受益一次。
顶一个
#21 楼 @michael_roshen 没几个人啦,呵呵,我会发帖子的,根据天气,看大家是否愿意出来喝咖啡。