昨天接獲通知，到出國前的日子，有四天必須出差外訓，而且四天
外訓結束後的隔天就要出國，等於我一下子少掉了四天時間可用。
外訓的重點跟我這次負責檢測的設備有關，所以那四天我也必須專
心上課(可能要做大量筆記)沒辦法幹嘛。這次的設備是第二代，我
以前職務調動到目前的單位是在第一代設備安裝完之後，所以我等
於沒受過完整的正規訓練就直接投入了第一代設備的維運工作，只
不過這也剛好適合我─先實際進行設備維運，再慢慢補足設備相關
知識，對我來說比較方便，因為單位急需的是一個協助維運的人力
，而不是一個什麼都要先懂的人力。因此這次的外訓對我來說蠻重
要的，因為我已經有實際先摸過一二代的設備了。
那我在sanc其實也是這麼做的，我一開始當 wiz，我先做的事就是
cp 其它 wiz 寫好的 code 去做增改，所以我很快就寫好我的第一
個區域跟其它物件，之後再藉由對照 code vs 實際執行的結果,快
速瞭解了寫區域所需的許多必要物件的寫法。
但是這有缺點:
一、因為實際上不瞭解 code 所以使用了非常多錯誤的語法，在之
後都必須花很長的時間修正。
ex: for(i=0;i<sizeof(users());i++)
一些沒什麼效率的寫法也都是在之後才慢慢重構，例如家族系
統就因此重寫過一次(從 write_file 改 save_object())。
二、初期抓 bug 的技術很差，這是因為我對於 mud 源頭函數的呼
叫流程並不清楚的關係，如果我清楚函數呼叫流程，對抓 bug
最有利的一點就是我會比較容易判斷 bug 發生點。
那因為不瞭解，只好每次都用試誤的方式去抓 bug，因此之前
只要 sanc 發生 bug，運氣好的話可以很快找出 bug，運氣不
好的話就會拖長 bug 改掉的時間。
三、核心的 mud code 因為很少接觸，所以我完全不瞭解那些code
是做什麼的，事實也證明不瞭解那些東西還是可以 coding 及
做管理甚至寫出各種系統(我在公司也有寫設備維運系統)，但
是，不懂這些，就不能稱得上是一個稱職的 mud 管理者。
從上面亦可知道，可以讓我當 semi-administrator & operator，
其環境必然是「有真正的主力人員在」以及「可允許維運人員犯錯
」，以sanc來說主力人員就是 nobu 及 satin，以公司來說就是職
階比我高的同事。
然後隨著我實際接觸及維運的時間越久，我才能漸漸瞭解更多我以
前所不瞭解的東西，從而使理論與實際順利 merge，這時間通常很
漫長。
講這麼多，主要是想說明「所以這次的外訓對我很重要」，這是第
一次真正有機會從設備維運的最源頭，開始瞭解整個系統架構及運
作原理。
我這禮拜就要將設備測完，光是測之前看完那些測項的細節就會耗
去今天一整天的時間，那因為在我之前的其它人的進度有落後，原
訂明天一整天測完我的部份，可能也會因此延後到星期六下班前才
測得完(說不定還測不完)，因此從我看完那些細節後，到實際進行
測試前，以及整個星期日，我都會拿來編完遊日行程手冊的初稿。
下禮拜則是設備的完測，行程手冊完稿印出，準備公司月底報告，
只會有零碎的時間。再下禮拜就是外訓＋出國，要到回國後才會再
開始有空。(但平常工作量也會變多，要同時維運新舊兩套設備)
laechan