昨天接獲通知，到出國前的日子，有四天必須出差外訓，而且四天 外訓結束後的隔天就要出國，等於我一下子少掉了四天時間可用。 外訓的重點跟我這次負責檢測的設備有關，所以那四天我也必須專 心上課(可能要做大量筆記)沒辦法幹嘛。這次的設備是第二代，我 以前職務調動到目前的單位是在第一代設備安裝完之後，所以我等 於沒受過完整的正規訓練就直接投入了第一代設備的維運工作，只 不過這也剛好適合我─先實際進行設備維運，再慢慢補足設備相關 知識，對我來說比較方便，因為單位急需的是一個協助維運的人力 ，而不是一個什麼都要先懂的人力。因此這次的外訓對我來說蠻重 要的，因為我已經有實際先摸過一二代的設備了。 那我在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 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 210.61.157.53 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/mud_sanc/M.1447814348.A.A16.html