近期上線了乙個新的專案，從前期的需求評審到專案整體設計，最後上線，歷時了快乙個月的時間。雖然是個小專案，但是由自己從頭開始跟的專案。 這個專案讓自己學到了很多，同時也發現了自己很多的不足，寫篇文章總結下專案從的0到1的過程以及這段時間的一些感悟
先說下專案的組成結構，web專案，由前端+後台+服務端組成，技術棧為：前端採用vue，後台使用react，服務端使用node，資料庫使用mysql，快取使用redis，這個技術棧整體看來，還是比較符合潮流的。
關於技術選型，若是小組沒有技術棧的沉澱，都是新的起點，那麼選型的時候就得考慮很多方面，如小組上手的速度、開發的成本、選型是否利於以後擴充套件、運維成本等
開發階段細分為以下幾個小階段:業務邏輯梳理、模組設計、開發任務劃分與分配
業務邏輯梳理
專案經過多輪的產品評審敲定後，就可以開始進入到設計階段了，這裡的設計不僅僅是簡單的專案**層面的設計，還包括用例圖、時序圖、表結構、與內部服務溝通配合等設計，這幾部分的設計的好壞是決定了整個專案的業務合理性、可靠性、擴充套件性，這部分產出可以體現程式設計師是乙個老司機，還是乙個小白
資料庫設計
資料庫是系統的基石，資料庫設計應建立在對業務的深度理解上，設計的時候對業務的理解不能僅限於產品或技術的思維，而是要兩者兼備，這樣設計的表結構才能更合理、更利於業務擴充套件
畫圖用例圖，顧名思義，體現系統功能的模型圖，用例圖是畫圖的第一步，只有知道系統需要實現哪些功能、系統的邊界，才能往下進展；
時序圖也叫泳道圖，顯示物件間的呼叫互動圖，物件可以是模組、服務等，將各個模組的呼叫順序和業務流轉清晰的畫出來，因為系統會隨著業務的發展不斷的迭代，若是沒有個文件將業務流轉給記錄下來，對後續接手的開發，那就是個大坑，周而復始不斷累積業務，這個專案離重構就不遠了；
還有流程圖等，就不一一說了
任務拆解
接下來到任務的拆解與分配，畢竟專案不乙個人單打獨鬥就能完成的，得由團隊的一起推動。這個專案前後端都是由前端小組來開發，js通吃前後端，所以任務的拆解按模組來拆解，比如登入模組，前端的互動和後端的服務均有乙個人來負責，這樣的分解，好處就是，免去了前後端聯調的這一溝通流程，讓大家的溝通成本大大降低，開發時效也提高了，但有個小前提，就是大家的編碼水平都要能滿足前後端的開發要求，畢竟大部分前端開發在服務端領域還是有所欠缺的。
制定好開發規範，優秀的專案，必然有一套完整成熟的規範，大部分公司內部都有自己的開發規範，同時借助主流的工具，可以為我們規範專案編碼
還有就是**review，我們使用git作為版本管理，團隊的提交都會先經過review才能merge到主幹，pull request(簡稱pr)是不必不可少的環節，因一些溝通理解、編碼粗心等，導致提交的**存在問題，所以在review的環節，就可以提交前發現，將其扼殺在搖籃中。
交叉測試
交叉測試，在正式提交測試前需要預留兩天左右進行交叉測試，即a開發的功能，由b來測試，因為開發自測往往會陷入邏輯黑洞，考慮場景不全、異常處理不夠等問，交叉測試，開發化身測試，提早將問題給發掘出來，同時也可以讓大家對整個專案邏輯了解的更加清晰
測試組測試
測試階段，因為採用的是瀑布流的開發方式，先開發，在計畫期限完成後，在移交給測試，測試遇到的bug，反映了開發的水準，因為開發階段有code review，所以測試的出來的專案質量，也體現了專案負責人的態度和水準。
專案往往會涉及到多個內部服務的呼叫，經常服務間出現些小問題，這次開發間就會拿出甩鍋**，互相推諉，都不願意去找原因，若一直沒人去跟進解決，輕會影響專案上線計畫，嚴重會給生產留下隱患。這個問題，歸結還是在與開發成員的工作態度，這個跟團隊宣導和建設有關啦，就不展開了。若出現甩鍋未能解決的問題，就需要專案負責人及時跟進處理。
測試完成後，下一步就是按計畫上線，此時，需要與運維小夥伴進行充分的溝通，申請線上資源、線上引數準備、效能監控、報警監控等
覆盤的作用在於回歸整個開發歷程，遇到了哪些問題、如何解決、哪些未能解決等等看似零碎的部分，將這些部分彙總起來，彙總的過程看似對專案，但實際上是在對自己進行審視，哪些讓自己成長了，哪些還有很大的不足、及自己沒做好的原因等，開發路漫漫，抬頭看看天才能知道自己的位置~
文章寫得有點流水賬了，在每個點上，自己懂得還很膚淺。 記錄下自己最近的一些心得吧
市場上大部分的程式設計師職位都是開發工程師，開發工程師的定位應該是：以完成功能需求為主，基本上是圍繞著產品經理提出的需求文件轉，很多人就吐槽，一直在做功能，沒有提公升的空間，但我不這麼認為，在我們不能改變自己開發工程師的職位時，要做的應當是少點抱怨，多自我挖掘，在完美實現功能的同時，深挖其中的技術點，況且能做到寫出來的功能健壯，就足夠考驗人了，其理解能力、邏輯能力絕對不是一般的水準
切忌浮躁，敬畏技術，不要會用乙個技術了，就認為自己能掌握了，多會幾個技術點，便說自己遇到瓶頸了。沉澱下來，好好啃一啃，比跟風、自我焦慮強的多。知其然，而知其所以然
一家公司的開發任務，伴隨著在職時間越長，便越會順手，老油條和晉公升達人也在悄悄的拉開差距，要及時走出自己的舒適區，多去承擔難點，讓自己在工作上難過，未來才能好過
那就先簡單做這句話在開發間經常聽到，既然都確定去做了，那為什要簡單做呢？；寫業務時，遇到難點，哎，就就這麼寫吧，反正也沒問題；以上現象，說到底，一句話：懶於思考，安於現狀。多思考，注重細節、端正態度，做乙個不將就的coder
持續學習，有句話說的好：淘汰你的不是你的同齡人，也不是這個社會，而是你自己在原地踏步。網際網路的更新速度令人咂舌，令人焦慮啊，一群人整體喊著跟不上了啊，學不動了啊，可是馬拉松是沒有暫停的，咬緊牙，少去瞎比比，學習是枯燥的，但要知道它才是給你帶來紅利的基礎，是你跑下去的資本
軟體專案管理的一些感想
軟體開發不能各司其職，分兵作戰。乙個龐大的，多服務，多系統的專案，可能保護多個團隊所開發維護的系統，每個系統都基於面向的使用者群是一致的。在系統整合過程中，涉及到多系統的資料互動，可能會產生各種雜亂的介面，服務程式依賴。一旦乙個專案選擇這樣得處理方式，專案就會走向不確定性，專案風險就會增加。其中，任...
關於做專案的一些感想
最近比較忙，本來不打算寫這篇文章的，但是最近經常聽到同學們討論關於跟指導老師做專案會不會影響到自己的學習，並且還有不少同學看到別人跟老師做專案，自己也盲目地想去找老師去做專案，沒有從實踐去考慮過。還有就是少數的同學認為，參加這種沒有工資的專案，不就是浪費時間，大材小用 嗎？對於這種現象，以下是我個人...
一些職場感想
不要相信領導給你畫的大餅 離開了，就不要回去 他說的為你好，都是套路而已 你會比你想象的更優秀 不要認為提增加工資不好意思，你不提，他永遠不會給你加工資 這就看你所處的隊友是怎麼樣的 如果隊友是乙個很拼的，可能你需要比他更拼才能出人頭地，當然也要注意方法，不是埋頭苦幹，隊友不知道，領導不知道 如果隊...