乙個常見的原則是將方法的行數控制在 5 行之內——《軟體開發沉思錄》
5 行之內這一標準簡直讓筆者感到恐怖，對，不是驚訝，真的是恐怖的感覺。 5 行以內的描述空間，這怎麼可能，稍微複雜一點的函式何止幾十行…，深呼吸，冷靜一下，再想想，這一規則背後到底還有什麼我不知道的，於是就有了以下對話：
lyning(我)：我沒看錯吧，居然不是 5 行左右，是 5 行之內？
劉光聰：@lyning 這很正常，這幾年遇到的專案（新專案，ai領域）大多都控制在5行以內。都是在@熊節 2023年**之後開始實踐的。
lyning(我)：感覺控制函式行數少是一種使**逼近單一職責的手段。
熊節：單一職責和恰當的抽象層次。
熊節：麥肯錫方法，講事情永遠是3-5個點。
lyning(我)：熊老師，恰當的抽象層次，怎麼理解這句話呢？
熊節：就…比如我跟你講乙個事，我知道這個事1分鐘講不完，要講5分鐘這麼個複雜度
熊節：我就一定會分成一二三點，每一點我會強調一下，再具體講裡面的內容，講完以後我會總結一下我講了三個點。
熊節：跟乙個幾十行的函式是一樣的。
lyning(我)：有點明白了，把大問題要拆分成小問題，拆分出來的這幾個小問題都屬於這個大問題層面的東西。
熊節：仝老師有個套路，就是每個問題你始終把它描述成 輸入-處理-輸出 三句話.
劉光聰：
劉光聰：乙個小的c++例子，抽象層次分明。
從上面可以對話中可以得到以下關鍵字：
單一職責
恰當的抽象層次
熊老師採用比喻描述了什麼是恰當的抽象層次，劉老師視覺化了該概念在**中的體現。可以看到乙個 10 多行的**被重構到 5 行秒懂的函式，看來這個標準還是可行的嘛。
其實該原則出自《軟體開發沉思錄》物件健身操一節，更「恐怖」的是，物件健身操還列出 9 個堪稱「**」的原則：
方法只使用一級縮排（one level of indentation per method）
拒絕使用else關鍵字（don』t use the else keyword）
封裝所有的原生型別和字串（wrap all primitives and strings）
一行**只有乙個「.」運算子（one dot per line）
不要使用縮寫（ don』t abbreviate）
保持實體物件簡單清晰（keep all entities small）
任何類中的例項變數都不要超過兩個（no classes with more than two instance variables）
使用一流的集合（first class collections）
不使用任何getter/setter/property（no getters/setters/properties）
還能更短
函式的第一規則是短小。第二條原則是還要更短小。
函式應該只做一件事。做好這件事。只做這件事
上面的描述出自 bob 大叔的《**整潔之道》，對於函式應該多小，bob 大叔提到了他看了 kent beck 寫的乙個程式，函式都是只有三到四行，非常簡潔易懂。最終 bob 大叔對函式應該多長下了乙個定義，他給出了乙個只有 3 行函式體**的示例，表示函式就應該這麼短。這又一次顛覆了我的價值觀！
單一職責
單一職責是 solid 中的首要原則，通過它可以引出其它原則。可以發現函式越短，那麼它能做的事情就越少，就越能做好這件事情，也就越能驅動出單一職責的函式。
恰當的抽象層次
對於 add() 這個函式而言，if(readonly)、 atcapacity()、 grow() 和 addelement() 這 4 個邏輯體現了同一抽象層次，因此 add() 函式還是只做一件事，畢竟編寫函式是為了把一些大的概念拆分成另乙個抽象層次的一系列步驟 。
如果函式體現了非常多的細節，或者處於不同的抽象層次，這對於讀者來說簡直是災難，不僅如此，亂其實還暗示了作者在當下同樣也是思維混亂。
程式設計與思維
軟體開發就像是乙個口耳交替的遊戲，獲得準確的一手資訊不容易，把問題描述清楚同樣也不容易。筆者現在覺得程式設計是一項非常重視描述技巧的活動，表達得是否清楚很大一部分源於人的思維是否清晰（結構化），也許程式設計只是基本功，思維才是內功，畢竟把問題搞複雜，比弄清晰要簡單得多。
良好的描述技巧
要把邏輯抽象化，必須知道某段邏輯在做什麼，並且對函式進行恰當的描述，這裡的難點之一在於作者需要有良好的描述技巧，好在描述技巧其實也有一些模式和規律可循，可以參考「名正則言順：聊聊「起名」這件事」
秒懂上面**了一些模模糊糊的概念，而秒懂應該是短函式的乙個最直觀的體現。不過不僅僅讓自己秒懂，還要讓讀者秒懂，因此寫好了**，應該分（e）享（xin）給其他的小夥伴，看看小夥伴們的反饋，在反饋中不斷改善**。
如果還覺得不過癮，那再看看這個函式，給自己計時看看需要多長時間讀懂：
然後再看看這個：
總結筆者認為，短函式的實際價值在於容易維護。處於同一抽象層次的短函式，做的事情越少，需要被理解的概念也就越少，就越不容易出現認知超載。需要強調的是，短函式、恰當的抽象層次和良好的描述，對於大部分人來說，不是一下子就冒出來的，而是被打磨出來的，怎麼打磨呢？當然是 tdd。
函式過載有感
好記性不如爛筆頭！函式過載注意點 下面程式段說明一些問題，雖然我們一般不會寫這麼迷惑人的 但是知道編譯器到底是怎麼幹得，始終沒有壞處。unsigned 可以作為函式過載的標示。unsigned char 和unsigned int 會自動轉換為 int 如果沒有unsigned int 的過載，則呼...
搭建短域 短鏈結跳轉平台
1.什麼是短鏈結 顧名思義，短鏈結即是長度較短的 通過短鏈結技術，我們可以將長度較長的鏈結壓縮成較短的鏈結。並通過跳轉的方式，將使用者請求由短鏈結重定向到長鏈結上去。短鏈結主要用在簡訊 社交分享時通過使用短鏈結，可以看起來整潔簡短，而不是在擔心鏈結超長的問題。隨便找了個長的鏈結，看起來又臭又長 2....
php mysql 短鏈結 PHP生成短鏈結案例
首先我們建立的檔案有三個,api檔案 生成短連線呼叫 index檔案 訪問短連線時跳轉使用 config檔案 連線資料庫用的 呼叫方法 網域名稱 api.php?url nginx規則 location elseelseelseelse echo json encode array code 201...