《編程匠藝》讀書筆記 2

編程巨藝—讀書筆記
08-10-5

我們日復一日地使用着工具,使用編譯器就像使用開罐器一樣自然,沒有經過太多的思考。如果它運轉正常,就沒有任何問題,但是當它發生了故障(或者你需要開啓一個奇形怪狀的罐頭)時,不管開罐器有多高檔,你都會被卡住。一個簡單便宜但是能用的開罐器要好過一個外表華麗構造複雜但是不能用的裝置。

雖然習慣於你平常使用的工具,學習並熟練使用它們很重要,但是千萬不要迷信它們。大多數Windows用戶都很看不起Unix風格的程序開發,同時Unix的高手們也因爲Windows的程序員不會使用命令行而很小看他們。克服這種心態。

我鼓勵你在一個大型項目中嘗試在不同的編程環境下工作。這有助於讓你充分理解是什麼造就了好的工具鏈,並且幫助你從全局的角度瞭解軟件工具。

讓我們弄明白我們到底爲什麼而使用工具:工具不是替我們做我們該做的工作,而是使我們有能力做我們的工作。

成爲一名成熟的程序員的條件之一,就是明白不同的情況需要不同的解決方案,並將正確的工具應用到正確的工作上。

關鍵概念 瞭解你的工具的最新發展情況,但是不要隨便進行升級。

給我們適當的工具,我們就會完成任何工作。
——溫斯頓·邱吉爾爵士(Sir Winston Churchill)

C.A.R. Hoare曾經寫到:“構建軟件設計的方式有兩種:一種方式是使軟件儘量簡單,以至於明顯沒有缺陷;另一種方式是使軟件儘量複雜,以至於沒有明顯的缺陷。第一種方式要難得多。”

編程的過程將檢驗初始的設計決策,並完成剩餘的設計工作。它會揭示不完善的地方、不一致的情況和錯誤,並讓你可以找到解決這些問題的途徑。

“有些程序員不認爲他們在編程的同時也是在設計,但實際上,每當你編寫代碼的時候,你總是會有意無意地做着設計。”(見參考書目Page Jones 96)

08-10-5 13.1章節

簡潔的代碼是否可能做到小到不能再小。這非常不容易,正如數學家Blaise Pascal所說的:“很抱歉寫這麼長的信,可是我實在沒時間寫一封短一些的信了。”認真地算出最少需要多少代碼,然後就編寫那麼多。記住,你在日後可以隨時爲額外的功能添加更多的代碼,但是你很少能夠有機會刪除那些已經緊密地交織在一起的代碼。

在代碼中進行設計

這是一種很有用的非正式的代碼設計方法。在設計的最初階段,你在代碼中放置了所有的API和低級接口,但是並沒有真正實現它們——你只是編寫了一些返回某種可能的值的代碼片斷,並在其中放置了一些描述還應該做哪些工作的註釋。當你的設計足夠成熟時,系統中就會有許多已經編寫好的代碼了。

這樣做可能利弊參半,因爲可能會導致設計的靈活性降低。設計的改動越多,需要更改的代碼片段也就越多。

跳出極度複雜,就是極度簡單。

——溫斯頓·邱吉爾(Winston Churchill)

優秀的程序員……
— 希望他們接觸過的任何東西都保持良好的狀態
— 認爲編程是一種創造性的過程,並在他們的工作中加入藝術元素
— 在開始編寫代碼之前,首先考慮代碼的結構
— 面對零亂的代碼,會覺得在開始對它們做任何額外工作之前,需要先進行一些清理和調整
— 堅持不斷地學習其他軟件的設計,積累成功和失敗的經驗

糟糕的程序員……
— 將越來越多的代碼填入一個混亂的框架中,直到他們覺得已經做夠了,然後就開始抱怨結果
— 在處理晦澀難懂的代碼時,注意不到糟糕的設計,也感覺不出有什麼不對
— 喜歡草草行事,然後就跑開,讓別人來收拾爛攤子
— 不欣賞也不尊重他正在處理的代碼的內部設計,並以冷淡的態度來踐踏這些設計

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章