淺談前端業務開發中的經驗與感想

從事前端開發轉眼已有三個半年頭，我的技術能力提高的同時，業務經驗也逐漸豐富。
回想初入職場，剛拿到設計稿時一臉忐忑，預估排期也不知定多少合適。以爲產品設計的不合理，找產品經理 PK，卻被簡單說服，結果仍是栽倒了坑裏。
隨着一個個項目的開發、上線、總結，曾經摔過的坑，化爲了本身避坑的方式（雖然仍是會掉進新坑），項目推動順暢了許多。在帶動我的開發效率提高的同時，也使項目及合做團隊的成員愈加成熟，造成了雙贏。
下面就先從前端開發與項目中各個角色成員的合做來談起。

產品經理

產品經理一般是一個項目中，最早接觸的角色。
產品經理一頭對接需求方，一頭對接實施方（設計/開發），將需求轉化爲一個個功能點，交給實施方來實現。
做爲開發，常常會吐槽產品經理的設計天馬行空、不明因此。出現這種狀況的緣由，不少時候確實是因爲產品經理對於需求的理解不足或多此一舉。但大多數狀況下，產品經理仍是發揮了很重要的做用的。這點，若是經歷過沒有產品經理項目的同窗應該會深有感觸：直接的需求方，商務/銷售/老闆等提來的需求，每每須要通過屢次的「翻譯」和確認才能真正知足需求。
印象比較深入的一次，是公司人事提過來的需求：給員工論壇增長郵件推送的功能。當時 hr 的需求只有一句話：「想要可以自動推送新帖和熱門帖子，還能夠手動指定推薦的帖子，最好能帶圖片。」
從中，須要本身提煉出這樣 3 個需求：
一、自動推送新帖；
二、自動推送熱帖；
三、可選項爲推送推薦帖，而且要附上插圖。
提煉了一遍以後，還須要再細化需求，好比熱帖的時間範圍，新帖和熱帖的數量，以及插圖來源和沒有圖的狀況等等，這些都須要反覆再跟需求方確認清楚。
因而可知，跟產品經理的對接，其實就是間接對接客戶需求。若是不幸遇到了不靠譜的產品經理，要避免掉進坑裏，就必須本身來幫助產品經理把需求弄清楚。方法也很簡單，就是要多問：「想實現的功能是什麼？」「爲何要這個功能？」「客戶的需求是什麼？」等等。最後，再把完善的結果落入產品文檔裏，「互相留證」。
有時，產品經理還會承擔一部分交互設計師的工做，畫較爲詳細的原型稿。這時候，除了確認清楚需求外，最好再梳理個優先級。由於，一些比較精益求精的產品經理，會強調很多的細節功能，但每每不是來源於客戶真正的需求，或至少優先級並不高。這時候，若是開發週期有限，能夠考慮與產品經理協商，放在下一期迭代再作。

交互/視覺設計師

交互/視覺設計師根據產品經理設計的產品原型，設計並優化交互/細節，完善細節，極大提高了用戶體驗。
一般狀況下，設計師對於交互和視覺自己是最專業的，除非你有足夠的事實理論依據，不然不必就某一個交互或視覺設計與設計師爭論不休，畢竟專業的人作專業的事。可是，在如下兩點上，做爲開發是須要着重關注的：
一、標準的一致性：因爲種種緣由，如標準規範的缺失、文檔的缺失、人員的水平差別、溝通不足等等，會形成同一項目不一樣頁面、甚至於同一頁面的同一類功能，出現多種交互或者視覺樣式。這不只會影響開發的效率，自己也會下降用戶體驗。做爲開發，尤爲是在前端組件化流行的當下，每每會比設計師對交互或視覺規範更熟悉。這時候就須要善於分析，某些功能模塊是否相似，是否可使用同一種組件來實現。一旦判斷能夠，就要積極溝通，一般設計師是會願意接受建議的。
二、通用性：這裏的通用性，更多在組件設計中體現。好比，設計師對於不一樣場景的佈局，可能給出多套尺寸，這時候能夠建議，統一採用柵格佈局，並與設計師肯定幾套柵格比。這樣一來，就不須要再爲不一樣的場景，專門編寫幾種寬度數值了。
此外，在與設計師、包括產品經理討論某個設計或功能點時，應當先從合理性角度分析，好比對於原始需求是否必要？是否存在過分設計？是否存在功能點的重複？切忌一會兒從技術實現角度出發，每每會形成很多的無謂爭論，好比那句經典口頭禪：「這個需求很簡單，怎麼實現我無論」。
只有當一個功能肯定是須要的時候，才須要加入項目進度因素。這時候能夠考慮或是技術實現困難須要延長開發週期，或是採用某些快捷實現方案，與設計師協商，略微調整設計。
固然，不是全部的項目都配備有交互/視覺設計師。對於沒有設計師的項目，一方面，藉助現有組件的拼裝，基本不須要太多的樣式設計；另外一方面，做爲前端工程師，理應具有必定審美能力的，尤爲是設計並編寫一些交互動畫的能力。因此不管有沒有設計師，均可以在細節上作一些小的「自由發揮」，以提高最終用戶體驗。

後端開發

在目前採用較多的先後端分離模式下，項目有一個很重要的環節，即先後端聯調。
雖然同爲開發，但由於關注點的不一樣，常常也會形成互相傷害的局面。對於前端來講，一般因爲如下幾點：
一、接口前端不友好，好比返回值的數據結構嵌套很深，或者須要屢次請求後前端組裝數據；
二、前端實現 vs 後端實現，好比分頁、過濾、數值的計算等；
三、規範問題，如接口字段命名的一致性、是否符合同一命名標準、報錯格式等；
四、缺乏詳細的 API 文檔說明；
五、後端服務不穩定，或 BUG 太多。
對於這些問題，一方面，能夠經過技術手段來解決。好比，構建一套 API 管理系統，按規範定義 API，而且約束 API 開發者必須按照固定格式編寫詳細的文檔才能發佈 API；同時，提供測試環境，供後端自測；或是前端部署 BFF 層，合併 API 等等。
另外一方面，在遇到分歧時，前端開發者須要堅持幾點原則：
一、後端 API 應儘量不依賴於特定的前端界面。這不只有利於 API 的複用性，也可避免前端太重的邏輯影響頁面性能；
二、單點維護原則：有時候，確實有些邏輯或功能，放在先後端來作皆可，好比錯誤提示的翻譯。這時候，秉持在一處維護的原則便可，而不是各自維護一套；
三、用戶優先原則：後端在定義 API 時，更多的會考慮原子性；而前端是直接面對用戶的，須要更多考慮用戶體驗。但無論前端仍是後端，最終都是服務於用戶的。因此，對於一些可能會影響用戶體驗的 API，要堅持用戶優先，甚至能夠拉上交互/設計同窗，來推進問題的解決。
此外，不少時候，前端做爲項目路徑的下游，每每比較的被動。這時候，須要學會去化被動爲主動。好比，採起一些技術手段，如 mock 數據減小對後端開發進度的依賴。
除了技術手段外，溝通問題的過程當中，應該抱着共同尋找解決方案的心態，與後端一塊兒分析問題並找出最佳方案，這樣纔有利於項目快速良好地推動。

測試

聯調完成後，一般須要提測，進入項目上線前的測試階段。
進入這一環節，可能會被搞得特別鬱悶：本身認爲已經完善了的系統，仍是被抓出了很多的 BUG。
若是僅此而已，那其實還好，畢竟是本身的問題。但有時候，依據測試人員的不一樣，還會遇到不少意外狀況。
就我經歷過的測試而言，發現測試人員大體可分爲兩類：
一、經驗豐富的測試，能快速定位問題，而且較爲準確的指給責任方，此外還會提一些交互或功能優化建議；
二、新手測試，不清楚問題緣由，基本都先提給前端，或者對產品設計理解不夠清楚，提一些無效 BUG；
前者還好，除了會提一些你認爲是新 Feature 的 BUG 讓你來改；然後者，就須要有足夠的耐心了。
可是，咱們能夠換個角度來思考。第二種狀況的測試，其實更接近真實用戶在使用系統時的場景。與其不耐煩地強調是否是 BUG，不如思考一下，是否這部分的功能設計還須要優化？是否是會給真實用戶帶來困擾？甚至能夠主動拉上產品經理，看看是否須要調整產品設計，或是做爲需求下期迭代實現。這樣一來，無形中，你就成爲了項目優化的推進者。
此外，對於測試提過來的問題，若是發現不是本身的 BUG，也不要簡單地推掉。幫助測試拉相關方一道討論，能夠更高效地解決問題。

對待變動

「變動」對於開發者來講是最頭疼不過的一件事了，每每一個看似很小的變動，可能牽扯出不少關聯問題，大大影響開發效率。
然而，現實狀況是，不管是需求方、產品經理、交互/視覺設計師，甚至後端開發均可能提出變動。
有些變動「看似」不可避免，好比開發途中收到用戶反饋，但願增長某個功能；
有些變動看似沒必要要，卻又被強烈堅持，好比上線前，交互設計師以爲某個按鈕位置不合適，須要調整。
不少時候，看似不可避免的需求變動，每每能夠在產品設計中來避免，或者採起更好的方式來解決，如放在下一期迭代。看似沒必要要的功能，也不是說必定不能增長。我認爲，關鍵須要作好幾點；
第一，作好變動帶來的影響範圍的評估。對於一些大型的系統，產品設計上的一點小變動，可能會牽一髮而動全身，特別是一些公共模塊，好比計費。一些小變動，若是不作好範圍評估，可能對其餘模塊產生影響，甚至是不可用；
第二，評估好所需時間。一般，一個項目的上線節點是肯定的。或者，會嚴格制定提測的時間，測試也會有本身的排期。一旦某一需求點變動，沒有評估好時間，萬一形成了延期，將會對整個項目的進度帶來影響；
第三，要權衡收益與時間。咱們不該該刻板堅持說，需求開始已經定好了，這版任何需求變動我都不接受。畢竟，多數的變動，仍是從優化產品的角度出發的。若是評估一個變動對上線時間沒有什麼影響，徹底能夠順手改掉。但若是某個變動，多是客戶直接要求的，看似非改不可，但修改起來須要大大延長項目週期，這時候就須要作個權衡了，或是調整人力資源，或是調整技術方案。
總之，對待變動，不是一味地拒絕，也不是輕易地接受，須要充分權衡利弊收益，作出合理判斷。

覆盤

「覆盤」一詞最初來源於圍棋比賽，指一局棋局結束後，復演該局，分析整盤的勝負所在。
對於一些大型項目，項目的結束作一下覆盤，能夠總結一些問題或經驗，用來提高後續項目的效率。因此，進行復盤是頗有必要的。
好比，我接手過一個項目，項目的前期，產品經理提供的文檔很是簡潔（只有一頁），但項目邏輯遠比文檔描述來的複雜。這致使，整個開發過程當中，須要屢次跟產品經理溝通確認需求。除此以外，在項目中途，視覺設計師還作了好幾處視覺上的調整，以致於整個項目時間遠比預估來得緊張。
對於這個項目，當時作了一個覆盤。覆盤前，專門統計了一些數據做爲依據，好比產品文檔變動次數，設計稿變更點的數目等等。在會議中，秉持對事不對人的態度，列舉事實依據指出影響項目效率的緣由，並提出優化方案，如產品經理須要在項目開發前，準備好足夠完善的文檔；視覺設計師的視覺稿完成後，須要組織評審，儘量避免在開發後，再作調整。
經過優化方案的沉澱與推動實施，成功確保了後續項目，再也不遇到相同的問題，從而提高了效率。

敵人 or 助手

我作的項目是誰的項目？
在我剛開始工做的一段時間，對於接手的項目，個人理解，它們純粹就是一個個任務。我須要考慮的，只是如何用代碼去實現它們。
但在如今，我會意識到，我最早考慮的，不是如何實現，而是爲何要作這個項目？具體來講，就是項目的需求自己爲了解決什麼問題？能帶來什麼收益？進而思考，產品的設計方案是否知足需求自己？是不是最佳的方案？是否會形成一些問題？
換言之，在項目中，應當把本身看待成一個項目 owner，而再也不僅僅是一個執行者。個人合做方，包括產品經理、設計師、後端開發、測試都是個人助手，幫助我一塊兒把這個項目作好並推進它成功上線。固然，前提是，你須要主動去充分理解並承認這個項目，使它真正成爲「個人項目」。
這樣一來，合做中遇到問題時，我會以對於項目積極的方向去努力，而不只僅知足於完成本身部分的工做。好比，後端某個接口有問題，除了反饋給後端外，若是根據本身的經驗作個判斷，是否是 API GATEWAY 的問題，或者是否是某個字段取值不對之類的，能夠幫助後端更快解決問題。這不只有利於項目的總體進度，也能下降一個溝通成本，畢竟若是本身不提供足夠的信息和建議，可能反而增長了溝通的頻率，對本身的開發效率也會形成影響。
總之，記住一點，合做方不是敵人，是個人助手，咱們是爲了相同目標，通力合做的夥伴。

成熟業務 vs 初創業務

在我經歷過的全部項目中，既有比較成熟的產品業務，也有初創的產品業務，它們的整個開發過程，仍是有比較大的不一樣的。
對於成熟的產品業務，整個項目流程和角色分工，基本是比較完備的。可是，這並不表明開發過程必定順風順水。由於，一些既定的流程未必獲得嚴格執行，或者某個角色專業度不足。這種時候，就須要對照前面提到的，與各個角色合做的方式。
某些狀況下，還會存在合做方自身存在一些問題，好比工做態度、負責程度等。這時候，可能就不是靠一己之力能夠解決的了，而是須要記錄相關過程，並及時將問題反饋至上級來解決。
相比成熟業務，初創業務每每更關注「速度」。由於初創業務極可能處於市場探索期，須要快速完成產品推廣市場；同時又要及時迭代，知足客戶各類需求。這種狀況下，整個研發流程或是角色分工，不必定會很完備。好比，不必定有專職測試，可能會由產品經理兼職；又或者，不必定有設計師，可能須要咱們前端利用現成組件加一點審美能力自由發揮。顯然，這種時候，想要事先制定一個嚴格完備的研發流程，每每不太現實。
那麼如何在這種條件下，確保開發效率呢？我認爲，須要作到如下幾點：
第1、藉助技術手段。好比，最經常使用的 mock 數據，實現先後端開發時間上的解耦。
相比成熟業務，初創業務可能缺乏不少基礎設施，這就須要多作一些工程化的工做優化工做流，下降溝通成本。
技術手段還體如今，藉助一些現成的腳手架工具或完善的框架來快速搭建項目，如dva。
第2、須要提升項目管理能力。最基本的一點，是要會評估需求優先級。
對於前端開發來講，實現的功能中，除了調用後端 API 來實現的基本功能外，很大一部分是提高用戶友好度的工做。對於初創業務，這一部分的彈性實際上是比較大的。相比成熟業務，初創業務、特別是技術型的初創業務，用戶對體驗上的問題，容忍度相對是比較高的。因此，在項目時間比較緊張的時候，合理評估需求優先級，合理安排研發時間，對於確保項目如期上線相當重要。
第3、要少抱怨、多建議。
初創業務畢竟要同時面對項目週期緊、規範流程不完備、基礎設施缺少等不利因素，天然會遇到不少問題。這時候，不能只作問題的發現者，而是儘量成爲問題的解決者，至少也是問題的推進解決者，纔有利於整個團隊和項目。

總結

程序員常常用搬磚來自嘲，其實軟件工程和土木工程都做爲工程，確實有一些能夠類比的地方：
若是我只關注我被派到的活自己，好比搬磚、砌磚，一旦整個設計、或某個環節出了差錯，即使個人活作得再好，整個工期仍是會受影響，甚至會推倒我砌的完美的牆從新蓋；
若是我把眼光放大，瞭解我砌的牆在整棟樓中起得做用，我可能會發現，這牆設計的不夠厚，我多砌一層，可能就避免了一次返工；
若是把眼光再放大，可能還會發現，磚擺放位置太遠，運磚上花了不少時間；設計圖紙不夠清晰，老是容易看錯...
對於項目開發過程當中，或多或少存在流程、人員、規範等等各方面的問題，這時候須要主觀能動性，去打破這些問題，而非選擇無視和忍受。告訴本身，我是要把整個項目作好，而不是僅僅把本身的手頭任務作好，由此一來，遇到相應問題，天然會想辦法推進解決。這樣不只有利於項目，就我的來講，不也是一種能力的提高嗎？