在傳統行業努力着的互聯網人

"到目前爲止整個團隊除了豆瓣流還有北郵的高材生、經驗豐富的老大哥以及幾個深大的小鮮肉。或許有一天我會離開，回到純互聯網公司中，但我希望我能留下一些東西：和小夥伴們一起奮鬥的回憶"，這是我幾個月來很想總結的一句話，也希望自己日後回頭看這篇文章時能激勵自己不斷上進。 

• 兩個不錯的人，一件看着不錯的事 

接到萬科物業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還有餓了麼的架構師這樣的牛人來做分享。到目前爲止整個團隊除了豆瓣流還有北郵的高材生、經驗豐富的老大哥以及幾個深大的小鮮肉。或許有一天我會離開，回到純互聯網公司中，但我希望我能留下一些東西:有我耕耘的一片土地！