譯者序

在還沒開始翻譯之前，我對于這篇譯者序就已經有了規劃：先聊聊我翻譯這本書的原因，再大致把這本書里的內容敘述一遍，最后重點推薦一些我個人認為有價值的章節。但是在后續潤色的過程中（其實也相當于重讀了），我發現當初的設想是不可能實現的，因為整本書涉及面太廣了——代碼調試、策略測試、團隊協作、效能提升、待人接物無所不談。

你肯定也疑惑了，那么本書究竟想介紹什么？難道沒有一個統一的主題嗎？

答案是“有”，用兩個字——原則總結就夠了。本書涵蓋的是所有你在開發中可能會運用到的各式各樣的原則。在本書的前言和第1章中，作者就開宗明義地指出，本書的目的是幫助你成為一名更好的開發者。通過書中作者在過往工作中總結下來的這些經驗，希望能夠讓你在成長的路上少走彎路。

多談些主義

關于如何對待編程領域中這些和編程間接、直接相關的知識，我見過兩種極端的態度：有的人只看結果，只關心“寫代碼”，而對“寫好代碼”一無所知；第二類人深諳各種架構設計、整潔代碼之道，但對于當下代碼中遭遇的問題卻沒有落地的方案。

在互聯網公司的多年工作經驗讓我個人更習慣于從第一種人的視角看待問題，畢竟這是行業性質決定的，跑馬圈地、快速擴張才重要，行業不允許你有時間思考。但是拋開行業、拋開公司，單純地看編碼這件事，我作為程序員最大的疑惑是：為什么我在每一家公司接手的代碼庫都如此難以維護？為什么總有人寫出500行代碼的函數和1000行代碼的組件？為什么每一個迭代的最后總是要加班加點，研發、測試、產品經理都叫苦不迭？為什么問題年復一年地發生，卻沒有人想做些什么來改變現狀？

DRY——Don’t Repeat Yourself。別忘了這可是我們自己說的。

我觀察到程序員存在一種戰略上的惰性，對學習新技術和新框架，對閱讀源碼有發自內心的推崇。我不否定這種行為，新技術能給我們的項目帶來便利，能給我們的簡歷增添濃墨重彩的一筆，這無可厚非。但技術背后的編寫思路演化至今的原因，同樣值得了解，它們和技術的語法本身同樣重要。仔細回想和思考就不難發現，工具的好壞和代碼的好壞，與項目將來適應需求變化的靈活能力沒有關系，從寫Vanilla JavaScript的年代，到BackboneJS，再到React，你看到團隊中能把代碼寫好的人真的是越來越多嗎？

不同行業對于軟件質量的要求是不同的。且不說你所在的行業有沒有意愿和資源解決這些問題，如果有，你應該去哪里尋找方案？

在我看來，前人留下的經驗是最值得我們借鑒的寶貴財富，無論這種經驗是來自傳統軟件行業還是其他互聯網公司。我們遇到的問題，尤其是對傳統軟件行業而言，他們在十年前甚至二十年前就已經遇到了，所思所想比我們更深遠。然而這些經驗也并不神秘，其中有一部分經典就是你已經耳濡目染的各類編程法則和開發模式，而另一類更實際的內容就散落在不同渠道的文字和口述當中，例如本書中。

但讓人望而卻步的是，大部分原則聽起來都過于抽象了，甚至有些是反直覺的。

我明白抽象帶給人的挫敗感，你肯定聽說過不少，甚至它們的名字都可以信手拈來，例如可維護性、可擴展性、可讀性、KISS、YANGNI等。但什么樣的代碼才稱得上可讀性好，KISS應該如何在代碼中實施？

反直覺的實踐也比比皆是。如果我告訴你，在每一次正式開發代碼前，提前對代碼做一些重構工作，那么無論是短期還是長期來看，你整體付出的開發時間是下降而不是上升的，你愿意相信嗎？相信之后又敢在工作中嘗試嗎？

遺憾的是有一些原則背后確實存在復雜的知識體系作為支撐，哪怕我用思維導圖把背后涉獵的概念一五一十地列舉出來，你的內心可能依然毫無波瀾。因為其中的很多原則需要你看到相似的代碼后才能心領神會，輪扁斫輪的寓意也是在此。但還有一些并不是，比如在判斷一個函數長度是否恰當時，我們有一些實打實的評判標準，其中一條是函數是否能在一個屏幕之內顯示完畢。

Uncle Bob Martin在他的“The Principles of OOD”系列文章中談到過糟糕設計（Bad Design）的幾個特征：

□僵化（Rigidity）：代碼難以修改，因為改動會影響到的地方太多。

□脆弱（Fragility）：當你做出修改時，系統中預期之外的地方會遭到破壞。

□難以修改（Immobility）：代碼很難被復用，因為它與當前系統中的功能耦合在了一起。

這一系列簡單扼要的描述，就將編程中涉及的原則和代碼中具體的癥狀聯系到了一起。

學習這些知識難嗎？一點也不難。想要了解它們很簡單，但想要在編程中靈活運用它們則是另外一回事，畢竟提升編程技能靠的不是死記硬背，而是反復刻意的練習。但再困難，也會比將來回過頭設法挽回代碼造成的損失要簡單。

如果他們錯了怎么辦

我無法否認這種可能性。但也請允許我問另一個問題：當需要在一個團隊內對某個技術方案進行決策時，決策應該是專制的還是民主的？

不如我再把這個例子具象化一些，假設在一個新建的項目中，我們需要制定webpack關于chunk打包的策略，那么很多與chunk有關的配置，比如hash、cacheGroups，應該如何配置？

解決這個問題的過程不太可能是民主的。首先人們需要對webpack涉及哪些chunk配置，以及每一個配置的可選項背后對應解決的問題場景有所了解；其次還要對項目的現狀、站點內靜態資源加載的需求有清晰的認識。

這些決策的前提知識，并不是每個人都具備的。

大部分時候——我說的是大部分時候，技術的決策是專制的。如果我在這個技術領域有豐富的經驗，如果我解決過足夠多的問題，哪怕是我在這個項目中待的足夠久，那么對于當下任何一個新的問題，我就能想得更多，看得更遠。當然如果團隊的時間和人員充足，可以抱著培養新人的心態，放手把問題交給一個從沒有接觸過這方面領域的人來解決。

很多時候這些原則不一定是錯的，而是讓你聽上去以為它是錯的。就拿注釋這件事來說，大部分程序員會認為注釋是消除代碼“惡臭”的靈丹妙藥，但是：

□Martin Fowler在《重構》里告訴你沒事別寫注釋。

□Uncle Bob Martin在《代碼整潔之道》里告訴你沒事別寫注釋。

□Jeff Atwood在codinghorror技術博客里告訴你沒事別寫注釋。

那你還有什么理由要繼續寫注釋？

現在依然半信半疑的你該何去何從？

你可以去了解這些建議背后的動機。在這些建議的背后他們都給出了各自的理由，以及替代的解決方案是什么。“start with why”有助于理解，神奇地讓你從對立面轉向認同他們的觀點。

但有一些知識可能找不到出處，或者只是團隊中留下的實踐，這種實踐還是以代碼的形式給出的。在這種情況下，你或許需要的是“信仰之躍”（Take a leap of faith）。也就是說此時你需要無條件地相信，日后再慢慢驗證，慢慢理解。

還有一種選擇，那就是置若罔聞，但可能需要承擔慘痛的、后患無窮的代價。

如果你依然對書中的原則將信將疑的話，不得不提我翻譯這本書的另一個原因：書中很多內容與我在實際工作中總結出的經驗不謀而合。

我個人在從獨立開發者的視角轉向關注團隊、關注項目、關注流程的視角的過程中，發現技術問題已不再是我眼中需要解決的首要難題。

因為哪怕你找到了整治項目的靈丹妙藥（某種最佳實踐），也需要整個團隊的力量來幫助你落地且一如既往地保持下去。項目里不需要英雄，即使團隊中真的存在能寫一手好代碼的高手，他的辛苦結晶也很快就會被庸才們“孜孜不倦”的“勞動成果”所打敗。

迫切地希望團隊中有“救世主”角色出現是一個危險的信號，而且通常這個時候救世主也派不上什么用場。另外，即便有靈丹妙藥，你有沒有考慮過團隊里的每個成員能否“咽得下”這顆靈丹妙藥？基于同樣的原因，僅僅只有幾個人能夠理解這套方案并且在項目里實施起來是不夠的。所以靈丹妙藥要怎么選？底線在哪？說白了，底線就是團隊能力的下線。

如何提升團隊效能？如何幫助團隊中的成員成長為明星程序員？這些都是在本書中會談及的問題。

多研究些問題

還記得我在開頭提及的第二種人嗎？他們同樣是危險的。如果拋開實現，單純地把問題抽象到某種高度，可能會讓問題陷入一種什么都解決得了或什么都解決不了的極端局面中。前者相當于“不就是”，后者等同于“又怎樣”。萬事萬物都可以套用“不就是”與“又怎樣”的句式，這樣的描述看似是無敵的，但仔細想想又破綻百出。

“不就是微前端嘛”——不好意思你說的是哪一種微前端？不同框架下組件間的通信問題是如何解決的？構建時集成流水線的粒度如何？組件間互相依賴的版本管理策略如何？

“又怎樣”的心態更是可惡，當代碼稍有改善時，就會有悲觀主義者“友善”地“提醒”你：這種杯水車薪的改善又能怎樣呢？現在整個代碼庫依然身陷囹圄。

這種思考問題的方式一點都說不通，代碼腐化是一個持續的過程，但為什么我們卻想在某個時間段內一勞永逸地把問題解決？

實話實說大部分代碼庫都是滿目瘡痍的，問題在于你要如何挽救它，從哪里開始挽救它。無論我們是引入committer機制還是代碼評審會議，總有一天會無法堅持下去，最壞的情況無非是我們沒有讓它變得更好，但也保證了在嘗試的過程中它不會變得更差。

前面所說的開發人員的能力困境“不就是”溫伯格的咨詢第二定律：不管一開始看起來什么樣，它永遠是人的問題。

它夠不夠抽象？夠。夠不夠深刻？夠。夠不夠有哲理？夠。但說實話對于解決我們當下的問題并沒有太大的幫助。如果瓶頸真的在團隊的成員上，我們想知道的是：怎樣才能提升團隊成員的編程能力？再實際一些，作為一家創業公司，我無法提供非常有競爭力的薪水來招到頂級的人才，或者迫于交付壓力我無法花太多的時間在培訓、代碼審查、重構上，那么我的代碼應該如何被拯救？

在我看來本書的魅力正是擺脫了高高在上的姿態，在“說白話”，作者并非只是憑空扔給你一句話（每一句話高深到每個詞你都認識，但連起來就讀不懂那種）之后讓你慢慢參悟。對于一些概念，甚至是常見的概念，作者會進行澄清和定義。如果他提出的是一條建議，那么他還會解釋這條建議的來龍去脈和它所適用的范圍。對于在實施過程中可能遭遇的阻礙，他也做出了適當的預測并給出了解決辦法。

我不敢茍同他在書中提出的每一個觀點，最終是否適合你還需要你自行判斷，畢竟在這個領域內沒有銀彈。但相信這些內容能夠給你帶來啟發。