大約在三個月前，也寫過一篇[這樣的文章](http://www.cnblogs.com/strick/p/3946475.html)，最近也在忙一個項目，最近幾天有時間，所以就來這里發發牢騷。   這次要開發兩個產品，為期兩個月，包括兩個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抓取頁面并分析》](http://www.cnblogs.com/strick/p/4055283.html)寫了點分享。后面時間不夠，公司就花錢讓外面的人抓了，本以為會輕松很多，沒想到還是有很多坑。 **1）反復抓取**   剛開始產品的說要以XXX網的數據為準，我們就按照指令去那邊抓。后面又說以YYY網的為準，那我們就重新把那個網站的數據抓下來。最后告訴我們說，要以他們自己的一套數據為標準，將抓來的數據和那套數據做個映射關系。一下子感覺好坑，但是沒有讓產品寫抓取數據的規范說明，只能自己認栽啦。這樣幾個來回讓我們非常厭惡抓數據了。 **2）分析數據**   后面讓第三方來抓，為了圖簡單，我們把給抓數據的人定了數據庫表，想到時候就直接倒進來。后面在分析數據的時候，缺了很多字段，這些信息都抓取不到，有些數據還是錯誤的。這些毛胚數據完全不能用，只能再寫腳本糾正，有些需要人工校對，先把數據導出成execl，讓產品的人整理，再把整理后的execl給我們開發，我們再編寫不同的腳本導入到數據庫中。反反復復好多次，腳本也寫了一個又一個，為這個操碎了心。 **3）條理不清晰**   在還沒有跑通正常流程前，就匆匆忙忙的把抓來的數據放到數據庫中，直接導致客戶端各種問題，不是圖片顯示不了就是信息沒有或者就是直接報錯。客戶端的APP遲遲不能給產品看，就是因為數據太渣根本沒法用。后面將這些數據清掉，走正常流程，從我們的后臺錄入，錄入一些完整的數據，在客戶端顯示，效果非常明顯，客戶端的流程順暢的跑起來了。 :-:    想做好一件事情，絕對需要付出很多精力腦力。前面我提到的很多問題，其實都有很多方法可以對付它們，或者在它們暴露之前就可以扼殺在搖籃中。如果有豐富的經驗應該已經一早就能意識到前面有多少坑了。開發經驗很有用，解決實際問題的能力很重要。以后還得多積累積累，做到臨危不亂，沉著應對，談笑間檣櫓灰飛煙滅。 ***** > 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。