xxxTMS專案總結
追夢1819(2017-7-26)
背景
今天是2019年5月13日，而這篇總結是去年7月26號寫的。博主一直都有一個習慣，就是在一個專案完成時或者一個大的版本迭代後，都會對工作的方方面面進行一個總結。不過這篇總結比較特殊，公司領導要求我們寫的，而博主的這篇總結，也被領導拿出來給其餘同事當範例參考。當時開發的是公司的 xxxTMS 專案，專案開發不久，團隊也是新組建的，大家處在一個探索期和磨合期。
可是再回頭看是，這個團隊以及當時領導的管理，是我見過的效率最高和管理最好的（此處的管理是指專案管理，不涉及公司層面的行政或者人事管理）。今天拿出這篇總結，目的是提醒自己不管什麼時候，都不能忘記自己的初心，同時要對自己的工作的方方面面不斷思考，而不只是做一個敲程式碼的機器。
前言
TMS本次迭代開發，我負責的模組主要有：到達確認、回單上傳、回單確認、企業錢包等功能。在開發過程中，遇到了很多問題，以下是對所遇到問題的描述以及總結。
正文
一、問題描述
專案開發過程中，我將所遇到的問題分為兩個部分，需求理解部分(1-6)和功能實現部分(7-9)。
1、需求文件不夠詳細。下面是所遇到的幾個例項。
1) 回單錄入列表，應該是“有回單”且“已到達”狀態，但文件只有“僅顯示待回單錄入的運單”幾個字；
2) 到達確認的邏輯，有到付金額顯示到付金額，無到付金額顯示尾款，兩者都無不顯示，這個邏輯在需求文件中都沒有；
3) 錢包註冊過程中，在使用體驗上來說是應該有【上一步】按鈕，但是需求文件沒提到，後面使我們自己加入的；
4) 檢索部，為提升使用者的體驗效果，有的欄位可以作為檢索條件，比如運單編號；
2、部分新的需求或者新的樣式到開發後期產品部才確定下來，比如錢包相關的功能，這在一定程度上同樣會影響開發進度；
3、需求的不斷變更(難以避免)；
4、如果是呼叫上海那邊的介面，很容易出問題，他們所給的api文件，可能不是最新的；
5、每個人只關注了自己的個人開發模組，對專案沒有一個整體的認識，或者說與自己相關的模組都沒有去了解；
6、業務理解得不夠深刻，甚至把比較複雜的邏輯理解得很簡單，導致開發後期手忙腳亂；
7、基本上都只是相似功能程式碼的複製貼上和修改。這導致了很多問題：
1) 出現很多沒用的垃圾程式碼；
2) 不理解所以然，會出現很多意想不到的bug；
3) 很多不規範的程式碼甚至錯誤的程式碼會不斷“流傳下去”，會進入一個惡性迴圈；
4) 看似相同的功能，但是實現方式不同的程式碼，並不能複用，更加不能簡單的複製貼上。例如系統中有很多的照片上傳功能，但是實現時，有的介面是接受圖片路徑，有的介面直接接收圖片；
8、框架不熟，如angular和bootstrap；
9、部分欄位的校驗被忽略。
二、總結
遇到問題，我們得總結出相應的方法去解決，避免下一次掉進同樣的坑。
1、關於需求理解，我一直都認為是開發過程中的重中之重。只有正確的、深刻的理解好需求，才能更好更快的進行開發，以下是關於需求理解的一些感想：
1) 儘可能細化需求文件，更深入理解，不理解的、不夠詳細的或者我們想到而產品部沒有提到的，儘早跟產品部溝通；
2) 複雜的邏輯，儘量能畫出圖表，有助於理解和修正；
3) 需求的不斷變更，是在任何專案開發、產品開發的過程中無法避免的。但是希望產品部的設計人員能夠以書面的方式通知需求變更，然後調整相應的開發時間和測試時間。而不是僅僅口頭說變就變，這樣可能影響開發進度；
4) 在深入瞭解自己開發模組的前提下，至少要理解跟自己相關的模組，比如資料的來源的對應模組，資料的輸出對應模組等。拿運單管理模組來說，運單的狀態變化要了然於胸；
5) 如果是呼叫別人的介面，一定要保證溝通的正確性(如欄位名、欄位型別)、及時性(必須是最新的介面)；
2、關於功能實現的總結
1) 在開發過程中，要善於總結，比如類似功能的程式碼，框架的基本使用，一些常用欄位的校驗等，形成自己的“程式碼庫”，這樣在後續的開發過程中會極大的提高效率；
2) 複製貼上類似功能的程式碼，一定要多問幾個為什麼。儘量做到理解每一行程式碼的意義，不寫無用無效的程式碼；
3) 所用到的框架(TMS系統主要用到了spring+hibernate（後端），bootstrap+angular（前端）)，應該主動、多花時間去熟悉去學習，儘量能夠做到知其然知其所以然；
三、後續
1、開發過程中，我們不應是為了開發而開發。要多多站在使用者的角度考慮(當然，這個如果跟需求文件設計的不一致，就要先跟產品部溝通)。比如上面說到的檢索部加一些比較實用的檢索條件、錢包開戶加【上一步】按鈕等；
2、專案所用到的技術，要去深究，不能一直只浮在表面，不然可能會產生許多不可意料的坑。