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

各位領導，同事：

我的工作內(nèi)容與諸位（軟件開發(fā)中心的）同事承擔之事大同小異，主要談談一年來的工作情況和感悟：

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

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

今年的工作的關鍵詞是：陪。

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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