前言

這次項(xiàng)目是騰飛學(xué)長交給張凱杰學(xué)長負(fù)責(zé)的一個小型商業(yè)項(xiàng)目，我在本次項(xiàng)目中是作為一個后端負(fù)責(zé)人的角色。

開發(fā)人員5人，開發(fā)周期為2星期，雖然我們提前完成了任務(wù)，但是在第一次交付后的新增需求變更中，我們又花了將近1個星期多的時間。中間后端全部回家，導(dǎo)致第一次交付延期（我猜極大可能是這個原因，所以內(nèi)心也比較愧疚），這一段時間中項(xiàng)目進(jìn)行了斷層，等后端人員回來后，需要思路重新回到這個項(xiàng)目中。不過最后還是順利完成交付，后續(xù)可能還是需要維護(hù)的。

經(jīng)驗(yàn)總結(jié)

以下都是我在這次項(xiàng)目中出現(xiàn)的問題和一些感悟，做項(xiàng)目中可以參考一下。

1. 沒有接觸框架，就去做項(xiàng)目，但是項(xiàng)目中就是要用這個框架怎么辦？

   • 這時候就需要自己去快速上手這個框架了，一開始可能會蒙，但是不要怕，沒見過豬跑，咱還沒吃過豬肉嗎，框架原生的代碼咋寫，咱先模仿著來寫，雖然不知道啥意思，但是模仿著模仿著就會了，代碼層面可以相似，但是思想很難同步，一千個人有一千個哈姆雷特，框架的搭建，使用以及架構(gòu)思想很重要，這時候需要自己對著官方文檔，快速過一遍，感悟這個框架的意義和框架是如何實(shí)現(xiàn)的。這樣才能快速上手，一般就花一天時間就可以去上手了，這時候是一個不斷模仿的過程的，循序漸進(jìn)就可以把握這個框架了。

2. 第一次作為后端負(fù)責(zé)人，應(yīng)該要做些什么？

   • 首先是自己要有信心能夠帶領(lǐng)后端團(tuán)隊(duì)順利完成排期任務(wù)，然后是要指導(dǎo)和幫助后端團(tuán)隊(duì)解決問題，這一塊的確很鍛煉人，技術(shù)溝通和思路很重要。要有規(guī)劃能力，對于工作的計劃規(guī)劃，是不是胸有成竹，進(jìn)行風(fēng)險規(guī)劃。最后就是解決一些難以理解的bug時候需要不斷記錄。

3. 我們對不同項(xiàng)目大小的態(tài)度應(yīng)該是什么樣的？

   • 不管拿到什么級別大小的項(xiàng)目，都要去認(rèn)真對待，從中吸取經(jīng)驗(yàn)，不斷成長，注重成長和過程。

4. 前期后端壓力比較大，前端等著后端的接口，如何有條理的去解決？

   • 首先是要后端需要根據(jù)需求去設(shè)計數(shù)據(jù)庫，因?yàn)閿?shù)據(jù)庫中的字段很多是需要返回給前端的，如果數(shù)據(jù)庫沒提前設(shè)計好，會影響后面的前后端接口約定，當(dāng)然了，后端是主要設(shè)計數(shù)據(jù)庫的，但是在時間比較緊張的情況下，前端也可以參與，或者拉大佬幫忙一起設(shè)計。當(dāng)數(shù)據(jù)庫設(shè)計完成并且表都建好了后，這時候后端再去定API接口，但是再時間比較緊張的情況下，前后端都參與比較好，這時候定的接口前后端都可以知道是什么樣子的，也就不需要再去review了，但是但是還是要建議有接口文檔，可以留作備份參考。如果項(xiàng)目組成員中有人不了解框架，需要讓他先快速上手一下框架，給他一點(diǎn)時間去熟悉，這段時間不急著去安排后端任務(wù)，先讓前端去寫頁面即可。后端負(fù)責(zé)人需要把握前端頁面開發(fā)情況，合理安排后端任務(wù)開啟。當(dāng)一切變得有條理的時候，那么你就可以去把握事件的走向，壓力自然就不會那么大。

5. 開發(fā)中一天提一次代碼有必要嗎？會不會太影響開發(fā)效率？

   • 我覺得非常有必要，一天一次我甚至覺得少了，因?yàn)榧皶r合并代碼能夠保證服務(wù)器上運(yùn)行的是最新的代碼，接口可以及時反饋給前端，同時出現(xiàn)的問題也可以很快浮現(xiàn)，這樣就減少大聯(lián)調(diào)中產(chǎn)生的bug。另一方面開發(fā)人員間的代碼會是最新的，減少了代碼產(chǎn)生沖突機(jī)率。如果你覺得影響了自己的開發(fā)效率，需要從自身找原因，為什么會覺得影響了，對吧？

6. 開發(fā)過程中遇到了很棘手的問題怎么辦？自己已經(jīng)將近一個小時沒解決，任務(wù)即將超時怎么辦？

   • 首先向項(xiàng)目負(fù)責(zé)人說明情況，申請協(xié)作和該任務(wù)時限重定。然后梳理問題，講清楚問題在哪，自己做過哪些嘗試的解決方案，節(jié)省協(xié)作人員問題感知時間。如果這個問題仍然沒有解決思路，尋找替代方案，暫時放棄該問題，記錄該問題，確保此問題不影響整個項(xiàng)目的開發(fā)和交付。

7. 項(xiàng)目中遇到的技術(shù)難點(diǎn)有哪些?

   • 框架的靈活使用，很多時候，我們是需要自己去完成某項(xiàng)功能的實(shí)現(xiàn)，但是有時候在框架中其實(shí)是有已經(jīng)寫好的實(shí)現(xiàn)了這個功能，這個時候我們就可以不用重復(fù)造輪子了。
   • 新技術(shù)學(xué)習(xí)成本高，有的功能需要新的技術(shù)去實(shí)現(xiàn)，但是這個技術(shù)又比較難，開發(fā)時間不夠自己去學(xué)習(xí)掌握，那這時候還是建議“對著葫蘆畫瓢”，只要咱們畫的瓢它能跑起來，咱就先不管了，等時間夠的時候回過頭來再去思考我這樣畫的他咋能跑起來的，也就是再去深入學(xué)習(xí)。
   • 框架出現(xiàn)的bug，使用框架過程中發(fā)現(xiàn)框架本身就帶bug，而且這個bug還影響到最后功能的使用，這時候還必須要debug挖框架底層代碼邏輯，從中去改了。
   • 前后端無法重現(xiàn)的bug，從頭開始梳理邏輯，最讓人頭大的。

8. 項(xiàng)目開發(fā)過程中與人交流產(chǎn)生的問題如何解決？

   • 人際關(guān)系的處理對于我來說應(yīng)該還是比較注重的點(diǎn)，我個人有過一兩次團(tuán)隊(duì)開發(fā)項(xiàng)目的經(jīng)歷，都出現(xiàn)過大大小小的與人交流上面產(chǎn)生的問題，多數(shù)情況是我沒有特別清晰的讓別人懂我的意思，而讓別人似懂非懂的去做了，結(jié)果到最后的他做的和我講的差別很大，這就是我的問題了，首先不要上去就懟，還是需要心平氣和的再給他講一遍，直到他懂我說的意思后再去做這件事才會帶來比較好的效果。
   • 另一個情況就是觀點(diǎn)不一致產(chǎn)生矛盾。那么競爭、回避、包容、妥協(xié)和協(xié)作等情況是常見的解決方式，這時候?qū)ふ翼?xiàng)目負(fù)責(zé)人進(jìn)行協(xié)商處理，往往可以解決這個問題，與其兩個人爭得面紅耳赤，不如將選擇權(quán)交給項(xiàng)目負(fù)責(zé)人來把控。美國總統(tǒng)林肯曾經(jīng)說過一句話：當(dāng)我準(zhǔn)備和一個人理論的時候，我會用1/3的時間思考我的立場以及我想說什么；另外2/3的時間我會思考對方的立場以及他想說什么。這無疑是一種從根本上解決問題的方法。

9. 對比之前的前端開發(fā)，后端開發(fā)有哪些需要注意的地方？

   • 前后端分離是一種架構(gòu)模式，前端人員需要思考如何將后端的數(shù)據(jù)進(jìn)行渲染上去，本次項(xiàng)目中前端表頭與表列的動態(tài)變化是一個難點(diǎn)。而后端同樣也許要做到excel文件和前端頁面表格一致，這都是一樣的道理，都需要考慮如何去做到數(shù)據(jù)變化表格動態(tài)變化。也就是說，后端的任務(wù)核心就是各項(xiàng)服務(wù)怎么實(shí)現(xiàn)和傳給前端數(shù)據(jù)的格式是什么樣的，數(shù)據(jù)庫字段咋傳給前端，各種復(fù)雜的sql語句如何編寫了。日志也很重要，出現(xiàn)bug就可以根據(jù)日志去解決。熟悉各種配置文件和注解，便于開發(fā)。CRUD很常見，要精通。代碼優(yōu)化與注釋是為了讓人看的，便于維護(hù)，也需要注意。后端的緩存與前端的緩存的作用是不一樣的，但都是可以幫助我們解決一定場景中出現(xiàn)的問題。

10. 本次開發(fā)的項(xiàng)目流程走的咋樣？(每次做項(xiàng)目都需要關(guān)注的點(diǎn))

1.需求人員向項(xiàng)目組提出需求，然后給項(xiàng)目組的所有人進(jìn)行需求講解，大家一起探討需求中各項(xiàng)細(xì)節(jié)的可行性。（Done）

2.當(dāng)開發(fā)人員和需求人員一起確定沒有問題的時候，開發(fā)人員返講一遍需求，當(dāng)雙方都沒問題的時候需求才可以定下來。(Done)

3.需求確定以后，開發(fā)人員進(jìn)行分工調(diào)整，然后訂制開發(fā)設(shè)計概要和Api，后端Api中一般包括一些接口，需要的參數(shù)，需要和前端確定訪問路徑以及傳遞的參數(shù)和數(shù)據(jù)格式。（Done 80%，本次項(xiàng)目中部分接口是在開發(fā)的時候才發(fā)現(xiàn)少的，以后需要避免出現(xiàn)這種情況）

4.在設(shè)計api的過程中，需要前后端各自設(shè)計好后互相講解，講解中要達(dá)到相關(guān)重要點(diǎn)的意見一致。(Done)

5.需要有測試人員編寫測試用例，驗(yàn)證是否可行。(Done 80%)

6.前后端開發(fā)人員自己需要有測試用例，在測試中不斷修改和優(yōu)化自己的代碼使其代碼更加簡潔。(Done)

7.當(dāng)雙方都測試沒問題后，進(jìn)行聯(lián)調(diào)，進(jìn)一步確定功能沒有問題。(Done)

8.打包部署到服務(wù)器，聯(lián)調(diào)測試。（Done）

小結(jié)

• 在編寫代碼過程中我們也需要不斷的總結(jié)，無論是需求的變更還是系統(tǒng)的搭建，我們都需要考慮哪一部分是變化的哪一部分是不變的，將不變的抽取出來，變化的封裝起來。這樣在以后無論是系統(tǒng)擴(kuò)展還是需求變更中我們都能夠以最小的代價來完成任務(wù)。
• 很開心項(xiàng)目能順利交付，并且得到學(xué)長的肯定，雖然項(xiàng)目是個小項(xiàng)目，但是每個小項(xiàng)目都有自己的難度點(diǎn)，像文凱他們的那個項(xiàng)目，用到了人臉識別，圖片壓縮技術(shù)；而浩鵬他們的那個項(xiàng)目戰(zhàn)線時間拉的長，并且后端人員又少，按浩鵬說的就是“又臭又長”，挺費(fèi)心力的；回到我參與的這個項(xiàng)目，excel的多個單元格合并和動態(tài)表格的制作以及不同角色用戶的權(quán)限設(shè)置等技術(shù)是這次項(xiàng)目的核心。也就是說，不管什么項(xiàng)目都有自己的核心要點(diǎn)，我們都從中收獲了許多，我感覺在做項(xiàng)目經(jīng)歷的這些過程中成長是最快的。
• 最后，“當(dāng)你越過了喜馬拉雅山，你有擁有了越過喜馬拉雅山的能力”，加油吧！