作者  | 馬大偉

多年以后，面對(duì)這篇文章，我會(huì)想起那兩天失敗的令人崩潰的開發(fā)過程。當(dāng)時(shí)，只是一個(gè)簡單的編碼需求，我信心滿滿的計(jì)劃一下午搞定，但是最終的過程卻是令人如此沮喪，讓我不得不懷疑我還適不適合繼續(xù)當(dāng)程序員。

思緒飄到那天的場景，我在開發(fā)過程中遇到一個(gè)很簡單的需求：將 JSON 格式的文件轉(zhuǎn)換成 JavaScript 的常量文件（json到j(luò)s的轉(zhuǎn)換不只是格式的轉(zhuǎn)換，還要在js文件生成json的全路徑）。如下圖：

我的想法是先把 JSON 轉(zhuǎn)成一棵抽象語法樹（AST），然后遍歷這棵樹，在特定的節(jié)點(diǎn)打印出所需的字符就可以了。JSON 轉(zhuǎn) AST 直接用 Clojure 的神器 instaparse 庫。我對(duì) Clojure 不熟悉，剛好可以通過這個(gè)過程提升下，也能試試這個(gè)神器到底神不神。通過這種特殊需求能一舉多得，讓無聊的開發(fā)過程變得有期待。

第一步是將 JSON 轉(zhuǎn) AST。對(duì)于 instaparse 庫來說這是個(gè)很簡單的任務(wù)，網(wǎng)上隨便搜索下就找到了解析 JSON 的代碼。耗時(shí)不過幾分鐘。

第二步是需要遍歷這棵樹。遍歷樹是我在大學(xué)算法課程上就學(xué)過的，雖然年代久遠(yuǎn)算法的細(xì)節(jié)都已經(jīng)忘記，但是我還記得有深度遍歷和廣度遍歷兩種方式。我的這個(gè)需求特殊之處在于需要在遍歷的時(shí)候打印相關(guān)的字符，比如需要在遍歷某個(gè)節(jié)點(diǎn)開始和結(jié)束的時(shí)候都得打印 [] 或 {} 。Clojure 應(yīng)該有具體的庫做這個(gè)事，簡單搜索下很快就找到了 walk 和 tree-seq 這兩個(gè)函數(shù)。這兩個(gè)函數(shù)看起來比較復(fù)雜，找了一些例子大概了解到： walk 函數(shù)可以在遍歷是提供入和出兩個(gè)鉤子來執(zhí)行對(duì)集合元素的轉(zhuǎn)換，而 tree-seq 會(huì)以深度遍歷樹的方式輸出一個(gè)節(jié)點(diǎn)序列。理解后就開始嘗試，花了半天后發(fā)現(xiàn)事情比我想象中的復(fù)雜，這兩個(gè)函數(shù)看起來強(qiáng)大，但是無法在遍歷節(jié)點(diǎn)時(shí)保存狀態(tài)，而我卻需要這個(gè)狀態(tài)來記錄我遍歷的路徑。看起來需要自己寫個(gè)遍歷算法來實(shí)現(xiàn)了，這時(shí)候半天已經(jīng)過去了，但我目前的進(jìn)度只解決了一半的問題。

自己寫遍歷樹的算法是一件不難的事情，我用 Java 也實(shí)現(xiàn)過，現(xiàn)在用 Clojure 實(shí)現(xiàn)看起來也不難。但是 Clojure 和 Java 的差異很大：它是函數(shù)式的，數(shù)據(jù)類型都不可變，很多操作都是通過遞歸來完成。用遞歸來實(shí)現(xiàn)深度遍歷也不是難事，但是當(dāng)你用不熟悉的語言去實(shí)現(xiàn)問題可能就會(huì)變得不可控。

在嘗試了一天多并寫了三個(gè)失敗的版本后我陷入了絕望的狀態(tài)，因?yàn)橐粋€(gè)非常簡單的問題我卻搞不定。在第二個(gè)版本的時(shí)候我以為我解決了這個(gè)問題，最終把實(shí)際的數(shù)據(jù)輸入?yún)s發(fā)現(xiàn)結(jié)果不符合預(yù)期。因?yàn)槲矣昧撕唵蔚臏y(cè)試數(shù)據(jù)，實(shí)際的數(shù)據(jù)比測(cè)試數(shù)據(jù)全面，我寫的版本只是解決了測(cè)試數(shù)據(jù)的問題。在第三個(gè)版本的時(shí)候因?yàn)榭紤]的情況更多寫的也更復(fù)雜了，導(dǎo)致程序始終跑不起來。因?yàn)槲也皇煜?Clojure 的語法，始終難以寫出滿足條件的遞歸代碼。

由于長時(shí)間在這個(gè)問題上耗著又沒有任何思路，我在周末連續(xù)搞了十幾小時(shí)后眼睛和腰終于受不了了。第二天整個(gè)人身心俱疲，在床上躺了半天后琢磨如何尋求幫助。腦海中第一個(gè)念頭就是在 Clojure 的社區(qū)里直接提問。為了能讓大家有意愿回答我的問題，我首先把自己的問題梳理了下，畫了一個(gè)簡單的草圖：

然后在 StackOverflow 提了這個(gè)問題，并在 Clojure 的 Discord 群組、Telegram 國內(nèi)社群和微信群里發(fā)了這個(gè)問題。大概不到半小時(shí)，微信群里有兩個(gè)人發(fā)了自己的代碼。這兩種代碼體現(xiàn)了不同的解決思路，并且附帶優(yōu)雅的實(shí)現(xiàn)，具體的實(shí)現(xiàn)方案我整理到了這個(gè) livebook 中。

第一種方案直接通過遞歸將 AST 語法樹轉(zhuǎn)換成了目標(biāo) Map 的數(shù)據(jù)結(jié)構(gòu)，然后使用 Json 庫打印成 Json 格式。第二種方案沒有使用 AST 語法樹，直接通過 Json 庫拿到 Json 數(shù)據(jù)結(jié)構(gòu)然后遞歸遍歷輸出最終目標(biāo)數(shù)據(jù)結(jié)構(gòu)。

在群里與這兩個(gè)人溝通的過程中，我發(fā)覺我在不知不覺中犯了幾個(gè)錯(cuò)誤：

• 不熟悉 Clojure 代碼，導(dǎo)致沒法使用最佳的函數(shù)和思路去解決問題；
• 通過 Json 庫去輸出最終數(shù)據(jù)結(jié)構(gòu)，而我卻是采用打印的方式將問題復(fù)雜化；
• 沒必要通過抽象語法樹去解決，通過 Json 庫遞歸遍歷 Json 是更簡單的方案；
• 沒使用更好的工具。我一開始用命令行自帶的 Repl，后來覺得編輯長函數(shù)不方便，所以在網(wǎng)上找了一個(gè)在線 Repl。不過后來看到群友提供的在線 livebook， 這種能更方便的開發(fā)并記錄這類代碼。

回顧這個(gè)問題的解決過程，我總結(jié)此次開發(fā)失敗的原因有以下：

• 理解需求錯(cuò)誤。我在遇到這個(gè)問題后并未做深入的分析思考，導(dǎo)致一開始就沖著問題的表象去解決。想著用打印的方式去解決問題，實(shí)際上可以用庫來輸出目標(biāo)格式。
• 不熟悉相關(guān)技術(shù)。我對(duì) Clojure 的熟悉程度還不足以解決這類并不簡單的問題。
• 解決問題不全面。問題總有很多解，拿著錘子很容易看啥都是釘子。我從一開始就想通過 AST 去解決這個(gè)問題，導(dǎo)致思維局限到一條線上了。
• 害怕失敗。因?yàn)橐婚_始覺得問題很簡單，害怕自己沒法在很短的時(shí)間解決，心態(tài)處于失衡的狀態(tài)。后期耗著的時(shí)間越長，思考能力越不在狀態(tài)，反而越來越迷糊。

失敗驅(qū)動(dòng)開發(fā)

不了解程序員的人眼中的程序員可能是這樣的：

但開發(fā)程序或維護(hù)程序，失敗是很常見的：

• 編譯失敗；
• 運(yùn)行失敗；
• 網(wǎng)絡(luò)失敗；
• 內(nèi)存失敗；
• 并發(fā)失敗；
• I/O 失敗；
• 認(rèn)證失敗；
• 權(quán)限失敗；
• 依賴失敗；
• 資源失敗；
• 上線失敗；
• 升級(jí)失敗；
• 環(huán)境設(shè)置失敗；
• 理解需求失敗；
• 項(xiàng)目管理失敗；
• 架構(gòu)設(shè)計(jì)失敗；

程序員的日常就是要在無數(shù)失敗中找尋讓程序正常運(yùn)行的那一種組合，成功運(yùn)行更像是運(yùn)氣與實(shí)力的雙重作用，這也就有了失敗驅(qū)動(dòng)開發(fā)（Failure Driven Development）。

失敗既然是不可避免的，要做好一個(gè)程序員，與失敗平和相處是必須要解決的問題，不然情緒會(huì)長期處于失衡狀態(tài)。

如何以失敗驅(qū)動(dòng)開發(fā)？我會(huì)從以下清單出發(fā)找尋處理失敗的方法：

是否全面理解問題？

很多時(shí)候不是問題復(fù)雜，而是我錯(cuò)誤的理解了問題，在錯(cuò)誤的路上越走越遠(yuǎn)。每當(dāng)失敗時(shí)我會(huì)重新全面的思考問題，看是否能發(fā)現(xiàn)新的解決問題的思路。

是否涉及知識(shí)盲區(qū)？

盲區(qū)是你不知道自己不知道。用有限的知識(shí)去解決未知的問題很容易陷入盲區(qū)而不自知。我的方法是如果一個(gè)失敗的原因我沒法在幾天內(nèi)解決，那很可能就是遇到知識(shí)盲區(qū)了。要跳脫盲區(qū)必須全面的搜索關(guān)聯(lián)的知識(shí)，通過知識(shí)的交叉理解或?qū)ふ腋私膺@個(gè)領(lǐng)域的人幫忙是有效的解決方法。

對(duì)技術(shù)的掌握是否滿足要求？

用不熟悉的技術(shù)去解決不懂的問題很容易失敗。如果對(duì)技術(shù)不熟悉并且難以解決問題的話，我會(huì)從短期和長期兩個(gè)方面出發(fā)制定不同的方案。短期可能會(huì)尋求外部幫助讓更了解的人來幫我解決，長期我會(huì)投入更多時(shí)間提升這方面的技術(shù)。

所用技術(shù)或工具是否合適？

用不合適的技術(shù)和工具去解決問題也很容易導(dǎo)致失敗，并且這種失敗是難以察覺的。有時(shí)候不合適的技術(shù)或工具并不會(huì)讓問題無法得到解決，而是會(huì)浪費(fèi)你大量的時(shí)間去解決技術(shù)或工具本身的問題。要解決這類失敗需要擴(kuò)大知識(shí)廣度，在搜索資料時(shí)不局限某一種技術(shù)，如果你對(duì)多種技術(shù)有一定的理解，就很容易發(fā)覺技術(shù)之間的差異。用合適的技術(shù)或工具能達(dá)到事半功倍的效果。

是否存在解決方案？

很多問題早已經(jīng)被前人解決。所以當(dāng)遇到感覺復(fù)雜的問題，我會(huì)先搜索一番已經(jīng)存在的解決方法，對(duì)問題現(xiàn)存的解決方法有個(gè)大概的認(rèn)知，然后修改這些解決方法讓其能更好的解決我的問題。

是否需要記錄問題？

各類很難搞的問題是提高能力的好機(jī)會(huì)，學(xué)習(xí)現(xiàn)存的解決方法能消滅知識(shí)盲區(qū)。所以不斷的記錄總結(jié)這種問題是提高我能力的好方法。如果一個(gè)人一輩子遇不到難題，他也只能停留在現(xiàn)有的能力圈無法破圈。

是否需要尋求幫助？

花了很多時(shí)間問題卻解決不了是很令人沮喪，有些問題還很緊迫。在嘗試一定時(shí)間還毫無頭緒時(shí)我就會(huì)想辦法找人幫忙。讓人愿意幫忙也需要一些技巧，如果你提出一個(gè)很大的問題，沒人會(huì)愿意免費(fèi)幫忙。所以我會(huì)把問題相關(guān)的上下文都寫下來或畫下來，然后將我錯(cuò)誤的解決方法放上去，標(biāo)記清楚失敗的點(diǎn)在哪里，然后把問題發(fā)給我覺得有這方面技術(shù)的朋友、同事及相關(guān)的社區(qū)。

如果問題比較復(fù)雜，我會(huì)提出付費(fèi)咨詢的請(qǐng)求。在別人幫忙解決后，及時(shí)表達(dá)感謝之情，如有必要也可以發(fā)個(gè)紅包。當(dāng)你通過這種方法認(rèn)識(shí)不同領(lǐng)域的人，逐漸地你解決問題的效率也會(huì)得到提高。一些人會(huì)擔(dān)心，將自己的愚蠢公開暴露出來，尤其是一些低級(jí)錯(cuò)誤出現(xiàn)的時(shí)候，是一件很掉面子的事情。其實(shí)一開始我也擔(dān)心，但是在網(wǎng)上你可以有很多虛擬身份，能緩解這種不適。

更重要的是，暴露自己的愚蠢能有效的解決自己的知識(shí)盲區(qū)，你覺得很復(fù)雜的問題在有經(jīng)驗(yàn)的人看來是很簡單的事情。這其實(shí)是一種極其有效的學(xué)習(xí)成長方式，在這個(gè)過程中我不僅可以解決我的難題，還能學(xué)習(xí)有經(jīng)驗(yàn)的人在這領(lǐng)域里的方法論和效率工具。

身體狀態(tài)是否合適？

長時(shí)間耗在一個(gè)問題上，身體和大腦都會(huì)疲憊。當(dāng)心態(tài)失衡時(shí)，解決問題的能力也會(huì)直線下降。我經(jīng)常會(huì)陷入一種急迫解決問題的困境，直到身體完全扛不住才放棄。這其實(shí)是一種低效的方式，情緒會(huì)在這個(gè)過程中逐漸壓制理智，讓人很難全面的思考問題。

與自己平和相處，接納自己的不足，休息好重新出發(fā)才能走的更長遠(yuǎn)。所以當(dāng)遇到自己很難解決的問題時(shí)，試著先確保身體狀態(tài)是正常的，如果身體很疲憊，先休息而不是直接攻克難題。

每一次失敗都是一次提升自己的機(jī)會(huì)。正是對(duì)失敗過程的不斷迭代解決，多年以后，讓我成為一個(gè)更好的開發(fā)者。