編碼工作也是一種設計

【設計 = 編碼】 VS 【設計 ≠ 編碼】
服務器君一共花費了286.216 ms進行了8次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議

在1992年,Jack?W.Reeves發表了一篇名為:Code?as?Design的文章,這篇文章可以在《敏捷軟件開發原則、模式與實踐》一書的附錄中找到。

這篇文章的核心觀點是:編碼也是設計,而軟件開發中與建筑行業中的施工所對等的工作,已經被編譯器代理了。這是幾近20年前的文章,但時至今日,類似的爭論仍未休止。好像是在《軟件架構設計》里,在討論架構設計時,作者就點了一句:這總不能說是設計就是編碼了吧。

解釋這一問題并不復雜,但需要用到一點辯證法。我們可以講:設計即是編碼,也不是編碼。

在別的文章里我們曾經提及,軟件是一種固化的思維。從這一角度看,軟件構建的核心步驟只有兩個:一是明確固化什么,二是對思維進行固化。

設計和編碼確實都屬于第二步,因此說設計即是編碼也沒什么不對,他們本質相同。但分類的時候,有一個很有趣的現象就是:區別個體差異的往往并非該物種最本質的特征,而是某些微小差別。比如區分不同人的,并非心臟,神經系統,而是膚色,臉型等等。

當軟件出現之后,人們定義設計,編碼這樣的名詞時,所想到的估計并不是他們本質上一樣不一樣,而是他們那里不同。設計和編碼的相同點在于他們本質相同,不同點則是他們考慮的問題層次不同。

也就是說考慮架構和考慮某個函數的實現時,本質并無差別,有差別的只是層次。從這個角度看,講設計不是編碼也沒什么不對。

如果我們認為思維固化過程中確實需要層層分解,而這種層次是連續的,那確實很難講清楚,從那個層次開始就不是設計,而是編碼了。所以這種爭議本身,起源于詞匯自身的定義,并不是特別的有意義。

當我們不需要努力區分設計和編碼的邊界時,盡可以認為他們是同一工作的不同層次。但這樣給設計留下了個難題,那就是究竟應該停在那個層次才最為合適——這并不是能夠簡單回答的問題。

最后說一句:設計處的層次較高,但服務的對象卻是更底層的編碼,畢竟只有最終的代碼才與軟件等價,只有好的代碼才代表好的軟件。只是現實中這種依賴關系往往被倒置,變成了設計指揮編碼。

本文地址:http://www.zqhthc.tw/librarys/veda/detail/1652,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.zqhthc.tw/librarys/veda/detail/1652

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏

大家都在看

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《UNIX編程藝術》 姜宏 (作者)

《UNIX編程藝術》主要介紹了Unix系統領域中的設計和開發哲學、思想文化體系、原則與經驗,由公認的Unix編程大師、開源運動領袖人物之一Eric S. Raymond傾力多年寫作而成。包括Unix設計者在內的多位領域專家也為本書貢獻了寶貴的內容。《UNIX編程藝術》內容涉及社群文化、軟件開發設計與實現,覆蓋面廣、內容深邃,完全展現了作者極其深厚的經驗積累和領域智慧。

更多計算機寶庫...

英超直播吻球网