寫在冬日的第一天--一個女程式設計師第七年工作總結

今年的天氣似乎特別暖和，雖說已經是冬天了我們這裡依然一片秋色。

 

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

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

 

1個人技術

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

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

 

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

 

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

 

2團隊管理

 

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

1.TDD,TestDriven Develop.看過書才知道這個多重要，作為程式設計師，悶頭寫程式碼可以但是如果寫測試很多人都會不情不願的(尤其小公司，沒有專門的人寫測試的script)。但是Test case的建立對於功能的擴充，維護是相當重要的，雖然開頭看起來寫測試是麻煩了一點但是這為以後節省的時間和資源是很大的.我所在的專案要是寫script的話還是比較困難的，於是我要求我的團隊寫文件。

2.當我們結束每一個Bug/Feature是真的結束而非半吊子。結束就是包括程式碼，註釋，對應文件等等。當團隊Build那一天不會因為某個看似完成實際上還需要那麼兩三句話的Bug而耽誤

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

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

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

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

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

 

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

 

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

 

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

 

最後還是那句話

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