再讀王垠的《編程的智慧》,有怎樣的感想？

王垠老師的《編程的智慧》這篇文章已經(jīng)讀了最起碼5遍了，最近的項(xiàng)目做完一個階段，到了把他做干凈的時候，也就是優(yōu)化代碼，全面整理的階段，這個時候我又想起了這篇編程的智慧，有一些啟發(fā)與大家分享。

王垠老師的《編程的智慧》

王垠老師是誰？想必很多朋友都有耳聞，不知道的也可以去查一查，首先是個真誠的人，性情中人，他也是一個頗具爭議的人物，有過多次退學(xué)、辭職被封殺、噴教育制度等等一些爭議事件，但是毫無疑問，他在計(jì)算機(jī)的理解、個人精湛的技術(shù)方面是無可爭議的。

這里沒有對個人進(jìn)行正面或者負(fù)面的討論，主要是他對語言的理解和經(jīng)驗(yàn)讓我受益，而我也覺得看人就需要看他的優(yōu)點(diǎn)和對自己有益處的東西就行了，《編程的智慧》這篇文章真的可以仔細(xì)看看。

從第一次看這篇文章的時候就感覺這文章十分的厲害，不在我當(dāng)時的層次范圍里，甚至現(xiàn)在也不是，我也是漸漸的學(xué)習(xí)按照其中去做。把文中的習(xí)慣和好的做法融入到自己寫的代碼中去但是很多時候總是找不得要領(lǐng)，有點(diǎn)邯鄲學(xué)步，所以總是在想到的時候打開看一遍。

這次再讀的時候覺得應(yīng)該整理一下，以自己的方式記錄出來，與大家分享交流，形成一個直觀的概念。

編程的智慧表達(dá)了什么？

王垠老師提出過很多次的教條主義，這篇文章也是苦口婆心的說了一些編程的知識與技巧，我們可能在編程的時候沒有那么多的創(chuàng)新與自己的見解，但是我們應(yīng)該知道什么時候干什么不該干什么，這是編程的共識，也是編程的智慧。

反復(fù)推敲代碼

反復(fù)回頭推敲代碼真的很有益處，我認(rèn)為在寫代碼之前就應(yīng)該想著怎么寫，一般來說，想的時間占比70%，寫的時間30%即可。而在調(diào)試完成之后，更要回過頭推敲。

可能得以實(shí)現(xiàn)的功能你用了100行代碼搞定了，但是回頭來看可以刪掉不少的代碼，這就會漸漸的把我們的思路帶到精簡的階段，會讓我們的水平得到一個提升。

古人也說過，溫故而知新，不僅是回頭看代碼，甚至是過段時間過頭看這個項(xiàng)目，可能都會有新的東西，這種感覺是難得的，不然每次看別人的留下的代碼都會吐槽：臥槽這個傻逼寫的什么代碼了。

寫優(yōu)雅的代碼

優(yōu)雅在代碼中也可以體現(xiàn)，這一點(diǎn)確實(shí)還是很有趣的，其實(shí)早就在很久之前，就聽過雷軍的一句話，寫像詩一樣的代碼，我想這就是優(yōu)雅的一方面了。

一面說到，我們書寫的格式以及大體結(jié)構(gòu)上需要整齊，有好的分支與傳遞，還有在嵌套或者縮進(jìn)方面都需要注意。我相信好的結(jié)構(gòu)可以使我們的理解更加清晰，也會讓我們的邏輯更加緊密。

另一面就是我們寫代碼的時候，需要注意一些用法，比如使用if語句的時候，else分支里面有可能出現(xiàn)少量重復(fù)的代碼，但是這樣的結(jié)構(gòu)卻是更加嚴(yán)密的。

寫模塊化的代碼

什么是模塊化？大家都知道我發(fā)過很多模塊化的文章，但是真正的模塊化，并不是文本意義上的，而是邏輯意義上的。

精選匯總 | 模塊化編程 也講到了很多。這里最讓我收獲大的一句話就是：每個函數(shù)只做一件簡單的事情。

寫可讀的代碼

每當(dāng)我們看代碼的時候，總是會說這個人寫的代碼連注釋都沒有，讓人怎么看。或者這么多注釋，表達(dá)的也不清晰或者錯位了，可能讓我們產(chǎn)生更大的誤解了，不但沒有更可讀反而成了障礙。

所以注釋不是主要原因，正真可讀的代碼體現(xiàn)在每個細(xì)節(jié)上面。王垠老師說到：真正優(yōu)雅可讀的代碼，是幾乎不需要注釋的。這一點(diǎn)我可能還沒體會到，有時候還是需要一些語言來輔助一下。

但是其說到各種命名、合理換行、局部變量的使用、把復(fù)雜的邏輯提取出去，做成幫助函數(shù)、把復(fù)雜的表達(dá)式提取出去，做成中間變量，這些思想與做法真的是難能可貴的。

寫簡單的代碼

隨著時代發(fā)展，語言也漸漸的變得豐富起來，也就是寫法變得更多了，支持更多特性了，有些代碼變得短小精悍了但是依然可以解決當(dāng)前的問題，這些特性往往是一些難以直觀理解的代碼。

的確，豐富的特性在一些特殊的場合是很耐用的，但是我們不能盲目去追求，去標(biāo)新立異并以此為榮。我們需要寫簡單的代碼，免得在后續(xù)讓整個邏輯看起來沒問題實(shí)際上正是這種特性使我們變得模糊，比如這個少了花括號。

if (...) 
  action1();

這個判斷沒使用{}，可是這其實(shí)經(jīng)常引起奇怪的問題。比如，你后來想要加一句話action2()到這個 if 里面，于是你就把代碼改成這樣，不用說，這肯定是有問題的，而往往我們可以避免。

if (...) 
  action1();
  action2();

寫直觀的代碼

王垠老師說到：寫代碼有一條重要的原則：如果有更加直接，更加清晰的寫法，就選擇它，即使它看起來更長，更笨，也一樣選擇它。

假如一段代碼寫出以下樣式，你看得出想表達(dá)的是什么意思嗎？

if (action1() || action2() && action3()) {
  ...
}

這種寫法是濫用了邏輯操作&&的短路特性，這種累加的判斷會讓人很費(fèi)腦，而隨著代碼或者邏輯復(fù)雜度的增加，這樣的代碼就很容易出現(xiàn)錯誤了。其實(shí)很簡單的就可以改成以下代碼，會清晰很多。

if (!action1()) {
  if (action2()) {
    action3();
  }
}

寫無懈可擊的代碼

無懈可擊的代碼其實(shí)是很難的，以前在上語文課的時候，老師說過好的詩句沒有一個字是多余的，甚至沒有哪一個字是可以替代的，但是代碼不盡相同。

王垠老師想表達(dá)的應(yīng)該是讓代碼不容易出現(xiàn)疏忽和漏洞，比如if語句分支最好考慮到極端狀況，也就是說最好要有else，在里面處理一些東西。比如下面s缺省為 null，如果x<5，那么把它等于ok，如果不成立，你需要往上面看，才能知道s的值是什么。

String s = "";
if (x < 5) {
  s = "ok";
}

那么將代碼改成下面的形式，雖然多打了兩個字，然而它卻更加清晰。

String s;
if (x < 5) {
  s = "ok";
} else {
  s = "";
}

正確處理錯誤

在異常出現(xiàn)的當(dāng)時就作出處理，不要丟回給調(diào)用者。

這是給我印象最深的一句話，一旦有錯誤，就應(yīng)該立即處理，即使是任何一種可能會出現(xiàn)的情況，都可能產(chǎn)生意想不到的災(zāi)難性結(jié)果。

我在項(xiàng)目中經(jīng)常遇到這樣的情況，為了趕項(xiàng)目進(jìn)度，這種方法實(shí)現(xiàn)不了或者實(shí)現(xiàn)的不是那么靈活，就放任不管，而繼續(xù)做下去。進(jìn)度是趕上了，但是總會出現(xiàn)一些莫名其妙的錯誤，或者當(dāng)需要更改一些功能的時候，這一塊代碼又出現(xiàn)問題了，你不得不重新去解決，所以不要逃避錯誤，每個錯誤都不容放過。

防止過度工程

只說三點(diǎn)，直擊要害

1. 先把眼前的問題解決掉，解決好，再考慮將來的擴(kuò)展問題。

2. 先寫出可用的代碼，反復(fù)推敲，再考慮是否需要重用的問題。

3. 先寫出可用，簡單，明顯沒有 bug 的代碼，再考慮測試的問題

Over engineering在我看來就是一個過度裝逼的設(shè)計(jì)，我在工作中也遇到過這樣的同事，一副架構(gòu)師的樣式指點(diǎn)江山，但實(shí)際上最重要的還是眼前的問題，解決掉！

最后

我認(rèn)為王垠老師身上最讓我缺少的就是：對權(quán)威以及先行者敢于質(zhì)疑，對編程語言原理、框架、概念等等理解的深度，以及他的鉆研精神，不論怎么樣，我都收獲了很多。

愿我們都可以看到他人的閃光點(diǎn)，同樣的這篇《編程的智慧》真的值得我們好好讀一下。