上週末已經就期滿了，算是 lag 的文章。慶祝一下自己國防役期滿。其實有沒有綁約是沒有差別的，總是對自己的努力和工作負責。唯一的差別就是心裡面爽字而已。因為，像王葛格一樣身為自由球員，合約不滿意，可以不要簽不要待。

Meeting 其實就是浪費時間和消耗體力精神的最好方法. 而 RD 要開會的目的如果是工作上專業有關的就算了, 比如說系統架構, 程式方面等等, 並且確保程式出來是 spec 和 user 需要的東西. Spec meeting 我倒是覺得改叫 spec 同意大會或是批鬥大會算了. 一方面 RD 在 spec meeting 來說, 主要應該負責看這種架構合不合理, 容不容易做, 需要多少技術跟工作時間. 但是往往在 S 公司 RD 是 design spec 全權主導的對象.TM 收集了 user requirements, 本來 spec 就是他們的工作卻一直都落在 RD 身上, 所以 RD 不僅只要會寫 code 也還會要開 spec, 還要制定 use model; 最好 programmer 身兼 layout designer 還知道他們需要什麼, 要怎麼操作比較方便. 開完一場 spec 下來其實根本也還沒完全定案, 會中討論的不定性還要跟 customer 或是 TM 自行再去確定.
總歸簡單的來說, spec meeting 就只是批鬥大會, 一堆 TM 在裡面爭論各自的論點. 不過請你們自己 TM 部門都確定了 user requirement 和 use model 再來請 RD 做完整 design spec 不是更好. RD 作 use model & spec 只是更浪費時間, RD 要寫 code 改 bugs, 找 TM 問 spec 常常找不到人. 所以說 TM 自己忙得沒時間寫 spec, 要 RD 寫只是再繼續拖累 RD schedule. 我只能說我乾脆先幫你們 booking 時間讓你們自己去開會去爭論, 然後結束了再 call RD 進去整理你們的定案.
最扯的是連 spec 或是 use model 都不知道, 只有 user requirements 的一些 description, 上面高層就排定說這個版本要做這功能. 如果 spec 有問題或是根本不需要, 是不是不用作了, 所以這個 release 階段個人的 schedule 就鬆了? 我猜也不是, 反正都排了就大家批鬥完, 看誰認輸誰勝出, 就照那個做. 沒有達到 user 真正要的, 沒關係下次出 patch 再繼續改.
RD: patch 只有一個月的時間又有一堆其他 bugs 要改, 這個 user 要的 model 根本跟之前 spec 提的不同, 怎是 patch?
Head: 有什麼完全不同嗎? 不就是把這個改成那樣? (真是xx比雞腿. 見識一下 Oral programming)

五一勞動節，放假一天。工程師節(6/6)沒有放假。所以是勞工（字面解釋 XD)。 記得距離上次 patch 才沒多久，這是又準備要 Code Freeze 進 QA cycle，不過沒有準備來得及 resolve，也不太想那麼趕。雖然說上次是 patch，不過我怎麼感覺做的東西是 new item or enhancement，一點都不像 "patch"。

聽說 SS 社的 L 大作在 '05 狂 crash，銷售也不佳，後來 training 以及 code review 時機乎最重要的重點就是，注意 pointer。只要遇到 pointer 的情況，有 * or -> 就很容易被 focus。例如 function body 前面加入對 pointer 類型的 parameters 做 check，只要情況不對馬上謝絕掉。或許這招不錯用，至少可以馬上降低 crash 次數，畢竟幾乎所有的 invalid segment access 都可以避掉，立竿見影。至少這樣可以避免得到 crash comment 一枚，因為程式沒到該有的功能所以得到 bug functional。（註：只要列出來 call stack 就是 core dump，所以單純 return 沒做事至少不會出事）。 不過源頭呢？為什麼會有 invalid address 傳進去？當然就是程式有 bug，一定有地方出錯了，所以才讓那個 bug 一直存活下來，然後還傳遞給其他地方使用。現在好了，大家看情況不對，就盡量謝絕掉。那最後一定還是會出錯，只是出錯就會錯在無法避免的地方。可能最終的源頭跟最後出鎚地點相差十萬八千里，但是 AE/QA 就會看 call stack 或執行過哪些 commands 就把 bug submit 給誰。更慘的是，如果是遇到無法 reproduce 的 bugs，更是查不到來源，因為無法再重複一次，但是他就是曾經 core dump 出來給你看。最後只是 RD 猛去 disassemble 那個位址的 assembly code 來看，然後找相對應 source code 那邊是否有 pointer access 沒有保護好或有 bug。 再來是，大家一定遇過 core dump，最常見的就是 windows 的程式執行錯誤。或是 firefox 遇到 crash 也會有。Apple 也有 crash report 功能。裡面有什麼東西，大家一定看過，不外乎就是 call stack、thread list、module list、environment variables、registers、stack dump、memory dump。就連 unix-like 的環境，也可以產生一個 core file。最神奇的是 SS 社，雖然有 segment fault handler，雖然有 coredump file，但是其實裡面是 call stack 而已，連個 registers values、stack dump、memory dump 都沒有。如果是單純的筆誤 bug，很容易看一下相對應的 source code 就查到了。但是大型軟體下，又無法 reproduce，什麼都沒有 dump，只有 call stack function chain，查得到來源才有鬼。