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

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

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

　　1、個人技術

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

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

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

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

　　2、團隊管理 

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

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

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

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

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

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

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

　　目前我們組的這個運轉模式得到了部門經理的認同，已經升級了現有的管理軟件，我就可以比較規范的依據"敏捷"模式管理了。

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

　　最后總結一下今年的工作狀態還不錯的，一直都在學習和摸索中。適應了角色的轉變，知道了如何應對問題。應付不來的，會去找適當的人尋求幫助。 

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

　　最后還是那句話

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