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

工作總結(jié)

1.開發(fā)周期偏短，產(chǎn)生大量遺留BUG和垃圾代碼

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

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

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

2.代碼質(zhì)量差

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

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

開發(fā)水平參差不齊。我的編程水平算是比較低的，但是同在一個公司，其他同事應(yīng)該也大差不差。比如有人在非阻塞或者未加鎖的情況下多線程直接訪問，輕則數(shù)據(jù)不同步，重則程序崩潰。還有個項目那兩個同事組件樣式定義都是復(fù)制粘貼而不是封裝成獨(dú)立的組件。這里要吐槽下開發(fā)組長，之前有個BUG最后查出來是他寫的，他讓我們?nèi)フ以蚓退懔?#xff0c;第二天開早會還在說代碼中不懂的要多問，此外，他還經(jīng)常把別人的代碼改出BUG來。

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

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

3.我寫B(tài)UG的一些經(jīng)驗

容易產(chǎn)生BUG的起因：

指針或者參數(shù)沒初始化。一般會因為異常訪問導(dǎo)致崩潰。有次調(diào)用Win API結(jié)構(gòu)體參數(shù)的指針沒初始化為NULL，導(dǎo)致崩潰，找了好久。

復(fù)制粘貼時變量名沒改。如多層循環(huán)時，外層的自增變量帶到內(nèi)部導(dǎo)致越界異常訪問。復(fù)制粘貼導(dǎo)致的BUG我沒少干，以后需要認(rèn)真點。

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

沒有對參數(shù)的有效性進(jìn)行判斷。這個也是同事的老毛病，有段時間各種越界導(dǎo)致崩潰。

修改歷史代碼也容易產(chǎn)生BUG，應(yīng)該盡量寫好注釋，便于別人修改。

還有一些UI交互的BUG，要和產(chǎn)品溝通好細(xì)節(jié)，不然做出來不符合需求。

只要養(yǎng)成各種壞的編碼習(xí)慣，寫完不自測，輕輕松松就能完成BUG KPI。

（2022-11-16）補(bǔ)充：剛發(fā)現(xiàn)我以前寫的代碼智能指針循環(huán)引用了，趕緊反饋給了前同事，罪過。

4.自動化測試

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

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

5.開源協(xié)議

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

6.這是一個成長中的團(tuán)隊

盡管這個團(tuán)隊存在著諸多的問題，但作為一個年輕的公司、年輕的團(tuán)隊，那些不足之處都會在成長過程中逐步完善。團(tuán)隊和人一樣，都只是在恰當(dāng)?shù)臅r間做出了恰當(dāng)?shù)倪x擇。

未竟的事業(yè)

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

1.任務(wù)調(diào)度器

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

2.QML組件封裝

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

3.封裝波形編輯組件

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

4.封裝數(shù)據(jù)庫操作

5.日志管理

展望未來

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

我就一農(nóng)民工，再好好干幾年Qt，就該回鄉(xiāng)下種菜去了，這就是我的宿命。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。