[閒聊] 近況

看板mud_sanc (Sanctuary - 聖殿)作者laechan (小太保)時間9年前 (2015/11/18 10:39)推噓0(0推 0噓 4→)

留言4則, 1人參與討論串212/249 (看更多)

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

→