啰啰嗦嗦地隨便寫寫-在工作1年後

要善於利用庫。

在某天，突然想起回顧這1年的收穫有些什麼時，腦中第一個蹦出的東西。

（我想不到好的封面圖了~）

一 搬磚

最近在看基礎知識，全屋漫遊的demo就先擱置了，但是知乎文章——讀完一篇(雞湯?)後——覺得還是應該流水賬地寫起走，所以趁著周末有時間，輕鬆地、簡單地、粗略地、通俗地、專業地(才怪咧)、和諧地寫一寫程序開發都是在搞么子。

搬磚

沒錯，這就是答案，而答案很簡單：）。如果把開發一個軟體比喻為修一間房子的話，作為施工工人的程序員當然是要用磚啦。至於為什麼用」搬「這個動作和「磚」這個對象，還是有道理的。

程序開發出來的目的是什麼？計算機的長處是什麼？我想答案之一就是為了解決大量的重複性工作，避免人的重複勞動。而這一條對程(ge)序(hang)開(ge)發(ye)本身也是適用的，程序員才不希望寫出來的代碼在這個地方用了1次之後再也不用了，巴不得寫了一段代碼之後能一勞永逸地能一直使用它。

於是就產生了很多複製粘貼型的程序員，從網上、從自己以前的代碼中複製代碼粘貼到正開發的程序中，然後再略加修改，這就好比是把別的地方的「磚頭」「搬」到自己的工地項目上用一樣。

二 搬磚史

噢，我的上帝，自從有了這個叫磚的東西，我再也不用自己燒草泥巴了。 ——河姆渡建築大師 · 王鋼蛋

• 最早人們修房子是從木頭、草木灰、泥土、石頭之類的開始，自己利用自然界的原材料完全從頭到尾地開始搞。
• 後來隨著科技進步，人們一步步發明了磚、水泥、鋼筋、混凝土、鋁合金等建材，這些成品的材料讓修房子的速度大大加快。
• 後來懂力學人們漸漸發現磚有很多砌法，這種砌法比那種砌法更牢固還更省料；房子的框架材料搭配做成這樣更隔音、做成那樣又更抗震...於是針對不同種類房子的需求，各種工藝套路出現了...
• 再後來可拆可復用的成品的牆面等，讓1小時修一個房屋成為可能。

這是一部對自然材料的利用與改造史 ——沃茲·吉碩德

-------------------------------------------------------------------------------------------

• 計算機只識別0和1，最原始的程序是採用穿孔紙帶的形式，去控制計算機的電路運算，方便了計算機，但不方便人。命令採用0和1的組合，難於記憶，寫一個程序，工作量很大，速度慢。（機器語言）
• 後來人們發明了彙編語言，它用一些簡單的字母代替了0和1的組合，雖然多了一道轉換，卻大大減輕了程序開發人員的負擔。
• 再後來人們覺得用彙編語言開發程序還是慢，還是不方便，還是不好記，更重要的是有一些操作總是分先後一齊出現的，於是又把計算機的一些操作進行抽象，在彙編語言的基礎的上開發了新的語言，如fortran語言、c語言等高級語言，這些語言更接近與人類的思維，讓程序員專註於程序要實現的業務，而不是專註於機器底層方面的東西，這雖然又多了一道轉換，但又大大減輕了程序開發人員的負擔。
• 再再後來有經驗的碼農們又發現了，雖然開發不同功能的軟體，但有很多業務是相同或者相似的，例如需要存儲一大批同類型的數據、對數據進行增加刪除修改查詢等等，於是他們把實現這些功能的程序段提取出來，成為一個個通用的模塊，於是庫(磚頭)就產生了。基本上計算機的方方面面都有相應的庫，比如網路庫、圖形庫、界面庫、並行庫、線程庫、遊戲庫、數學演算法庫等等很多，某種意義上一個應用程序自己也可以看作庫。程序員可以找到現有的符合自己要求的庫，搬過來自己用，這又大大減輕了程序開發人員的負擔。
• 再再再後來人們要構建的程序越來越大，但是幾個庫已經滿足不了，而且依然可以找到相似的需求組合，於是更粗粒度的框架登場了....現在說的計算機技術更新換代快，一方面是硬體的迅速發展作為支撐，另一方面也是指各種框架層出不窮。不過，越向底層走變得越少，像廣泛被使用的數據結構和演算法這些幾十年都沒怎麼變。

計算機的發展史是一部對底層的封裝史 ——旺勒·施誰碩德

為什麼用搬"磚"這個詞，我覺得磚是粒度比較適中的對象，無論是牆體磚頭也好、地磚也好，是一個功能明確的基本單元，而對應編程中的概念就是高級語言中的庫。再細粒度的是磚里的粘土，更粗粒度的是牆。（天啊我好無聊hhhh居然研究搬磚為什麼叫搬磚）

三、該搬的磚

機器語言和彙編語言目前應該是很少有人使用了，絕大多數人使用的都是高級語言，每一個語言都有自己的庫和框架，編程不僅要學語言的本身語法，也要會使用用這種語言寫的標準庫（"官方"提供的庫），最好還要了解一些非官方但比較著名的庫。

舉個例子，如果一門編程語言的本身如果比喻為單個字，那麼庫好比慣用語，標準庫就好比是成語。你自己用盡心思花了很多字實現了一個意思，浪費時間不說，往往沒有標準庫/著名的庫實現地那麼高效，例如開平方根這個數學演算法。

成語成語，就是現成的詞語~

所以說既然官方都提供標準庫了，程序員當然要會搬磚了。本文開頭提出的要善於利用庫。也就是這個意思。不要重複造輪子，不要重複做已有的工作。

程序員需要搬的磚大概有3類，第1類是官方自帶的標準庫，第2類是非官方但比較著名的庫，第3類就是各種渠道找到的庫代碼片段等，最後這一類的質量就參差不齊了。另外就是寫多了，自己也會有自己的代碼庫積累。

四、磚的使用

既要會使用，也要會選用，最好能了解所使用庫的內部原理，知其然也知其所以然的意思。先說說封裝與介面。

【封裝與介面】

舉個例，汽車的內部構造很複雜，但是汽車製造商把內部都封裝起來了，使用者看不見也無需了解，只提供了方向盤、離合、剎車、油門、檔位桿這5個裝置供使用者使用，使用者只需要會操作這5個裝置就能讓輪子轉動，把車用起來。5個裝置和輪子就是汽車的對外介面。5個裝置是輸入，輪子是輸出。

同理，在程序開發中，函數也好（庫是大量函數的集合組成的）、程序片段也好，我們要想使用它，基本的要求也就是了解它的功能與介面。輸入與輸出有點像是一塊磚的形狀，它們要與外部匹配，這塊磚才放得下去，不然的話就不能直接用，需要外部轉換一下。

庫包含了大量的函數，比較好的庫都會有文檔說明，說明了庫函數的功能與介面，像說明書一樣告訴使用者怎麼用。而且基本都是英文的。

【庫的內部】

了解庫的內部也是很重要的，因為它能指導我們正確地、更高效地利用庫。有看文檔介紹、直接看源代碼、看別人的文章這幾個途徑。

雖然不了解也可以用它 ，就像不懂車內部構造也能開一樣，就像不懂磚的構造也能砌出一面牆一樣。

但是，如果了解了內部的構造的話就不一樣了：如果車壞了，我們知道問題在哪，甚至自己修好，怎樣開車更省油；修房子的話，同樣外形的磚/牆，有的硬度大，有的硬度小，有的能吸水，有的不能承重，這些外形看上去差不多，但內部構造不一樣導致使用場合也會不一樣，如果不分清楚就用的話，不但發揮不出它們該有的效果，甚至房子還會垮。

庫的內部構造往往就是數據結構和演算法的層面了，計算機專業會教的，基本幾十年沒變過的，抽象，難度相較而言大，屬於一個碼農的核心能力了~

五、最後

程序猿們做的事大概就是：了解需求，明確自己要做什麼軟體，業務有些什麼，實現相關業務有些什麼普遍套路，可以用到什麼設計模式和庫，設計下架構，具體寫代碼，遇到不會的百度谷歌搜搜搜，遇到特定的功能又看有沒有現成的庫，根據實際需要引入使用，寫完一個部分了後自己測試下輸入輸出是否符合預期等等......

【前端和後端】

• 前端是更「靠近」用戶的一端，比如軟體的用戶界面，網頁頁面等，牽涉到數據的展示、少量的數據處理；
• 後端是更「遠離」用戶的一段，比如後台資料庫、伺服器等，牽涉到數據的存儲，數據的處理、數據的傳輸。

啰啰嗦嗦地居然寫了這麼多