書評:軟體設計哲學
這篇文章是關於John Ousterhout的新書“軟體設計哲學”的評論:
事實證明,寫一篇有關如何將俄羅斯方塊AI實現為容器化的Kotlin微服務的文章要比如何編寫好的程式碼要容易得多。
170頁的“軟體設計哲學”(以下簡稱PoSD)是一本不起眼的書。John的背景是系統而不是軟體工程或程式語言,他從未聲稱擁有特殊的專業知識。但他的從業者信譽是巨大的。Ousterhout的分散式記憶體儲存系統RAMCloud我見過的最清晰,編碼最好的程式碼之一。他是一個忙於管理大型實驗室的教授,他是Tcl語言及其Tk框架的創造者。
PoSD最適合作為操作指南的戰術指南。大約四分之一用於命名和評論,其餘大部分用於特定模式。該書的建議比“清潔程式碼”等初學者書籍更高階,但其大部分內容對於高階軟體工程師來說都是熟悉的。
遵循Code Simplicity等其他書籍,PoSD首先對高質量程式碼的好處和複雜性的危險進行了高度的解釋。
前幾個章節是對軟體組織基本概念的一次盛大之旅:分離抽象層次,隔離複雜性,何時分解功能。
但這是第4章,他介紹了這本書的核心理念:深層模組。Ousterhout解釋說,介面不僅僅是程式碼中編寫的函式簽名。它還包括非正式要素:高階行為,邏輯順序的限制。
許多模組都很淺薄:他們需要做很多解釋,但實際上並沒有做那麼多。一個好的模組很深:介面應該比實現簡單得多。
這個觀點是錯誤的!
當規格長於程式碼時
聽起來“介面應該比實現更短?”聽起來很不錯。你如何測試它?
對於Ousterhout來說,介面只是一個備註說明和一些關於它是否易於使用和思考的討論。直覺和經驗是這裡唯一的仲裁者。這揭示了他的主要盲點。
我之前已經解釋 過 ,軟體設計的重要資訊不在程式碼(第2級)中,而是在邏輯中!
規範和推理很少具體寫下來,但仍然塑造了程式碼。
我同意規範通常應該比程式碼簡單得多。但是,任何具有實際規範規範經驗的人都可以告訴您,有一些有趣的情況,實際中規範是並且應該比實現更復雜。
有時候,實際上需要一個比程式碼更復雜的規範。兩個主要原因是Ghost狀態和不精確。Ghost狀態是來自驗證的概念,描述了某些型別的“微妙”程式碼。
不精確有例如:
- 規範:XX的溫度在60到90度之間。
- 實施:XX的溫度為70度。
規範更長,這正是因為它能建立抽象的特點所在。如果假設XX正好是70度,然後再設計系統的其餘部分,則XX變得難以更換或替換。透過削弱對模組的假設,程式碼變得更加可演化。
除此之外,還有另一個根本原因:從內部描述內容比從外部描述內容要容易得多。向您展示一個蘋果的樣子要比回答可能會問到的每個問題要容易得多(有關外部的問題如種子在哪裡?當我放下播下時它會如何長大?)。(banq注:介面是有關事物外部描述,介面的實現是有關內部詳細描述)
舉一個例子:堆疊stack資料結構,大家都同意這是一個有用的抽象。堆疊是按照後進先出順序執行推送和彈出操作的序列集合,其內部連結串列的實現非常簡短:只需在列表前面新增和刪除元素即可。但是如果你使用堆疊,並且你不想接觸到這個實現的內部細節,那麼你需要一種思考它的方法,它不會引用底層連結串列細節,一種解決方案是使用堆疊公理,比如說“如果你把東西放到堆疊然後從堆疊中彈出,你會得到舊值”和“如果你曾經把東西推到堆疊上,那麼它就不是空的。”
....
名稱和型別
在本書的後半部分,我只發現了兩個值得注意的建議,我認為這些建議很糟糕。
在本書的最後,Ousterhout的程式碼如下:
private List<Message> incomingMessageList; … incomingMessageList = new ArrayList<Message>(); |
為什麼它被宣告為List,即使它就是一個ArrayList,Ousterhout質疑這點?這不是那麼明顯嗎?畢竟,ArrayList有自己的效能屬性。
是的,但它這樣做的好處是不必要地將程式碼繫結到ArrayList的特定實現,並且可以使程式碼更難以更改。Joshua Bloch在他的“ Effective Java”一書中使用點52“透過介面引用物件”中幾乎相同的例子,充分爭論了相反的建議。
Ousterhout建議:為每個變數提出完美的名稱。
嚴肅對待名稱,不對兩個不同的概念使用相同的名稱,這是一個好主意。
“使用更精確的型別”是許多軟體工程問題的答案。
總結
PoSD是我讀過的三本軟體設計書之一,屬於“中級”類別,這本書有足夠的程式碼示例可以清晰地進行交流。PoSD不是一本完美無瑕的書,也不是原創的,但它是一本很好的書。他收集了許多建議,這些建議已經漫遊成一本薄薄的書,還有一些古怪的東西,還有更大的東西。初級工程師需要學習很多東西,高階工程師需要反思很多。
相關文章
- 書籍版面設計軟體
- 程式語言設計,程式設計哲學程式設計
- 程式設計師的哲學程式設計師
- 從軟體哲學角度談 Amazon SageMaker
- 好的軟體哲學家有哪些? - Hillel
- 漫談哲學與程式設計程式設計
- 「 思考 」 React Hooks 的設計哲學ReactHook
- 程式導向程式設計哲學程式設計
- 《軟體架構設計》讀書筆記架構筆記
- 幽默:哲學與軟體工程的區別軟體工程
- Unix哲學(Unix程式設計藝術)程式設計
- 為什麼軟體工程師應該學習哲學?軟體工程工程師
- 軟體測試書籍-學軟體測試最好的書
- 電腦科學哲學(史丹佛大學哲學百科全書)
- Kotlin語言中的泛型設計哲學Kotlin泛型
- UI設計需要學會哪些軟體?UI
- 學好UI設計,需要學習哪些軟體?UI
- 《簡約之美:軟體設計之道》- 讀書筆記筆記
- 從零開始理解 Laravel 的設計哲學Laravel
- 軟體設計模式學習(十八)命令模式設計模式
- 軟體設計模式設計模式
- 走近宮本茂:遊戲之神的設計哲學遊戲
- Go 設計哲學:少即是多,哪裡來的?Go
- 軟體設計模式學習(二十)迭代器模式設計模式
- 軟體設計模式學習(十三)裝飾模式設計模式
- DND體系的哲學思考
- 軟體設計原則
- 軟體設計師:UML
- 電路設計軟體
- 軟體測試設計
- 軟體設計模式學習(十七)職責鏈模式設計模式
- 總體設計(軟體專案)
- 軟考資料-軟體設計師
- 用c++設計哲學家進餐問題的求解C++
- 【軟體設計】專案設計流程規範
- 《如何做好軟體設計》:設計原則
- 軟體設計模式學習(二十一)中介者模式設計模式
- 軟體設計模式學習(二十四)狀態模式設計模式