在传统行业努力着的互联网人

"到目前为止整个团队除了豆瓣流还有北邮的高材生、经验丰富的老大哥以及几个深大的小鲜肉。或许有一天我会离开，回到纯互联网公司中，但我希望我能留下一些东西：和小伙伴们一起奋斗的回忆"，这是我几个月来很想总结的一句话，也希望自己日后回头看这篇文章时能激励自己不断上进。 

• 两个不错的人，一件看着不错的事 

接到万科物业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还有饿了么的架构师这样的牛人来做分享。到目前为止整个团队除了豆瓣流还有北邮的高材生、经验丰富的老大哥以及几个深大的小鲜肉。或许有一天我会离开，回到纯互联网公司中，但我希望我能留下一些东西:有我耕耘的一片土地！