說來慚愧, 大概半年前買的, 在書柜里躺了半年了, 前幾天看了幾頁, 很認(rèn)真的那種看, 僅僅看了幾頁, 覺得還是能夠?qū)W到很多東西的, 在此用筆記記錄自己的感想和學(xué)到的認(rèn)識到的.
第一章 開篇
第一章講的是關(guān)于給10,000,000數(shù)據(jù)排序的問題, 引發(fā)的思考和程序設(shè)計(jì)的過程. 現(xiàn)在, 就算是通過最差的算法去排序, 我想都可以完美的在10s之內(nèi)排序完成, 但是作者那個(gè)年代, 卻要考慮內(nèi)存, 算法復(fù)雜度等等因素, 就是內(nèi)存和處理器都足夠強(qiáng)大的現(xiàn)在, 找到最好的解決方案也是很重要的. 我覺得優(yōu)質(zhì)的代碼不僅僅能加快運(yùn)行效率, 也能提升更好的用戶體驗(yàn), 更重要的是, 優(yōu)質(zhì)代碼是一個(gè)合格程序猿必須的態(tài)度.
**準(zhǔn)確的描述問題: **第一章作者回答別人的請教時(shí)候, 第一次并不知道具體的問題和需求到底是什么, 就開始盲目的作答, 結(jié)果答非所問. 其實(shí)在工作中, 我么向別人請求問題, 最好是能夠詳細(xì)的描述好自己的需求和待解決的問題, 只有了解所有詳細(xì)的細(xì)節(jié), 才能找到更好的找到解決方案; 接受別人的求助時(shí)候, 也要詳細(xì)的問清楚問題所在, 問清楚具體的用途, 具體需求.
**復(fù)雜問題,分步解決: **編程過程中, 難免遇到很復(fù)雜的問題, 乍一看沒有任何思路, 這時(shí)候可以將大的問題, 詳細(xì)的分布解決, 先定義好每一個(gè)具體的步驟, 定義好每個(gè)步驟要做什么, 然后具體的去實(shí)現(xiàn)每一個(gè)步驟, 只要每個(gè)步驟都是完美的, 那么問題就可以解決.
**先讓程序跑起來: **最近本人在看設(shè)計(jì)模式, 剛學(xué)完組合模式, 然后用oc做了一個(gè)簡單的小說網(wǎng)站爬蟲, 準(zhǔn)備爬小說. 動(dòng)手之前, 我大概考慮了一下, 編碼過程中可能會用到的幾種類型的節(jié)點(diǎn)? 抽象層用抽象類還是接口? 下載一本書中的一個(gè)章節(jié)應(yīng)該有哪些步驟? 下載一本書應(yīng)該有哪些步驟? 應(yīng)該同步還是異步? 異步的話怎么創(chuàng)建運(yùn)行循環(huán)? 什么時(shí)候保存內(nèi)容到本地, 一個(gè)章節(jié)保存一次還是一本書統(tǒng)一保存一次? 那一張A4, 類圖畫了一個(gè)小時(shí), 也確定不了到底怎么做, ..........., 尼瑪, 越想問題越多, 想著想著就心煩意亂的, 覺得這東西太tm難了, 根本無從下手了. 然后就不管什么章法了, 直接上代碼吧! 首先敲出來了下載一個(gè)章節(jié)的代碼, 完成后開始優(yōu)化代碼, 很明顯的, 應(yīng)該用抽象類比較好, 某些需要共用的屬性和方法都給提取到抽象類中, 具體處理葉子節(jié)點(diǎn)的類, 只需重寫一個(gè)抽象方法, 然后處理自己請求的結(jié)果, 具體的葉子節(jié)點(diǎn)該怎么寫就怎么寫, 最終很快就完成了. 并且本人覺得, 代碼質(zhì)量還可以, 功能模塊劃分很清晰. 寫在后面的: 如果遇到覺得很頭大的問題, 首先先分解具體步驟, 其次先寫出代碼讓程序跑起來, 然后優(yōu)化, 讓程序更好的跑起來.
簡單的設(shè)計(jì):設(shè)計(jì)者確定其設(shè)計(jì)已經(jīng)達(dá)到完美標(biāo)準(zhǔn)不是不能夠增加任何東西, 而是不能夠再減少任何東西. 程序猿應(yīng)該用該標(biāo)準(zhǔn)檢視自己的程序. 簡單的程序通常比相同功能復(fù)雜的程序更可靠, 更安全, 更健壯, 更高效, 而且易于實(shí)現(xiàn)和維護(hù).
