大约在三个月前，也写过一篇这样的文章，最近也在忙一个项目，最近几天有时间，所以就来这里发发牢骚。
这次要开发两个产品，为期两个月，包括两个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迟迟不能给产品看，就是因为数据太渣根本没法用。后面将这些数据清掉，走正常流程，从我们的后台录入，录入一些完整的数据，在客户端显示，效果非常明显，客户端的流程顺畅的跑起来了。
想做好一件事情，绝对需要付出很多精力脑力。前面我提到的很多问题，其实都有很多方法可以对付它们，或者在它们暴露之前就可以扼杀在摇篮中。如果有丰富的经验应该已经一早就能意识到前面有多少坑了。开发经验很有用，解决实际问题的能力很重要。以后还得多积累积累，做到临危不乱，沉着应对，谈笑间樯橹灰飞烟灭。
posted on
