IT人的素質 & 設計雜談

IT 人應具備的一些素質

空杯心态，接受新事物。

沒有實踐就沒有發言權。

沒有徹底了解，不要去推翻它。

不要抨擊其它你認為沒有意義的技術，任何事物都有它産生的原因。

不要看不起老技術。隻有站在巨人的肩膀上，你才能看得更遠。

認識到：業務是收益、技術是成本。

設計雜談

如何做到方案設計得比較完善？答：一項浩大的方案設計，需要平時不斷地收集、整理問題。這樣才能在出解決方案的時候，做到盡量全面地解決問題。不可能靠人腦臨時想出一個完善的方案，很可能會丢三落四，顧此失彼。

WPF架構使用有感：

不熟悉架構的時候，使用架構寫出來的上層代碼很多都是無用的、雜亂的，這也正反映了底層知識的不足。

随着不斷的學習深入，逐漸地對這些上層代碼進行重構。每一次精簡，都是對底層知識的積累。

忽然有一天，你發現代碼被重構得非常簡練了，其實也會發現原來基礎知識也都越來越紮實了。回頭想想，當初寫的都是些什麼代碼，純粹是為了應急，搞出來就行……

删除沒必要的抽象（例如兩年内用不到的），每個抽象都增加了使用的複雜度。

程式都要盡量地解除耦合，單向依賴。但是有時候是無法做到的。

“雙向緊耦合的設計，往往是極度抽象的設計，很可能是經典一筆～”

例如 .NET 中的：AnimationTimeLine 和 Animatable。

要了解這樣的程式，也需要從抽象層面入手。

隻有當全面整體熟悉甚至精通這些理論與技術之後，設計才能做到得心應手：“程式設計手法”、資料結構、算法、資料庫、作業系統、程式設計語言、基礎平台類庫、基礎平台架構、網絡、ORM、XML、序列化、Web、協定、設計模式、架構模式、思維導圖、設計經驗。

寫了代碼那麼久，越來越體會到，代碼注釋最重要的不是解釋這幾行代碼做了什麼，而應該寫清楚為什麼要這樣做。“做了什麼”，就算你不寫注釋，他人大不了花點時間看看代碼流程。但是“為什麼這樣寫”，你要是不寫注釋的話，就沒人知道了。

對于架構而言，API 的公有接口設計是非常重要的，如果這些公有接口沒有設計好的話，說明封裝沒有做好，類型抽象不到位，内部的設計隻可能會更糟。

本文轉自BloodyAngel部落格園部落格，原文連結：http://www.cnblogs.com/zgynhqf/archive/2010/11/18/1880383.html，如需轉載請自行聯系原作者