編程哲學（三）：是什麼影響了我們的開發效率

06-26

來自專欄業餘程序員的個人修養

工作量是實際工作任務或可達工作任務，

而工作效率，一般指工作投入與產出之比。

在進行某項任務時，工作效率是取得的成績與所用時間、精力、金錢等的比值。

產出大於投入，就是正效率；產出小於投入，就是負效率。

軟體是一個神奇的行業，

不同的工作方式，在工作效率上可能會產生15倍甚至100倍的差距。

因此延長工作時間，變成了一件不是特別重要的事情了，

人們更多考慮的是如何在有限的時間內效率更高。

在提高工作效率方面，每個人都有自己的辦法。

「不要重複造輪子」就是其中一個，

它使我們看到了重複勞動，這在一定程度上確實提高了我們的工業水平。

然而，另外一些方面，就不是那麼直觀了。

我經常看到很多人在忙著寫代碼，卻沒有意識到，

我們確實有很多事情要做，但是卻未必有那麼多代碼要寫。

更多的代碼，意味著更高的開發成本，測試成本和維護成本。

因此，當我們需要動手實現很多功能的事情，

不妨問一下自己，為什麼我們不得不寫這麼多東西。

難道我們真的走在了業界的前沿，做一些發明創造嗎？

這個問題的答案通常是「否」。

沒有在專業性上保持謙遜

某個領域的專家，會更傾向於喜愛自己所在的領域，

認可自身領域專業性的價值，否則當初就難以成為專家了。

這是一件利弊參半的事，

專業性使得一些工作被巧妙的解決掉，也使得一些工作被解決的過於勉強。

軟體也是如此，

只有極少數情況下，用戶是不得不需要軟體的，

雖然我們聽到和感受到的都是他們的確需要。

商業軟體要解決的問題，通常在於緩解當前已有的工作壓力，

或者說對現有方案做出改善，

卻很少創造出全新的解決方案，雖然我們不是這麼宣傳的。

因此，帶著專業領域的自豪感，我們很容易綁架用戶，

或者幫用戶做太多只能由他們做的事情。

這會在不經意間給用戶帶來新的負擔，還會極大的增加軟體的功能範圍和複雜度。

所以，我理解的專業性，並不是在專業領域給用戶尋找方案，

而是專業性的給用戶尋找方案，結果可能是用戶並不需要我們做那麼多事情。

沒有把自己變成信息源

人們對工程師的認識可能帶有成見，

認為工程師一定是內向的，不善言辭的，

因為他們覺得只有這樣才會顯得更專註。

然而，別人這麼認為，並不代表著這樣做就是好的，

僅僅代表著如果這麼做會給自己帶來較小的阻力。

事實上我們應該反思一下，

內向和不善言辭是不是真的有助於自己把工作做好。

溝通問題在任何行業都會存在，並不是軟體行業所獨有的。

缺乏溝通，人們都被動的接受信息，會降低團隊的工作效率。

這件事大家都是知道的，

然而卻很少有人肯站出來，主動彙報自己的工作，變成信息源。

人們靦腆的不分享自己的成功案例，這可能算是一種謙虛，

但是因為沒有機會得到反饋，而堅持自己的錯誤就很難被定義為謙虛了。

軟體工程師需要主動得到工作反饋，確認待解決問題的動向，

向團隊彙報自己的工作內容，向顯然已經知道答案的同事學習經驗。

不要自己扛下所有的事情，不要自己研究。

沒有吃自己的狗糧

Eating your own dog food，直譯為「吃你自家的狗糧」，也稱為dogfooding，

是一句英語俚語，常用於描述公司（尤指軟體公司）使用自己生產的產品這一情況。

好的工匠常常擁有自己的工具箱，

工程師也會思考如何利用團隊的產出反哺團隊自身。

我們有哪些工具是完成業務目標之外的副產品？

哪些副產品可以在後期當做產品來發布的？

我們做事情的方式是不是可以總結下來？

這是產生技術產品的一個有效辦法，

而那些立志於只產出技術產品的團隊，卻往往難以存活下來，

因為他們並不用自己的產品。

吃自己的狗糧，讓我們把一部分注意力放到了副產品和歷史積累上面。

這些積累才是一個團隊賴以生存的根基，

也是工作效率不可能被新團隊取代的根本保障。