今天睡到九點多才肯從床上離開(中途被自己設的7:30鬧鐘吵醒過一次),看看時鐘,算了,下午再去學校吧!反正老師早上有事情,也沒辦法meeting,不過下午出門的壞處就是太熱了,早上七八點出門騎腳踏車還好,下午一點多出門完全熱到爆,根本就不敢騎車,怕中暑,於是就坐捷運去學校,下午兩點,剛口試完的三位學弟先上去找老師,討論論文修改的事宜,本來以為會很快,沒想到也討論了一個小時左右,看到他們回研究室,趕緊拿著journal paper找老師,因為口試中斷了2次meeting,總算可以review了,這次老師看得倒是挺快的,一口氣看到第三章完,不知道這是好事還是壞事?希望是好的那一面(沒甚麼大問題要改了),目標是七月底把paper丟出去。

  今天的課程回憶錄是PSP,這門課想修可不見得修得到,因為不是年年都開,這門課的老師還有另外一門軟體測試與驗證課,通常就是開了A就沒開B,所以這門課我唸博班後才修到,而且這門課如果是在校外修,可是很貴的呢!聽說要二萬多元,這門課會讓人印象深刻,肯定有它獨到之處。首先,這門課一共會有10次作業及2次報告,幾乎是每2個禮拜就一次作業,程式作業嘛,沒甚麼大不了的,是的,就程式的難度來說,確實沒甚麼大不了的,都在幾百行之譜的小程式,但在寫程式的過程中,要不斷地記錄時間,而且紀錄的項目越來越多,從一開始的coding、compile和debug花多少時間,到design、design review、code review花多少時間通通都要記錄,時間都記錄了當然不會放過程式碼行數跟bug的數量,記錄這些東西比寫程式還痛苦,寫到第三次作業時,還在想記錄這些東西有什麼用啊?

  但等到最後一次作業時,很多神奇的事情就發生了,但說明什麼事發生前,還是先講一下什麼是PSP好了,PSP是Personal Software Process的縮寫,主要是讓programmer能了解自己的產能、良率和軟體開發的流程,就拿產能來說,10次作業下來,我每小時寫的程式碼行數就蠻平穩地維持在45行,看起來好像不多,但穩定是很重要的一個因素,因為穩定可以提供預測的基準,假設有個程式預估是450行的規模(預估程式碼規模是另外一門學問),那我來寫大概需要10小時,如果一個programmer不瞭解自己的產能,或是產能極度不穩定,那就很難預估時程了。那良率呢?每千行程式的bug數大約是25個,哇~看起來很多,但這很多是現代IDE在寫程式的過程中就會立刻偵測到的語法錯誤,實際上要到執行期或是測試期的bug,每千行大約5個。那這些bug都是怎麼被發現的呢?就跟軟體開發流程有關了,這門課我用TDD的方式開發,所以除了design review和code review外,測試也找到許多bug,這些資訊都讓自己更清楚自己的能力。對一個PM來說,如果帶領的programmer都能提供相關的數據,那時程的預估會輕鬆很多,而且誤差也不至於太離譜了。

  所以最後一次作業神奇的事情是什麼呢?用歷史資料(前九次)推導第10次作業的程式碼行數及所需時間,與實際的程式碼行數和真正寫程式的時間,彼此的誤差只有9.4%和3.2%!

arrow
arrow
    全站熱搜

    dbi1463 發表在 痞客邦 留言(0) 人氣()