"到目前为止整个团队除了豆瓣流还有北邮的高材生、经验丰富的老大哥以及几个深大的小鲜肉。或许有一天我会离开,回到纯互联网公司中,但我希望我能留下一些东西:和小伙伴们一起奋斗的回忆",这是我几个月来很想总结的一句话,也希望自己日后回头看这篇文章时能激励自己不断上进。
- 两个不错的人,一件看着不错的事
接到万科物业hr的电话,有些错觉。物业公司要做App?hr说公司要做社区o2o,基于万科业主资源的优势,所以万科做这件事有很大的优势,一件看着不错的事。于是我抱着“去看看吧”的心态去面试了。 面试一切都是很常规的流程没有笔试,这比我想象中的好,没想到传统企业的面试还挺务实的,坐下来就聊聊。 技术总监:网易、豆瓣经历,牛逼的全栈工程师,年轻,有情怀,聊着感觉不错,气场对应。 团队负责人:十年互联网老将,豆瓣产品,原来他们是一伙的。他的面谈方式相当的free style,面试过程感觉不错。
他们对我还是挺认可的,后续的电话沟通中也希望我能考虑下,希望能一起“大干一场”。经过几轮的纠结(当时手头有其他offer,猎头推荐的,好几次差点被猎头说服了),最终选择了“大干一场”。
- 百废待兴
“劣币驱逐良币就是牛逼的人觉得和混日子人一起没有未来,然后走了;混日子的人发现没有牛逼的人去攻关扛着自己也没法混,然后也走了…”。这是我们负责人很久以前朋友圈发的一条感叹。 刚进前两个星期,相当压抑,团队气氛很消极,而我刚好深陷重灾地带。进去第一个星期开始熟悉产品业务,首先下载代码,当初版本控制还是使用的svn。然后慢慢的开始发现了很多问题,代码的问题入的问题,总结为历史的问题。
- 一、没有历史的项目。
进去没几天,我想知道我们的app上过哪些渠道,然后找产品问,产品貌似不知道渠道包时啥意思,然后问了项目组所有的人,没有一个能说清楚的;我想知道历史发过哪些版本,每个版本是否做记录,我找之前的两位Android工程师问,他们就开始翻svn的提交日志,版本没打打tag的么?
- 二、工程师的技术水平和态度让产品降低了标准
一次我发现《助这儿》首页的“消息”小红点显示的未读条是和实际未读条数不对,经过调试,log后端返回的数据,发现后端数据的问题,我去找后端开发工程师,他的回答让我很惊讶:“在我看来这不是bug”,我问他为什么,他说一直的这样啊,我当时很绝望,我错了么?这让我对这位开着轿车来万科物业上了三年班的工程师“另眼相看”,我相信产品经理也是多么的无奈。后来这位哥们也和我们的技术经理撕过几次,原因是后来我们使用GitHub托管代码,review代码比较严格,估计技术总监看了他的代码然后叫他如何如何改正,哥们受不了了,觉得技术总监老是针对他。
- 三、胡乱堆叠的结构而后不断沉沦与堕落的代码
每天都能碰到奇葩代码,经常会听到“尼玛,这TM谁写的代码?”这样的吐槽,开始觉得这样不好,会传递一些负能量,但是从另一个角度讲这未必是坏事,我们在吐槽别人的代码的时候同时也反思到,将来别人会不会吐槽我们的代码?这就使得我们格外的注意自己的代码设计,因为我们深深知道渣代码给后来人带来的痛苦和恶心。 关于代码的黑历史真是太多了,知乎上有篇文章叫做《你见过的最想笑的,最奇葩的,最逗逼的代码是什么?》,看了很多人的答案,我好想说,我都遇到了,太多了,这里仅仅截取两个来看看吧。 这就是一位4年工作经验的工程师写出来的代码,还不让改,这让强迫症的我们很是痛苦。谁都写过奇葩代码,这些不可怕,最可怕的是,抱残守缺,不愿意接受改变,不愿意接受优秀思维方法或者工具。这位哥们,让我很伤感。某一天我又看到一段他关于连接服务器l正式环境和测试环境url的代码:
//public static final String BASE_URL = "http://xxx.vanke.com/"; public static final String BASE_URL = "http://aaa.vanke.com/";
你能看懂哪个是正式环境那个事测试环境么?只有他看得懂,或许过一段时间以后他自己回头看也不知道了。我问他为啥要这样写?他给我演示了注释快捷键,然后振振有词说:这样注释很方便。怪不得在他写的很多代码里我看到了成片成片的方法被注释的痕迹。 不到一个星期,我开始怀疑我是不是做了一个错误的选择?很是纠结,又想起了那句:“劣币驱逐良币就是牛逼的人觉得和混日子人一起没有未来,然后走了;混日子的人发现没有牛逼的人去攻关扛着自己也没法混,然后也走了…”,虽然我也不是太优秀的人,但至少我一直在追求进步,下了这么大的决心来这就是希望能能把这事儿做成,这样的情况能做好吗?做为一个互联网团队不该是这样的,看到不好的代码我有努力去改变,但是我去很难去改变一个人的思维习惯,既然选择了就再努力一下吧。好吧,看到问题我会告诉你,你不改我改过来,这摊事儿你搞不定我来搞,事实证明后来产品和设计师都喜欢来找我,然后“混日子”的人被架空了(万科有钱愿意养闲人就养着吧,我目的很明确,来这就是希望能把这事做好,你可以不参与,但别碍着我),再后来被“架空的”人走了,这是早晚的结局。后来和技术总监交流过,毕竟我们要干实事,需要有正向输出的人,和人品道德无关,和思维方式及做事的习惯有关,我们没能力也没这么多精力说教,不合适的,离开对双方都有好处。
- 四、各种老it系统高度依赖混陷焦油坑
也许这是很多传统公司都有的问题,系统老、旧,各种数据逻辑耦合。关于老、旧最典型的例子就是在家开vpn还IE only(只能通过IE浏览器使用),这让在家处理问题的哥们情何以堪?然后就是就是各种系统的交织混乱。比如我门App后端是A,A里面的大部分数据和逻辑分散在老系统B和C中(实际还有D、E、F…),而B、C分别在很久很久以前由不同的外包公司开发的,然后A又是由不同的外包公司完成的,一锤子买卖之后又经历了一批平庸的团队,在填一个坑的同时又不知不觉的创造了两个坑。最后我们来了,慢慢的看到了千疮百孔系统,我们多么希望原本就没有A,甚至没有B和C,重铸高塔远比在摇摇欲坠的高塔上建筑顺手得多。
或许是因为早期对技术的无知或不重视,万科物业正在痛苦的偿还着巨额技术债,甚至在将在短时期内无法摆脱这个困扰。好在高层拥抱互联网的态度越来越坚决,对技术的态度越来越重视。
- 革命
开发工具
人和动物的区分是看会不会使用工具,是工具触发了猿人的思考,最终进化成了现在聪明的人类。虽然现在我们更强调的是思维上的超越,但是在有些阶段我们还是要借助先进的工具来改变我们的思维习惯。
团队沟通工具:BearyChat。在之前是用邮件沟通的,很难想象在互联网开发这样的高效协作需求下是怎么沟通的。
团队任务管理工具:Trello。可以创建白板,白板上创建任务card,并能和BearyChat互通。
代码托管及版本控制:GitHub。这个是我的最爱,程序员的书脸,同样能互通BearyChat,最重要的是有了它我们才能更好的做代码review,控制代码质量增加工程师自己的讨论氛围。
apk托管工具:fir.im。非常喜欢这类轻工具,编译、上传、更新、通知到BearyChat,一键打通任督二脉,再也不用担心测试、产品人员拿着手机来喊你打包了。
AndroidStudio:估计很多团队还在用Eclipse,但就做Android开发来说AndroidStudio已经在各方已经远远超越Eclipse了。 最后站在客户端开发的角度总结一张工具协作图:
代码review流程。
使用GitHub协作管理,程序员要提交自己负责的代码之前,其他相关合作人员要review他的代码,发现问题会发起讨论,觉得代码不够好就要继续优化,直到大家都觉得ok为止。这个不是很复杂的一件事儿,但是相信很多团队都没有认真做好这个,因为我之前经历过的公司就很少有这个习惯,但是就程序员的提高上来说这个太有必要了,有这个流程之后写代码的人才会觉得不是一个人在写,项目再忙也不能仅止于功能的实现,代码是要给别人看的,才会有意识去写高质量的代码。看了很多代码,我发现高质量的代码是渣代码之间的差别其实相当小,究其缘由就是细微的思维意识差别,所以代码review重在改变程序员写代码时候的意识,当这种强迫的意思变成一种习惯时,也许这个程序员在开始产生质的变化了。
- 挣扎中的收获
三个月过去了,总算为停滞了六个月的项目带来一点起色。两个App分别在网络流量、内存、流畅度上都得到了一定的优化,《助这儿》搁置了几个月的报事、抢单功能总算有了样子,《住这儿》管家功能也提上了日程。 最重要的是团队氛围已经慢慢行程,工程师技术讨论环境完全得益以GitHub的使用和代码review的流程。由于豆瓣流的关系,时不时还能请来极光推送的CTO还有饿了么的架构师这样的牛人来做分享。到目前为止整个团队除了豆瓣流还有北邮的高材生、经验丰富的老大哥以及几个深大的小鲜肉。或许有一天我会离开,回到纯互联网公司中,但我希望我能留下一些东西:有我耕耘的一片土地!