讓你選一句話裱起來，你會選什麼？

原文連接html

摩爾定律對軟件開發也是間接奏效的，每過18個月，就會有一半的知識會過時。我以前寫的有些文章就已通過期了，今天咱們來聊一個不會那麼容易過期的話題 —— 那些業界‘大佬’是怎麼思考的？一個結構化的知識體系是怎樣的？程序員

不過要提早說明，本文沒那麼嚴肅，僅做拋磚引玉。若是你想要多瞭解這方面的知識，應該多讀幾本經典的書籍。面試

從思考框架到基本原則，到具體最佳實踐

前些日子學習了《10x程序員工做法》、《研發效率破局之道》，內容自己質量很高自沒必要說，給我啓發較大的是他們的內容組織方式。以《10x程序員工做法》爲例，它的內容是這樣組織的：算法

這種設計可讓咱們直觀地把握課程的主要脈絡。編程

思考框架是事物的出發點，用於審視目標、把握方向；基本原則是在思考框架下的核心指導思想；最後在基本原則指導下進行具體實踐。後面會詳細說明這三者的關係。設計模式

在我看來，這纔是一種結構化的知識體系。這種方法能夠幫助你創建一套本身的知識體系、認知模型，還能夠用來指導你的行動實踐。但願本文也能夠給你一些啓發。markdown

思考框架

最上層的思考框架每每是一些哲學問題，無非就是保安常常問你的那三個問題：框架

你是誰？
從哪來？
到哪去？

還有相似的 WWH：oop

Why？ → 目的、理念
What？→ 定義、概念、現象或成果
How？ → 具體操做方法、措施

《10x 程序員工做法》的思考框架是：學習

估計這個思考框架你從小學、幼兒園老師就會教你，不用多解釋。那麼問題來了，你們有沒有造成這樣的思考習慣呢？

這個思考框架，雖然簡單，卻能夠受益終生。

它能夠是任何行動的基礎。好比我在上一篇文章中「如何看待新技術章節」也套用了這個模式：

這是啥玩意？
解決什麼問題？
怎麼解決的？思想 → 流程 → 實現

再好比下次產品經理給你一個需求，套用這個框架，你能夠問他：

WHY？爲何要這個作這個功能？它能夠給用戶帶來什麼價值？或者說能給公司帶來什麼收益？ → 沒價值，就沒有作的意義
WHAT & HOW ？什麼樣的用戶會用到這個功能，他們在什麼場景下使用，他們又會怎樣使用它？實現這個功能就只有這種方式嗎？還有沒有其餘方案？ → 能夠衡量這個功能是否有通過認真思考的，是否是本身 YY，是否是合理

若是產品回答不上來，那很差意思，回去等通知吧。

碰巧最近也招人(簡歷砸過來 Y2FybmV5NTIwQGhvdG1haWwuY29t)，按照上面的套路，我可能會這樣考察你的'要性'(阿里土話，道聽途說)：

你以爲你如今處於什麼水平？有哪些不足
你的目標是什麼？想加入什麼樣的團隊？
你有什麼計劃？

OK，這裏留一個思考題，若是你的老闆在畫大餅，你會怎麼懟他呢？

原則

接下來是在思考框架指導下的‘原則’。這些原則相比思考框架要具體一些，是針對特定領域的思想指導，在處理某個特定領域的問題時會更有用一些。

好比《10x 程序員工做法》概括了四個原則：

由於是付費專欄，因此我也很少劇透，能夠看它的導讀。

能夠舉其餘咱們比較熟悉的例子，好比面向對象設計的 SOLID 原則：

S 單一功能原則: 認爲「對象應該僅具備一種單一功能」的概念
O 開閉原則: 認爲「軟件體應該是對於擴展開放的，可是對於修改封閉的」的概念。
L 里氏替換原則: 認爲「程序中的對象應該是能夠在不改變程序正確性的前提下被它的子類所替換的」的概念。
I 接口隔離原則: 認爲「多個特定客戶端接口要好於一個寬泛用途的接口」的概念
D 依賴反轉原則：認爲一個方法應該聽從「依賴於抽象而不是一個實例」的概念。依賴注入是該原則的一種實現方式。

搞對象的人，看到這些原則就會如數家珍，剛入門的小白可能比較難以理解。他們是歷代火影燃燒火的意志沉澱下來的寶貝，沒有通過戰場的洗禮理解可能不會那麼深入。

說一個我編程生涯比較受用的原則，那就是 DRY(Don't repeat yourself)，由於它相比SOLID原則、KISS原則，更好理解、或者說更有實踐性。

DRY 原則簡單說就是識別你的重複代碼，思考，而後重構它。

若是你在編程時養成了這種習慣，你會發現你的代碼天然而言會有比較良好的結構，同時也可能符合上述各類原則一些特徵（實際上它們原本就是交叉和相通的）。

或者說，通過 DRY 原則下的刻意訓練，你會造成一種編程品味( 敲黑板，這也是大廠考點)。

相似思想/原則還有不少，好比 Unix 哲學、Windows 哲學，還有一些算法思想：

經典算法思想，來源zhuanlan.zhihu.com/p/73144439

Unix 哲學

上圖有兩個彩蛋：

一個是 Ken Thompson(Unix、Go 做者之一，真大神級人物) 很是實用的‘建議’：「拿不許就窮舉」, 幹就是了，幹了再說。

Unix 哲學用一個詞歸納就是 KISS(Keep It Simple, Stupid)，在這個'面試造火箭，上班擰螺絲釘'內卷年代, 不少人容易走偏，把事情複雜化，寫一些花裏胡哨代碼，作一些花裏胡哨的功能。Unix 的遠古哲學告誡咱們：簡潔就是好，好就是簡潔。
第二個是我本身寫的，儘管大學時就看過這本書，當時只有盲目崇拜，時隔多年再看，這些原則個個是說到心尖上了，頓時感嘆應該把這些'哲學'裱起來，日看夜看。這也是本文的靈感來源。

Windows 哲學

這些原則你說難嗎？其實不難，幾句話就能夠說清楚。

若是你是多年的老鳥，可讓你返璞歸真。若是你是菜鳥，那你應該背誦下來(開玩笑)，或者裱起來掛客廳、搞成壁紙、作成鼠標墊、印在保溫瓶上...

具體的最佳實踐

再往下更具體，這是在原則指導下、通過實踐總結出來的最佳實踐/設計模式。能夠用於指導解決具體的領域問題。

仍是以《10x 程序員工做法》爲例，它最終的知識結構以下：

舉你們比較熟悉的例子，最典型的莫屬於面向對象的《設計模式》，它就是屬於這個層次的知識：

來源：my.oschina.net/u/4353432/b…

設計模式就是在 SOLID 原則指導下的具體實踐。

並非說咱們只要學習思考框架和指導原則就好了，最佳實踐也是要刻意學習的。三個層次相得益彰，這樣造成的知識體系纔是比較穩固的：

最佳實踐是在思考框架和指導原則下造成的產物。若是隻是掌握最佳實踐，停留在皮毛，不去挖掘它的內在思想，則不能作到內化和昇華。若是有幸，來到了一個新大陸，這裏沒有任何最佳實踐和設計模式，要怎麼辦呢？
思想和原則不能脫離實踐。

最佳實踐一般是別人實踐總結出來的，能複用的就複用是吧？最佳實踐、準則、對咱們來講是站在巨人的肩膀上，是捷徑，讓咱們能夠少走點彎路。

因爲每一個人的場景千差萬別，別人的實踐並不必定適合你，或者你走在世界前頭，上層的思想則是創造最佳實踐的有用指導。

另外實踐也在深化咱們對上層思想的理解。
實踐和思想是相互驗證的關係。

後面你們看書、學習某些課程時，能夠留意一下它們的組織結構，某種程度上能夠折射出做者的水平。

一切都是套路，套了又套。

那麼，讓你選一句話裱起來，你會選什麼？

不要跟我扯什麼自*、民*、和*...

來點實際的，軟件開發領域選一句讓你受益不淺的話，裱起來告誡本身/後人，你會選什麼?

我舉一些例子吧：

KISS
DRY
SOLID
SPOT
Unix 哲學 17 大原則
程序員的三大美德：懶惰、急躁、傲慢。

來源於Perl 做者 Larry Wall，附帶相關解釋：
- 懶惰，是一種品質，它會使你花很大力氣去規避過分的精力消耗，敦促你寫出節省體力的程序，別人也能很好地利用，你還會爲此寫出完善的文檔，以避免別人來問問題。
- 急躁，是計算機偷懶時，你會感到的一種憤怒。它會促使你寫出超越預期的程序，而不僅是響應需求。
- 傲慢，極度自信，寫出（或維護）別人挑不出毛病的程序。
—— Larry Wall

不是開玩笑，這真是美德。若是身邊多幾個這樣的程序員，就不用996了。
Stay hungry, Stay foolish —— Steve Jobs
Talk is cheap. Show me the code —— Linus Torvalds
...

本文說起 & 擴展閱讀

《Unix 編程哲學》

《設計模式》