2022年9月2日，是在這家公司的最后一天，從2020年11月2日入職算起，也不到兩年的時間。離職前加班加點的趕工了一個月把最后一個版本完成了（周末在趕，晚上一兩點還在趕那種），本來這個版本可以不做早點走人的，但是之前的代碼確實寫的不好（有我自身水平低的原因，也有多人交叉修改代碼的原因），所以重構了一些代碼，這樣別人改起來也方便一點。離職之后打算先休息一段時間再找工作，期間進行一些總結和學習，反正單身狗也沒有房貸和婚姻的壓力。面試總會問為什么離職，問這個都是明知故問，還有比錢更重要的考量嗎（雖然也有人際、環境等因素），一是當前薪資（能力匹配），二是未來的薪資（個人成長），雖然現在疫情的原因工作沒那么好找，但辭職學習一段時間也比待著混日子強（沒有經濟壓力、想要自我提升的前提下）。

工作總結

1.開發周期偏短，產生大量遺留BUG和垃圾代碼

目前的流程是開完需求評審會后，開發組長把任務分給小組人員進行時間評估，然后根據時間再重新調整部分需求。一般產品經理會給個提測或者驗收日期，一些超時的小的需求就留到下個版本，但是重點需求不能按時完成就需要延長開發周期。

之前我有兩次評估時間開發組長覺得長了，就說公司是創業公司要提高開發效率巴拉巴拉的，搞得好像我在摸魚一樣。我的思路是組件內一些關聯的代碼也需要簡單的重構下，因為初期的設計沒有考慮到當前版本這個需求點，但是他們就覺得直接做加法把功能堆上去，先把需求完成再說，后續也不給時間優化代碼。這也導致目前項目里很多冗余的代碼，就是為了趕進度瞎寫的，寫起來容易改起來難，每次提測除了當前版本新需求一堆BUG，還能測出一堆遺留BUG。本來我們組開發水平也有限，還只關注需求完成不關注質量，那就沒法了（雖然大部分小公司都有這種問題）。寧愿多給一周時間測試和改BUG也不多加一點開發時間，我不懂這是什么思路。

剛開始我有空還會改點遺留一兩年的老BUG，后來被組長教育后就醒悟了，在這里把需求完成就可以了。

2.代碼質量差

項目代碼質量差，除了我自身能力不足，也有其他的一些原因：

項目開發周期短。給的時間短，自然就容易出現代碼設計上的缺陷，不利于維護和拓展。最開始的時候開發過程中還會修改和增加需求，后來流程完善了一些，不會在開發過程中有大的需求變更了。盲猜產品覺得功能完成了，界面好看，就完事了。

開發水平參差不齊。我的編程水平算是比較低的，但是同在一個公司，其他同事應該也大差不差。比如有人在非阻塞或者未加鎖的情況下多線程直接訪問，輕則數據不同步，重則程序崩潰。還有個項目那兩個同事組件樣式定義都是復制粘貼而不是封裝成獨立的組件。這里要吐槽下開發組長，之前有個BUG最后查出來是他寫的，他讓我們去找原因就算了，第二天開早會還在說代碼中不懂的要多問，此外，他還經常把別人的代碼改出BUG來。

缺少開發規范。目前我們組是沒有開發規范的（之前提過一個編碼規范，但也沒落實），大家都按照自己的一套邏輯在寫。沒有注釋就算了，如果是多人合作還可能出現一個功能多個實現接口的情況，沒有接口規范來約束。

缺少代碼審查。目前是只管完成需求，個人和公司都沒去管代碼質量的問題，項目代碼早已經是一座座屎山了。

3.我寫BUG的一些經驗

容易產生BUG的起因：

指針或者參數沒初始化。一般會因為異常訪問導致崩潰。有次調用Win API結構體參數的指針沒初始化為NULL，導致崩潰，找了好久。

復制粘貼時變量名沒改。如多層循環時，外層的自增變量帶到內部導致越界異常訪問。復制粘貼導致的BUG我沒少干，以后需要認真點。

多線程同步問題。這個同事寫的BUG比較多，死鎖卡死程序，不加鎖出現異常訪問等。

沒有對參數的有效性進行判斷。這個也是同事的老毛病，有段時間各種越界導致崩潰。

修改歷史代碼也容易產生BUG，應該盡量寫好注釋，便于別人修改。

還有一些UI交互的BUG，要和產品溝通好細節，不然做出來不符合需求。

只要養成各種壞的編碼習慣，寫完不自測，輕輕松松就能完成BUG KPI。

（2022-11-16）補充：剛發現我以前寫的代碼智能指針循環引用了，趕緊反饋給了前同事，罪過。

4.自動化測試

目前的版本迭代，每次都需要一兩周的時間用于測試和修復BUG，本來一個版本的開發周期一般也就四五周。由于時間和人手的原因，一般也沒有進行單元測試和自動化測試，全靠測試人員跑流程，如果可以引入自動化測試，可以提高回歸測試的效率和覆蓋率，而手動測難免會遺漏一些地方。

之前有嘗試過UI自動化測試，Qt的話可以通過QAccessible導出屬性給測試框架訪問。引入自動化測試主要的成本在于前期導出測試用接口和編寫測試代碼，似乎按目前的開發流程和周期沒法安排人去做這個事。

5.開源協議

首先懺悔下我以前也沒遵守開源協議，后來了解了才開始盡量去遵守。目前參與的項目里，也有一些同事引入的GPL庫，我這里得撇清責任，我沒有引入也沒有使用那些庫。

6.這是一個成長中的團隊

盡管這個團隊存在著諸多的問題，但作為一個年輕的公司、年輕的團隊，那些不足之處都會在成長過程中逐步完善。團隊和人一樣，都只是在恰當的時間做出了恰當的選擇。

未竟的事業

雖然參與了好幾個項目，但主要負責的是辨音這個項目的開發，目前還遺留了一些想做但沒做的任務：

1.任務調度器

之前的需求任務是獨立且只能單個執行的，只需要開個進程通過RPC調用即可。后續新增需求可以將不同任務組合按順序執行，前者輸出作為后者輸入，同時不限制任務個數按順序執行。我的想法是再抽象一個任務調度的模塊管理各種任務的組合執行、插隊執行等，每一種任務一個隊列。同時，計算機資源占用也納入考量，因為算法執行時很占CPU資源，按優先級需要可以先暫停其他優先級更低但是不在同一個處理進程的其他任務。

2.QML組件封裝

目前做的QML組件都是很零散的，沒有一套統一的接口，后續考慮統一接口并增加樣式管理。

3.封裝波形編輯組件

無論是我畫的錄音組件還是公司已有的圖譜組件，都太原始了，每次修改都是牽一發而動全身。需要參考其他成熟的圖表庫進行重構。

4.封裝數據庫操作

5.日志管理

展望未來

隨著工齡的增長，自己的能力也在逐步成長，只想在有限的時光多嘗試一些新鮮的事物。吾生也有涯，而知也無涯。平時就學一點音視頻和3D的知識，不需要學多深，可以應用到項目中即可，目前主要還是以做Qt界面為主。非要說定個什么目標的話，那就是希望自己能有一個上千星的開源項目，不過目前還沒想好項目方向。

我就一農民工，再好好干幾年Qt，就該回鄉下種菜去了，這就是我的宿命。

總結

以上是生活随笔為你收集整理的离职总结（2022-9-5）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。