IT人的素質 設計雜談

2022-02-04 10:54:22 字數 1077 閱讀 2543

it 人應具備的一些素質

分享。樂於分享,才能共同成長。

開放 & 空杯心態,接受新事物。

沒有實踐就沒有發言權。

沒有徹底理解,不要去推翻它。

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

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

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

設計雜談

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

wpf框架使用有感:

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

隨著不斷的學習深入,逐漸地對這些上層**進行重構。每一次精簡,都是對底層知識的積累。

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

刪除沒必要的抽象(例如兩年內用不到的),每個抽象都增加了使用的複雜度。

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

「雙向緊耦合的設計,往往是極度抽象的設計,很可能是經典一筆~」

例如 .net 中的:animationtimeline 和 animatable。

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

只有當全面整體熟悉甚至精通這些理論與技術之後,設計才能做到得心應手:「程式設計手法」★、資料結構★、演算法★、資料庫、作業系統、程式語言、基礎平台類庫★、基礎平台框架★、網路、orm、xml、序列化、web、協議、設計模式★、架構模式★、思維導圖★、設計經驗★。

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

對於框架而言,api 的公有介面設計是非常重要的,如果這些公有介面沒有設計好的話,說明封裝沒有做好,型別抽象不到位,內部的設計只可能會更糟。

未完待續,想到再加……

IT人的素質 設計雜談

it 人應具備的一些素質 分享。樂於分享,才能共同成長。開放 空杯心態,接受新事物。沒有實踐就沒有發言權。沒有徹底理解,不要去推翻它。不要抨擊其它你認為沒有意義的技術,任何事物都有它產生的原因。不要看不起老技術。只有站在巨人的肩膀上,你才能看得更遠。認識到 業務是收益 技術是成本。設計雜談 如何做到...

設計模式雜談

近日正在狂k設計模式,看來看去,n多的模式,n多的原則。搞得複雜無比,也加大了學習的難度。其實,我個人認為,模式是為開發人員服務的,而開發人員都是很懶的 能坐著就不站著,能躺著就不坐著 因此,他們也很懶得去做一些事情,而讓計算機去做。套用偶之前的一句 名言 什麼事都讓偶幹了,那計算機幹什麼用?正是因...

雜談設計模式

最近貌似又出現了很多設計模式相關的文章,不過這確實是乙個 百談不厭 的話題。我也來湊下熱鬧吧,週末閒得無聊來扯扯淡,不要丟我臭雞蛋。前兩天和朋友去爬香山,走在林蔭小道上,看著不高的樹枝伸到路上,突然好像回到了 年輕的時候 就跳起來摸了一下樹枝。朋友說笑著說,你長高了。或許說者無心,聽者有意。突然腦子...