微時代

開發人員請深思:一位39歲程序員的困惑

2016/4/29 8:50:55 / 來源: / 點擊: 99

Zilk1988 年 14 歲時就開始編程,此后嘗試過幾種職業,最終還是在 1997 年決定成為職業程序員(又稱碼農),現在已經 39 歲,對此選擇依然無怨無悔。
知道得越多編程越慢

但是后來他發現一個問題,自己的經驗越豐富,完成項目或任務的時間反而越長。因為他見過了太多可能會出問題的情況而對選擇躊躇。比方說,假設他剛想到要寫一段寫入文件的代碼時,電光火石之間他就已經開始擔心起下面的一系列的問題:權限、鎖定、并發、源自操作、迂回 / 框架,不同的文件系統、目錄中的文件數、可預測的臨時文件名、PRNG(偽隨機數生成器)的隨機性質量夠不夠、操作過程中斷電怎么辦、API 怎么寫才好理解、文檔應該怎么寫等等。

簡而言之,他的問題已經從“怎么做”變成了“怎么做最好 / 最安全”。

結果就是他他做出來的版本堅如磐石,但是也導致他完成項目的時間比菜鳥還要長。

Zilk 說,他自己精通算法、熱愛數學,享受復雜項目,專注度也沒有問題。也許經驗是有問題(盡管已經 39 歲了),所有會害怕犯錯,因此導致項目費時。所以他在問答網站上邀請同行幫助他解決這個問題。

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

你完成項目并不慢。以前你認為自己的菜鳥項目做完了但實際上并沒有完。你應該把質量賣給客戶。“公司可以做得更快成本更低,但項目真的完成了嗎?或者說你愿意花幾年的時間找 bug 嗎?”此外,你還應該知道并接受那句老話:“完美是好的敵人。”

“好、快、省只能 3 選 2”。以前你懂得少所以犧牲了“好”,現在你懂得多了卻犧牲了“快”。


似乎你的經驗的確不足:)。教訓:遵守需求即可,不要想其他。這樣才不會實現不需要的功能。

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

似乎你加入黑暗面:管理的時候到了。

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

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

哪怕你是開發者也無妨:忽略權限和命名沖突的情況下建個臨時文件只需 5 分鐘的時間。凈收益:團隊其他成員可以開始依賴此文件的代碼編寫工作。這是不是一個完美的解決方案?當然不是。99% 呢?95%?90%?這些可能性是存在的。

還要問你一個問題:你對技術債務(注:快速解決但會增長后續維護成本的做法)感覺如何?有人認為不應該有技術債務。我不同意。跟商業一樣,技術債務讓你可以借到“金錢”和“時間”以便晚點交付某樣東西。2 年做出一個完美解決方案,或者用 4 個月時間快刀斬亂麻作出客戶可以使用并且購買的東西,哪一個更好?判斷當然要因情況而定,但是大多數情況下如果你要讓客戶等兩年的話,客戶可能早就跟競爭對手簽約了。

關鍵是像管理商業債務一樣管理好你的技術債務。借的錢不夠的話就拿不到最佳的投資回報。但是負債太高的話利息會把你壓垮。
我的建議是用番茄工作法。專注于小的時間間隔(番茄),然后為未來的工作 / 研究分配這些時間段,并且在執行的過程中不斷根據事情的優先級進行調整。

 

編程的一個關鍵是管理并控制好復雜性,這是我的最高優先級之一。忽略了復雜性管理,要么缺陷頻發,要么軟件的 ETA(預計到達時間)急劇增加。

軟件復雜性有很多不同的管理層次和辦法,好的做法可以是這樣的:“任何軟件項目的最高優先都是客戶滿意度,這是客戶期望的函數。”

換言之,軟件復雜性取決于你控制客戶期望的水平如何。

如果你接受這個觀點,那么下面兩點也很顯然:

  1. 客戶期望必須明示
  2. 客戶期望永遠都可以改變且通過協商完成。

你舉了一個很好的例子,“直接寫”還是“無數的其他考慮”。考慮一下,如果有人詳盡寫下了此二者的需求,雙方的功能描述還是一樣的嗎?

同樣是造飛機,F16 能飛,航模也能飛,但那能一樣嗎?

上一篇:大學生研發微信“桌游助手”4個月獲10萬用戶
下一篇:微信公眾號爆料破解WIFI案例 分分鐘劫持各種社交賬號

分享到: 0
辉柏嘉和酷喜乐