今年的天氣似乎特別暖和，雖說已經(jīng)是冬天了，我們這里依然一片秋色。 （寫于2011年11月7日）

　　這是我工作的第七年，要是一段感情的話正是七年之癢的時候。如果在感情中每年作一份總結(jié)，是不是就不會有傳說中的坎兒。

　　我所在的公司不大，地方也不大。見識不廣，深度不夠，太多的隨遇而安讓我的工作這么多年都起伏不大，必須承認我骨子里就是個吃貨和懶鬼。這篇文章僅僅是自己過去一年工作的總結(jié)，對于有理想有抱負的好青年就當看個反面教材然后鞭策自己更加努力吧。另外我現(xiàn)在的心境也是工作這么些年后的感受，歡迎閱讀以前的總結(jié)，在那里你也許會找到共鳴。

　　1、個人技術(shù)

　　話說畢業(yè)頭兩年我覺得技術(shù)噌噌的往上漲，會了好多東西，然后的幾年就緩慢爬行了。一個是我的工作性質(zhì)是做應(yīng)用的本來也不探討什么高深的技術(shù)點，另一個就是自己懶沒有好好利用時間充實自己。

　　而今年64bit的普及，賴以生存的AutoCAD開始嫌棄古老的VB6，勞動力市場等等原因使我不得不接觸掌握新技術(shù)。一些技術(shù)點，諸如SQL Server的spatial部分，把GIS的理論算法引入我所在的應(yīng)用領(lǐng)域；利用AutoCAD的.NET類重新設(shè)計已有系統(tǒng)。Linq, C#多線程，WPF編寫美觀的界面等等。學(xué)習(xí)新技術(shù)是個享受的過程，覺得自己開始跟得上時代的步伐。當然如果項目時間緊的話也會有壓力，總覺得用原來的技術(shù)很短時間搞定的東西，現(xiàn)在卻大大增加了開發(fā)時間。和上一次系統(tǒng)學(xué)習(xí)比起來，這次自己就要穩(wěn)重的多，雖然過去幾年并沒有在技術(shù)點上特別精進但是基本功更加扎實了，不會向上次那樣不知道從哪里下手。這次算是心理有底有步驟有計劃地學(xué)習(xí)，感覺好很多。

　　技術(shù)點的學(xué)習(xí)與應(yīng)用不僅僅對于我個人能力的一種提高，更是在很大程度上幫助軟件重新架構(gòu)。由于平臺的轉(zhuǎn)換，我們有機會對原有系統(tǒng)重新作分析、設(shè)計。以前的我完全是一個實施者，而現(xiàn)在所扮演的更多的是一個設(shè)計者。這種角色的轉(zhuǎn)變意味著責任更大，如果出錯就不是浪費我一個人的時間，而是從整體上浪費團隊資源。去年寫總結(jié)的時候我在尋覓軟件設(shè)計上面的建議，今年系統(tǒng)的看了UML和設(shè)計模式。強烈的意識到從理解理論到靈活運用實在不是一件簡單的事情。我的做法是從大的系統(tǒng)中選取一個相對獨立的子系統(tǒng)，根據(jù)學(xué)到的理論自己搭個設(shè)計，想想再搭另外一個，跟團對討論下，找找感覺。這個過程我大量依賴mindmap, flowchar, UML。 開始的草稿是Mindmap把需求細分，然后UML建立塊之間的關(guān)系。UML是個好東西，雖然它的各種規(guī)范讓設(shè)計在軟件生命周期中所占比例加大，但是它對于細節(jié)的考量是非常到位的。如果我可以把所要軟件的類圖、順序圖畫好那基本上就能證明這個東西我想明白了，另外還可以把它解釋給其他組員。在設(shè)計思想上我一般會從業(yè)務(wù)邏輯出發(fā)，比較注重可讀性，或者說是結(jié)構(gòu)更符合人腦邏輯。除非在非常要效率的地方，一些函數(shù)，類的分布才會看起來不那么順溜。每每這個時候一定要配有相關(guān)文檔。之所以會這樣一層一層的，大部分來源于自信心不強，沒有這些圖表文檔的支持，我不確定是否能夠把意思清晰準確的傳達給團隊其他成員，當然也不能夠保證過段時間自己就不會忘記。目前我還在磕磕絆絆的前進中，真心希望將來的某一天我可以熟練運用UML工具，做個合格軟件建筑師。

　　對我來說做架構(gòu)的過程是一個挑戰(zhàn)自己決策能力的過程。畢竟軟件是有生命的，它不斷成長完善，或者某些部分在不久的將來被卸掉。我看不到那么遠，設(shè)計時間太長影響工程進度，只能折中平衡。實施是同樣的道理，同一個函數(shù)可以用不同的方法實現(xiàn)。平衡與博弈是超出軟件設(shè)計與實施之外的能力，也就是俗話說的經(jīng)驗。在這個方面我還太嫩。

　　2、團隊管理 

　　去年的總結(jié)里面我寫了大段大段自認為的帶領(lǐng)小團隊的方法，如今總結(jié)為四個字：“敏捷開發(fā)”。年初的時候我的一個組員推薦我讀了敏捷開發(fā)的書，才發(fā)現(xiàn)我那些實踐中"創(chuàng)"出來的方法其實都是敏捷開發(fā)的一部分。建立在實踐基礎(chǔ)上的理論學(xué)習(xí)讓人茅塞頓開。下面寫一下除了去年那些方法我看過書以后覺得特別重要一定要記錄的

　　a) TDD(Test Driven Develop)。看過書才知道這個多重要，作為程序員，悶頭寫代碼可以，但是如果寫測試，很多人都會不情不愿的(尤其小公司，沒有專門的人寫測試的script)。但是Test case的建立對于功能的拓展，維護是相當重要的，雖然開頭看起來寫測試是麻煩了一點，但是這為以后節(jié)省的時間和資源是很大的。我所在的項目要是寫script的話還是比較困難的，于是我要求我的團隊寫文檔。

　　b) 當我們結(jié)束每一個Bug/Feature是真的結(jié)束而非半吊子。結(jié)束就是包括代碼、注釋、對應(yīng)文檔等等。當團隊Build那一天不會因為某個看似完成實際上還需要那么兩三句話的Bug而耽誤。

　　c) 無論是否面向客戶，每一個Build都是一個完整的msi(歸檔備案)。這樣我們可以輕松的比較每個版本之間的不同。

　　前兩個月又有兩個人歸到我的團隊下，我們開會規(guī)范統(tǒng)一了編碼規(guī)范，比如每一個函數(shù)前都會加三個單引號(這個在.NET里面很好用，可以自動生成幫助)。比如如何命名函數(shù)、變量。其實經(jīng)過一同工作，大家的編碼規(guī)范已經(jīng)在不經(jīng)意中逐步統(tǒng)一，這次只是正式明確出來以便新的組員盡快上手。

　　"敏捷開發(fā)"是現(xiàn)在比較流行的軟件開發(fā)模式，我的認識是他非常合適8個人以下的小團隊靈活作戰(zhàn)。它充分發(fā)揮團隊成員的主觀能動性，可以比較及時地調(diào)整狀態(tài)，降低資源損耗。雖然敏捷有正式的管理模式、工具，但一切一切的根源來自于團隊成員間的坦誠交流、相互信任。這兩樣沒有，根本"敏"不起來，大家心里都有自己的小九九，還不如不用"敏捷"。

　　信任和坦誠這種東西沒有硬性標準，只能靠團隊慢慢磨和，也靠緣分吧。這個方面我的運氣不錯，組內(nèi)合作討論的氣氛非常好。從這些比我勤奮比我有經(jīng)驗的組員們身上學(xué)到了很多東西。

　　目前我們組的這個運轉(zhuǎn)模式得到了部門經(jīng)理的認同，已經(jīng)升級了現(xiàn)有的管理軟件，我就可以比較規(guī)范的依據(jù)"敏捷"模式管理了。

　　今年我們部門作了一次人事變動，去年提及的那個不作為的經(jīng)理走了新來了一個。在一定程度上我需要輔助他的工作，這也給我提供了一些作為代表參與部門間會議以及決策層會議的機會。一種會議是傳遞意見給大家，需要演講。對于正式的演講不夠自信，總怕不能準確表達自己的意思。于是搭建了演示平臺，特別作了事例分析，作了ppt用作主脈絡(luò)。效果意外的好，得到了很多積極的反饋，對于以后的開發(fā)思路很有幫助。另外一種是聽取意見的，售前的哥們很能"吹毛求疵"，挑得毛病那個細那個偏。關(guān)鍵還不早說，開發(fā)周期尾端才說，一改又是麻煩。以前這樣的會議我不是主角跟著聽聽就好，現(xiàn)在成了主聽者，第一反應(yīng)就是抵觸、辯解。但是輪到我說話，我都只能說對不起，我們沒有考慮周到，下次會注意，也希望在開發(fā)進程中多多交流。能有這樣的態(tài)度也是工作時間長了的緣故，初出茅廬的時候應(yīng)該不會這樣說。“對不起”一說，明顯感覺到售前松了口氣，開發(fā)和銷售本來就不是兩個對立面，只有把這樣"挑"的毛病細化，在開發(fā)進程中循環(huán)出現(xiàn)才會減少不必要的成本浪費。我們是小公司，這些個互相交流指正不需要大家很正式的到會議室坐下，就是互相串門子的時候帶一句。做開發(fā)的把態(tài)度擺出來，歡迎各種意見建議，人家自然也就愿意過來。 

　　最后總結(jié)一下今年的工作狀態(tài)還不錯的，一直都在學(xué)習(xí)和摸索中。適應(yīng)了角色的轉(zhuǎn)變，知道了如何應(yīng)對問題。應(yīng)付不來的，會去找適當?shù)娜藢で髱椭?nbsp;

　　工作之外，記得去年說想去西藏于是就在雪域高原過了圣誕新年，今年的旅行提前到了金秋九月，冬天估計就不去遠的地方了。 

　　最后還是那句話

　　低頭做事，抬頭做人 
　　過幸福的小日子 :) 

it知識庫：一個女程序員第七年工作總結(jié)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。