踩雷無數的狐狸先生

我們都希望透過測試自動化, 來讓測試夠方便一點, 或是把人力投入在更有效率的地方 手動的做每一次的回歸測試 (Regression), 對人力的消耗是非常大的 事實上 regression test 不太適合由人去執行...  regression test 理想上是可以完全重複, 我們希望在每一個的測試,執行一樣的步驟, 得到一樣的結果 這件事由人做會比機器做得更精準嗎？ 這是我們選擇做test automation  的原因, 那我們對automation 的期待是什麼？ 在沒有任何變動的情況下, 我們希望相同的版本和相同的環境能得到相同的結果  更重要的是我們希望系統或功能真正出現問題的時候失敗,  但是要做到這一點非常的難... 我們常常會遇到測試的不穩定 (Test Flaky) 帶給我們不可預期的結果 不穩定帶我們的結果是什麼？  在沒有任何變動的情況下,  綠燈, 紅燈交互出現  你選擇相信哪一個？紅燈？綠燈？ 這種flaky 的情況下,  選擇哪一個都是在欺騙自己... 在沒有查看之前,你不會知道是真的有功能壞掉, 還是只是假警報 如果你不相信automation 帶給你的測試結果,  這樣寫automation 還有意義嗎？ Treat Tests as Falsification, Not a Proof Test Automation 執行過後沒有噴出任何錯誤, 不代表系統沒有錯 有可能是你的測試寫錯了, 或是沒有涵蓋到這一塊 但是我們可以換一個角度想, 會讓我們更有信心 當automation fail 的時候, 代表是真的遇到了問題 五個會導致Automation Flaky 的原因 環境 (Environment) 測試資料 (Test Data) 版本控制 (versioning) 資源限制 (Resource Use) 系統行為 (System Behavior) 環境 (Environment) 如果我們的Automation 所使用的環境以任何方式的不穩定, 這些可能是配置上的改變或是依賴第三放的服務, 這些變化都是我們不可預測及掌控的 最常遇到的說法是 在我的環境或是local 跑起來是好的啊～～ 如果程式碼都一樣,  最大的差別就...

 軟體工程一向都是複雜的, 很多問題都是藏在細節裡面一開始都不會發現, 直到他咬了你讓你感到頭痛 怎麼樣快速的找到不熟悉技術的通關密語或是秘訣,讓整個工作便順利, 這是本篇想要聊的重點 會有幾個徵兆或是信號代表系統或是開發過程可能會出現問題 使用大家都不熟悉的技術 缺乏專注, 團隊成員一開始可能都是以兼職的方式會是side project,並不是非常的在意 時間壓力 解決問題的第一步 : 版本控制 &  可部署性 利用docker 或是容器化技術讓local 和 real  環境跑的程式碼是一樣的, 差別只是要做管理設定配置 (configuration) 使用版本控制可以低風險的嘗試錯誤, 當發現下一步走錯的時候,  可以很簡單的回復成上一個可成的版本 雖然這件事看起來沒有什麼大不了的事...但是他對整體的工作模式有了很大的改變 你不能明智的期待我們會準確預測未來的事 所以了解當下的問題以及做出當下適合的決策很重要 即使這個決策在之後被證實他是錯誤的, 但是我們已經開始在執行且發現錯誤了 等待完美的方法 VS 快速面對失敗且快速學習 但在倡導快速的時候, 我們很常會掉入另一個陷阱裡.... 當我們面對問題的時候,  可能會很快地提出解決方案, 但是我們看到的只是問題的表面 而忽略了我們想要解決的問題是什麼？ 導致走的方向偏離原本的目標 你對目標的猜測遠比你所決定採取的步驟更為重要 如何選擇正確的技術？ 如果你的技術沒有做正確的事,  有時候他會讓你的工作變得更加困難,  技術選擇問題的時候應該這麼做 先釐清我們想要解決的問題是什麼？ 再來尋找有哪些技術可以解決我們所遇到的問題？ 這個技術能做到前面提到的版本控制嗎 再思考這些技術所帶來的限制或是缺點是什麼？ 是我們可以承受的嗎？ Goal over Tech  選擇王牌技術 (Feature of top trumps)可能不會是最好的, 每個問題都不一樣, 適用的技術也不一樣 只有適不適合的技術 Make it work before you change, Make one change at a time 在動手修改配置之前先確定他是可以正確運行的, 有點類似TDD 的概念, 先是綠燈再來重構 且不要隨機的改動配置, 應該要...

什麼才叫做好的設計？ 怎麼樣算是過度設計? (Over Design) 看完了影片之後記錄一些重點和心得 Big up front Design  VS  Incremental Design   如何避免去建造明天會覺得老式的系統呢？ Agile Design = Incremental Design Anti-pattern => Big up front Design   非常古老的方法且目前還非常普遍, 會希望我們在寫Code 之前詳盡地做完一切的Design YAGNI =  You Ain't Gonna Need it (你不會需要他) Extreme Programming Explained: Embrace Change 的作者Kent Beck提到 只做最簡單可以完成工作的部分 盡可能地讓程式小步驟地前進 透過Refactoring 去完善你的設計 你永遠沒有足夠的時間完成你心目中完美的設計 核心理念是以目前所知所能做的做簡單方法去完成這個任務 如果我們提前去設計目前看不到需求的功能, 或是我們還不是真正了解需求背後的目的 我們有很大的機會在浪費時間做不對的事 當遇到問題的時候, 好的工程師會透過對話去探索或是理解問題的本質 進而從搜集的資訊中去找出最簡單可行的方案 在給出解法之前, 非常建議多花點時間去了解問題的上下文, 不然你給出的方案只是建立在你的假設上, 並沒有解決真正的問題 如果你的問題的認知是錯的, 非常的可能你給的答案也會是錯的 只專注在什麼是我們現在該解決的問題 當我們釐清問題之後, 我們可以小步驟的去驗我們的方案是否有解決問題 並且只專注在目前的問題上 YAGNI 的方法去限制過度設計的問題 大部分工程師在專案初期都有所期待, 認為自己的產品之後會爆紅, 在不自覺中就會去想著之後如果User 都在同一時間上來, 我們的系統撐得住嗎？ 該採取怎麼的設計才比較好擴展？ 以至於在專案的前期花費了大量的時間和金錢, 但是還無法得到驗證User是否買單... 並不是說這些設計完全不需要, 只是現在還用不到,更應該專注當下最重要的問題, 並用做簡單的方法去做驗證 如果我們建立團隊的方式是可以快速地應對變化, 我們是否還需要事先假設未來的需求呢？ 如果我們團隊成長到一定的程度之後, 可能...

 我們面臨技術債時該如何處理？  看完了影片之後記錄一些重點和心得 先說說什麼是技術債？ 是使用簡單或有限的方法而不是使用從根本去解決問題的方法, 這會導致一些隱含成本的產生, 雖然解決了當下遇到的問題, 但是不完整的解法對以後埋下了更多的問題 技術債不還會怎樣？ 就是你跟金融單位借錢一樣, 技術債也是會產生利息的, 直到團隊無法有新的產出, 所有的精力都在應付的技術債帶來的問題, 意思是說你的程式碼會變得難以維護,困難到讓團隊前進速度變緩慢,甚至到整個停下來 為什麼我們不會主動還技術債？ 如果你跟金融單位借錢, 他會通知你什麼時候該還多少錢...你就有心理準備說～喔～下禮拜要還錢了, 要準備一下了 但是技術債是跟未來的自己所借的, 我們把沒有處理完善的問題丟給未來的自己, 但是未來的自己並不會向金融單位一樣來提醒該還債了, 以致於常常忽略了技術債的存在 技術債的種類和什麼時候該還技術債？ 跟朋友借款 - 不還沒關係 跟朋友借工具, 就算不還也許你還是可以借到更多的工具 跟金融單位借款 - 不還錢會遭處罰, 但不會太致命 手動測試也許會拖慢整個release 的速度, 最後還是可以release , 但也許會從理想週期的一個月變成半年一次 跟高利貸借款 - 利息快速飛漲, 而且不還錢會有生命危險 沒有測試, 沒有設計, 整個團隊工作模式一團混亂 (Big ball of Mud) 當到達此種程度的時候, 組織如果想要維持固定的產出, 只好不斷地加人,加資源來推動 只是大家都不想面對問題, 不想做任何改變, 他們會害怕微小的改變會破壞現有的平衡 所以又再使用肩擔但不完善的做法來解決問題, 但同時又產生更多的技術債...  這是一種死亡螺旋 如何避免技術債？ 技術債無法避免, 我們無法在第一時間就給出完美無瑕的設計架構 軟體沒有完成的那一天, 只有開發的時間到了 軟體是一個不斷演化的過程, 在不斷的試誤中成長 一個功能所花費的成本有80%是在後續的維護 如果我今天製造了垃圾, 那我明天的工作將會是清理這些垃圾, 這會使我們產出變慢 我們能做是建造一個輕鬆安全可以進行變更的能力 我們發現有任何技術債產生的時候就快速的修正