最近一個項目的反思

　　大約在三個月前，也寫過一篇這樣的文章，最近也在忙一個項目，最近幾天有時間，因此就來這裏發發牢騷。

　　此次要開發兩個產品，爲期兩個月，包括兩個APP和三個後臺。與上次開發的項目相比，規模要大不少，功能點也要多一些，難度也要大一些。

　　我負責的是整個後臺的前端、部分後臺邏輯、部分API接口邏輯與數據抓取分析。

 

1、霧中前進

　　這是我在這個迭代期中最直觀的感受，看不到前進的方向，也看不到離終點還有多遠，有一種走一步算一步的趕腳。

　　天天都在忙碌，趕進度，但別人問你還剩下多少或者問你大約作了多少的時候，我卻答不上來。

　　爲何會這樣？由於咱們在開發的開始階段沒有作項目進度計劃，也沒有作項目的時間評估。急哄哄的上來就開幹，這是咱們給本身挖的第一個坑。因爲沒作這個計劃，天然而然的也就低估了這個項目的難度，樂觀的覺得憑藉團隊裏成員們豐富的開發經驗，能夠很順利的完成交付。後面吃進了苦頭，常常的加班、返工、修改，陷入了一個惡性循環。

　　

 

2、原型的理解

1）倉促的設計：

咱們這邊產品部門是在原型基本定稿以後，咱們纔開始開發的，因此需求的變動倒不是不少。不過產品部門的原型設計是在倉促出趕出來的，因此有不少地方寫的很模糊，很容易產生歧義。

2）準備不足：

在項目的開始階段，沒認真的看原型，沒仔細的分析，後面出那麼多問題，只能說本身當初太任性，怪不得產品太複雜。後面在開發的時候，遇到模糊的地方就與產品面對面的討論，反反覆覆許屢次，其實徹底能夠在項目伊始，就該注意到這些歧義點。

3）原型大而全：

產品的原型作的是大而全，就是想一會兒吃成胖子，他們可不幫你考慮實現難度這些問題。咱們沒作上面的分析，沒有與產品討價還價，等於默認照單全作，這是咱們給本身埋的第二個坑。在接下來的日子裏，光實現功能就花了咱們不少的精力與時間，作出的產品質量可想而知，確定是漏洞百出。

4）產品瘦身：

最後在產品發佈前不得不瘦身，將能有的功能先上，倉促的發佈，很是影響你們的心情，辛辛苦苦作出的東西卻被硬生生的砍掉。當初就該與產品力排衆議一下，先將核心業務實現出來，而後再圍繞這些核心開發出周邊的一些無關緊要的功能。讓咱們有充足的時間寫出健壯代碼，減小返工，少走彎路，穩穩上線，你們開開心心和和睦氣的，何樂而不爲呢。唉.... YY一下啦。

　　下圖是我聽到瘦身時候的感覺：

　　

 

3、團隊的建設

1）全新組建：

咱們的團隊是從新組建的，成員都是在項目中陸續加入的，十一月初的時候服務器組有4我的，IOS和Android各1人，設計1人。這是剛開始的配置，項目在開始45天后，服務器組10人，IOS有6人，Android有5人，設計有4人，團隊發展迅速很是快。

2）磨合期：

你們都是初次合做，就須要一段磨合期，不過項目很是趕，剛進來的人，基本都是給他們介紹一下後，就立刻開始，這致使不少潛在問題。例如你們都是各自開發，不少功能其實能夠抽象在一塊兒，但每一個人都寫了一套，也沒時間作code review，只能發現一個問題改一個，相似的地方還得複查一遍，以防出現一樣的問題。再好比，一開始也沒怎麼訂代碼規範，有的成員沒在方法的註釋中寫author，等這個函數出了問題，都不知道該找誰。

3）對產品的理解不一樣：

成員都是後面陸續進來的，對產品的理解一開始都是模糊的，直接就開發，不免會走岔，返工是常常的事兒，邊開發邊理解產品就是咱們目前的方式了。

4）初次配合：

服務器與客戶端之間的配合也是第一次，剛開始因爲接口文檔沒有寫具體，致使兩邊之間出現了些溝通問題，很耗時間，剛開始是舉步艱難。古語說的萬事開頭難，真的頗有道理。後面通過各類措施，狀況獲得好轉，成員之間的默契也愈來愈好。

5）代碼從0開始：

剛開始的時候，啥也沒有，大部分的工具類代碼都沒有，都是從新寫的，這個也是挺耗時間與精力的。前端的JS腳本和CSS都是從新設計編寫，寫的代碼確定也不會很健壯。項目開始的時候服務器端只有4我的，咱們是先編寫後臺，因此還得再分出一我的去作前端，人員就更加緊張了。

　　

 

4、與產品的溝通

1）認識層面不同：

一個大問題，開發人員與產品設計的理解老是不在一個頻道上面。例如原型上面的一個功能，咱們按照對原型的理解開發好了，給產品的看要麼不是這樣作，要麼又漏掉了一些細節。有時候在與產品的人討論事後，咱們在開發後也會出現相似的問題。後面就採起措施，每次討論就要產品把要修改的地方發郵件出來，有根有據的，出了問題也能找到在哪塊作岔了。

2）情緒做怪：

情緒也是個大問題，功能多，時間緊，常常返工，這無形中就給了咱們不少壓力。有時候在與產品部討論功能的時候，他們讓我改這改那，心中會有種潛在的排斥心理，就是不想配合你，有時甚至會有點怒火，果真仍是年輕氣盛。常常會聽到站在對方角度看問題，就能理解對方，提及來容易，作起來好難。

3）站的角度不一樣：

產品設計人員不懂開發，常常是要實現一個功能，但對咱們開發來講卻不會那麼簡單。原型上面就有不少這種耗時間的功能，託咱們開發的進度，在我看來徹底能夠在迭代的第二期完成，把核心功能作作紮實，把大流程跑通，你們都方便。產品設計的人是完美主義，咱們程序開發是現實主義。

4）沒作短時間交付：

我感受應該每一個禮拜都給產品看個demo展現，若是有業務錯誤就能立刻糾正，不用等到後面再花大力氣修復。也能讓產品的人知道項目進行到什麼程度了，讓他們內心有底，讓他們能早點作補救措施的決定，別到了後面幾天纔想到搶救。不過作起來仍是挺麻煩的，給他們看代碼確定不行的，他們要看的是能操縱的東西，要有血有肉，開始的階段沒數據沒頁面，流程也跑不起來。得想辦法給他們一個能看的懂的東西。

　　開發的過程當中，我常常會向下圖那樣凌亂：

　　

 

5、抓數據

　　爲了豐滿頁面，須要大量的外部數據，只有經過抓取其餘網站的數據才能得到。抓數據這塊有不少坑，踩了好多個。剛開始是本身抓，我在上一篇《用PHP抓取頁面並分析》寫了點分享。後面時間不夠，公司就花錢讓外面的人抓了，本覺得會輕鬆不少，沒想到仍是有不少坑。

1）反覆抓取：

剛開始產品的說要以XXX網的數據爲準，咱們就按照指令去那邊抓。後面又說以YYY網的爲準，那咱們就從新把那個網站的數據抓下來。最後告訴咱們說，要以他們本身的一套數據爲標準，將抓來的數據和那套數據作個映射關係。一會兒感受好坑，可是沒有讓產品寫抓取數據的規範說明，只能本身認栽啦。這樣幾個來回讓咱們很是厭惡抓數據了。

2）分析數據：

後面讓第三方來抓，爲了圖簡單，咱們把給抓數據的人定了數據庫表，想到時候就直接倒進來。後面在分析數據的時候，缺了不少字段，這些信息都抓取不到，有些數據仍是錯誤的。這些毛胚數據徹底不能用，只能再寫腳本糾正，有些須要人工校對，先把數據導出成execl，讓產品的人整理，再把整理後的execl給咱們開發，咱們再編寫不一樣的腳本導入到數據庫中。反反覆覆好屢次，腳本也寫了一個又一個，爲這個操碎了心。

3）條理不清晰：

在尚未跑通正常流程前，就匆匆忙忙的把抓來的數據放到數據庫中，直接致使客戶端各類問題，不是圖片顯示不了就是信息沒有或者就是直接報錯。客戶端的APP遲遲不能給產品看，就是由於數據太渣根本無法用。後面將這些數據清掉，走正常流程，從咱們的後臺錄入，錄入一些完整的數據，在客戶端顯示，效果很是明顯，客戶端的流程順暢的跑起來了。

 

 

　　想作好一件事情，絕對須要付出不少精力腦力。前面我提到的不少問題，其實都有不少方法能夠對付它們，或者在它們暴露以前就能夠扼殺在搖籃中。若是有豐富的經驗應該已經一早就能意識到前面有多少坑了。開發經驗頗有用，解決實際問題的能力很重要。之後還得多積累積累，作到臨危不亂，沉着應對，談笑間檣櫓灰飛煙滅。