一位39歲程序員的困惑：知道得越多編程越慢怎么辦？
Zilk1988 年 14 歲時就開始編程，此后嘗試過幾種職業(yè)，最終還是在 1997 年決定成為職業(yè)程序員（又稱碼農(nóng)），現(xiàn)在已經(jīng) 39 歲，對此選擇依然無怨無悔。
但是后來他發(fā)現(xiàn)一個問題，自己的經(jīng)驗(yàn)越豐富，完成項(xiàng)目或任務(wù)的時間反而越長。因?yàn)樗娺^了太多可能會出問題的情況而對選擇躊躇。比方說，假設(shè)他剛想 到要寫一段寫入文件的代碼時，電光火石之間他就已經(jīng)開始擔(dān)心起下面的一系列的問題：權(quán)限、鎖定、并發(fā)、原子操作、迂回 / 框架，不同的文件系統(tǒng)、目錄中的文件數(shù)、可預(yù)測的臨時文件名、PRNG（偽隨機(jī)數(shù)生成器）的隨機(jī)性質(zhì)量夠不夠、操作過程中斷電怎么辦、API 怎么寫才好理解、文檔應(yīng)該怎么寫等等。
簡而言之，他的問題已經(jīng)從“怎么做”變成了“怎么做*** / 最安全”。
結(jié)果就是他他做出來的版本堅(jiān)如磐石，但是也導(dǎo)致他完成項(xiàng)目的時間比菜鳥還要長。
Zilk 說，他自己精通算法、熱愛數(shù)學(xué)，享受復(fù)雜項(xiàng)目，專注度也沒有問題。也許經(jīng)驗(yàn)是有問題（盡管已經(jīng) 39 歲了），導(dǎo)致害怕犯錯，使得項(xiàng)目費(fèi)時。所以他在StackExchange上邀請同行幫助他解決這個問題。
下面就是精選出來的解決方案：
Telastyn：
你完成項(xiàng)目并不慢。以前你認(rèn)為自己的菜鳥項(xiàng)目做完了但實(shí)際上并沒有完。你應(yīng)該把質(zhì)量賣給客戶。“公司可以做得更快成本更低，但項(xiàng)目真的完成了嗎？或者說你愿意花幾年的時間找 bug 嗎？”此外，你還應(yīng)該知道并接受那句老話：“***是好的敵人。”
sevenseacat：
“好、快、省只能 3 選 2”。以前你懂得少所以犧牲了“好”，現(xiàn)在你懂得多了卻犧牲了“快”。
mouviciel：
似乎你的經(jīng)驗(yàn)的確不足:)。教訓(xùn)：遵守需求即可，不要想其他。這樣才不會實(shí)現(xiàn)不需要的功能。
Satish:
應(yīng)考慮敏捷方法論而不是瀑布流。先交付然后迭代交付。此舉有助于降低風(fēng)險和成本。
DXM:
似乎你加入黑暗面：管理的時候到了。
我不是要建議你放棄編程變身經(jīng)理。但從你的描述來看你的經(jīng)驗(yàn)僅限于技術(shù)層面。寫文件這么簡單的事情你居然能想到 10 個方面的問題，稚嫩一點(diǎn)的開發(fā)者絕對是想不出來的。這不是什么壞事，但是……
黑暗面的一切都與現(xiàn)值有關(guān)。它要考慮的是如何用最小的投入實(shí)現(xiàn)***的產(chǎn)出（成本效益分析）。商業(yè)上的一切事情都要?dú)w結(jié)到成本、成功幾率、失敗幾率、潛在回報等問題。做好這方面的數(shù)學(xué)然后采取相應(yīng)行動。
哪怕你是開發(fā)者也無妨：忽略權(quán)限和命名沖突的情況下建個臨時文件只需 5 分鐘的時間。凈收益：團(tuán)隊(duì)其他成員可以開始依賴此文件的代碼編寫工作。這是不是一個***的解決方案？當(dāng)然不是。99% 呢？95%？90%？這些可能性是存在的。
還要問你一個問題：你對技術(shù)債務(wù)（注：快速解決但會增長后續(xù)維護(hù)成本的做法）感覺如何？有人認(rèn)為不應(yīng)該有技術(shù)債務(wù)。我不同意。跟商業(yè)一樣，技術(shù)債務(wù) 讓你可以借到“金錢”和“時間”以便晚點(diǎn)交付某樣?xùn)|西。2 年做出一個***解決方案，或者用 4 個月時間快刀斬亂麻作出客戶可以使用并且購買的東西，哪一個更好？判斷當(dāng)然要因情況而定，但是大多數(shù)情況下如果你要讓客戶等兩年的話，客戶可能早就跟競爭 對手簽約了。
關(guān)鍵是像管理商業(yè)債務(wù)一樣管理好你的技術(shù)債務(wù)。借的錢不夠的話就拿不到***的投資回報。但是負(fù)債太高的話利息會把你壓垮。
我的建議是用番茄工作法。專注于小的時間間隔（番茄），然后為未來的工作 / 研究分配這些時間段，并且在執(zhí)行的過程中不斷根據(jù)事情的優(yōu)先級進(jìn)行調(diào)整。
Saul:
編程的一個關(guān)鍵是管理并控制好復(fù)雜性，這是我的***優(yōu)先級之一。忽略了復(fù)雜性管理，要么缺陷頻發(fā)，要么軟件的 ETA（預(yù)計(jì)到達(dá)時間）急劇增加。
軟件復(fù)雜性有很多不同的管理層次和辦法，好的做法可以是這樣的：“任何軟件項(xiàng)目的***優(yōu)先都是客戶滿意度，這是客戶期望的函數(shù)。”
換言之，軟件復(fù)雜性取決于你控制客戶期望的水平如何。
如果你接受這個觀點(diǎn)，那么下面兩點(diǎn)也很顯然：
客戶期望必須明示
客戶期望永遠(yuǎn)都可以改變且通過協(xié)商完成。
你舉了一個很好的例子，“直接寫”還是“無數(shù)的其他考慮”。考慮一下，如果有人詳盡寫下了此二者的需求，雙方的功能描述還是一樣的嗎？
同樣是造飛機(jī)，F(xiàn)16 能飛，航模也能飛，但那能一樣嗎？
本來我打算把所有建議都摘錄出來的，但是考慮到上述的精彩見解足以解決 Zilk 的困惑，并且為了踐行這些建議，本文就此打住，感興趣者可參見完整討論。
***我只補(bǔ)充一句：
你還可以看看麥當(dāng)勞理論。
