軟體設計的一些感想

2022-04-02 10:13:29 字數 2484 閱讀 1609

已經好久沒有寫部落格了,不是因為沒有學東西,而是因為學的東西不夠系統,不夠具體,沒有整理起來(外加人懶),所以不想浪費筆墨。所以一直潛水。。但總會有感想的,在學習的過程中,時常會遇到一些令人驚喜的東西,令人拍案叫絕的東西,但學會之後覺得簡單或者不值一提,於是沒有當機立斷寫出一些洞見。事後用的時候倒覺得理所當然了。其實這是要不得的,學習的過程我認為不應該是純粹的吸收,而是要有選擇的過濾,留其精華,去其糟粕,如果能加入自己的總結就更好了,只可惜我在很多時候忘記了這事兒,或者在很多時候沒有空下來專門做一次如此認真的總結。但在技術的層面上,一般的說法是,任何一種技術都是基於某種設計思想,而至於用什麼來具體實現並不是最重要的。其實思想和設計不能用簡單的一對一和一對多關係來說明。經常會有人說一種思想可以衍生多種技術,其實他只說對了一半,因為一種技術並不只是一種思想的實現,而是多種思想的交融。

拿軟體設計來說,對於基於視窗的程式設計,我們有多種技術方案可以選擇,在windows下有mfc,.net, wpf,在linux下有gtk, qt, wxwidgets,在mac下有cocoa, 但核心思想差不多,大多用到了mvc思想,但mvc思想本身也是乙個組合思想,它組合了策略模式,觀察者模式等。對於這樣的乙個設計思想來說,它其實是乙個對設計的高度抽象。我甚至可以做這樣乙個奇怪的思考:如果將mvc模式套用到人身上,那麼人所看到的就是view,人所想到的就是controller,人所使用的便是model了,那麼針對乙個人來說,他的基本動作可能如下:看到東西->產生需求->尋找工具來實現自己的需求。所以我感覺,軟體設計有時更像對人的行為模擬,軟體系統更像是乙個虛擬的人(這個人的智商要看你給他多少知識和能力),或者說,軟體設計歸根到底是以人的認知來實現的,所以我們要劃分模組,要理清各個模組之間的關係,要考慮它們之間的相互影響,還要考慮他們之間的互動。如果各個模組之間關係混亂不清,那麼你將會的到乙個很爛的系統,置於會出現什麼結果,那就不得而知了。舉個簡單的例子:試想一下如果你吃飯咬到舌頭了,卻發現屁股痛,這是一件多麼尷尬的事情。

所以,軟體的設計實際上是乙個很複雜的事情,乙個高超的軟體更為複雜,因為你要考慮太多的情況,乙個人是極其複雜的。但正如所有的物質都是由簡單的原子組成的,所有的複雜性都能劃分成最簡單最基本的東西。就好比作業系統這樣乙個常人很難企及的東西,其實最底層也就六個操作,引用linux創始人linus的話來說就是:「你在unix上完成的大部分任務都是通過六個基本操作完成的,它們被稱作"系統呼叫"(system call)。第乙個基本操作是"建立子程序"(fork),乙個程式把自身完全複製出來,這樣你就有了兩個相同的拷貝。第二個基本操作是複製出來的程式,再用乙個新專案替換自己。其他四個基本系統呼叫--開啟、關閉、讀和寫--都是為了訪問檔案的。這六個系統呼叫便組成了unix的簡單操作。然後,你只需在程式之間創造出交流渠道(pipes),就能解決複雜的問題。」,那麼歸結到人身上,也就是那麼幾種:活動(身體活動和思維活動),新陳代謝,睡覺(純屬個人想法勿噴)。

記得以前看bbc的紀錄片《混沌理論》中講到圖靈的一段,圖靈曾經提出乙個偉大的構想:自然界由乙個最簡單的數學公式組成。這個理論促進了後來的「混沌理論」和「分形學」的研究和發展,包括著名的「蝴蝶效應」,也和「混沌理論」有關。我們都知道,圖靈被稱為「計算機之父」,而現代的軟體設計方法和這種構想肯定存在千絲萬縷的聯絡。所以,我認為,軟體設計如果是一種把問題搞複雜的設計,那將是乙個失敗的設計。軟體設計應該是將乙個複雜的系統一步一步劃分成「原子」的過程,而軟體架構的目標應該是使每乙個分塊都容易理解而且容易改變(所謂的可維護性和可擴充套件性)。

而對於人來說,人生活在乙個「實體」的世界裡,如果把人類的歷史看作一天,那麼人擁有真正的思想是在一分鐘以前,所以上帝無法阻止人類用「物件導向」的方式來進行軟體設計,也無法阻止程式設計師用mvc的思想來實現乙個軟體系統,因為這一切看起來理所當然。所以,無論你的技術多麼高超,我都可以想象你在面對一堆複雜的演算法和一堆鮮活的物件的時候的不同感受,因為我也可以感同身受:)。所有的人都喜歡用簡單的方式解決問題(如果你不是,那你也許是公務員,:)),更喜歡用簡單的方式解決複雜的問題,那樣會有成就感,程式設計師是最佳案例。為什麼說乙個會偷懶的程式設計師是乙個好的程式設計師?那是因為程式設計師的偷懶是對問題的抽象和擴充套件,對之前冗長而繁瑣的解決問題的方式建立乙個更為寬泛的適用模型,從而應對類似重複的問題。而所謂的抽象,便是思維的結晶。其實,抽象在各行各業都有應用,只不過在軟體開發領域,這個詞被提及的非常之廣範非常之響亮,以至於成了某些程式語言的關鍵字。其實抽象是乙個很寬泛的概念,它是一種對事物本質的提取過程(《資料結構》中有這樣的定義),所以我覺得在軟體設計中的抽象,可以運用到其他領域,在其他領域中的抽象,也能應用到軟體設計中來。所以,沒必要驚訝圖靈是個數學家,或者唐納德也是數學家...,因為從本質上來說,數學這門科學就是一種抽象科學,把自然界抽象成數學模型,而計算機就是對數學抽象模型的模擬器。

胡說了一大堆,也不知從哪兒來的靈感,但作為乙個軟體工程師,我覺得這些東西是應該而且值得去思考的。上次看到一則博文講到,這個世界由三種人推動:科學家,藝術家,工程師。也許這種說法並不一定正確,但至少說明了乙個觀點:工程師想要實現優秀的產品,必須懂得科學家和藝術家的抽象,因為那是他們的思維結晶。而乙個好的工程師,從某種程度來說,也是乙個科學家或者乙個藝術家

軟體設計的一些思考

軟體設計的一些思考 從事軟體開發工作已經五年了,仔細想想,雖然做了不少專案,但是在軟體技術上,感覺始終還是進步甚微,一方面和公司的情況有關,一方面,我想,也是自己個人總結和思考不夠吧。所以,慢慢的,還是有必要對自己的一些經驗做思考和總結。為什麼只談軟體設計,不談軟體開發呢,軟體開發涉及的不僅僅是設計...

一些主要的軟體設計原則

一,開閉關法則 就是對於擴充套件要開放,對於修改要關閉,什麼意思呢?就是說你的軟體架構如果功能發生了變化,你應該是想著去擴充套件原來的類,而不是去修改原來的類,因為萬一你修改了這個類,那麼又有上萬個類與這個類有著聯絡,那麼你就要去改寫上萬個類了,所以,我們應該是去主動的擴充套件某個類,而不是去修改那...

關於軟體設計分層的一些思考

從大學開始走程式設計師這條路近四年了。之前的三年大多是在學習基礎知識 也不甚紮實。真正覺得進步比較快的是最近一年,主要原因有兩個,一是實習了,二是在做畢業設計,其實歸根結底來說,是參與真正專案的開發了就知道要學什麼要做什麼了。1.個人對分層的認識 2.學習應該先學理念再學細節 第一點 無論是桌面應用...