為何我認為在程式設計中選擇乏味的技術堆疊很重要
前幾天有一個人問了我一個問題。這個人想要開始寫部落格,並決定用 Angular 作為前端,自己建立一個部落格平台。
我回答他,如果目標是寫部落格,那麼他必須放棄這個想法,使用現成的解決方案。
我想他不喜歡我的回答,因為我沒有收到回覆,但我想表達的意思是:如果你想要創建一個部落格並且認真對待寫作,那麼你應該使用最乏味和可靠的工具。絕對不要在部落格基礎架構上浪費時間,如果你想進行一些認真的寫作。
技術必須退居次要,你只需要專注於內容。
否則,你會花費大部分的空閒時間來調整部落格平台(除了你之外沒有人在乎這些),而不是寫作內容。沒有人在乎部落格架構。
如果你想要製作一個視頻,你會先編寫一個 YouTube 的克隆嗎?它能夠同時處理1億個訪客嗎?這讓我想起那些想寫視頻遊戲並開始建立物理引擎的人,最終卻沒能完成遊戲。
我使用 Hugo,一個靜態網站生成器。
Hugo 對我來說是最好的,因為它專注於部落格和 Markdown。它很乏味。它的模板語言很乏味。當我需要微調一些東西時,我會睡著。我很喜歡它。
Hugo 最好的特點在於它快速,我認為這主要得益於使用了 Go。如今看來,這似乎是一個乏味的特點。
“看看 Gatsby,它好華麗!”
Gatsby(這只是一個例子,我並沒有反對它)對我來說已經太華麗了,即使它是個很棒的技術。為什麼?因為它讓你太過關注技術而忽略了結果。作為一個開發者,你可能覺得這很棒,但事實並非如此。React、GraphQL,這些都有點太令人興奮了。
這讓我想起了 Redux,那些對於具有“時間旅行”示範的人感到興奮的人,這是在日常編碼中非常有用的功能(開玩笑)。人們為了使用華麗的技術而過度複雜化他們的應用程式。
讓我們以預取為例。當靜態網站已經足夠快時,我們真的需要預取嗎?我們的部落格訪客有要求嗎?這樣做有什麼缺點?可能會出問題嗎?
記住墨菲定律:“任何可能出錯的事情終將出錯”
我曾經和一位使用 Gatsby 開始撰寫部落格的人交談過,他意識到他們並沒有啟用服務器端渲染,即使他們認為已經啟用了。這使得該部落格幾乎對 Google 不可見(是的,我知道他們有時執行 JavaScript,但你就容忍我,堅持使用乏味的服務器端渲染)。
在一個普通的部落格中,每位用戶平均只會瀏覽1.1 / 1.2個頁面。這意味著大部分用戶只會經過 Google 來到你的網站上,快速瀏覽一下然後離開。你真的需要預取所有的鏈接嗎?為什麼要浪費那麼多的數據和資源?
讓我們停止批評 Gatsby,我真的很喜歡它作為創建網站和應用程式的工具。
我的觀點是,為了開始一個簡單的部落格,你可能不需要它80%的功能。使用一個更簡單的工具,一個專為部落格而設計的工具,絕對不要自己寫。
這也適用於更複雜的應用程式。你應該使用你已經使用了10年的技術,還是應該去嘗試你不了解但大家都講得很好的潮流技術?你應該使用 Rails 還是 Elixir?我應該使用 TypeScript 還是 Reason 編寫我的下一個應用程式?C、Go還是Rust?
我們浪費了大量的時間,從舊的庫跳到新的庫,從舊的框架跳到新的框架。想想 jQuery、Backbone和Ember,以及它們之前和之後出現的無數框架。想想 AngularJS 和 Angular。想想 Laravel 掀起 PHP 世界的風潮之前的所有 PHP 框架。記得 NoSQL 的“革命”讓我們重新考慮使用 MySQL,轉而使用更花哨和更靈活的數據庫系統?事實上,SQL 仍然強勢。
“只需使用 MySQL,乏味的技術革命就在這裡” Marty Weiner,Reddit CTO,2016
大多數開發人員認為是行業標準的工具是由 Google 和 Facebook 等大型公司建立的,它們對於它們的需求來說是完美的。一個小團隊或獨立開發人員可能也有相同的需求,但這有多大可能性呢?是因為同儕壓力和炒作而驅使的嗎?還是因為營銷的影響?
你想要做的事情是否可以完全使用純 JavaScript 和 DOM API 實現,還是你真的需要重新編寫整個應用程式,花費幾天時間來嘗試讓 Webpack 符合你的需求?有時這是一個很好的選擇,有時不是那麼完美。使用 DOM APIs 會感覺很乏味,但這可能會使你的應用程式更快速,當工程圈子中的其他人說這樣做會一團糟時,你可能在10倍的時間內完成並且它可能運行得更好。
有一個原則是你瞭解你所使用的平台的缺點,草坪的另一邊總是更綠。你喜歡想像新平台是完美的,但從來沒有發生過,魔鬼就在於細節。
這些細節可能是你在投入這個看起來對你來說很乏味的堆疊數年而熟練掌握的。因為你是一個工程師!你喜歡挑戰!你不想錯過學習新事物的機會!
你仍然可以這麼做。
我認為在創建關鍵平台(例如你的部落格平台,如果你是認真對待它的)時,乏味的技術更好。理解這個概念是成為高級開發人員的一部分。