本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 5 篇。
Day 1 我提過一句，沒有展開：實習的前兩個月，我在做一個前端自動化測試的重寫，最後沒成。
今天講那兩個月。
有一支三千行的腳本，是一位來了一年的正職工程師寫的。它能跑。但它一點都不好讀，改一個地方要看很久。
我的任務是把它重寫。
我那時候滿腦子都是可讀性：這個變數該叫什麼、這段要不要抽成函式、同樣的流程重複三次是不是該包起來。我每天在想的就是這些。
那些問題後來都要面對。只是不該在那個時間點。
後來兩個月後就沒什麼回去維護了，手動測試的任務隨著產品上線後變得更多佔據手上的資源，於是就暫緩開發了。
我後來在別的地方又犯了一次一樣的錯，那次比較容易講清楚。
我上了大人學，學到一個很好的觀念：做一件事之前，先想清楚牽涉到哪些利害關係人、各部門的利益點在哪裡。
然後我拿這個觀念，把一個自己很想做的監控工具卡死了。
那個專案沒有人交辦、沒有截止日。我一開始很有熱情，做著做著卻卡住，最後開始拖延。因為我滿腦子都是「這個工具會影響哪些部門？符合他們的利益嗎？他們到底會不會想用？」結果 MVP 遲遲不敢定案，範圍越想越大。
後來我才想通，我把兩件事黏在一起了：
先對齊、再動手，順序是反的。你手上什麼都還沒有，別人根本無從反應。你問十個部門「你們會想用一個還不存在的工具嗎」，只會收到十個模糊的答案。
正確的順序是先做一個很小的 POC，再拿它去對齊。那個 POC 就是讓對話變得有意義的道具，有了具體的東西，別人才給得出具體的反應。
利害關係人思維沒有錯。錯的是我用它去 gate 住最上游的那一步。
可讀性也是一樣的東西。
它是「這份程式碼要被別人接手、要跟 production code 一起活下去」時的標準。那是採用之後的問題。
而我當時在的階段，是還沒有任何東西能穩定跑起來。
現在回頭來看，或許當時先做冒煙測試，總有些功能像登入一樣做好了就不太會有變動，同時又是核心業務邏輯。
我後來用的判準是一句話：問這件事現在最大的不確定性是什麼。
把第三階段的工具搬到第一階段用，看起來很專業。實際上那是在替自己製造拖延的藉口，而且是一個聽起來很正當的藉口，所以更難被自己抓到。
我實習的時候沒有人跟我講這件事。我的主管問我「這份程式碼交得出去嗎」，那是對的問題，但那是第三階段的問題。而我那時候連第一階段都還沒過。
卡住的時候，先不要問「我該用什麼方法」。先問：
我現在最大的不確定是什麼？
我手上這個方法，是拿來解決那個不確定的嗎？
如果不是，那它再好都是阻力。
沒有人給你截止日的事情，你自己給它一條「做到這裡就算完成」的線。不然它會被你自己悄悄降級成「有空再說」，因為反正做完也沒有人在等。
明天聊第六件事：那些很難量化的東西，怎麼變成看得見的形狀。
iThome鐵人賽
看影片追技術