.NET Walker

當你在Azure服務裡面，看到 “Managed” 這個字眼，大多被翻譯成『受控XX』，例如我們現在要介紹的這個『受控憑證』。這是一個可以讓你的網站免費享有SSL憑證服務的好東西。 這年頭 網站已經不能沒有SSL 應該是眾所周知的觀念，過去，我的非商用網站大多使用 ZeroSSL 或 Let’s Encrypt 這種免費的憑證，但用起來頗為麻煩，有要額外申請，有的管理手續繁瑣。 最近我開始試用Azure Web App的『受控憑證』，發現我沒有再使用其他憑證的理由了。因為… 免費 可和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，似乎沒什麼測試好寫的? 這樣要如何提高測試程式碼覆蓋率?』 當時我的答案是：『如果真沒什麼東西好測的，那就別寫了，不需要為提高覆蓋率來硬寫測試程式。』這個答案乍聽之下可能讓人疑惑，特別是那種對於工程技巧實踐極端渴望，到近乎有些強迫症的工程師。 然而，現場學員這個問題的背後，真正的核心問題應該是，為何你寫的程式碼都沒啥東西可測的? 要探索這個問題，得先回到單元測試的本質。我們之所以要寫單元測試，大約有底下幾個原因： 減少人工手動測試，建立自動化回歸測試。 or 將測試案例(test case)自動化。 確認重要的核心邏輯程式碼不會出問題(確認你的程式碼堅固且可被驗證) 提高可維護性的確據(確保不會改了這邊，壞了那邊) 便於類別開發(例如開發API、或商業邏輯類別函式庫) … 差不多上面這些，是我聽到大多數人想做單元測試的原因。 但問題來了，我在養成班或是許多剛進入開發領域的工程師身上，大多碰到一個問題。就是…他手上寫的程式碼幾乎都是很基本的資料庫CRUD，再不然就是畫面UI的處理，就還真沒什麼複雜的邏輯，程式碼主要的工作差不多都是 ==> 取得畫面上用戶輸入的欄位，然後呼叫EF(entity framework)做資料庫的寫入，或是反過來，從資料庫把資料讀出來，然後呈現在畫面上。 『這樣的程式碼，要怎麼寫單元測試?』學員問。 的確，這樣的程式碼，確實沒什麼重要的單元測試好寫。因為，你既不需要去測試EF(entity framework, ORM)，也不應該去測試UI是否正確的把你需要的畫面呈現出來，因為這都是框架本身已經做好的事情，若你的程式碼中沒有什麼運算邏輯，卻花大把時間去寫測試，似乎有點划不來。你真正要測試的對象，應該是你自己撰寫的『邏輯』。 一般我在上課的時候，大多用撰寫BMI計算、或是轉換匯率的類別來當作Unit Test範例，是因為它們都有明確的處理邏輯，如果程式碼大多只是為了做輸出輸入，撰寫單元測試的意義就不大。

這張圖片很有意思。 我有些朋友很有勇氣，會在每年年底的時候，在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看起來是不可變動的，但老闆要的其實是敏捷度，是面對市場的機動性(彈性、選擇性)。而工程團隊要的呢? 是足夠的時間嗎? 如果有更多的時間，就一定能夠提升品質嗎?

在TW MVC舉辦的 .net conf mini中，現場學員問了一個問題: 『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』 這個問題，有些時候，換了不同的身分，你可能會有不同的答案。 在職涯中前十幾年我身為工程師，我很能理解工程師常常被時程追著跑的壓迫感，常常會覺得客戶(或老闆)要系統在很短的期限內上線，迫使我們沒有時間做好該做的事情。😣 『該做的事』有很多種不同的類型，從系統或架構設計、到單元測試、添加log或telemetry、甚至只是要多一點時間重構或調整程式碼改善品質(以後的可維護性)…族繁不及備載。 這些當然都是對的，也都是該做的，但常常 在deadline面前，這些都顯得奢侈 。看著自己的軟體作品被迫於期限而逐漸成為疊床架屋的怪獸，心裡確實很難過。 但，在老闆心裡可不是這麼想的。 老闆想的是，我答應客戶X月X日要能使用，我需要在記者發布會之前，讓XX功能出現，這個deadline都是訂好的，而且還需要留一點buffer，然而到今天，我甚麼都沒看到。工程師說已經完成了80%，什麼底層架構元件都做好了，最後只要把這些組在一起就可以給客戶用了，但…每次就是那該死的10%花了最久的時間(然後delay)，結果因為各種我聽不懂的意外(程式碼合併衝突? 套件衝突?OO框架有個XX的坑? 程式碼都是對的，我們這邊都可以用，但客戶環境有問題，找不到原因…這什麼鬼?)，導致無法準時交付。 過去有這麼多奇怪的延遲的經驗，而現在我(老闆、客戶)什麼都看不到，感到非常沒安全感。 我不知道這個是不是換了位置就換了腦袋? 但開始身兼專案資方身分幾年後，我對這件事情確實有了不同的感受。 老闆在意的常常是 time to market， 有時候，如果不能在某一個時間點推出產品，前面所有的努力(投資)基本上都是一場空。特別是這個競爭激烈且變動的時代，市場瞬息萬變，這幾年我們經歷過疫情，大家也開始能夠體會，許多時候，時間(或機會)是不等人的。 這讓過去瀑布式的軟體開發，顯得更力有未逮。 當天，我在會場對大家的回答是 : 這個問題本質上其實是一個『溝通問題』。 因為，雖然時程和deadline看起來是不可變動的，但老闆要的其實是敏捷度，是面對市場的機動性(彈性、選擇性)。而工程團隊要的呢? 是足夠的時間嗎? 如果有更多的時間，就一定能夠提升品質嗎?

#多工問題怎麼解 #老闆不願加人手怎麼辦 看到網路上有人詢問到 “部門人力不夠，老闆不願意加人，導致同仁水深火熱” 的問題。感覺提問者問的聲淚俱下，但其實這問題並非特例，幾乎每家公司都有這個狀況。 我們在企業導入敏捷時，常碰有團隊面臨多工(一人接多個專案)，或是人力不足的問題。 同仁提出後，問我，敏捷(或Scrum)專案該怎麼面對這個問題? 我其實很想跟同仁說 : 這問題跟敏捷一點關係都沒有。敏捷也不是設計來解決這些問題的。 然而確實，當你採用敏捷或Scrum，這些原本被公司 “掩蓋的很好” 的人力(人事)問題，就會被你凸顯出來。(這也是一種透明度的展現?) 有人覺得，那為何以前在瀑布開發的時候，人員可以參與多個專案，可以多工，看起來沒什麼問題，但為何現在敏捷就不行??? 再強調一次，不是敏捷不行，也不是瀑布式開發可以，而是瀑布式開發把透明度降低了，讓問題被掩蓋(隱藏)了起來，直到驗收結案時(前)一次償還這個被掩蓋問題所要付的代價(專案延遲、品質降低、團隊士氣低落…etc.)。而這時你根本分不出問題的 root cause 是什麼，是人力不足、是太多技術債、是專業能力不足、是插單…? 其實是專案中這些所有的問題所帶來的後果，一次一起呈現在你面前。 而敏捷則會在專案一開始，就讓你知道，當你把人同時投入多個專案多工時，會付出什麼代價? 但，這個問題該如何解決? 你得換位思考，把自己當老闆的角色，去思考這個問題。 你可能會發現，人夠不夠最終往往不是工程需求或計算工時的問題(所以任憑你做出再怎麼精緻的人力使用率報表，上面充斥著紅色的加班時數，也不見得有用)。而是資源(錢)怎麼分配，和資源(現金)夠不夠的問題。 也就是說，我們去證明人力不足，是工程思維；但設法證明，在我的部門若有更多的人，將會為公司帶來更多的價值(錢)，或是人太少會讓公司虧很多錢，這是商業價值。 而主管大多在意 商業價值 > 工程需求。 "老闆好像總覺得我們部門有能力空間去支援OOO" <=== 這往往凸顯出的是，老闆覺得這個部門再多花點錢請人"不划算"，暫時用加班可以解決問題就好。 當然同時也意味著，老闆可能還看不到這個部門人力使用的透明度，你確實應該使用一些工具(像是看板、CFD、燃盡圖)把工時的透明度呈現出來。但最終老

前陣子，一群朋友吃飯，在座一位友人問到，大家假日都在幹嘛? 我說: 『在寫 Code 啊。』 她不解:『什麼意思? 你都一直在加班寫程式?』 我說: 『不是，是我自己的 side project，就是興趣啦。』 對方有點不可思議地看著我：『你平常上班沒寫夠? 假日還寫興趣的?』 我說：『這不同，平常寫程式是工作，而假日寫 side project 是舒壓。』 他不信。 我說，真的，我最近在寫一個可以自動產生網頁報表的程式，這樣我就可以自動把學員的成績單，輸出成 HackMD 的網頁格式，不賣錢的，純粹就是喜好而已。而且為了寫這個功能，我還順手幫 HackMD 寫了套C# SDK，然後又寫了單元測試… 一票人愈聽愈目瞪口呆… 哈哈哈哈，你們真的不懂工程師的世界。真的啦，不蓋你們，HackMD.API C# SDK nuget package 套件開源專案網址如下: https://github.com/isdaviddong/HackMD.API 真的，不唬爛。

這張圖是一個老梗了。 記得前陣子跟幾個朋友聊天，席間，一夥人為了一個話題爭論不休。小時候，我的管理學老師曾說，有兩類議題，你不用試圖跟朋友討論清楚，因為不管怎麼說，都說不清的。一個是宗教，一個是政治。 年輕時覺得真理愈辯愈明，後來才知道，其實沒這回事。我們所相信的，其實都會左右我們觀察事情的角度，而看事情的角度不同，看到的真相就會不同。 網路時代，社群媒體更強化了同溫層的力道(對這原理有興趣的人可以看Netflix有一部影片Social Dilemma)。 試圖跟不同看法的人溝通，你會很訝異的發現，你怎麼可能會這樣想? 如果你常覺得，TMD的這麼簡單的道理為什麼總有人想不通? 那你更該看看這影片。 柯維在『第三選擇』中說：「溝通中的傾聽是你讓對方充分表達並且了解對方的感受，到足以為對方辯護的程度…」 身為工程師，我很喜歡明辨是非對錯，但總要提醒自己，身為負責溝通的顧問或教育訓練的引導者，我得嘗試設身處地，從不同的角度來重新觀察我已經相信的事實，或許，會有其他的收穫也說不定。