「 人月神話 」掃讀雜記

        1. 專案時程估計

        在估計專案時程的時候，必須要把測試的比重佔到時程一半以上，前期規劃次之，真正實作時間最少。

        實際開始專案的時候，傳統的作法會把功能實作估到deadline沒多久前，想說在實作的同時也一直在de bug，當實作結束的時候，想必bug也差不多沒了吧。

        沒想到交貨前，給公司內部總測試的時候，一些之前沒發現的bug開始浮出來，於是又瘋狂趕工，趕得出來還好，趕不出來得延期交貨，客戶失去信任感，公司也失去信譽，工程師在業界的名聲可能也會打折扣。

        所以在規劃時程的時候，絕對要分配最多時間給測試。

        2. 錯誤的增加人手時機

        我剛進公司的時候，大概有兩個禮拜的適應期，兩個禮拜之後被交派一個小小的除錯任務，由於這個任務不太緊急，所以依然可以繼續跟資深的工程師討論之前的架構，又經過了兩三天，bug解決。

        不過有些專案在已經很趕的狀況下，增加人手可能不會帶來預期中的效益，人力吃緊沒錯，想透過增加人手來加快開發速度的狀況會演變成老手需要撥出珍貴的時間來幫助新手進入狀況，當新手進入狀況之後，產能或許不會比老手把全部時間投入在專案裡面還要來得高。

        這時候精簡一些功能，或是調整一下工作時程會是一個相對適合的做法。

        3. 一個高手 vs 十個凡人

        在台灣，傳統公司徵工程師的思維還是停留在夠用就好，東西能work就好，不會去考慮比較未來的問題，但幾乎沒想過一個問題，一個高手的戰力，可以電爆十個凡人甚至等比級數上漲。

        十個凡人並沒有非常優秀的工程思維，幾乎都還停留在程式能動就ＯＫ的階段，不會去考慮擴充性及可維護性。

        一個高手有很好的架構思維，clean code、好接手、好維護、好擴充，非常優質的程式碼，就算之後離職了，下一個接任的是新手，也能維持一段時間不crash，更重要的是生產力屌打凡人的同時，完全不會影響到程式碼的品質。

        以前有聽到一個故事：一個老闆說我為什麼要給你66k？你的薪水我可以請三個22k。

        而網路有一句話完美的回擊：生病的時候你要選一個30萬醫藥費的頂尖醫師，還是10個3萬的新手醫師？

        老實說我現在也有困擾，我是個凡人，還是個最初階的凡人，公司請我開發新專案的時候，畢竟經驗實在不足，雖然公司有另一個經驗豐富的工程師可以問，難免還是有種力不從心的感覺。

        相信老闆心中也瞭解，一個剛入行沒多久的開發出來的產品能優秀到哪，所以我很感謝他，還願意給我這個機會繼續在公司歷練，有很多專案能加入自己成長的軌跡。