08年的感想

08年的感想

 

08年是不平凡的一年，物價飛漲、汶川地震、北京奧運、股市大跌、經濟危機、三鹿牛奶等等都在這一年中發生了。

 

記憶如同瘋長的野草，就過去的事情很快就漸漸模糊了，多年後，只有透過51cto的博客，才能找回往昔的星星點點，所以要堅持寫博客，再忙也要寫。

 

眼下就要對08說byebye了，回想一年中的經歷，有收穫也有遺憾。

 

最大的收穫就是換了份工做並認識了不少同事（如今是好朋友），拓寬了技術領域，使我更清楚的認識技術自己，也從新認識java，思考人生。

 

java不是萬能的，要成爲一個優秀的程序員，精通一門語言還不夠，有不少問題用Java也許能作，可是代價太沉重，若是用C、C++、C#等，問題會迎刃而解。

 

Java不是最好的，有時候開源的東西作得更好，好比Apache的commons，不少功能都是對Java API的補充。用到本身的項目中，會讓你省去不少時間編寫一些基礎的代碼。我在本身的項目中，大量用到Apache的提供的組件，令工做的效率質量獲得了史無前例的提升。好比上篇的文件的操做，當初是本身用遞歸寫的。可是仍是Apache封裝的全面、好用，畢竟人家就是「補丁專家」，不服有罪。

 

技術是爲需求服務的，不要爲用技術而用技術。一味的追求流行技術是不明智的。好比你在作一個網站，你非要採用struts二、ajax....等等。到頭來甚至不如人家在短期內用php作得好。

 

對一個軟件項目來講，系統的分析、系統設計是第一重要的。沒有好分析，就沒法全面把握需求，需求是須要挖掘的，須要分析和篩選的。需求的分析最好是採用UML的用例圖來描述，簡單也容易維護，由於沒有一成不變的需求，固然也不必搞太複雜，寫大堆的doc文檔作需求是極其愚蠢的，在作需求分析以前，應該與客戶交流作一份軟件的前景文檔，這是客戶、開發人員雙方都承認的一個藍圖。

 

系統設計是系統實現的基礎依據，對於中小型公司的項目來講，若是沒法按照標準的RUP進行迭×××發，就不要硬套UP開發。不然項目的負責人會陷入兩難的局面。無論怎麼說，設計仍是少不了的。對於複雜的業務，能夠經過UML流程圖、序列圖、狀態圖來綜合描述，一般只用其一就能夠描述清楚。對於項目的大框架來講，開源的就那幾個套路，不必爲每一個業務都作出完整的類圖纔去寫代碼。

 

對於複雜的業務，必定經過活動圖來描述業務過程，對着圖去討論，不然口頭討論，紙上亂畫都是浪費時間沒有實效。所以，做爲一個項目的負責人，必定要學會用UML來表達本身的思想，用UML來交流。

 

技術不是最複雜的，一般作一個東西時，每每是業務讓技術人員陷入困境，寫代碼的時候流程還沒搞清楚----業務還沒想清楚，這是致使工做效率低下，代碼質量低下的罪魁。對一個熟練工來講，寫代碼是體力活，很快。新手另當別論，能夠將一些最簡單很具體的事情交給新手來作，對他們來講也是個學習的好機會。

 

還有一個很關鍵的問題，就是系統建模，實際上屬於系統設計的範疇。

系統建模可從兩個方面着手，一個是對象建模，一個是數據建模。這兩種模型的本質是同樣的，就看我的的習慣和工具了。

 

最流行的工具備兩種，一種是Rose、一種是PowerDesigner，就工具自己來講，PD更好些。站在OOA、OOD設計角度來講，ROSE更好。

建模的任務有二：一是找出系統中的實體、二是找出實體間的關係。

實體簡單說就是類或者表。

關係簡單說就是組合關係或外鍵。

其實都是很是的簡單的問題，但是每每在使用數據建模，不少人不去加外鍵----難道表之間不要緊嗎？ 有，那麼關係如何體現呢？ 問其故：外鍵不要也行，經過業務控制便可，呵呵，要知道，如今是建模，經過圖就能看到實體的關係，這纔是目的。

要是用Rose建模，組合關係一目瞭然。

一些英雄人物，在項目不太大的狀況下，他們能夠不用工具建模，而是在本身的大腦中建模，而後直接寫出類的代碼，最後從類的代碼生成數據表，最終能夠從這些對象生成實體關係圖、物理數據模型，真正達到了手中無劍心中有劍的境界。如今更講求團隊合做，不太推崇我的英雄主義。

 

08年的遺憾是有些計劃沒實現，作了一些沒有意義的工做。

 

09年作個計劃：

一、學習盜版Java----C#和ASP.NET, C#也很好玩，有時候仍是大有用處的,J2EE有很多東西用起來都至關費勁，看看微軟是怎麼作的。

 

二、學習下PHP5，只要能作出好網頁的技術都是好技術，關鍵是要簡單易行。

 

三、學習一下網頁設計（css、div、JavaScript）。

 

四、學習一門動態語言Groove，很喜歡這個。

 

六、研讀《人月神話》、《數據結構》。

 

七、補補英語，目標是提升E文技術文檔的閱讀速度和理解的準確性。