來源 |?編程新說

責編 | Carol

頭圖 | CSDN 下載自視覺中國

切身感受

在這個世界上，最難看懂的文檔，永遠是同事寫的需求文檔。最難看懂的代碼，永遠是同事寫的業務代碼。

我很納悶，像Spring這樣的官方英文文檔，我看起來也不太費勁，但是需求文檔，我卻要花費極大力氣。

像Spring這樣的源碼，我讀起來也尚能較好應付，但是業務代碼，我卻常常需要絞盡腦汁。

清晰 VS 混沌

如果一道高考證明題的作答，是卷面清晰，字跡工整，說明考生當時的思路是清晰的。

相反，如果卷面凌亂，寫了之后又劃掉，劃掉之后又再寫，說明考生當時的思路是混沌的。

對高考作文來說也是一樣的，一氣呵成的一定是思路清晰的，修修改改的一定是思路混沌的。

思路清晰的作答，正確的可能性更大一些，思路混沌的作答，錯誤的可能性更大一些。

就像狙擊手一樣，一定要一發命中，否則便暴露了自己、喪失了天機、影響了情緒，幾乎不可能再命中了。

需求文檔寫的不清晰，是因為需求人員自身對需求的認知就不清晰。代碼寫的混亂的，是因為開發者自身的思路就是混沌的。

相同的東西，不同的宿命

北方有些省份早晚都是吃稀飯的，我家鄉就是。

面粉和水就可以做出一種稀飯叫面湯，如果加幾個雞蛋進去，口感會更好些。

然而同樣是面粉和水，只要把比例變一下，最后做出來的就是漿糊。可以用來粘東西。

我們經常聽到一個比喻，說場面亂成了一鍋粥，其實粥還好，要是亂成一鍋漿糊，那才是真的亂。

如果我們要建造一個普通的平房，那幾乎不用準備什么，直接按自己的思路走就可以，最后也不會有太大出入。

如果要建造一座復雜的房子，那必須要先設計好造型、畫好圖紙，這才能保證造出來是自己想要的樣子。

同樣是面粉和水，一個成了面湯，一個成了漿糊。同樣是一堆建材，一個成了平房，一個成了別墅。

為什么相同的東西最后卻落得不同的宿命呢？其實不在東西本身，而在它的主人，主人掌握了它們的命運。

主人精雕細刻一些，那就是工藝品，主人粗制濫造一些，那就是日用品。

渴望美麗，追求美好

工具都是一樣，代碼卻是不同，原因不在于語言、類庫或IDE，而在于寫代碼的人。

水平和能力只占次要原因，主要是認知和態度。

這些寫代碼的人只把代碼當作“日用品”，壓根兒沒想過把它變成“工藝品”。

要知道代碼除了被服務器運行外，也是要被人看的，怎么說也要講究點美感吧。

我們從小都知道踏青和春游，那是因為春天萬物復蘇、柳綠花紅、春意盎然。不僅是視覺上的盛宴，還有心靈上的享受。

我們從來沒見過像下面這樣的詩句：

腳踩干枯的野草，手拿落葉的光棍，眼望滿目的瘡痍，背對凄涼的大地，內心萬念般俱灰。

這種場面應該不會有人追求，是吧。

前戲做足，水到渠成

我對畫畫不太了解，但是我知道有個成語叫胸有成竹嘛，就是在畫竹子之前，大腦中已經有竹子的樣子了。所以畫畫就是一個對物體的復原過程。

隨著計算機科學的發展，軟件行業也得了較大的發展，三維立體圖，三維動畫，各種仿真程序等做的越來越逼真。這對各行各業都起到了極大的推動作用。

比如在一棟大樓開工前，它的三維立體模型就用軟件做出來了，跟真的一摸一樣。那么在實際建造時，就是一個復原過程，只需解決工程問題即可。

同樣在裝修開始前，裝飾公司也會用三維軟件把裝修后的效果圖給畫出來，我們可以調整配色方案，調整家具布局，這樣最后裝出來的才能最大限度的滿意。

寫代碼也是一樣的，如果提前不規劃，想到哪兒寫到哪兒，結果很可能就是混亂的。不僅別人很難看懂，自己過段時間也會迷糊。如果再沒有注釋的話，簡直就是噩夢。

當然了，寫代碼要想做到“胸有成竹”，其實也是很難的。但是大腦中必須有個七七八八的樣子，這樣寫代碼的過程就是對自己想法的復原過程或實現過程，這就叫做代碼實現。

所以“代碼實現”的含義就是，已經做好了設計或已經有了成熟的想法，然后采用寫代碼的方式來變現。而不是啥也不想，一上來就一通亂寫。

就像從來沒見過，哪個人在街上看到個美女就立馬上去表白的，這樣的結果不是挨罵就是挨揍。所以，無論做什么事情，前戲一定要做足。

模型化是必由之路

其實“建模”這個詞我們每個人都知道，而且都聽過無數次了，我自然也是這樣的，但是我以前一直沒有認真思考過這個問題，所以對建模也沒有什么深刻印象。

直到我從事軟件開發幾年后，我發現如果能把復雜的問題在生活中找到一個與之相似的場景，這樣問題可以得到極大的簡化，真的是極大的。

這其實是一種“轉換”的思想，把不熟悉領域的問題轉換到熟悉的領域去解決。當然這也是一種“模型”思想，因為在我們熟悉的領域必然存在很多我們熟悉的場景，而場景就是模型，或者說是簡化的模型。

舉一個轉換的例子，以前科學家在地球上觀測火星，記錄了很多時間和位置數據，最后把火星的軌跡畫出來，發現是一團亂麻。可是我們都知道火星的軌道明明就是橢圓啊。

這需要一個前提，就是以太陽作為參考系才是橢圓。但是科學家是在地球上觀測的，是以地球作為參考系的，因此畫出來的是火星相對于地球的軌道，是非常復雜的。

這里講的是參考系或坐標系的轉換，可以極大的簡化天體的軌道方程。我記得高中物理中也有通過轉換坐標系來簡化解題過程的。

把復雜的領域轉換到簡單的領域，把不熟悉的領域轉換到熟悉的領域，很多熟悉的場景自然浮現，很多適合的模型也會靈光乍現。

操練一把試試

老話說得好，“光說不練假把式，光練不說真把式，連說帶練全把式”。這次咱們來個全活兒，從頭到腳的“大保健”，有說也有練。

首先需要鄭重說明的是：

在對未知事物探索的過程中，不存在嚴格意義上的對錯，也不存在嚴格意義上的好壞。

只有一個八字方針，那就是：大膽假設，小心求證。

我希望讀者朋友不要以對錯好壞去評價這個世界上的任何人和事。這不是一個非黑即白的世界，這是一個五彩繽紛的世界，同樣，這也是一個真實的世界。

假設領導讓你實現一個限流方案，可是你對此沒有一點概念，說白了就是束手無策，因為你從來沒有接觸過編程中的限流。

此時我們要把不熟悉的領域轉換為熟悉的領域，那么什么領域是我們最熟悉的呢？當然非生活莫屬，那生活中有限流場景嗎？

非常之多，經過這次疫情之后，我們應該對限流更熟悉一籌。下圖就是2月份在我家樓下拍的，超市八點半開門，我去晚了，所以要排隊等待。

這其實就是一個限流場景，因為怕人員太密集的話，會增加互相感染的風險，所以在人為的控制。

我們一起來分析下，看這個場景中有哪些值得我們關注的方面：

1、所有人進入超市前都要測體溫（后來還要掃碼），也就是說需要滿足一定條件才可以進入，這叫準入門檻。

2、體溫并不是自己測，而是由專人為你測，所以這個人就是準入門檻的執行者。

3、超市空間有限，一次進入的人數是有限制的，要保證低的人員密度。所以有專人查看著密度，一旦達到臨界值便通知門口測體溫的，不允許顧客再進入。或者測體溫的自己記錄好進入超市的人員數目也行。

4、當超市內人員密度降下來后，或者出去一定數目的顧客后，才允許新的顧客進來。

5、當超市內顧客購物時間過長時，會有人提醒他們趕緊選購好去收銀臺結賬，外面還有很多人在排隊等著呢。

6、當體溫不合格時，會被拒絕入內，或者直接打120把人拉走。（我沒有遇到過不合格這種情況）

7、外面很多人排隊時，可能還需要一個人來維持隊形或秩序，或給一些解釋說明，甚至安撫。

8、有些人排隊時間較長，等不及了，就選擇放棄，然后自行離開了。

這就是生活中真實發生的且我親身參與的限流場景。對于這個普通的甚至有些平淡的場景，我們隨意分析一下，竟然分析出至少8個方面的問題。

所以我就想問一句，對于那些想成為優秀程序員或架構師的人，你們是否真心愿意花時間和精力去琢磨和分析這些各個方面的問題，如果愿意，那恭喜你，如果不愿意，那也恭喜你，至少是遵從自己內心的選擇。

這個場景中描述的限流方法是有效的，因為最終解決了問題，大家都買到了菜，而且整個過程中人員也不密集。

我們可以把這個場景（或模型）中的限流方法轉換到編程中，如果代碼寫的沒有問題的話，一定是管用的，因為它的有效性已經在生活中得到了驗證。

不過話說回來，肯定不是原封不動的直接照抄過去，要根據實際的情況和需求進行適合的取舍和定向的改造。畢竟生活領域和編程領域還是有差別的。

當然了，即使最后不采用這個方法，但是，它也為你打開了思路，不再讓你沒有方向，不再讓你寸步難行。

最后送給讀者朋友一個祝福（或期望）吧：

勤學習，多思考，要總結，會分析。凡事多向自己熟悉的領域靠，但也要有挑戰未知領域的勇氣。

推薦閱讀

• 一文帶你認識keepalived，再帶你通關LVS+Keepalived！

• 那個分分鐘處理 10 億節點圖計算的 Plato，現在怎么樣了？
  

• “谷歌殺手”發明者，科學天才 Wolfram

• 數據庫激蕩 40 年，深入解析 PostgreSQL、NewSQL 演進歷程

• 超詳細！一文告訴你 SparkStreaming 如何整合 Kafka ！附代碼可實踐

• 5分鐘！就能學會以太坊 JSON API 基礎知識！

  真香，朕在看了！

總結

以上是生活随笔為你收集整理的架构师前辈告诉你：代码该如何才能自己写得容易，别人看得也不痛苦的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。