碼農老吳寄語

《設計原本》是布魯克斯老爺子（軟件工程之父，計算機科學家，圖靈獎，馮諾依曼獎等獎項得主）的經典著作，它裡面旁征博引的有關設計的名言，橫跨科學，哲學，藝術，音樂，建築等多個領域，句句展現着布魯克斯老爺子的涉獵廣泛，博學多才，值得我們每一個程序員，架構師細細的品味，在此向布魯克斯老爺子緻敬，他的書值得我們作為架構師的床頭書。

碼農老吳，才疏學淺，學藝不精，點評更是詞不達意，畫蛇添足，權當博大家一笑，如能抛磚引玉，讓你有一點點收獲，我心足矣。

創意是如何産生的？

對一種技藝進行觀察，并将所思所想運用到另一種技藝中，使得諸般妙用在一個人的頭腦中不斷反思（新思維也就不期而至了）

--弗朗西斯培根

碼農老吳點評：

舉一反三，觸類旁通，深度思考，是創意的有效途徑。

設計工作是相通的嗎？

很少有工程師和作曲家……能夠通過探讨對方的專業作品而各取所長。我建議，他們可以共同探讨有關設計的問題……（由此）共享他們在創新性的專業設計過程中取得的經驗。

希爾伯特·西蒙 計算機科學家-摘自《設計原本》

碼農老吳點評：

看來直男碼農和前端設計師小姑娘，要多溝通溝通工作哦，以便提高軟件設計的創新能力。

曲子全部譜好了，隻是還沒有寫下來。

——緻利奧波德。莫紮特信劄（1780年）

碼農老吳點評：

軟件已經設計好了，隻是還沒有開始編碼，優秀的程序員，架構師往往都具有這種特質。

如果許多個體有共用的名字，則可以認為它們對應着同一個構想或形式。

世上有一些床和桌子，但是它們僅僅擁有兩個構想或者形式：一個是床的，一個是桌子的。

任何人在制作一張床或者一張桌子給我們使用時，都要遵循這構想。

——柏拉圖（公元360年）《理想國》卷十

碼農老吳點評：

看來柏拉圖，是面向對象編程的祖師爺。

如果設計理念本身是焦點，而不是拐彎抹角的表達或殘缺不全的細節，那麼溝通就可以非常直截了當。

摘自《設計原本》第一章，設計的疑問

碼農老吳點評：

架構師，軟件開發人員，需要形成自己的軟件設計理念。

……因為設計的理論是普通的搜索理論……即在巨大的組合空間搜索

——Herbert Simon希爾伯特·西蒙（1969）計算機科學家《The Sciences Of The Artificial》

摘自《設計原本》第二章，工程師怎樣進行設計思維--理性模式

碼農老吳點評：

藝術的盡頭是數學，所謂設計，不過是從設計師的頭腦中，搜索積累的知識和經驗，然後排列組合，形成創意而已。

耐用、高效和情趣

——[古羅馬] 維特魯威（公元前22年）《建築十書》

摘自《設計原本》第十二章，技術設計中的美學與風格

碼農老吳點評：

遇事不決，量子力學，程序員，架構師則是遇事不決，建築解決，需要效仿建築行業的大師們，提高自己的設計能力。

風格是思想的外衣，高尚的思想正如裝束體面的紳士那樣令人神往。

——查斯特菲爾德勳爵四世（1774年）

摘自《設計原本》第十二章，技術設計中的美學與風格

碼農老吳點評：

當程序員的代碼，軟件設計，處處體現出自己的風格，就離優秀的架構師不遠了。

優雅，就是用最少的元素，定義出盡可能對的概念。

風格，就是一種不同的，可重複的微觀決策集合，即使所處的環境不同，但決策制定的方式是保持不變的。

摘自《設計原本》第十二章，技術設計中的美學與風格

碼農老吳點評：

我欽佩布魯克斯老爺子的地方就在這裡，即使是藝術化的名詞，都可以用數學語言來解釋，這一點對我們理工男來說，是很重要的，能從這本書學習到這兩句，我認為就值了。

……當你尋找某樣東西時，隻有當你對它有所了解時，才有可能找到。否則，你根本毫無頭緒，甚至根本無從知曉是否已經找到。這再次證明了，架構師在設計時，腦海中閃過的，往往還是已有的方案和風格。

—— Bill Hillier and Alan Penn（1995年） 與研究領域無關的設計理念是否存在。

碼農老吳點評：

你不會找到你不知道的東東，學習與積累，是你創新的基礎。

大約在16世紀，在大多數歐洲語言中，出現了“設計”這個術語或等價的詞……

總的來說，這個術語的出現表明，設計從實現中分離出來。

碼農老吳點評：

設計和實現分離，是技術發展的一種趨勢，建築行業尤其明顯。軟件行業也出現了這種苗頭，程序員高工資的一個重要原因，是軟件開發的設計和實現還沒有徹底分離。

（當設計師）按照初始狀況進行設計改造的時候，狀況本身會“抵觸”，而設計師隻能就這種狀況反彈做出回應。

在良好的設計過程中，這種狀況交互是自反的。在回應狀況反彈時，設計師會将問題的構造，行動的策略以及現象的模式納入行動的考量，在每一步的推進中，都隐含了這些考量。

——Donald Schon 麻省理工學院設計理論家。

碼農老吳點評：

怕理解得不到位，還是聽布魯克斯老爺子怎麼說，“在對權衡的沉思中，一種關于整體設計問題的新理解逐漸浮現出來，即它（這種新理解）是諸多因素，以錯綜複雜、彼此牽制而又彼此交互的方式組合的結果。由此，對于諸項必要條件的權重計算方法就發生了變化”。

一種廣泛認同的觀念是：創新性設計并不是先把問題定死，再去尋找一個令人滿意的概念解決方案；它似乎更像是針對問題的構造本身以及解決方案的思路這兩者同時進行研發和完善，這包括不斷地在兩個“空間”（問題空間和解空間）之間進行循環往複的分析、綜合和評估過程的疊代。

——Nigel Cross and Kees Dorst 1999,"創新性設計中問題和解空間的共同演化"

碼農老吳點評：

經常有以下口頭禅的程序員，架構師，好好參悟一下這句話，一定會受益匪淺。

”需求文檔裡面是這樣寫的“，”我是嚴格按照需求文檔開發的“，”産品經理是這麼要求的“

嚴格按照需求文檔開發的是普通程序員，能對需求提出優化方案的是優秀程序員，能提出新的高價值需求的程序員不得了，可以轉行當産品經理了，也可以自己當Boss了。

如果一個設計，尤其是團隊設計，想要獲得概念完整性，那麼就應該清晰地定義出稀缺資源；公開、公正、公平地跟蹤使用記錄，并嚴格控制其使用情況。

——摘自《設計原本》第10章 英寸、盎司、比特與美元-預算資源

碼農老吳點評：

對于一個軟件開發團隊，項目中的稀缺性資源，要确保團隊所有人達成共識，并由架構師或者Leader統一管理。

人們最關心的指标有兩個：交付的産品到底有多大的價值，以及為了交付該産品花費了多少精力。功能點非常有用，因為它可以衡量前者，反過來說，代碼行數，類的規模以及其他一些指标則真實地反應出開發風格。如果做得夠好，就能夠在減少代碼行數及類的數量的同時，輕松提升交付産品所能創造的價值。

——摘自《設計原本》第三部分 設計面面觀，第10章 英寸，盎司，比特與美元-預算資源

碼農老吳點評：

優雅，就是用最少的元素，定義出盡可能對的概念。優秀的程序員，架構師，就是要用盡可能少的代碼，來實現盡可能多的功能點。

……專注于軟件過程成熟度方面的工作，其背後的基本假定就是：

軟件産品的品質在很大程度上取決于構建産品時的軟件開發和維護過程。

——MarkPaulk（1995），“論軟件能力成熟度模型的演化"

碼農老吳點評：

軟件開發團隊需要高手，大牛，大神，但是軟件的高品質，更需要科學的項目管理，架構師，項目經理都很重要。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部