數據結構與算法
教你寫出高效
的代碼,設計模式
教你寫出高質量
的代碼- 寫代碼能夠說是程序員每天要乾的事情,要是代碼都寫很差,最基本的看家本領都練很差,整天堆砌爛代碼,寫代碼還有啥意思呢?那還幹啥程序員啊!寫出「能用」代碼的人比比皆是,可是,並非每一個人都能寫出「好用」的代碼。只會寫能用的代碼,咱們永遠成長不成大牛,成長不成最優秀的那批人。
- 不少工程師寫了多年代碼,代碼功力一點都沒長進,編寫的代碼仍然只是能用便可,能運行就好。平日的工做就是修修補補、抄抄改改,一直在作重複勞動,能力也一直停留在「會幹活」的層面,就像高速路上的收銀員,只能算是一個「熟練工」。
- 「爲何要有這種設計原則、思想或者模式?它能解決什麼編程問題?有哪些應用場景?又該如何權衡、恰當地在項目中應用?」等等。
思考,回顧,思考,實踐
- 不少程序員都已經意識到基礎知識的重要性,以爲要夯實基礎,才能走得更遠,但同時對於如何將基礎知識轉化成開發「生產力」仍然有些疑惑。因此,你可能看了不少基礎的書籍,好比
操做系統、組成原理、編譯原理
等,但仍是以爲很迷茫,以爲在開發中用不上,起碼在平時的 CRUD 業務開發中用不上。實際上,這些基礎的知識確實很難直接轉化成開發「生產力」。可是,它能潛移默化地、間接地提升你對技術的理解。設計模式、數據結構、算法
更像是一道兒的,相比那些更加基礎的學科,設計模式能更直接地提升你的開發能力
1.應對面試中的設計模式相關問題程序員
- BAT-TMD
- 區分度選項
2.告別寫被人吐槽的爛代碼面試
- Talk is cheap,show me the code
- 代碼能力是一個程序員最基礎的能力,是基本功,是展現一個程序員基礎素養的最直接的衡量標準
- 你寫的代碼,實際上就是你名片
- 爛代碼,好比命名不規範、類設計不合理、分層不清晰、沒有模塊化概念、代碼結構混亂、高度耦合等等
3.提升複雜代碼的設計和開發能力算法
- 如何分層、分模塊?
- 應該怎麼劃分類?
- 每一個類應該具備哪些屬性、方法?
- 怎麼設計類之間的交互?該用繼承仍是組合?
- 該使用接口仍是抽象類?
- 怎樣作到解耦、高內聚低耦合?
- 該用單例模式仍是靜態方法?
- 用工廠模式建立對象仍是直接 new 出來?
- 如何避免引入設計模式提升擴展性的同時帶來的下降可讀性問題?
4.讓讀源碼、學框架事半功倍編程
- 優秀的開源項目、框架、中間件,代碼量、類的個數都會比較多,類結構、類之間的關係極其複雜,經常調用來調用去。因此,爲了保證代碼的擴展性、靈活性、可維護性等,代碼中會使用到不少設計模式、設計原則或者設計思想。
- 若是你不懂這些設計模式、原則、思想,在看代碼的時候,你可能就會琢磨不透做者的設計思路,對於一些很明顯的設計思路,你可能要花費不少時間才能參悟。
- 相反,若是你對設計模式、原則、思想很是瞭解,一眼就能參透做者的設計思路、設計初衷,很快就能夠把腦容量釋放出來,重點思考其餘問題,代碼讀起來就會變得輕鬆了。
5.爲你的職場發展作鋪墊設計模式
- 可維護性
- 「代碼易維護」 就是指,在不破壞原有代碼設計、不引入新的 bug 的狀況下,可以快速地修改或者添加代碼
- 代碼的可讀性好、簡潔、可擴展性好,就會使得代碼易維護
- 更細化地講,若是代碼分層清晰、模塊化好、高內聚低耦合、聽從基於接口而非實現編程的設計原則等等,那就可能意味着代碼易維護
- 可讀性
- 看代碼是否符合編碼規範
- 命名是否達意
- 註釋是否詳盡
- 函數是否長短合適
- 模塊劃分是否清晰
- 是否符合高內聚低耦合等等
- 可擴展性
- 代碼的可擴展性表示,咱們在不修改或少許修改原有代碼的狀況下,經過擴展的方式添加新的功能代碼。說直白點就是,代碼預留了一些
功能擴展點
,你能夠把新功能代碼,直接插到擴展點上,而不須要由於要添加一個功能而大動干戈,改動大量的原始代碼。- 對修改關閉,對擴展開放
- 靈活性
- 若是一段代碼易擴展、易複用或者易用,咱們均可以稱這段代碼寫得比較靈活
- 簡潔性
- KISS原則(keep it simple stupid)
- 代碼簡單、邏輯清晰,也就意味着易讀、易維護
- 思從深而行之簡,用最簡單的方法解決最複雜的問題
- 可複用性
- 儘可能
減小重複代碼的編寫
,複用已有的代碼
- 面向對象特性,繼承、多態存在的目的之一,就是爲了提升代碼的可複用性
- 設計原則中的單一職責原則也跟代碼的可複用性相關
- 重構技巧,解耦、高內聚、模塊化等都能提升代碼的可複用性
- 可測試性
- 容易編寫單元測試
- 要寫出知足多種評價標準的高質量代碼,咱們須要掌握一些更加細化、更加能落地的編程方法論,包括
面向對象設計思想、設計原則、設計模式、編碼規範、重構技巧
等- 面向對象中的繼承、多態能讓咱們寫出可複用的代碼
- 編碼規範能讓咱們寫出可讀性好的代碼
- 設計原則中的單一職責、DRY、基於接口而非實現、裏式替換原則等,可讓咱們寫出可複用、靈活、可讀性好、易擴展、易維護的代碼
- 設計模式可讓咱們寫出易擴展的代碼
- 持續重構能夠時刻保持代碼的可維護性
- 面向對象
- 主流的編程範式或編程風格有三類,面向過程、面向對象、函數式編程
- 7大知識點
- ① 面向對象的四大特性:封裝、抽象、繼承、多態
- ② 面向對象和麪向過程編程的區別和聯繫
- ③ 面向對象分析,面向對象設計,面向對象編程
- ④ 接口和抽象類的區別以及各自應用場景
- ⑤ 基於接口而非實現編程的設計思想
- ⑥ 多用組合少用繼承的設計思想
- ⑦ 面向過程的貧血模式 和 面向對象的充血模式
- 設計原則
- 理解各種設計原則定義、掌握設計初衷、能解決哪些編程問題、有哪些應用場景
- SOLID原則-SRP 單一職權原則
- SOLID原則-OCP 開閉原則
- SOLID原則-LSP 裏式替換原則
- SOLID原則-ISP 接口隔離原則
- SOLID原則-DIP 依賴倒置原則
- DRY 原則
- KISS 原則
- YAGNI原則
- LOD 法則
- 設計模式
- 針對軟件開發中常常遇到的一些設計問題,總結出的一套解決方案或設計思路,大部分的設計模式要解決的都是代碼可拓展性問題
- 23種經典設計模式,分爲如下幾類
- (1)
建立型
4種經常使用:①單例模式②工廠模式③建造者模式
不經常使用:④原型模式
- (2)
結構型
7種經常使用:⑤代理模式⑥橋接模式⑦裝飾者模式⑧適配器模式
不經常使用:⑨門面模式⑩組合模式⑪享元模式
- (3)
行爲型
11種經常使用:⑫觀察者模式⑬模板模式⑭策略模式⑮職責鏈模式⑯迭代器模式⑰狀態模式
不經常使用:⑱訪問者模式⑲備忘錄模式⑳命令模式㉑解釋器模式㉒中介模式
㉓對象模式
數據結構
- 編程規範
- 代碼規範主要解決代碼的可讀性問題,好比如何給變量、類、函數命名、如何寫代碼註釋等問題
- 《重構代碼大全》《代碼整潔之道》
- 此處總結20條規範
- 代碼重構
- 重構的目的(why)、對象(what)、時機(when)、方法(how)
- 保證重構不出錯的技術手段:單元測試和代碼的可測試性
- 兩種不一樣規範的重構:大重構(大規模高層次)、小重構(小規模低層次)
- 五者之間聯繫
- 面向對象編程,由於具備豐富的特性(封裝、抽象、繼承、多態),能夠實現不少複雜的設計思路,是不少設計原則、設計模式等編碼實現的
基礎
。- 設計原則是指導咱們代碼設計的一些經驗總結,對於某些場景下,是否應該應用某種設計模式,具備
指導意義
。好比,「開閉原則」是不少設計模式(策略、模板等)的指導原則- 設計模式是針對軟件開發中常常遇到的一些設計問題,總結出來的一套解決方案或者設計思路。應用設計模式的主要目的是提升代碼的可擴展性。從抽象程度上來說,
設計原則比設計模式更抽象。設計模式更加具體、更加可執行
- 編程規範主要解決的是代碼的可讀性問題。編碼規範相對於設計原則、設計模式,更加具體、更加偏重代碼細節、更加能落地。持續的小重構依賴的
理論基礎
主要就是編程規範- 重構做爲保持代碼質量不降低的有效手段,
利用
的就是面向對象、設計原則、設計模式、編碼規範這些理論