随笔- 219  文章- 79  评论- 724 

  大约在三个月前,也写过一篇这样的文章,最近也在忙一个项目,最近几天有时间,所以就来这里发发牢骚。

  这次要开发两个产品,为期两个月,包括两个APP和三个后台。与上次开发的项目相比,规模要大很多,功能点也要多一些,难度也要大一些。

  我负责的是整个后台的前端、部分后台逻辑、部分API接口逻辑与数据抓取分析。

 

一、雾中前进

  这是我在这个迭代期中最直观的感觉,看不到前进的方向,也看不到离终点还有多远,有一种走一步算一步的赶脚。

  每天都在忙碌,赶进度,但别人问你还剩下多少或者问你大约做了多少的时候,我却答不上来。

  为什么会这样?因为我们在开发的开始阶段没有做项目进度计划,也没有做项目的时间评估。急哄哄的上来就开干,这是我们给自己挖的第一个坑。由于没做这个计划,自然而然的也就低估了这个项目的难度,乐观的以为凭借团队里成员们丰富的开发经验,可以很顺利的完成交付。后面吃进了苦头,经常的加班、返工、修改,陷入了一个恶性循环。

  

 

二、原型的理解

1)仓促的设计:

我们这边产品部门是在原型基本定稿之后,我们才开始开发的,所以需求的变更倒不是很多。不过产品部门的原型设计是在仓促出赶出来的,所以有很多地方写的很模糊,很容易产生歧义。

2)准备不足:

在项目的开始阶段,没认真的看原型,没仔细的分析,后面出那么多问题,只能说自己当初太任性,怪不得产品太复杂。后面在开发的时候,遇到模糊的地方就与产品面对面的讨论,反反复复许多次,其实完全可以在项目伊始,就该注意到这些歧义点。

3)原型大而全:

产品的原型做的是大而全,就是想一下子吃成胖子,他们可不帮你考虑实现难度这些问题。我们没做上面的分析,没有与产品讨价还价,等于默认照单全做,这是我们给自己埋的第二个坑。在接下来的日子里,光实现功能就花了我们很多的精力与时间,做出的产品质量可想而知,肯定是漏洞百出。

4)产品瘦身:

最后在产品发布前不得不瘦身,将能有的功能先上,仓促的发布,非常影响大家的心情,辛辛苦苦做出的东西却被硬生生的砍掉。当初就该与产品据理力争一下,先将核心业务实现出来,然后再围绕这些核心开发出周边的一些可有可无的功能。让我们有充足的时间写出健壮代码,减少返工,少走弯路,稳稳上线,大家开开心心和和气气的,何乐而不为呢。唉.... YY一下啦。

  下图是我听到瘦身时候的感受:

  

 

三、团队的建设

1)全新组建:

我们的团队是重新组建的,成员都是在项目中陆续加入的,十一月初的时候服务器组有4个人,IOS和Android各1人,设计1人。这是刚开始的配置,项目在开始45天后,服务器组10人,IOS有6人,Android有5人,设计有4人,团队发展迅速非常快。

2)磨合期:

大家都是初次合作,就需要一段磨合期,不过项目非常赶,刚进来的人,基本都是给他们介绍一下后,就马上开始,这导致很多潜在问题。例如大家都是各自开发,很多功能其实可以抽象在一起,但每个人都写了一套,也没时间做code review,只能发现一个问题改一个,类似的地方还得复查一遍,以防出现同样的问题。再比如,一开始也没怎么订代码规范,有的成员没在方法的注释中写author,等这个函数出了问题,都不知道该找谁。

3)对产品的理解不同:

成员都是后面陆续进来的,对产品的理解一开始都是模糊的,直接就开发,难免会走岔,返工是经常的事儿,边开发边理解产品就是我们目前的方式了。

4)初次配合:

服务器与客户端之间的配合也是第一次,刚开始由于接口文档没有写具体,导致两边之间出现了些沟通问题,很耗时间,刚开始是举步艰难。古语说的万事开头难,真的很有道理。后面经过各种措施,情况得到好转,成员之间的默契也越来越好。

5)代码从0开始:

刚开始的时候,啥也没有,大部分的工具类代码都没有,都是重新写的,这个也是挺耗时间与精力的。前端的JS脚本和CSS都是重新设计编写,写的代码肯定也不会很健壮。项目开始的时候服务器端只有4个人,我们是先编写后台,所以还得再分出一个人去做前端,人员就更加紧张了。

  

 

四、与产品的沟通

1)认识层面不一样:

一个大问题,开发人员与产品设计的理解总是不在一个频道上面。例如原型上面的一个功能,我们按照对原型的理解开发好了,给产品的看要么不是这样做,要么又漏掉了一些细节。有时候在与产品的人讨论过后,我们在开发后也会出现类似的问题。后面就采取措施,每次讨论就要产品把要修改的地方发邮件出来,有根有据的,出了问题也能找到在哪块做岔了。

2)情绪作怪:

情绪也是个大问题,功能多,时间紧,经常返工,这无形中就给了我们很多压力。有时候在与产品部讨论功能的时候,他们让我改这改那,心中会有种潜在的排斥心理,就是不想配合你,有时甚至会有点怒火,果然还是年轻气盛。经常会听到站在对方角度看问题,就能理解对方,说起来容易,做起来好难。

3)站的角度不同:

产品设计人员不懂开发,经常是要实现一个功能,但对我们开发来说却不会那么简单。原型上面就有很多这种耗时间的功能,托我们开发的进度,在我看来完全可以在迭代的第二期完成,把核心功能做做扎实,把大流程跑通,大家都方便。产品设计的人是完美主义,我们程序开发是现实主义。

4)没做短期交付:

我感觉应该每个礼拜都给产品看个demo展示,如果有业务错误就能马上纠正,不用等到后面再花大力气修复。也能让产品的人知道项目进行到什么程度了,让他们心里有底,让他们能早点做补救措施的决定,别到了后面几天才想到抢救。不过做起来还是挺麻烦的,给他们看代码肯定不行的,他们要看的是能操纵的东西,要有血有肉,开始的阶段没数据没页面,流程也跑不起来。得想办法给他们一个能看的懂的东西。

  开发的过程中,我经常会向下图那样凌乱:

  

 

五、抓数据

  为了丰满页面,需要大量的外部数据,只有通过抓取其他网站的数据才能获得。抓数据这块有很多坑,踩了好多个。刚开始是自己抓,我在上一篇《用PHP抓取页面并分析》写了点分享。后面时间不够,公司就花钱让外面的人抓了,本以为会轻松很多,没想到还是有很多坑。

1)反复抓取:

刚开始产品的说要以XXX网的数据为准,我们就按照指令去那边抓。后面又说以YYY网的为准,那我们就重新把那个网站的数据抓下来。最后告诉我们说,要以他们自己的一套数据为标准,将抓来的数据和那套数据做个映射关系。一下子感觉好坑,但是没有让产品写抓取数据的规范说明,只能自己认栽啦。这样几个来回让我们非常厌恶抓数据了。

2)分析数据:

后面让第三方来抓,为了图简单,我们把给抓数据的人定了数据库表,想到时候就直接倒进来。后面在分析数据的时候,缺了很多字段,这些信息都抓取不到,有些数据还是错误的。这些毛胚数据完全不能用,只能再写脚本纠正,有些需要人工校对,先把数据导出成execl,让产品的人整理,再把整理后的execl给我们开发,我们再编写不同的脚本导入到数据库中。反反复复好多次,脚本也写了一个又一个,为这个操碎了心。

3)条理不清晰:

在还没有跑通正常流程前,就匆匆忙忙的把抓来的数据放到数据库中,直接导致客户端各种问题,不是图片显示不了就是信息没有或者就是直接报错。客户端的APP迟迟不能给产品看,就是因为数据太渣根本没法用。后面将这些数据清掉,走正常流程,从我们的后台录入,录入一些完整的数据,在客户端显示,效果非常明显,客户端的流程顺畅的跑起来了。