[工作日誌] #3 我們的開發與維運人員

變形的作業方式

開發人員不做開發文件，卻投入製作某種意義上的維運文件。

沒錯，有些know how開發者才知道，但維運者不知道就無法判斷問題或處理嗎？

已經驗證過的input和output真的有需要懂理面在做什麼?

如果如此，那麼這個模式背後指出許多問題。

1. 開發與維護根本沒實質切開，仿佛高偶合的程式碼，切離開發那塊knowledge，是做不到的。

 2. input和output無法控制範圍，無法信任系統會處理到什麼狀況，產出什麼結果。

 3. 開發人員無法給維護人員保證，維護人員總需要開發人員協助。

分析

所以開發人員的產出結果能夠被保證，input和output範圍能夠控制，維運人員可以在有限的範圍搜索問題與釐清feedback。

能做到如此，我們就可以破除困境。

---

開發人員：

是大廚，食材原料是什麼，中間加了什麼調味料，做法工藝是什麼，煮出的東西大概會怎麼樣，雖然味道最終是客人品嘗。

但做菜的前後，當然是主事者最清楚，維護的人怎麼可能知道，所以有需要這方面的說明和了解當然找開發者。

開發者握有這部分的大權，訊息、情報最完整的資訊，call 什麼資料庫，call什麼API，資料怎麼加工，過過什麼驗證檢查，就開發者最清楚。

文件無法真實代表程式怎麼跑，這部分的knowledge又會隨著時間流逝，ㄧ點一滴的從開發者的腦袋中流逝。

開發者應該即時的花費精力付出這部分，但要怎麼做？

---

維運人員：

是場控，是經理，是服務生，反正做菜以外全包了。

要做的事情大多是接收客人反應，確認狀況，假設客人抱怨點了牛排七分熟，卻拿到豬排還不熟，就開始找問題了。

首先確認客人真的是點牛排七分熟，再來確認點餐的訊息有傳到內場，內場真的是收到牛排七分熟的點餐。

假設這個廚房非常先進，收到點餐，有特殊機器自動抓把肉抓出來處理烹煮，烹煮之後自動傳到人員裝飾擺盤，就送到外場。

所以維護人員再找，是不是牛肉櫃裡面有人放了豬肉進去？烹肉的機器是不是故障？傳遞到擺盤人員的中間過程是不是有問題？

送餐的人員是不是送錯，客人是不是真的拿到豬排還不熟？

他不應該懷疑機器收到抓牛肉的指令，卻去抓了豬肉。

他不應該懷疑，擺盤人員故意惡搞。

這些應該是要被驗證和保證的部分。

可是今天如果內場他完全進不去，無法確認內部肉源狀況，機器狀況，人員狀況，完全是個黑箱作業。

哈哈哈他只能猜猜猜，憑經驗猜，或者求助開發人員。

更慘的是若這個維護人員是個菜鳥，由於內場完全是個黑箱，他可能甚至不知道要檢查什麼。


以上，就是我們的囧況。

解決方向

這工作鏈，明顯缺少了ㄧ些關鍵的東西。

可以讓開發人員貢獻只有他們能貢獻的部分，貢獻完了就可以安心剔除他們，讓他們進行下個專案了。

可以事先保證的某些東西，要機器煎七分熟就七分熟，絕對不會錯。

可以讓維運人員感到系統是透明，而非黑箱，查問題要快要即時，要精準，慢或查錯問題，客人會掀桌的。

得出的需要關鍵：

[自動化即時測試與驗證報告]

開發人員要提供自動化處理的方向，input和output範圍，整合測試案例。

開發人員可以自己清楚知道，肉類種類應該只有雞鴨魚牛豬共5種，不會有恐龍肉，兔肉，羊肉，人肉，就驗雞鴨魚牛豬這五種有沒有問題。

出什麼菜，有什麼菜單，哪個菜鹽加得比較多，就開發者最知道而已。

[測試人員]建立這個自動化處理系統。

維護人員收到feedback，懂得要看哪裡的定時自動化驗證報告，或者手動啟用驗證機制，甚者根據客人提供的情報做為input，丟到驗證系統看結果。

時間已經證明了是不可能用人工作業，人工彌補這一塊。



[測試人員]與自動化處理，再由另一個篇章探討。