系統(tǒng)方的設(shè)計指標(biāo)越來越高，很多硬件的效能必須靠軟件進行體現(xiàn)。而且在自動化控制/信號處理方面也必須借助相關(guān)的算法和技術(shù)才能實現(xiàn)。這些方面我們還需要摸索和積累.下面是小編帶來的一個軟件工程師的年終總結(jié)，有興趣的可以看一看。

各位領(lǐng)導(dǎo)，同事：

我的工作內(nèi)容與諸位（軟件開發(fā)中心的）同事承擔(dān)之事大同小異，主要談?wù)勔荒陙淼墓ぷ髑闆r和感悟：

作為一個軟件工程師（就是碼農(nóng)），主要的工作自然是寫代碼。分析需求、設(shè)計框架、完善細(xì)節(jié)、調(diào)試代碼、修正BUG、需求變更分析、修改代碼，流程進行中還穿插了各種表格和文檔。一個完整的流程下來，需要付出加班、白頭發(fā)、腦細(xì)胞、體重等多重代價，其中辛苦，如人飲水，冷暖自知。

快樂是有的，看到自己辛苦搭建起來的軟件系統(tǒng)能夠正常運轉(zhuǎn)，收獲幾個贊美之詞，就已經(jīng)很知足了。尷尬也是有的，因為軟件的一點小問題日夜兼程去千里之外修補代碼這種尷尬事也遇到過�？傮w而言，今年的任務(wù)還是順利完成了，試驗也如期保障了，這些都還得益于領(lǐng)導(dǎo)的關(guān)心和同事的給力支持，在此表示感謝！

今年的工作的關(guān)鍵詞是：陪。

陪調(diào)試、陪聯(lián)試、陪試驗。細(xì)算了一下，今年的出差達到了8次，出差時間接近60天，期間基本成了某單位（總體部門）的陪練。當(dāng)然，出差期間也不敢閑著，坐在A項目現(xiàn)場拿著筆記本干B項目的活，還被某單位的同志笑話：你們有那么忙么？一把辛酸淚啊！

都說某單位（總體部門）牛，真的牛。有個軟件剛寫好測評完，人家說通信協(xié)議改了，改就改了吧，還得3天內(nèi)改完，帶著軟件去參加匹配。加班加點改完去了北京，人家說別急，協(xié)議又變了，我們的軟件人員還沒改呢，你們先把協(xié)議對一對，現(xiàn)場改吧。于是又在北京陪了一周，當(dāng)了一周的北漂。后來，軟件改好了，我把軟件帶回來測評，設(shè)備留在某單位。又出差一次把軟件釋放設(shè)備上，本以為沒事可以回去了，某單位的朋友發(fā)話了：聯(lián)試完了再走吧，萬一出了問題呢？于是又陪。等某單位安裝設(shè)備等了3天，調(diào)試設(shè)備又等了4天，終于可以開始聯(lián)試了！剛開始就遇到問題（不是軟件的問題），接著就是排查，就這么折騰著，又一周過去了，測試項還沒跑完。家里一堆活，實在等不及只好找個借口先撤了。

再后來，陪試驗。本以為是輕松活，誰想并不輕松。由于其它項目的原因，每天抱著QT的書使勁啃，早上趕完飯點就回宿舍啃書本敲代碼，剛開始還參加下單位的團體活動，后來發(fā)現(xiàn)寫代碼的進度比預(yù)期落后，索性啥活動也不參加，回歸為標(biāo)準(zhǔn)的宅男。

陪的事情就吐槽到這，再說說對工作的感悟。

經(jīng)過這兩年的工作，我對軟件開發(fā)的基本認(rèn)識是：業(yè)務(wù)框架+技術(shù)框架。

業(yè)務(wù)框架的構(gòu)造通常輔以UML工具進行業(yè)務(wù)流程的識別和設(shè)計，技術(shù)框架主要考慮面向?qū)ο笤O(shè)計、設(shè)計模式、結(jié)構(gòu)化分析、算法設(shè)計等理論方法和系統(tǒng)平臺選擇、開發(fā)環(huán)境選擇等工程化環(huán)境選擇。只要這兩個框架搭好了，開發(fā)軟件就不困難。像我這種半路跳槽來開發(fā)軟件的人也能寫軟件就是活生生的例子。剛來軟件開發(fā)中心的時候，我對業(yè)務(wù)流程并不熟悉，有一段時間很被動。經(jīng)過學(xué)習(xí)和同事的指導(dǎo)，理解了前人的技術(shù)框架和整體業(yè)務(wù)流程，不但維護了代碼，還可以在該框架的基礎(chǔ)上開發(fā)些新功能出來。

就我從事的業(yè)務(wù)領(lǐng)域而言，業(yè)務(wù)框架和業(yè)務(wù)流程是清晰的，短期內(nèi)不會有大的變動，現(xiàn)階段的主要工作就是優(yōu)化和移植。但依然有問題在困擾我們：

1.通信協(xié)議過于復(fù)雜，數(shù)據(jù)在設(shè)備間傳輸?shù)倪^程中被切分的很細(xì)小，導(dǎo)致頻繁的拼幀解幀，給編程工作帶來不便，即使現(xiàn)在對協(xié)議棧做了整體封裝，由于協(xié)議本身的彈性有限且復(fù)雜度較高，未來協(xié)議一旦發(fā)生改變，維護工作量不會小；2.重復(fù)編程的煩惱。不同項目間的配置項大致相同，甚至一個項目中的幾個配置項的大量功能重疊，導(dǎo)致為相同功能重復(fù)編程花費了大量的人力。且不同人員的編程方法千差萬別，一方面導(dǎo)致軟件質(zhì)量參差不齊，另一方面由于接口不統(tǒng)一，好的軟件構(gòu)件也無法復(fù)用。如果我們能從多個項目或單個項目的多個配置項出發(fā)，進行系統(tǒng)分析和設(shè)計，識別相同的構(gòu)件，使多個軟件在一個框架下進行開發(fā)，提高復(fù)用度，也許可以減少重復(fù)編程，提高開發(fā)效率和質(zhì)量。這個方法我在某項目中進行了嘗試，封裝了一個協(xié)議棧，雖然過程坎坷，但表明路線可行；3.需求變更多。之前的故事里已經(jīng)有了例子，我們技術(shù)人員無法控制變更，唯一能做的就是在設(shè)計之初增加軟件框架的彈性，為可能的變更留下余地（或者干脆想辦法拒絕變更）。

4.對軟件功能和性能的要求越來越高。系統(tǒng)方的設(shè)計指標(biāo)越來越高，很多硬件的效能必須靠軟件進行體現(xiàn)。而且在自動化控制/信號處理方面也必須借助相關(guān)的算法和技術(shù)才能實現(xiàn)。這些方面我們還需要摸索和積累；5.新技術(shù)的運用。新技術(shù)通常代表了更高的生產(chǎn)效率，但它同樣不是萬能的。新技術(shù)的學(xué)習(xí)需要周期，適應(yīng)也要有過程，而且新技術(shù)也存在自身的劣勢，這種劣勢往往是傳統(tǒng)技術(shù)的優(yōu)勢。比如QT開發(fā)程序的編譯和運行速度在windows平臺下明顯差于VC開發(fā)環(huán)境，VC編程人員無法無縫遷移至QT，很多習(xí)慣的編程方法不適用（但是搞VC的遷移到.net或VB就很快）。所以我的感受是不必強求新技術(shù)，技術(shù)框架間更多的是一種互補關(guān)系。

6.界面設(shè)計。被拿出來說事兒的次數(shù)較多。如果有專業(yè)UI設(shè)計人員進行設(shè)計，對我們的工作就更有幫助。

最后，身體是最重要的，祝大家都身體健康！

 

來源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問題，請聯(lián)系我們及時刪除。

《一個軟件工程師的年終總結(jié)》由互聯(lián)網(wǎng)用戶整理提供,轉(zhuǎn)載分享請保留原作者信息,謝謝!
鏈接地址：http://www.seogis.com/gongwen/188380.html

• 上一篇：從與他人分享經(jīng)驗活動總結(jié)
• 下一篇：2018年門診個人工作總結(jié)及2019年工作計劃