我們期待自己成為一個優秀的軟件模型設計者，但是，要怎樣做，又從哪里開始呢？
將下列原則應用到你的軟件工程中，你會獲得立桿見影的成果。
1. 人遠比技術重要
你開發軟件是為了供別人使用，沒有人使用的軟件只是沒有意義的數據的集合而已。許多在軟件方面很有成就的行家在他們事業的初期卻表現平平，因為他們那時侯將主要精力都集中在技術上。顯然，構件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的東西。但是對于用戶來說，如果你設計的軟件很難使用或者不能滿足他們的需求，后臺用再好的技術也于事無補。多花點時間到軟件需求和設計一個使用戶能很容易理解的界面上。
2. 理解你要實現的東西
好的軟件設計人員把大多數時間花費在建立系統模型上，偶爾寫一些源代碼，但那只不過是為了驗證設計過程中所遇到的問題。這將使他們的設計方案更加可行。
3. 謙虛是必須的品格
你不可能知道一切，你甚至要很努力才能獲得足夠用的知識。軟件開發是一項復雜而艱巨的工作，因為軟件開發所用到的工具和技術是在不斷更新的。而且，一個人也不可能了解軟件開發的所有過程。在日常生活中你每天接觸到的新鮮事物可能不會太多。但是對于從事軟件開發的人來說，每天可以學習很多新東西（如果愿意的話）。
4. 需求就是需求
如果你沒有任何需求，你就不要動手開發任何軟件。成功的軟件取決于時間（在用戶要求的時間內完成）、預算和是否滿足用戶的需求。如果你不能確切知道用戶需要的是什么，或者軟件的需求定義，那么你的工程注定會失敗。
5. 需求其實很少改變，改變的是你對需求的理解
Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜歡說：“分析是一門科學，設計是一門藝術”。他的意思是說在眾多的“正確”分析模型中只存在一個最“正確”分析模型可以完全滿足解決某個具體問題的需要（我理解的意思是需求分析需要一絲不茍、精確的完成,而設計的時候反而可以發揮創造力和想象力 - 譯者注）。
如果需求經常改動，很可能是你沒有作好需求分析，并不是需求真的改變了。
你可以抱怨用戶不能告訴你他們想得到什么，但是不要忘記，收集需求信息是你工作。
你可以說是新來的開發人員把事情搞得一團糟，但是，你應該確定在工程的第一天就告訴他們應該做什么和怎樣去做。
如果你覺得公司不讓你與用戶充分接觸，那只能說明公司的管理層并不是真正支持你的項目。
你可以抱怨公司有關軟件工程的管理制度不合理，但你必須了解大多同行公司是怎么做的。
你可以借口說你們的競爭對手的成功是因為他們有了一個新的理念，但是為什么你沒先想到呢？
需求真正改變的情況很少，但是沒有做好需求分析工作的理由卻很多。
6. 經常閱讀
在這個每日都在發生變化的產業中，你不可能在已取得的成就上陶醉太久。
每個月至少讀2、3本專業雜志或者1本專業書籍。保持不落伍需要付出很多的時間和金錢，但會使你成為一個很有實力的競爭者。
7. 降低軟件模塊間的耦合度
高耦合度的系統是很難維護的。一處的修改引起另一處甚至更多處的變動。
你可以通過以下方法降低程序的耦合度：隱藏實現細節，強制構件接口定義，不使用公用數據結構，不讓應用程序直接操作數據庫（我的經驗法則是：當應用程序員在寫SQL代碼的時候，你的程序的耦合度就已經很高了）。
耦合度低的軟件可以很容易被重用、維護和擴充。
8. 提高軟件的內聚性
如果一個軟件的模塊只實現一個功能，那么該模塊具有高內聚性。高內聚性的軟件更容易維護和改進。
判斷一個模塊是否有高的內聚性，看一看你是否能夠用一個簡單的句子描述它的功能就行了。如果你用了一段話或者你需要使用類似“和”、“或”等連詞，則說明你需要將該模塊細化。
只有高內聚性的模塊才可能被重用。
9. 考慮軟件的移植性
移植是軟件開發中一項具體而又實際的工作，不要相信某些軟件工具的廣告宣傳（比如java 的宣傳口號write once run many ? 譯者注）。
即使僅僅對軟件進行常規升級，也要把這看得和向另一個操作系統或數據庫移植一樣重要。
記得從16位Windows移植到32位windows的“樂趣”嗎 ？當你使用了某個操作系統的特性，如它的進程間通信(IPC)策略，或用某數據庫專有語言寫了存儲過程。你的軟件和那個特定的產品結合度就已經很高了。
好的軟件設計者把那些特有的實現細節打包隱藏起來，所以，當那些特性該變的時候，你的僅僅需要更新那個包就可以了。
10. 接受變化
這是一句老話了：唯一不變的只有變化。
你應該將所有系統將可能發生的變化以及潛在需求記錄下來,以便將來能夠實現（參見“Architecting for Change”，Thinking Objectively, May 1999）
通過在建模期間考慮這些假設的情況，你就有可能開發出足夠強壯且容易維護的軟件。設計強壯的軟件是你最基本的目標。
11. 不要低估對軟件規模的需求
Internet 帶給我們的最大的教訓是你必須在軟件開發的最初階段就考慮軟件規模的可擴充性。
今天只有100人的部門使用的應用程序，明天可能會被有好幾萬人的組織使用，下月，通過因特網可能會有幾百萬人使用它。
在軟件設計的初期，根據在用例模型中定義的必須支持的基本事務處理，確定軟件的基本功能。然后，在建造系統的時候再逐步加入比較常用的功能。
在設計的開始考慮軟件的規模需求，避免在用戶群突然增大的情況下，重寫軟件。
12. 性能僅僅是很多設計因素之一
關注軟件設計中的一個重要因素--性能，這好象也是用戶最關心的事情。一個性能不佳的軟件將不可避免被重寫。
但是你的設計還必須具有可靠性，可用性，便攜性和可擴展性。你應該在工程開始就應該定義并區分好這些因素，以便在工作中恰當使用。性能可以是，也可以不是優先級最高的因素，我的觀點是，給每個設計因素應有的考慮。
13. 管理接口
“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你應該在開發階段的早期就定義軟件模塊之間的接口。
這有助于你的開發人員全面理解軟件的設計結構并取得一致意見，讓各模塊開發小組相對獨立的工作。一旦模塊的接口確定之后，模塊怎樣實現就不是很重要了。
從根本上說，如果你不能夠定義你的模塊“從外部看上去會是什么樣子”，你肯定也不清楚模塊內要實現什么。
14. 走近路需要更長的時間
在軟件開發中沒有捷徑可以走。
縮短你的在需求分析上花的時間，結果只能是開發出來的軟件不能滿足用戶的需求，必須被重寫。
在軟件建模上每節省一周，在將來的編碼階段可能會多花幾周時間，因為你在全面思考之前就動手寫程序。
你為了節省一天的測試時間而漏掉了一個bug，在將來的維護階段，可能需要花幾周甚至幾個月的時間去修復。與其如此，還不如重新安排一下項目計劃。
避免走捷徑，只做一次但要做對（do it once by doing it right）。
15. 別信賴任何人
產品和服務銷售公司不是你的朋友，你的大部分員工和高層管理人員也不是。
大部分產品供應商希望把你牢牢綁在他們的產品上，可能是操作系統，數據庫或者某個開發工具。
大部分的顧問和承包商只關心你的錢并不是你的工程（停止向他們付款，看一看他們會在周圍呆多長時間）。
大部分程序員認為他們自己比其他人更優秀，他們可能拋棄你設計的模型而用自己認為更好的。
只有良好的溝通才能解決這些問題。
要明確的是，不要只依靠一家產品或服務提供商，即使你的公司（或組織）已經在建模、文檔和過程等方面向那個公司投入了很多錢。
16. 證明你的設計在實踐中可行
在設計的時候應當先建立一個技術原型， 或者稱為“端到端”原型。以證明你的設計是能夠工作的。
你應該在開發工作的早期做這些事情，因為，如果軟件的設計方案是不可行的，在編碼實現階段無論采取什么措施都于事無補。技術原型將證明你的設計的可行性，從而，你的設計將更容易獲得支持。
17. 應用已知的模式
目前，我們有大量現成的分析和設計模式以及問題的解決方案可以使用。
一般來說，好的模型設計和開發人員，都會避免重新設計已經成熟的并被廣泛應用的東西。http://www.ambysoft.com/processPatternsPage.html收藏了許多開發模式的信息。
18. 研究每個模型的長處和弱點
目前有很多種類的模型可以使用,如下圖所示。用例捕獲的是系統行為需求，數據模型則描述支持一個系統運行所需要的數據構成。你可能會試圖在用例中加入實際數據描述，但是，這對開發者不是非常有用。同樣，數據模型對描述軟件需求來說是無用的。每個模型在你建模過程中有其相應的位置，但是，你需要明白在什么地方，什么時候使用它們。
19. 在現有任務中應用多個模型
當你收集需求的時候，考慮使用用例模型，用戶界面模型和領域級的類模型。
當你設計軟件的時候，應該考慮制作類模型，順序圖、狀態圖、協作圖和最終的軟件實際物理模型。
程序設計人員應該慢慢意識到，僅僅使用一個模型而實現的軟件要么不能夠很好地滿足用戶的需求，要么很難擴展。
20. 教育你的聽眾
你花了很大力氣建立一個很成熟的系統模型，而你的聽眾卻不能理解它們，甚至更糟－連為什么要先建立模型都不知道。那么你的工作是毫無意義的。
教給你開發人員基本的建模知識；否則，他們會只看看你畫的漂亮圖表，然后繼續編寫不規范的程序。
另外， 你還需要告訴你的用戶一些需求建模的基礎知識。給他們解釋你的用例(uses case)和用戶界面模型，以使他們能夠明白你要表達地東西。當每個人都能使用一個通用的設計語言的時候（比如UML-譯者注），你的團隊才能實現真正的合作。
21. 帶工具的傻瓜還是傻瓜
你給我CAD/CAM工具，請我設計一座橋。但是，如果那座橋建成的話，我肯定不想當第一個從橋上過的人，因為我對建筑一竅不通。
使用一個很優秀的CASE工具并不能使你成為一個建模專家，只能使你成為一個優秀CASE工具的使用者。成為一個優秀的建模專家需要多年的積累，不會是一周針對某個價值幾千美元工具的培訓。一個優秀的CASE工具是很重要，但你必須學習使用它，并能夠使用它設計它支持的模型。
22. 理解完整的過程
好的設計人員應該理解整個軟件過程，盡管他們可能不是精通全部實現細節。
軟件開發是一個很復雜的過程，還記得《object-oriented software process》第36頁的內容嗎？除了編程、建模、測試等你擅長工作外，還有很多工作要做。
好的設計者需要考慮全局。必須從長遠考慮如何使軟件滿足用戶需要，如何提供維護和技術支持等。
23. 常做測試，早做測試
如果測試對你的軟件來說是無所謂的，那么你的軟件多半也沒什么必要被開發出來。
建立一個技術原型供技術評審使用，以檢驗你的軟件模型。
在軟件生命周期中，越晚發現的錯誤越難修改，修改成本越昂貴。盡可能早的做測試是很值得的。
24. 把你的工作歸檔
不值得歸檔的工作往往也不值得做。歸檔你的設想，以及根據設想做出的決定；歸檔軟件模型中很重要但不很明顯的部分。 給每個模型一些概要描述以使別人很快明白模型所表達的內容。
25. 技術會變，基本原理不會
如果有人說“使用某種開發語言、某個工具或某某技術，我們就不需要再做需求分析，建模，編碼或測試”。不要相信，這只說明他還缺乏經驗。拋開技術和人的因素，實際上軟件開發的基本原理自20世紀70年代以來就沒有改變過。你必須還定義需求，建模，編碼，測試，配置，面對風險，發布產品，管理工作人員等等。
軟件建模技術是需要多年的實際工作才能完全掌握的。好在你可以從我的建議開始，完善你們自己的軟件開發經驗。
以雞湯開始，加入自己的蔬菜。然后，開始享受你自己的豐盛晚餐吧。
程序員的10種級別
來源：http://www.javaresearch.org/faq/thread.jsp?column=723&thread=46872
|
發表時間: 2006-02-20 16:22
?作者：jshao
頭銜: JR元老專家
|
|
程序員的10種級別?
??
第一級：神人，天資過人而又是技術狂熱者同時還擁有過人的商業頭腦，高瞻遠矚，技術過人，大器也。如丁磊，求伯君。?
第二級：高人，有天賦，技術過人但沒有過人的商業頭腦，通常此類人不是頂尖黑客就是技術總監之流。?
第三級：牛人，技術精湛，熟悉行業知識，敢于創新，有自己的公司和軟件產品。?
第四級：工頭，技術精湛，有領導團隊的能力，此類人大公司項目經理居多。?
第五級：技術工人，技術精湛，熟悉行業知識但領導能力欠加，此類人大多為系分人員或資深程序員，基本上桀驁不遜，自視清高，不愿于一般技術人員為伍，在論壇上基本以高手面目出現。?
第六級：熟練工人，技術有廣度無深度，喜歡鉆研但淺嘗輒止。此類人大多為老程序員，其中一部分喜歡利用工具去查找網上有漏洞的服務器，干點壞事以獲取成績感。如果心情好，在論壇上他們會回答菜鳥的大部分問題。此級別為軟件業苦力的重要組成部分。?
第七級：工人，某些技術較熟練但缺乏深度和廣度，此類人大多為程序員級別，經常在論壇上提問偶爾也回答菜鳥的問題。為軟件產業苦力的主要組成部分。?
第八級：菜鳥，入門時間不長，在論壇上會反復提問很初級的問題，有一種唐僧的精神。雖然招人煩但基本很可愛。只要認真鉆研，一兩年后就能升級到上一層。?
第九級：大忽悠，利用中國教育的弊病，頂著一頂高學歷的帽子，在小公司里混個軟件部經理，設計不行，代碼不行，只會胡亂支配下屬，拍領導馬屁，在領導面前胡吹海侃，把自己打扮成技術高手的模樣。把勾心斗角的辦公室文化引入技術部門，實在齷齪！?
第十級：驢或傻X，會寫SELECT語句就說自己精通ORALCE，連寄存器有幾種都不知道就說自己懂匯編，建議全部送到日本當IT產業工人，掙了日本人的錢還嚴重打擊日本的軟件業！?
其中又以前兩級和后兩級最為難得，其余級別只要努力，皆有可能達到。
|
? |
JAVA高手的基礎素養
來源：http://www.javaresearch.org/faq/thread.jsp?column=723&thread=38473
|
發表時間: 2005-10-07 22:25
作者: xuyy_cn
頭銜: JR元老專家
|
|
世界上并沒有成為高手的捷徑，但一些基本原則是可以遵循的。??
1、扎實的基礎??
數據結構、離散數學、編譯原理，這些是所有計算機科學的基礎，如果不掌握它們，很難寫出高水平的程序。程序人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學OOP，即使你再精通OOP，遇到一些基本算法的時候可能也會束手無策。因此多讀一些計算機基礎理論方面的書籍是非常有必要的。??
2、豐富的想像力??
不要拘泥于固定的思維方式，遇到問題的時候要多想幾種解決問題的方案，試試別人從沒想過的方法。豐富的想像力是建立在豐富的知識的基礎上，除計算機以外，多涉獵其他的學科，比如天文、物理、數學等等。開闊的思維對程序員來說很重要。??
3、最簡單的是最好的??
????? 這也許是所有科學都遵循的一條準則，復雜的質能轉換原理在愛因斯坦眼里不過是一個簡單得不能再簡單的公式：E=mc2。簡單的方法更容易被人理解，更容易實現，也更容易維護。遇到問題時要優先考慮最簡單的方案，只有簡單方案不能滿足要求時再考慮復雜的方案。??
4、不鉆牛角尖??
當你遇到障礙的時候，不妨暫時遠離電腦，看看窗外的風景，聽聽輕音樂，和朋友聊聊天。當我遇到難題的時候會去玩游戲，當負責游戲的那部分大腦細胞極度亢奮的時候，負責編程的那部分大腦細胞就得到了充分的休息。當重新開始工作的時候，我會發現那些難題現在竟然可以迎刃而解。??
5、對答案的渴求??
人類自然科學的發展史就是一個渴求得到答案的過程，即使只能知道答案的一小部分也值得我們去付出。只要你堅定信念，一定要找到問題的答案，你才會付出精力去探索，即使最后沒有得到答案，在過程中你也會學到很多東西。??
6、多與別人交流??
三人行必有我師，也許在一次和別人不經意的談話中，就可以迸出靈感的火花。多上上網，看看別人對同一問題的看法，會給你很大的啟發。??
7、良好的編程風格??
注意養成良好的習慣，代碼的縮進編排，變量的命名規則要始終保持一致。大家都知道如何排除代碼中錯誤，卻往往忽視了對注釋的排錯。注釋是程序的一個重要組成部分，它可以使你的代碼更容易理解，而如果代碼已經清楚地表達了你的思想，就不必再加注釋了，如果注釋和代碼不一致，那就更加糟糕。??
8、韌性和毅力??
這也許是“高手”和一般程序員最大的區別。高手們并不是天才，他們是在無數個日日夜夜中磨煉出來的。成功能給我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。你不妨做個測試，找個10000以內的素數表，把它們全都抄下來，然后再檢查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這一條
|
軟件高手是這樣練成的
來源：http://www.javaresearch.org/faq/thread.jsp?column=723&thread=39051
|
發表時間: 2005-10-15 00:53
作者：xuyy_cn
頭銜: JR元老專家
|
|
???? 中國人大都喜歡用武俠小說來比較軟件開發，但是在實戰武功中，只有葵花寶典才是最厲害的，也只有掌握了葵花寶典，才能稱為“不敗”。?
???? 但什么才是軟件開發的葵花寶典？?
讓我們先從一些現象出發。我們的前提是，軟件開發是一項智力密集型勞動。對于智力密集型勞動，我們觀察到的現象是，個體的表現差異很大，團隊的表現差異很大，組織的表現差異很大，國家的表現差異很大。這不象體力占主要的勞動，象百米王跑百米的速度也僅比我快50%。但在棋類運動中，一個高手可以車輪戰數位低手，而且毫無例外地將他們一一擊敗！?
這些智力運動員表現出的特點是，計算精確而且速度快。其行為很象東方不敗。雖然關于葵花寶典的傳說很多，但最準確的描述只有一個字“快”。東方不敗已經快到了嚇人的地步。就象卡斯帕羅夫已快到了深藍的地步。?
有一則關于物理學家玻爾的軼事，有一次玻爾在普林斯頓大學聽兩個年青教授演講他們的工作成果。期間玻爾突然發言說，如果照你們的研究算下去，會得到一個很有意思的推論。結果兩個年青教授回去計算了兩天，果然得出了同樣的結論。玻爾是如何做到這樣快的？?
在軟件開發中，我們同樣注意到這樣一種高手，他們可以每天寫出一千行左右的高品質代碼。他們可以運用已有的一些軟件包，迅速完成一個新的產品。他們可以在很短的時間內，學會一項新的程序語言或是新技術。他們表現出一種神奇的速度。?
在武俠小說中，所有的高手都有一些凡人不能企及的表現。象張無忌學太極，用龍爪手擊敗龍爪手名家；喬峰用太祖長拳擊敗天下英雄；姑蘇慕容以其人之道還治其人之身，令狐沖一劍剌瞎十幾雙眼睛等等。我認為，之所以他們能做到這樣，關鍵是在于他們快。?
快并不意味著不準或品質差。快與品質并不矛盾。?
高手的快，其實包含著很高的品質在其中。如果你因為高手的快，就質疑其品質，那就相當于在問：東方不敗出手那么快，會不會刺不準？東方不敗并不滿足于刺死對手，他會在對手身上刺朵花。他把殺人變成了藝術。準確來說，他真正的興趣不在殺人，而在于藝術。?
退一步說，就算東方不敗第一擊有點偏差，他稍作修正后，馬上跟上的第二第三擊，也會擊中他想擊中的地方。在武功差的對手劍還沒撥出來的時候，他已殺死對方并刺上了一朵花。?
所以真正的軟件高手，他并不滿足于他的代碼能有效地工作了，他認為編程是藝術，并醉心于其中。在低手能寫出一個版本的時間里，他已經寫出了第十版。其品質當然不可同日而語。就象一個九段棋手，在給定的時間里，他能計算十種可能，并將每種可能計算到100手之后，從中選擇一種最有利的下法。低手豈有茍全的機會？?
高手寫軟件總是不停地在重構(refactoring）。高手喜歡迭代式開發。高手說，增量就是打補丁，迭代就是推倒重來。對于軟件這種東西，寫一遍它可能ok（做到這一點也不容易），寫十遍就是一個偉大的產品，再多寫一遍它就更偉大些。?
高手快的訣竅在于他很熟悉各種東西。高手看書很快，因為每一本新書里，值得他好好看的新技術只有一兩章的內容。他能迅速看完，并準確領會這本書的中心思想和價值。而對于一個新手，每句話都是新的，他都需要去理解，每一段例子，他都需要去試。?
很少看到一種100%全新的技術或理論。就象java?language?specification里說的，java沒有使用任何新技術，用的都是業界久經考驗的技術。對于高手來說，那些技術都是他所熟悉的。自然，很快他就從一個c++高手變成了java高手。如果一個編程新手學java，學兩年也不如一個高手學兩個月的。高手學新東西快。?
高手寫代碼速度快。統計結果說，人均每人月的有效代碼速度大概是300至400行。但那是業界平均生產效率。對于高手來說，這個數字太低了。每天寫300至400行是完全有可能的。因為在寫代碼時，所有知識都已具備，已經沒有任何需要他多花時間的事情了。他甚至很少需要debug。?
高手重用代碼的能力很強，熟悉新的api的速度很快。這也是因為，他曾經使用過很多的api，重用過很多的代碼。他知道哪些是可用的，哪些有缺陷。他既過用qt，也用過gtk+，也用過windows?api?&?mfc，也用過awt?&?swing。新的api對他來說，也是老熟人。?
????? 高手喜歡用輕量級的工具，象vi，notepad，最多到ultraedit這樣復雜的。高手用這種工具寫出很多的東西。這些工具就象東方不敗的針。那根針已具有神奇的魔力，有時候它可以當激光槍來用。?
對于一些重量級的工具，高手雖不常用，但一經使出也威力大于常人。如果讓東方不敗用劍，最厲害的劍術名家也會敗得很難看。高手其實用過很多的重量級工具，而且深知其優缺點。所以使出來，就會把威力發揮到最大，而把缺陷減少到最小。而低手則不然，總是把缺陷加以大大的發揚而渾不知其精髓何在。就象很多人學用uml、rup、xp、design?pattern那樣。?
高手所學博雜且融會貫通。高手做什么都快，當低手還在一愁莫展的時候，高手已經圓滿解決問題，去干別的事去了。?
相信你有一點點想成為高手了。但是有一個問題亟等解決，那就是“欲練神功，必先自宮”的問題。這一點其實是有比喻意義的。就是說，你必需拋棄一些世俗的人們很看重的東西。有詩為證：?
世人都曉高手好，只是寂寞受不了?
世人都曉高手好,?只有名利忘不了?
世人都曉高手好,?只有金錢一定要?
世人都曉高手好,?天下美女都要抱?
??????? 世人都曉高手好,?不寫代碼最最好?
高手的武功不是一朝一夕練成的。還記得玻爾那件軼事嗎，玻爾回答說，他年青時也計算過很多的問題。在很多計算的基礎上，高手能培養起一種感覺。高手不寫代碼就能做設計是因為他以前寫了很多的代碼。而且他們會保持寫代碼，以保證自已的水平不下降。想一想九段高手是如何練成的。最難做到的是能忍受十年磨一劍的寂寞。別人在父母那里撒嬌時，他們在一旁用功。十年磨一劍，劍就成了東方不敗的針。?
在你下定決心要做高手之后，也就是下定決心拋棄那些世俗的追求之后，也就是你下決心忍受那些來自于庸俗的人的白眼、攻擊和謾罵之后，你就具備了練成神功的必要條件。?
事實上其實你不必一開始就練神功，一開始大家可能是為了錢，房子，汽車，美女才編程序的，然而后來藝術就從中產生了。那時高手就不再關注那些東西了。卓別林曾說過，他開始進入那個圈子也是為了錢，后來藝術就從中產生了。當然，也有人一開始是為了藝術，后來變成為了錢。?
所謂三十而立，就是說到了三十，你找到了你的真愛，值得用一生去追求的那種。比如說有的人到了三十認為這一輩子應該賺盡可能多的錢，這也沒什么不好，也可以把賺錢本身變成一種藝術，所謂資本運作是也。所以在三十以前，有些私心雜念沒什么。三十以后還這樣是可恥的。而我，想做一個程序員。?
每個人做自己最喜歡的事。這個世界需要程序員，也需要資本運作。所有真正的程序員，他最喜歡的事是編程和他自已。如果他后來去做ceo去了，不再編程，只說明他本來不是一個真正的程序員。?
在成為高手的路上，要有熱情，要循序漸進，要持之以恒。?
要靠自己，書要快快地看。要試圖迅速理解其主旨。其實你快快看所接受的信息量，與慢慢看接受的差不多。能明白多少很大程度上取決于你的功底。以后用到再回過頭來看。一本對你來說新東西太多的書，不要指望看一次就全理解吸收。就象很多功力不夠的人看design?patterns那本書一樣。慢慢看還不如找到多種?信息來源，都快快看一遍。對于一個完全陌生的領域，只看一本書很遠遠不夠的。?
????? 要靠自已，事要快快做。有一個朋友，幾年前我介紹他去玩玩linux，他也表示想玩，但他現在還沒碰過。他失去了很多機會。
???? 平時要有意識提高自己寫代碼的速度，其實你一天寫15行有效代碼，與你寫50行有效代碼，其品質是差不多的。你應該把那些業界平均水平拋諸腦后，把超越自己做為唯一目標。等到你寫了很多各式各樣的代碼，你的水平就不一般了。一個老師曾向我介紹他的學英語的決竅，他說你去啃原版小說，啃到50本，就和一般人有很大距離了。就是這個理。如果你寫得太慢，怎么能寫得多？水平怎么能提高？?
要靠自己，學很多別人怕學的東西。低手總會說：這么多東西怎么學得過來啊。于是就少學或不學。這樣就成不了高手了。高手有非常廣的知識面，有很豐富的經驗。知道很多低手不知道的事。玩過很多低手聽都沒聽過的東西。?
要靠自己，努力滿足客戶的各種需求。個人技能是在滿足客戶的各種需求的過程中提高的。比如你喜歡用delphi，客戶說一定要用vb，那你就答應他，然后把自己培養成為vb的高手。用戶的需求看似**，但對你是一個機會。?
怎樣才能做到看書快，寫代碼快，學新東西快，一個顯而易見的途徑就是將工作并行化。你在一臺機器上make時，同時可以在看別的文檔和聊天。對于計算機是這樣，對人也是這樣。如果你只能串行地處理問題，你的速度將提高有限。你的大腦有很大潛力可挖，它應該是一個多任務分時系統。努力減少它idle的時間。搞經濟的samuelson被人稱為human?brain?main?frame，可見他的大腦有多快。?
讓你的思維快起來，你就會區別于那些反應遲鈍的人。如果你不能讓人生的道路變長，就讓它變寬。這世界變化快，需要你變得比它快才行。?
這樣加快并不會讓你短命，相反，你有更多的時間來享受生活和鍛煉身體。你的生活將更有品質，更豐富，更有意義。面對變化，你將立于不敗之地。我們都是和自己賽跑的人，需要跑得比昨天的自己更快。?
|
|