一位39歲程序員的困惑：知道得越多編程越慢怎麼辦？

Zilk1988 年 14 歲時就開始編程，此後嘗試過幾種職業，最終仍是在 1997 年決定成爲職業程序員（又稱碼農），如今已經 39 歲，對此選擇依然無怨無悔。

可是後來他發現一個問題，本身的經驗越豐富，完成項目或任務的時間反而越長。由於他見過了太多可能會出問題的狀況而對選擇躊躇。比方說，假設他剛想 到要寫一段寫入文件的代碼時，電光火石之間他就已經開始擔憂起下面的一系列的問題：權限、鎖定、併發、原子操做、迂迴 / 框架，不一樣的文件系統、目錄中的文件數、可預測的臨時文件名、PRNG（僞隨機數生成器）的隨機性質量夠不夠、操做過程當中斷電怎麼辦、API 怎麼寫纔好理解、文檔應該怎麼寫等等。

簡而言之，他的問題已經從「怎麼作」變成了「怎麼作最好 / 最安全」。

結果就是他他作出來的版本堅如磐石，可是也致使他完成項目的時間比菜鳥還要長。

Zilk 說，他本身精通算法、熱愛數學，享受複雜項目，專一度也沒有問題。也許經驗是有問題（儘管已經 39 歲了），致使懼怕犯錯，使得項目費時。因此他在StackExchange上邀請同行幫助他解決這個問題。

下面就是精選出來的解決方案：

Telastyn：

你完成項目並不慢。之前你認爲本身的菜鳥項目作完了但實際上並無完。你應該把質量賣給客戶。「公司能夠作得更快成本更低，但項目真的完成了嗎？或者說你願意花幾年的時間找 bug 嗎？」此外，你還應該知道並接受那句老話：「完美是好的敵人。」

sevenseacat：

「好、快、省只能 3 選 2」。之前你懂得少因此犧牲了「好」，如今你懂得多了卻犧牲了「快」。

mouviciel：

彷佛你的經驗的確不足:)。教訓：遵照需求便可，不要想其餘。這樣纔不會實現不須要的功能。

Satish:

應考慮敏捷方法論而不是瀑布流。先交付而後迭代交付。此舉有助於下降風險和成本。

DXM:

彷佛你加入黑暗面：管理的時候到了。

我不是要建議你放棄編程變身經理。但從你的描述來看你的經驗僅限於技術層面。寫文件這麼簡單的事情你竟然能想到 10 個方面的問題，稚嫩一點的開發者絕對是想不出來的。這不是什麼壞事，可是……

黑暗面的一切都與現值有關。它要考慮的是如何用最小的投入實現最大的產出（成本效益分析）。商業上的一切事情都要歸結到成本、成功概率、失敗概率、潛在回報等問題。作好這方面的數學而後採起相應行動。

哪怕你是開發者也無妨：忽略權限和命名衝突的狀況下建個臨時文件只需 5 分鐘的時間。淨收益：團隊其餘成員能夠開始依賴此文件的代碼編寫工做。這是否是一個完美的解決方案？固然不是。99% 呢？95%？90%？這些可能性是存在的。

還要問你一個問題：你對技術債務（注：快速解決但會增加後續維護成本的作法）感受如何？有人認爲不該該有技術債務。我不一樣意。跟商業同樣，技術債 務 讓你能夠借到「金錢」和「時間」以便晚點交付某樣東西。2 年作出一個完美解決方案，或者用 4 個月時間快刀斬亂麻做出客戶可使用而且購買的東西，哪個更好？判斷固然要因狀況而定，可是大多數狀況下若是你要讓客戶等兩年的話，客戶可能早就跟競爭 對手簽約了。

關鍵是像管理商業債務同樣管理好你的技術債務。借的錢不夠的話就拿不到最佳的投資回報。可是負債過高的話利息會把你壓垮。

個人建議是用番茄工做法。專一於小的時間間隔（番茄），而後爲將來的工做 / 研究分配這些時間段，而且在執行的過程當中不斷根據事情的優先級進行調整。

Saul:

編程的一個關鍵是管理並控制好複雜性，這是個人最高優先級之一。忽略了複雜性管理，要麼缺陷頻發，要麼軟件的 ETA（預計到達時間）急劇增長。

軟件複雜性有不少不一樣的管理層次和辦法，好的作法能夠是這樣的：「任何軟件項目的最高優先都是客戶滿意度，這是客戶指望的函數。」

換言之，軟件複雜性取決於你控制客戶指望的水平如何。

若是你接受這個觀點，那麼下面兩點也很顯然：

1. 客戶指望必須明示

2. 客戶指望永遠均可以改變且經過協商完成。

你舉了一個很好的例子，「直接寫」仍是「無數的其餘考慮」。考慮一下，若是有人詳盡寫下了此兩者的需求，雙方的功能描述仍是同樣的嗎？

一樣是造飛機，F16 能飛，航模也能飛，但那能同樣嗎？

原本我打算把全部建議都摘錄出來的，可是考慮到上述的精彩看法足以解決 Zilk 的困惑，而且爲了踐行這些建議，本文就此打住，感興趣者可參見完整討論。

最後我只補充一句：

你還能夠看看麥當勞理論。

[本文編譯自：programmers.stackexchange.com/36kr]