踩雷無數的狐狸先生

我們都希望透過測試自動化, 來讓測試夠方便一點, 或是把人力投入在更有效率的地方 手動的做每一次的回歸測試 (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 的概念, 先是綠燈再來重構 且不要隨機的改動配置, 應該要...

為什麼A+ 巨人會倒下？ 這一個十分讓人震驚的標題, 大部人都一味著追求成長, 想要變得更大更好 2008 年金融海嘯之後常常聽到"大到不能倒的公司", 會出現這個詞是因為他們夠大？ 還是他們要倒了？ 有誰想過再大的巨人終究會倒下呢？  我們常常以為大就會帶來成功, 卻忽略一但超過可以負荷的極限,  再多的成長都會反而會成為負擔 或是組織的文化內涵追不上組織擴張的速度,這樣的組織還是你想像中的樣子？還是會帶來許多問題, 最終走向失敗？ 成為第一不難,最難的是怎樣維持第一 可以不用自身經歷過這樣的波折,  怎麼尋找避免衰敗的秘訣 最聰明的人, 就是從別人失敗中學習的人 避免自己及帶著組織走向難以挽回的地步 企業衰敗的五階段 成功之後傲慢自負 不知節制地追求更大更快 輕忽風險, 罔顧危險 病急亂投醫 放棄掙扎, 變得無足輕重最終走向滅亡 所謂成功之後的自負是不重視主要飛輪尚餘的潛能, 或是更糟糕的出於無聊就把注意力放在下一個目標上, 傲慢地以為自己可以自然而然的成功下去, 並開始分心在原本做得很好的本業上面, 導致推動原本飛輪所需要的專注和資源都下降了... 領導人變得不再好學不卷以及不再認為自己很幸運, 反而假定成功完全是因為企業和領導人優越的特質所帶來的 接著就會進入不知節制的第二階段 成功會帶來成長的壓力, 過高的期望值會帶來惡性循環, 沒有生物可以無止盡的不斷生長下去... 只要超過能負荷的極限就會慢慢走向衰忙, 企業也是一樣 組織在不斷長大的過程中, 是否能保有初心, 還保有創業的核心價值？ 是否還能達成世界頂尖的水準呢？ 以及這些擴大的組織中是否有利於推動公司的經濟引擎呢？ 組織是否變得越來越官僚制呢？ 在關鍵位置上對的人的比例是否正在快入減少? 這些東西我們在組織成長的過程中要去不斷思考的問題 承擔看不見得風險 不是沒有風險, 只是我們看不到... 你會選擇在沒有經歷過的低溫環境發生太空梭？ 你怎麼選？ 你能不能證明發射太空梭很安全？ 你能不能證明發射太空梭不安全？ 吃水線原則 假設你在一艘船上,  只要做錯任何事, 船身就會撞出一個洞來, 如果洞的位置在水面上方的話,  你可以很容易的補起來, 從錯誤中得到教訓, 但如果撞出來的洞在水面上, 你必須要花很大很大的工夫才能把洞補起來, 同時間還要承擔船不斷在下...

 能交出成果的, 都很重視輸出 有了輸入之後, 必須透過實際的運用知識, 大腦才會將其視為重要情報而轉換成長期記憶儲存 輸入只有改變腦內的世界, 只有輸出才能改變真實的世界 把習得的知識輸出, 在沒有經過整理說出口之前, 都是在自以為懂的境界 透過不斷地說和寫讓資訊變成長期的記憶存在大腦裡 檢視輸出的結果,  無論成功或失敗, 記得查明原因,並將經驗活用在下一次的輸出裡 沒有後續的反饋, 是不會有成長的 面對疑惑和奇怪的感覺時, 不要放任不管, 盡可能透過各種方式去尋求解答 克服弱點, 發揮所長 加強深度和寬度 解決疑惑 請教他人 輸出的好處 留下記憶 改變行動 改變現實狀況 獲得自我成長 變快樂 獲得正面結果 想要成功就隨持保持正向的語言,  說人壞話對事情完全沒有幫助 針對體驗過的事情, 清楚地描繪自己的感受 在說話的過程保持眼神的接觸, 更容易了解彼此情感上細微的變化, 使溝通更加深入 在需要提及對方缺點時, 先提他做得好的部分, 使對方放下戒心 你想要什麼很重要, 先透過問自己想學什麼,再把學習目的裝進大腦中 這時候大腦就會努力在生活周遭尋求答案, 你會發現學習效率會變超好 問題可以幫助你更了解, 如何問對問題呢？ 邊聽邊想問題 問對方樂於聽到的問題 問其他參與者也想知道的問題 問使討論可以更有深度的問題 某種程度的緊張,  對於工作來說,  具有提升的作用,  這意味的緊張並不是敵人, 而是戰友 如何降低緊張的感覺呢？ 更多的事前準備可以有效提高安心感 練習討論 切割討論和感情 事先推演流程 擬定假設問答 搶先提出意見 對於別做得好的行為給予具體的讚美,  滿足對方的承認需求 與其責備『你說該怎麼辦才好？』指出具體錯誤, 一起思考對策, 效果會更好 沒有信賴關係之前,   責罵只會帶來反效果, 在以力服人之前,  先想辦法贏得他人尊重 道歉並不是認輸, 道歉可以讓自己做到輸出後的反饋 說清楚的七個方法, 只要充滿自信地從結論開始說,  說服力就會大幅提升 大聲且清楚的說 充滿自信且落落大方的說 先說重點 長話短說 舉例 借助專業 使用數據 與其強調商品的特色, 不如告訴對方可以得到什麼好處 熱銷公式其實很簡單, 『價值 > 價格』 要想要不調降價格又能把...

 故事對照讓我們聚焦在使用者及其經驗上, 促成更好的對話,  最後建造出更棒的產品 你的公司無法得到你想要的東西,除非你的客戶和使用者先得到他們想要的東西 我們要建造的東西總是超過我們擁有的時間和資源 讓輸出最小化,讓成果最大化 MVP  為什麼會有那麼大的爭議？ 最小可行產品不是你或許能夠交差的最低劣的產品 最小可行產品是達到想要之成果的最小產品釋出 最小可行解決方案是將成功達到想要之結果的最小解法 最小可行產品也是你能夠建立來證實你的假設為真偽的最小產品釋出 要先驗證你的問題是存在的 反覆進行直到可行 https://x-staticmediagroup.com/blog/what-mvp-and-why-do-i-care This is NOT MVP 的例子裡面, 在每一次都版本中都無法真的得到可以用的功能, 直到最後一版的釋出 This is MVP   的例子裡面在每一次的交付都是一個可以使用的交通工具或滿足某一個功能 你可以透過產出去驗證是否滿足問題是否存在 如果你的客戶的目標是從城鎮裡面的A點移到B 點, 也許滑板就很足夠滿足他的需求了 如果發現客戶想要的是長途旅行, 他可能就會反應目前提供的滑板無法承載太多物品, 以及長距離的移動, 透過第一個產出你就能更清楚使用者的需求 畢竟很多時候連使用者都不清楚他們要的是什麼....直到他們也了第一次的體驗, 才能提供回饋讓需求更具體一點 將每個釋出版本都當作是實驗並且留意你想要學習什麼？ 驗證性策略學習 - Lean Startup 思維的重要觀念 如果認清我們的目標是學習, 就能最小化我們想要建造的東西,並且聚焦在只建造我們需要了解的東西上,如果處理得當, 這表示你可能在早期階段做得太多了

 QBQ = The Question behind the Question QBQ的精神是個人擔當 別再有受害者的心態,別再拖延或怪東怪西 我能改變的只有自己 當下就去執行 我們總是期待別人會有所改變, 或是可以幫助別人改變 但我們真正能控制的只有自己, 改變從自己開始 當別人看到你有所改變的時候, 才有機會跟著改變 如果你想贏, 就別抱怨那些無法控制的事, 讓自己厲害到足以擊敗生命中的裁判 在競爭者眾多的情況下, 我們沒有錢閒工夫來扯彼此的後腿 只要記住我們都在同一個團隊之中 一味的責怪對解決問題於事無補,反而製造了恐懼在人與人之間築起高牆 每個組織的制度都不完美, 資源也有限,或許我們希望擁有共多的工具,更完善的制度,更多的資源 但花太多時間思考想擁有的事物,卻是造成拖延的另一個原因 QBQ 的精神: 在現有的資源下,我們怎麼達到成功呢？ 當遇到問題的時候, 也許我們能問的是 我能提供什麼解決方案？ 我如何以更有創意的方式去解決問題？ 我該如何取得決策所需要的資源？ 多問問題, 你的答案就會在問題之中被發現 學著去問更好的問題 以 [什麼]或 [該如何] 這兩個詞當開頭發問,  而不是[為什麼] 或是 [什麼時候] 把重點放在 [我] 可以做些什麼事情, 帶來改變 而不是希望[你們/他們/ 別人]做什麼改變 為什麼說改變自己就可以改變環境甚至改變世界呢？ 瑞士奶酪理論 （英語： Swiss Cheese Model ） 主要是講，瑞士起司在製造與發酵過程當中，很自然的會產生小孔洞。如果把許多片起司重疊在一起，正常情況下，每片起司的空洞位置不同，光線透不過。只有在很極端的情況下，空洞剛好連成一直線，才會讓光線透過去。導致嚴重事故發生的從來都不是因為某個單獨的原因，而是多個問題同時出現。 如果每一個關卡的人都負責做好自己的事, 是否就不會讓前後的起司洞連在一起了呢？ 每個人都想著如何在自己能做到的範圍內, 不斷地去追求完善該做的事 最近CPBL 討論很熱烈的一個Play, 捕手把球棒踢到壘線上面去影響跑者得分？ 如果打擊者當下有把球棒放在相較不影響跑者跟守備方的位置？ 如果第一位跑者在回來的當下就撿起球棒了？ 如果守備方在第一時間就發現球棒位置,  把球棒丟去更遠的地方？ 如果守備方在後來發現的時候, 把球棒踢遠一點？ 每個人都有機會...

什麼才叫做好的設計？ 怎麼樣算是過度設計? (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是否買單... 並不是說這些設計完全不需要, 只是現在還用不到,更應該專注當下最重要的問題, 並用做簡單的方法去做驗證 如果我們建立團隊的方式是可以快速地應對變化, 我們是否還需要事先假設未來的需求呢？ 如果我們團隊成長到一定的程度之後, 可能...