程式設計師觀點：過度思考的三種毒

banq發表於2021-08-13
程式設計師

過度思考也就是想得太多，過於注重理性計劃，該文是 Rust 和 Go Bloom 的創造者 和Black Hat Rust 的作者博文：
我曾經是一個病態的過度思考者。一切都必須仔細計劃，從我對面包師說的要訂購法式長棍麵包的話，到我參與的任何專案的所有無關緊要的細節。在 18:00 或 18:05 發推文更好嗎？生鏽還是去？函式式還是命令式？聯合還是點對點？FROM scratch或者FROM alpine？開源軟體還是免費軟體？藍色還是綠色？
明顯是想多了！想太多
然後我意識到還有另一種表達方式來描述這種情況：分析麻痺/分析癱瘓。
我們都知道“完美是優秀的敵人”，但我們仍然在試圖做出完美的設計、演示、完美的規範文件、完美的資料模型、選擇完美的技術或框架方面浪費了無數時間。
結果？專案從未實現或比計劃晚了幾個月，每個人都感到沮喪。
我已將這個問題的根源追溯到 3 個原因。3種毒藥，所有的痛苦都源自於此。這3種毒是：
  • 教育
  • 營銷
  • 自我

 

第一毒：教育
教育很少是關於如何行動的。更多的是如何思考。因此，我們學會了如何思考，最終導致整個國家都充滿了思考、思考、思考但從未開始做任何事情的人。結果是很多爭論，無論是在網上還是在電視上，以及來自需要幫助他們思考、思考、思考的時間的愚蠢規則和官僚機構。
在科技界，閱讀一些關於軟體架構的部落格時，這是公然的。所使用的術語與該領域的現實相去甚遠，幾乎是荒謬的。我對此事的看法是，任何專案的架構師都需要是開發人員之一，是實幹家之一。
 

毒藥二：營銷
第二個毒藥是由企業對開發者 (B2D) 公司推動的營銷。
這些公司在解決實際問題（通常是可擴充套件性或資料處理方面的問題）的同時，有很大的興趣讓我們相信我們有他們正在解決的問題，並且他們是我們解決這些問題的最大希望。
所以現在，在設計我們的系統時，我們不再只考慮最簡單的解決方案，而是為了解決我們未來的、想象中的問題而考慮無數的替代方案。SQL 還是 NoSQL？容器還是函式？Java 還是 Kotlin？
老實說，大多數時候（我懷疑它超過 90%），我們只需要PostgreSQL作為資料庫，Go、PHP (Laravel) 或 Node.js 作為後端，前端使用 React 或 Vue.js，根據團隊的喜好選擇。
 

第三毒：自我
我們都害怕被我們的工作評判。當這是你的第一次或第二次釋出時，當網際網路論壇上的一些隨機人開始指出你在數百到數千小時的專案中花費了 10 分鐘的這個無關緊要的小事情，您有多糟糕。
因此，為了預測批評，我們開始花時間完善細節。時間越來越多。有一天我們意識到，所有這些時間都在打磨細節，而那些帶來真正價值的重要點甚至還沒有開始。
我們害怕犯錯，然後因為這些錯誤而被公開指責和羞辱。透過釋出和公開分享多個專案，我體驗到值得留下深刻印象的人永遠不會因為小錯誤而打電話給你。他們明白我們都是人：容易犯錯、缺乏經驗、不完美。所有的吹毛求疵的人都對我的專案不感興趣，他們來這裡只是為了告訴世界他們比我們更聰明、更偉大。這幾乎不值得我們花時間和注意力。
我注意到，在某種程度上，一個人越聰明，就越需要在他們的工作中表現出來。每個演算法都需要完美，每個函式都需要無副作用，每個資料結構都需要最快，每個最佳實踐都需要遵循。這本身並不壞，但是當它阻止做真正的事情時，應該避免這種繁忙的工作。
這是我發現 Go 是一門優秀語言的原因之一。一切都是無我的，一切都是一個array或一個map。簡單的。基本的。您可以在優秀文章中閱讀更多相關內容：Go之道。
“我們的生活充滿了細節。簡化，簡化！” ——梭羅
 

解決方案
現在怎麼辦，我們應該停止所有的設計過程並開始瘋狂地建造嗎？
不，我不是說我們今天應該關掉大腦。我只是在爭辯說，能給你帶來大部分結果的事情可能不是你正在考慮的事情。停止評估每個 AWS 服務是否適合您的問題，您最終會發明自己的問題，您不必證明使用這些閃亮的技術是合理的（我過去做過太多次）。
如果您從 0 到 1，那麼您不知道和無法控制的事情太多了。無論您是在處理軟體專案還是部落格文章，您都可以及時更新並修復它。所以放鬆並運送。
停止嘗試提前連線所有點。

擁抱不確定性並開始做。
 
“你不能把點點滴滴地向前看；您只能向後連線它們。所以你必須相信這些點會在你的未來以某種方式連線起來。你必須相信某些東西——你的直覺、命運、生活、業力等等。這種方法從來沒有讓我失望過，它讓我的生活發生了翻天覆地的變化。” ——史蒂夫·賈伯斯




 

相關文章