在現在的這個項目組已快三個月，可以說這是我畢業後進入這家公司的參加的第一個正式的項目，早在8月底部長就問我願不願做這個項目，一直到9月中下旬才正式開始，而不是像之前參加的項目，都是中途加入項目的，剛明白我要做什麼，那個項目就結束了。
在參加這個項目的兩個多月裏，學到了點東西，也明白了點東西，如下(沒有什麼技術問題，只有工作方法)：
1，在項目開始時，多做準備工作，磨刀不誤砍材功的道理，在這裏體現出來。
這是一個有關通信的項目，我和另一程序員的工作就是負責把一種電文轉換爲另一種電文，而至於SOCKET通信之類的東西，則交由另個一人負責。因爲電文比較多，且文檔資料經常變更，所以PL在項目開始之初，就讓我們整理出兩個電文之間的轉換關係，比如由A電文轉換爲B，則整理成文檔要求細分到B的第N位，由A的第M位通過計算而來，這樣做，一是可以加深我們對電文轉換的理解，二是在實際寫代碼時可以不必去理解電文怎樣轉換了，因爲有這份文檔，只須照着寫就行。事實證明，這是一個很好的方法，因爲在以後的工作中，遇到什麼問題，就去找那份變換規則文檔，節省不少時間。
2，在閱讀文檔時，把發現的問題分(1,2,3,4。。。)記錄在筆記本上，在開會時就按那1,2,3,4的編號來提。
在看客戶提供的文檔時，肯定會碰到不少問題。對付這種情況，我之前的做法就是直接在文檔上劃出來，然後等到開會時再到處找，這樣做，在問題較少時還不會出現什麼問題，若問題較多，往往會出現漏掉某幾個問題的情況，如果再就這幾個問題去問客戶，則會給我方的工造成不小的麻煩，所以在最開始看電文轉換的時候，PL就說我，讓我把所有的問題都列成一個LIST，但是我不聽，果然有一次漏到一個問題未問，使得PL在組內開會時就批評我，並對我的印象大打折扣，在那之後，就對我特別嚴，只要發現產生問題的原因是因爲我，就會很嚴厲地說我。所以，把問題歸類，列表，是一個很好的工作習慣。
3，在實際工作時，若發現自己的風格和別人不一樣，在例會時提出來，並確定一個方法來修改代碼。
其實，這點根本就不用提的，因爲據我所知，所有的項目，都有自已確定的一套編碼規範，變量怎樣命名，註釋怎樣寫， 不同的模塊之間空幾行等。可是不知因爲什麼原因，只是在開始寫代碼時的一次例會時提到命名，註釋的規範，但是對於代碼的結構沒有說明，於是我和那個一起做電文轉換的哥們的代碼的風格就不一樣，主要區別體現在：他的是在定義類時，成員變量後緊跟着這個變量的屬性，而我的呢，則是把所的成員變量定義完後，再來定義屬性。很明顯示，在同一個項目內，兩種風格是不允許的，在一次例會時，客戶提出這個問題，PL問我們解決辦法，讓我和那哥們商量，是由哪位改，最後，我考慮我參加工作時間不長，就退讓說由我改。唉，其實在剛開始寫代碼時，我就發現這個問題，只是沒有提出來，不然，我也不會花上兩天的時間來改已經成型的代碼了。其實，團隊合作，這個很寬泛的概念，在這裏就可以體現出來，當由幾個人合作完成一項工作時，不能標新立意，哪怕是自己的方法沒錯或者更好，因爲這項目工作，是由幾個人一起來完成的。發現問題，及時提出，可以做工作效率大大提高。
4，確保所做的中間工具的運行結果是自己所期望的，也就是說，一定要確保中間工具的正確性。
對程序員來說，這點就是對於一些通用的函數，一定要確保其正確性。舉例說明，我所負責的編碼工作中，要大量用到數組，而在要經常查某一元素在數組中所處的位置，但是C#的數組這個數據類型沒有IndexOf()這個方法，於是就自己寫個吧，很簡單，不超過10行代碼，寫完後我就想當然地認爲這個方法是正確的，區區10行代碼，不必測試了，於是在其他地方，肆無忌憚地用，等到這幾天測試時，發現這個方法的運行結果不是我所期望的，於是就狂加班，一頓狂改，PL問我進度時我都是緊張西西的，因爲實在不好意思說自己已落後於進度表了，特別是在前幾天還高調宣佈已提前幾天完成工作的情況下，沒有辦法，只好晚上晚點走了。其實，在寫完IndexOf()這個方法後，只須拿出10分鐘甚至更少時間，就可以避免這幾天的加班，更重要的是，可以消除不必要的緊張感。
5，定期自我檢查工作成果。
其實這點和第4點差不多，但是我還是認爲4和下面要說的有點差別。以項目的實際情況爲例說明吧，在完成把一種電文轉換另一種電文之後，還是測試一下，看看結果是否正確。但是我沒有這樣做，而是寫完一個電文的轉換後，再接着去寫另一個的轉換，所在，在這幾天的DEBUG中，發現了不少問題，從而使得原計劃最晚週二就測試的計劃，推遲到今天下午才進行。雖然各個電文的轉換是並行的，並不存在一種電文的轉換會用到上一個電文轉換的結果，所以不存在上面第4點說明的情況，可是若能在完成一個模塊之後，在思維還很清晰時就自我檢查，發現問題馬上解決，並且在接下來的工作中，在相同的地方，可以特別小心地處理，而不是留到最後測試時再一一解決，用PL的話來說，把問題留到最後，沒有一點益處，還會給自己增加不安情緒。這不，最近我就一直在緊張地加班，一聽到PL叫我名字，我就發悚，以爲又是哪個地方我做錯了。
6，對應問題點時，對應完畢在提交工作成果之前，一定要再次確認後，才提交。
每次開例會，PL總會指出幾個新問題，並且詢問上次的問題是否完全解決。這對於那些態度認真的人來說，沒有什麼，但是對於我這種有點粗心，馬虎的的人來說，有時就會犯很嚴重的錯誤。因爲有好幾次，我都是沒有對應全部的問題點，或是隻是一部分對應所有的問題點，而還有一部分完全沒有更改。就是因爲這樣，也難怪PL會很嚴厲地對我了。所以，在這幾天的修改中， 我總是在修改完畢，上傳服務器之前，用對比工具對比一下前後的結果，然後再才放心地上傳到文件服務器上。
7，修改共通部分時，一定要通知項目組的所有成員。
這點，在最近共碰到過兩次，一次是另外兩人把我要用到的一個LOG消息的參數個數給改了，而沒有通知其他人，結果是我花了差不多三個小時來對應這個修改，二是我把一個常量的修改後，也是沒有通知其他人，結果另一哥們花一上午來DEBUG他的代碼，發現原因就是因爲那個改量了值的常量。共通部分雖小，但是影響很大，所以在更改之前，勿必全員通知，確認該不該改，這樣可以大大節省團隊的時間。
8，有效的交流，聽別人把話說完。
這應該是做人的基本禮儀吧，但是我經常忽視這點，在最開始和項目組的其他成員不熟悉時，還能做到，可是到後來和大家都混熟了，工作時就放開了，往往在別人話沒有說完就自以爲是的知道對方的意思，於是就很粗魯的打斷對方，這樣，無疑又加大的交流的成本，眼看項目的deadline越來越近，可不能在內部交流上再浪費時間。其實，不管和對方關係多好，也不能打斷對方的話，這點，以後一定要注意。
9，在進行重大的變更之前，做好備份工作，把應該上傳到版本管理服務器的。
對於這點，特別是在進行多個改動時，再改動完一個之後， 先上傳，然後再修改下一下，再上傳。。。。。不然，在發現某一個修改沒有必要時，到時連個哭的地方都找不到的。還是以第7點中的和共通有關的那個LOG信息來說明，最開始定義四個參數，修改後爲三個參數，然後另兩同事又改爲四個參數，而當時我正在對應這個修改，按照三個參數來修改，花了一上午，改完，沒有上傳，接下來再對應第二個大的修改，改到一半時參考其他同事的代碼，發現他的還是四個參數，而不是三個，於是跟他說起這樣，發現才發現他們又把三個改爲四個了，呵呵，這時，我要是重新取上一個版本，那我下午的修改完全白做，若再接着改，上午的工作白做。想哭，上哪找哭的地方去？
10，在定義常時時，最後在這個常量註明它是由誰定義的。
這點，我不知道是否正確，只是感覺在最後整理常量時，會發現要省事得多。因爲在項目進行時，沒有時間去爲每個常量的定義而和其他人商量，並且是在項目的中後期再去由專人來整理這些常量，這無疑給這人制造了一個不小的麻煩，因爲他不清楚這個常是做什麼用的，也不清楚這個常量能和其他哪個常量合併。所以在定義常量時，註明使用者，這樣在修改時，若看註釋還不明白的話， 就可以很方便地知曉它是由誰定義，於是這整理工作，就要輕鬆很多了。
---------------------------------------------------------------------------------------
今天在公汽上想到的，好像不止這十點，等想到後，再補上來。