當你在Azure服務裡面，看到 “Managed” 這個字眼，大多被翻譯成『受控XX』，例如我們現在要介紹的這個『受控憑證』。這是一個可以讓你的網站免費享有SSL憑證服務的好東西。
這年頭網站已經不能沒有SSL應該是眾所周知的觀念，過去，我的非商用網站大多使用 ZeroSSL 或 Let’s Encrypt 這種免費的憑證，但用起來頗為麻煩，有要額外申請，有的管理手續繁瑣。
最近我開始試用Azure Web App的『受控憑證』，發現我沒有再使用其他憑證的理由了。因為…
使用的方法很簡單，首先，確定你的網站有B1以上的level：
接著，請自行建立你需要的domain(如果你以前用過SSL，應當知道該怎麼做)，然後在Azure Web App的管理後臺點選到『TLS/SSL 設定』的畫面，選擇 『私密金鑰憑證 (.pfx) --> 建立 App Service 受控憑證』：
接著，選擇你設定好的domain，並且建立該憑證:
建立完受控憑證之後，再到繫結畫面進行設定即可：
這樣就搞定。
免費，簡單，好用。👍
沒想到這題會變成有網友敲碗要求解答的問題?
我在TW MVC的 .net conf mini 研討會中，大致描述了在 DevOps 採行高強度的持續交付時，團隊應該要做單元測試(unit test, UT)的原因。
議程後，有學員提問：『老師建議要做unit test，但同仁的程式碼大多是CRUD，似乎沒什麼測試好寫的? 這樣要如何提高測試程式碼覆蓋率?』
當時我的答案是：『如果真沒什麼東西好測的，那就別寫了，不需要為提高覆蓋率來硬寫測試程式。』這個答案乍聽之下可能讓人疑惑，特別是那種對於工程技巧實踐極端渴望，到近乎有些強迫症的工程師。
然而，現場學員這個問題的背後，真正的核心問題應該是，為何你寫的程式碼都沒啥東西可測的?
要探索這個問題，得先回到單元測試的本質。我們之所以要寫單元測試，大約有底下幾個原因：
差不多上面這些，是我聽到大多數人想做單元測試的原因。
但問題來了，我在養成班或是許多剛進入開發領域的工程師身上，大多碰到一個問題。就是…他手上寫的程式碼幾乎都是很基本的資料庫CRUD，再不然就是畫面UI的處理，就還真沒什麼複雜的邏輯，程式碼主要的工作差不多都是 ==> 取得畫面上用戶輸入的欄位，然後呼叫EF(entity framework)做資料庫的寫入，或是反過來，從資料庫把資料讀出來，然後呈現在畫面上。
『這樣的程式碼，要怎麼寫單元測試?』學員問。
的確，這樣的程式碼，確實沒什麼重要的單元測試好寫。因為，你既不需要去測試EF(entity framework, ORM)，也不應該去測試UI是否正確的把你需要的畫面呈現出來，因為這都是框架本身已經做好的事情，若你的程式碼中沒有什麼運算邏輯，卻花大把時間去寫測試，似乎有點划不來。你真正要測試的對象，應該是你自己撰寫的『邏輯』。
一般我在上課的時候，大多用撰寫BMI計算、或是轉換匯率的類別來當作Unit Test範例，是因為它們都有明確的處理邏輯，如果程式碼大多只是為了做輸出輸入，撰寫單元測試的意義就不大。
我跟學員說 : 『你還記得小時候的電腦教學101?』
輸入 --> 處理 --> 輸出
還記得嗎?
我們所撰寫的『程式碼』的核心功能，應該有一些『處理(process)』的部分，撰寫單元測試理當以這些部分作為首要重點。而這些負責處理(process)的程式碼，我們大多會寫成類別(Class)。所以，如果你有撰寫類別，並且為類別撰寫很多方法(method)，那你應該就會有很多單元測試需要寫。
同學說: 『我沒有。我大多數程式碼都只有呼叫別人寫好的類別，很少(幾乎沒有)自己寫什麼類別庫。』
我說：『那這樣，即便你硬去做單元測試，十之八九你實際上做的是「整合測試」，而非「單元測試」。』
單元測試的主要目的，是撰寫程式碼來測試特定的功能(function)或方法(method)函式，以確保該函式的運作邏輯是正確的。而我們大多在MVC框架中，寫在controller裡面的程式碼，都只是呼叫(調用)其他的類別(例如資料庫處理、Log處理、UI處理)，倘若有複雜的邏輯運算程式碼(例如算薪資、剩餘休假時數、費用帳單…etc.)，你就應該將其從controller中抽出，把它寫成類別，然後在controller中去呼叫(這個你撰寫的類別)，如此一來，你寫了類別，自然就需要為此類別撰寫單元測試了。
如果開發人員總是把這些運算邏輯，一股腦寫在controller中，或是寫在UI的 event handler 中，那你當然覺得沒啥測試好寫，而且，這樣也大大失去了你使用MVC框架開發的意義了。
『所以，或許我們可以這樣說』我跟學員說道：『只要你撰寫類別，幾乎跑不掉一定會需要撰寫測試程式。而如果你在撰寫程式時，幾乎不用寫什麼類別，那你的程式一定有些什麼問題。要麼是相依性、耦合性太高，要麼是本身的商業邏輯太少，而這多半也意味著這種程式碼的value偏低。』
『那如果我負責撰寫的程式碼真的就只有一堆的表單，只需要依照資料庫的結構，把相同的欄位設計成畫面UI，並且進行CRUD(新增、讀取、更新、刪除)，只是數量非常非常多(大概上百上千隻)，那我該做什麼?』另一位同學問。
『那你該做的是換工作。』我說：『因為，這類的工作其實用程式碼產生器(code generator)大多就可以處理，而不需要花費人力。不然，你就乾脆嘗試寫一個表單程式碼產生器，可以偵測資料表結構，一口氣把成千上百隻表單自動產生出來。這樣，你的貢獻程度將遠遠超過人工去做那一兩百隻表單。』
『而且，開發表單產生器(form generator)的過程中，你將會有數不盡的單元測試必須做。』我笑著回答。
這張圖片很有意思。
我有些朋友很有勇氣，會在每年年底的時候，在FB列出自己今年度成就了哪些事情，例如 : 寫了幾篇部落格、錄了幾支影片、出了幾本書、完成什麼專案…等等等。
可能是因為，不管是MVP、LAE或是其他的Award，大概都需要這些具體的數字，才有獲選的機會。因此有許多人，平時都習慣整理和累積這些KPI。
我們在指導養成班轉職的學員寫履歷表的時候，也常常建議同學，你已經畢業一段時間了，履歷上不能只寫學經歷，要盡可能寫出你過去曾經"成就過(完成過)" 哪些事情。
具體的數字和成果，才是大部分企業想看到的內容。
但許多學員可能從來沒做過軟體專案，因此養成班才會規劃大量的實作，累積專案經驗。因為真正的實力，永遠都是從戰場上操練出來的。
前幾天在一個研討會現場，有位講師鼓勵聽眾，如果有機會，嘗試把你自己寫的程式真的放到市場上銷售(這年頭確實有很多管道)。當我們這麼做，會學習(突然間領悟)到很多事情，你可能會發現，要讓用戶心甘情願的持續掏錢，不一定如同想像般的容易，不管你程式碼寫的有多快、自覺技術能力有多強、架構設計的多美…在面對真實市場時，所有人都必須低頭謙卑。
之前FB有位朋友回覆，提到了 “從真實世界中得到的反饋，才會有助於提升品質”，我想，應該也是一樣的意思。
在工程的領域，一切都是很務實的。
履歷上只寫著自己有經驗、會做事、有熱誠這些口號般的內容，不如具體寫出自己曾經成就了什麼專案，為過去服務的企業帶來什麼價值與成果。
在職場上，沒有誰一定有責任要搶救誰;也沒有規定一定要給什麼人一個機會。能給未來自己機會的，永遠是過去的自己。吃飽飯，休息一下，再繼續努力，未來的我，還等著現在的我去搶救呢~
2022/11/23
在TW MVC舉辦的 .net conf mini中，現場學員問了一個問題:
『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』
這個問題，有些時候，換了不同的身分，你可能會有不同的答案。
在職涯中前十幾年我身為工程師，我很能理解工程師常常被時程追著跑的壓迫感，常常會覺得客戶(或老闆)要系統在很短的期限內上線，迫使我們沒有時間做好該做的事情。😣
『該做的事』有很多種不同的類型，從系統或架構設計、到單元測試、添加log或telemetry、甚至只是要多一點時間重構或調整程式碼改善品質(以後的可維護性)…族繁不及備載。
這些當然都是對的，也都是該做的，但常常在deadline面前，這些都顯得奢侈。看著自己的軟體作品被迫於期限而逐漸成為疊床架屋的怪獸，心裡確實很難過。
但，在老闆心裡可不是這麼想的。
老闆想的是，我答應客戶X月X日要能使用，我需要在記者發布會之前，讓XX功能出現，這個deadline都是訂好的，而且還需要留一點buffer，然而到今天，我甚麼都沒看到。工程師說已經完成了80%，什麼底層架構元件都做好了，最後只要把這些組在一起就可以給客戶用了，但…每次就是那該死的10%花了最久的時間(然後delay)，結果因為各種我聽不懂的意外(程式碼合併衝突? 套件衝突?OO框架有個XX的坑? 程式碼都是對的，我們這邊都可以用，但客戶環境有問題，找不到原因…這什麼鬼?)，導致無法準時交付。
過去有這麼多奇怪的延遲的經驗，而現在我(老闆、客戶)什麼都看不到，感到非常沒安全感。
我不知道這個是不是換了位置就換了腦袋? 但開始身兼專案資方身分幾年後，我對這件事情確實有了不同的感受。
老闆在意的常常是 time to market， 有時候，如果不能在某一個時間點推出產品，前面所有的努力(投資)基本上都是一場空。特別是這個競爭激烈且變動的時代，市場瞬息萬變，這幾年我們經歷過疫情，大家也開始能夠體會，許多時候，時間(或機會)是不等人的。
這讓過去瀑布式的軟體開發，顯得更力有未逮。
當天，我在會場對大家的回答是 : 這個問題本質上其實是一個『溝通問題』。
因為，雖然時程和deadline看起來是不可變動的，但老闆要的其實是敏捷度，是面對市場的機動性(彈性、選擇性)。而工程團隊要的呢? 是足夠的時間嗎? 如果有更多的時間，就一定能夠提升品質嗎? 其實不盡然! 開發軟體多年之後，你會知道，永遠沒有足夠的時間，就像系統永遠沒有完美的一刻一樣。工程團隊要的，其實是自由度。
軟體要能做的是持續改善，時間是永遠不夠的，也永遠沒有所謂的完美。一個活著(有人用)的軟體，就是必須持續調整、持續改善。
那如何縮短客戶(老闆)與開發團隊之間的落差??
我真心認為 『扎實地落實敏捷迭代式的開發』就是重點了。
每兩周(或每周，每一個迭代)把成果交付給老闆或客戶使用(注意，不只是看，是真的上正式機去使用)，老闆有責任提供反饋，不要再等上線前一周、前一個月，才去測試成品，要從專案開發kick-off後就開始，每兩周交付一次、使用一次，這樣才可以強化溝通，減少資訊落差，確認彼此的認知和需求。
而開發團隊也需要清楚的告知客戶(或老闆)，如果現在我們要趕時程、走捷徑，將可能付出什麼代價(技術債? 資安風險? 未來維護困難?)，把這些都攤開透明，讓客戶(或老闆)清楚的知道，縮短時程所需要附上的代價，然後大家一起來承擔，這就是敏捷了。
而採用敏捷式開發，只是把原本的開發方式變成更小的一個階段一個階段? 不!不!不!
如果你這樣想，就是天大的誤會，當開發要變成迭代式，例如改成兩周交付一次，那所需要調整的，絕不只是改改團隊開會的時間和頻率而已。而是，系統架構、框架的選擇、版控策略、團隊合作模式、系統設計方式、甚至UI/UX的做法，都會有所不同。(如果有興趣，請參考我們的敏捷/DevOps 課程)
所以回到上面的問題：
『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』
我的答案是，這是溝通問題，解決root cause的方式是增加專案透明度和溝通頻率，而實踐上最好的方式就是改成迭代式的開發，而迭代式的敏捷開發，絕對不只是專案團隊改一改作法就好，團隊的底子(技術能力)是否足夠支撐敏捷式的開發才是核心重點。
這也是為何我在研討上常說的 : DevOps實現了敏捷頻繁交付的承諾，而想要真正實踐DevOps，團隊需要技術能力，沒有技術能力支撐的團隊，就好像沒有體力支撐的球隊。
事實上，我在TW MVC這場『Azure DevOps高階工程技術實踐』的分享中，其實整個核心就是在談論這個議題。團隊的技術能力，支撐了DevOps的實踐，而DevOps讓敏捷承諾的頻繁交付有實現的可能。如此一來，才能夠time to market、頻繁交付、持續改善。
後話:
曾有過幾年老闆的經驗後，你可能也會發現，其實老闆不太可能真的不重視軟體品質，因為最終要付上代價的是出資的老闆，公司倒了工程師可以換工作，但老闆比較難。若你發現老闆看似在乎時程遠高過於軟體品質，大多是因為，老闆不知道這些品質犧牲所換來的時程，將來需要付上什麼代價。這一切，依舊還是溝通的問題。但『做好溝通』沒有想像的簡單，不是開幾個會把話講清楚就可以解決的。因此，迭代式的敏捷開發，才是解決root cause的最好辦法。
在TW MVC舉辦的 .net conf mini中，現場學員問了一個問題:
『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』
這個問題，有些時候，換了不同的身分，你可能會有不同的答案。
在職涯中前十幾年我身為工程師，我很能理解工程師常常被時程追著跑的壓迫感，常常會覺得客戶(或老闆)要系統在很短的期限內上線，迫使我們沒有時間做好該做的事情。😣
『該做的事』有很多種不同的類型，從系統或架構設計、到單元測試、添加log或telemetry、甚至只是要多一點時間重構或調整程式碼改善品質(以後的可維護性)…族繁不及備載。
這些當然都是對的，也都是該做的，但常常在deadline面前，這些都顯得奢侈。看著自己的軟體作品被迫於期限而逐漸成為疊床架屋的怪獸，心裡確實很難過。
但，在老闆心裡可不是這麼想的。
老闆想的是，我答應客戶X月X日要能使用，我需要在記者發布會之前，讓XX功能出現，這個deadline都是訂好的，而且還需要留一點buffer，然而到今天，我甚麼都沒看到。工程師說已經完成了80%，什麼底層架構元件都做好了，最後只要把這些組在一起就可以給客戶用了，但…每次就是那該死的10%花了最久的時間(然後delay)，結果因為各種我聽不懂的意外(程式碼合併衝突? 套件衝突?OO框架有個XX的坑? 程式碼都是對的，我們這邊都可以用，但客戶環境有問題，找不到原因…這什麼鬼?)，導致無法準時交付。
過去有這麼多奇怪的延遲的經驗，而現在我(老闆、客戶)什麼都看不到，感到非常沒安全感。
我不知道這個是不是換了位置就換了腦袋? 但開始身兼專案資方身分幾年後，我對這件事情確實有了不同的感受。
老闆在意的常常是 time to market， 有時候，如果不能在某一個時間點推出產品，前面所有的努力(投資)基本上都是一場空。特別是這個競爭激烈且變動的時代，市場瞬息萬變，這幾年我們經歷過疫情，大家也開始能夠體會，許多時候，時間(或機會)是不等人的。
這讓過去瀑布式的軟體開發，顯得更力有未逮。
當天，我在會場對大家的回答是 : 這個問題本質上其實是一個『溝通問題』。
因為，雖然時程和deadline看起來是不可變動的，但老闆要的其實是敏捷度，是面對市場的機動性(彈性、選擇性)。而工程團隊要的呢? 是足夠的時間嗎? 如果有更多的時間，就一定能夠提升品質嗎? 其實不盡然! 開發軟體多年之後，你會知道，永遠沒有足夠的時間，就像系統永遠沒有完美的一刻一樣。工程團隊要的，其實是自由度。
軟體要能做的是持續改善，時間是永遠不夠的，也永遠沒有所謂的完美。一個活著(有人用)的軟體，就是必須持續調整、持續改善。
那如何縮短客戶(老闆)與開發團隊之間的落差??
我真心認為 『扎實地落實敏捷迭代式的開發』就是重點了。
每兩周(或每周，每一個迭代)把成果交付給老闆或客戶使用(注意，不只是看，是真的上正式機去使用)，老闆有責任提供反饋，不要再等上線前一周、前一個月，才去測試成品，要從專案開發kick-off後就開始，每兩周交付一次、使用一次，這樣才可以強化溝通，減少資訊落差，確認彼此的認知和需求。
而開發團隊也需要清楚的告知客戶(或老闆)，如果現在我們要趕時程、走捷徑，將可能付出什麼代價(技術債? 資安風險? 未來維護困難?)，把這些都攤開透明，讓客戶(或老闆)清楚的知道，縮短時程所需要附上的代價，然後大家一起來承擔，這就是敏捷了。
而採用敏捷式開發，只是把原本的開發方式變成更小的一個階段一個階段? 不!不!不!
如果你這樣想，就是天大的誤會，當開發要變成迭代式，例如改成兩周交付一次，那所需要調整的，絕不只是改改團隊開會的時間和頻率而已。而是，系統架構、框架的選擇、版控策略、團隊合作模式、系統設計方式、甚至UI/UX的做法，都會有所不同。(如果有興趣，請參考我們的敏捷/DevOps 課程)
所以回到上面的問題：
『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』
我的答案是，這是溝通問題，解決root cause的方式是增加專案透明度和溝通頻率，而實踐上最好的方式就是改成迭代式的開發，而迭代式的敏捷開發，絕對不只是專案團隊改一改作法就好，團隊的底子(技術能力)是否足夠支撐敏捷式的開發才是核心重點。
這也是為何我在研討上常說的 : DevOps實現了敏捷頻繁交付的承諾，而想要真正實踐DevOps，團隊需要技術能力，沒有技術能力支撐的團隊，就好像沒有體力支撐的球隊。
事實上，我在TW MVC這場『Azure DevOps高階工程技術實踐』的分享中，其實整個核心就是在談論這個議題。團隊的技術能力，支撐了DevOps的實踐，而DevOps讓敏捷承諾的頻繁交付有實現的可能。如此一來，才能夠time to market、頻繁交付、持續改善。
後話:
曾有過幾年老闆的經驗後，你可能也會發現，其實老闆不太可能真的不重視軟體品質，因為最終要付上代價的是出資的老闆，公司倒了工程師可以換工作，但老闆比較難。若你發現老闆看似在乎時程遠高過於軟體品質，大多是因為，老闆不知道這些品質犧牲所換來的時程，將來需要付上什麼代價。這一切，依舊還是溝通的問題。但『做好溝通』沒有想像的簡單，不是開幾個會把話講清楚就可以解決的。因此，迭代式的敏捷開發，才是解決root cause的最好辦法。
#多工問題怎麼解 #老闆不願加人手怎麼辦
看到網路上有人詢問到 “部門人力不夠，老闆不願意加人，導致同仁水深火熱” 的問題。感覺提問者問的聲淚俱下，但其實這問題並非特例，幾乎每家公司都有這個狀況。
我們在企業導入敏捷時，常碰有團隊面臨多工(一人接多個專案)，或是人力不足的問題。
同仁提出後，問我，敏捷(或Scrum)專案該怎麼面對這個問題?
我其實很想跟同仁說 : 這問題跟敏捷一點關係都沒有。敏捷也不是設計來解決這些問題的。
然而確實，當你採用敏捷或Scrum，這些原本被公司 “掩蓋的很好” 的人力(人事)問題，就會被你凸顯出來。(這也是一種透明度的展現?)
有人覺得，那為何以前在瀑布開發的時候，人員可以參與多個專案，可以多工，看起來沒什麼問題，但為何現在敏捷就不行???
再強調一次，不是敏捷不行，也不是瀑布式開發可以，而是瀑布式開發把透明度降低了，讓問題被掩蓋(隱藏)了起來，直到驗收結案時(前)一次償還這個被掩蓋問題所要付的代價(專案延遲、品質降低、團隊士氣低落…etc.)。而這時你根本分不出問題的 root cause 是什麼，是人力不足、是太多技術債、是專業能力不足、是插單…?
其實是專案中這些所有的問題所帶來的後果，一次一起呈現在你面前。
而敏捷則會在專案一開始，就讓你知道，當你把人同時投入多個專案多工時，會付出什麼代價?
但，這個問題該如何解決?
你得換位思考，把自己當老闆的角色，去思考這個問題。
你可能會發現，人夠不夠最終往往不是工程需求或計算工時的問題(所以任憑你做出再怎麼精緻的人力使用率報表，上面充斥著紅色的加班時數，也不見得有用)。而是資源(錢)怎麼分配，和資源(現金)夠不夠的問題。
也就是說，我們去證明人力不足，是工程思維；但設法證明，在我的部門若有更多的人，將會為公司帶來更多的價值(錢)，或是人太少會讓公司虧很多錢，這是商業價值。
而主管大多在意 商業價值 > 工程需求。
"老闆好像總覺得我們部門有能力空間去支援OOO"<=== 這往往凸顯出的是，老闆覺得這個部門再多花點錢請人"不划算"，暫時用加班可以解決問題就好。
當然同時也意味著，老闆可能還看不到這個部門人力使用的透明度，你確實應該使用一些工具(像是看板、CFD、燃盡圖)把工時的透明度呈現出來。但最終老闆願不願意增加人，則得看你和你的部門，能夠為企業帶來多少價值?
最近，你聽到北美很多公司在裁員，meta、twitter、MS、google…幾乎所有科技產業都在精簡人力，你覺得是因為，這些人力突然間都變的很閒? 突然間都沒有事情做了? 因為沒有工作所以被裁掉? 不是的，是因為市場變了，這些人預期能夠為產生的價值(獲利)將要變低了，導致企業非得先裁員不可。
其實說穿了，從企業的角度思考，人力的增減往往跟你的工作量多寡無關，而跟你的工作能為企業帶來的價值有關。無論我們在哪一個職位，除了花時間工作，更得花點時間證明自己為企業帶來的價值。
順帶說一句 : "薪資高底也往往跟你的能力無關，而是跟這家聘請你的公司有多需要你有關。"
前陣子，一群朋友吃飯，在座一位友人問到，大家假日都在幹嘛?
我說: 『在寫 Code 啊。』
她不解:『什麼意思? 你都一直在加班寫程式?』
我說: 『不是，是我自己的 side project，就是興趣啦。』
對方有點不可思議地看著我：『你平常上班沒寫夠? 假日還寫興趣的?』
我說：『這不同，平常寫程式是工作，而假日寫 side project 是舒壓。』
他不信。
我說，真的，我最近在寫一個可以自動產生網頁報表的程式，這樣我就可以自動把學員的成績單，輸出成 HackMD 的網頁格式，不賣錢的，純粹就是喜好而已。而且為了寫這個功能，我還順手幫 HackMD 寫了套C# SDK，然後又寫了單元測試…
一票人愈聽愈目瞪口呆…
哈哈哈哈，你們真的不懂工程師的世界。真的啦，不蓋你們，HackMD.API C# SDK nuget package 套件開源專案網址如下:
https://github.com/isdaviddong/HackMD.API
真的，不唬爛。
