???????
需求調研、總體設計、開發過程、代碼結果、運行效率，也許這些是作為程序開發的我們所關注的問題。其實就這個過程中的每一步而言，都有向優雅方向努力的需要，也許最終會形成一個優雅的軟件項目工作方式。呵呵。。扯遠了，其實作為開發人員我們最為關心的也許就是優雅的系統框架以及代碼過程。優雅二字，說起來很
easy
，每個人隨口就可以說出來，但是真正的要去做到這兩個字實在是需要我們投入相當的的時間與精力去做這件事情。
??????
做開發已經好幾年了，自己也有很多的想法。雖然自己在過去的一年半時間里面離
開發逐漸遠去，但是回過頭來我依然覺得自己需要、也希望能投入到一線的開發過程當中。所以這段時間也在研究一些自己感興趣的內容，也是希望這些內容以后能與小組中其他人的興趣進行一些結合，碰撞出更多更絢麗的火花來。談到開發，談到優雅開發，我最近也是在琢磨“優雅”這兩個字
?????
。。。怎樣才能讓我們真正的向這個方向發展呢？我覺得有那么幾點內容是我們需要首先做到的：（裝次文人，所以用兩句古語來進行評點好了）
????
所有得軟件系統在設計系統框架得時候都必須能將未來做出更加充分得預測，同時需要在系統框架上做更多得工作使得系統得兼容性更好。說的很是空洞，其實簡單來看就是在系統框架設計上必須要符合一種靈活部署同時盡可能多的去滿足已知的軟件標準。確實，我們無法預知技術在
5
年，
10
年后會是什么樣子，甚至
3
年后會是個什么樣子我們都無法預測。
Ajax
基礎從
05
年年底開始橫掃互聯網，但是到了
06
年
12
月就開始出現“
Ajax
只是一種瘦客戶端向胖客戶端發展過程中的一個過渡技術”的聲音（對此，本人不置可否）。我不是大師，所以我無法知道這種過渡技術會有多久的生命力，但是我一直認為軟件系統中表示層技術更新的周期應該就是
3
年左右。所以我們仔考慮軟件核心系統的時候就必須去考慮如何讓軟件架構更為合理，讓軟件可以有更為優秀的生命力。
為了讓軟件能有更加強大的生命力，同時有更加良好的兼容性（永遠不要忘記，這是
一個合作的年代，沒有人說可以一個人獨霸武林的），我們在整個軟件系統的框架設計上就必須提供更加靈活的方式。這些要求我們的系統必須采用標準的信息、數據交換技術來實現，而不能僅僅只是支持我們自己的技術規范，我們需要支持的是一種標準的軟件規范。對于這些要求，我個人覺得軟件行業一直提倡的“構件”這個概念比較優越。按軟件構件提出的設想，我們最終的軟件就應該和
Windows
一樣的玩法：所有符合規范的軟件系統都能在一個平臺上進行簡單的安裝、配置然后完成其具體應用的實現。構件技術的使用可以有效降低重復投資率，抽取相關應用的共同點（肯定會有，沒有就繼續找，沒有共同點憑什么叫做“相關應用”？），建立基礎構建安裝管理平臺，然后在平臺上真正的實現軟件的即插即用，甚至是新的標準的兼容協議的即插即用。。。
?????
其實就支持標準規范這一點而言，我個人以前意識很弱，甚至說根本沒有這么去做，所以今天寫這文字的時候很是汗顏呀。。。
???
?
作為軟件系統，從本質而言，都是出于草根滴。如果在這種背景下你無法去做到一步一個腳印，做到博觀約取利用多方面的資源，踏踏實實，這個軟件系統最終很難成功。也正式這一點就對我們提出一個核心問題：堅持一下，再挖一米就是油：）
????
作為
java
程序員，很多人都會郁悶，郁悶的是
java
的開源社區太過于活躍了，總是不停的有新的內容需要你去學習，總有一些新的想法讓你感到震撼（震撼的結果就是－－去學）。但是就是因為開源社區的活躍實際上給我們提供了更好的一種開發模式，讓我們不需要去重復的創作一些已經存在的解決方式，讓我們能夠以最大限度的來進行根據需要開發還沒有實現的內容，或者是進行應用的整合達到目的。做到這些，我們需要不斷的更新自己的知識庫，不斷的再
java
社區攝取能量。（當然，社區也需要我們不斷的貢獻才能獲取其生命力）多看，多了解，也許很多東西你現在用不上，但就像技術趨勢一樣你無法預知今后你是否會用上，只有你有了一個容納很多概念的索引庫，才能在你想要實現應用時將這些概念融入到你的工作，捏開發之中。。。正所謂：磨刀不誤砍柴功是也
?????
所以，作為程序員，作為
java
程序員，你就必須要做到“博觀約取，厚積薄發”！這是你的工作對你的要求。
?
?
???? “
優雅”很難，但是我們都可以盡力去完成自己能做到的那一步。結合標準以及已有技術（框架、功能等），我們能再提高自己的代碼效率的同時讓自己的軟件變得更加生動。程序員只有再軟件讓自己感到滿足的時候這個軟件才是最好的，永遠都要想著怎么把需求引導到自己感興趣的內容之上！