2022年11月27日 星期日

為網站建立免費的SSL受控憑證

enter image description here

當你在Azure服務裡面,看到 “Managed” 這個字眼,大多被翻譯成『受控XX』,例如我們現在要介紹的這個『受控憑證』。這是一個可以讓你的網站免費享有SSL憑證服務的好東西。

這年頭網站已經不能沒有SSL應該是眾所周知的觀念,過去,我的非商用網站大多使用 ZeroSSL 或 Let’s Encrypt 這種免費的憑證,但用起來頗為麻煩,有要額外申請,有的管理手續繁瑣。

最近我開始試用Azure Web App的『受控憑證』,發現我沒有再使用其他憑證的理由了。因為…

  1. 免費
  2. 可和Web App站台一起管理
  3. 建立操作非常容易

使用的方法很簡單,首先,確定你的網站有B1以上的level:
enter image description here

接著,請自行建立你需要的domain(如果你以前用過SSL,應當知道該怎麼做),然後在Azure Web App的管理後臺點選到『TLS/SSL 設定』的畫面,選擇 『私密金鑰憑證 (.pfx) --> 建立 App Service 受控憑證』:
enter image description here

接著,選擇你設定好的domain,並且建立該憑證:
enter image description here

建立完受控憑證之後,再到繫結畫面進行設定即可:
enter image description here

這樣就搞定。
免費,簡單,好用。👍

2022年11月26日 星期六

程式碼只有CRUD,好像沒單元測試好寫?

enter image description here
沒想到這題會變成有網友敲碗要求解答的問題?

我在TW MVC的 .net conf mini 研討會中,大致描述了在 DevOps 採行高強度的持續交付時,團隊應該要做單元測試(unit test, UT)的原因。

議程後,有學員提問:『老師建議要做unit test,但同仁的程式碼大多是CRUD,似乎沒什麼測試好寫的? 這樣要如何提高測試程式碼覆蓋率?』

當時我的答案是:『如果真沒什麼東西好測的,那就別寫了,不需要為提高覆蓋率來硬寫測試程式。』這個答案乍聽之下可能讓人疑惑,特別是那種對於工程技巧實踐極端渴望,到近乎有些強迫症的工程師。

然而,現場學員這個問題的背後,真正的核心問題應該是,為何你寫的程式碼都沒啥東西可測的?

要探索這個問題,得先回到單元測試的本質。我們之所以要寫單元測試,大約有底下幾個原因:

  1. 減少人工手動測試,建立自動化回歸測試。 or
  2. 將測試案例(test case)自動化。
  3. 確認重要的核心邏輯程式碼不會出問題(確認你的程式碼堅固且可被驗證)
  4. 提高可維護性的確據(確保不會改了這邊,壞了那邊)
  5. 便於類別開發(例如開發API、或商業邏輯類別函式庫)

差不多上面這些,是我聽到大多數人想做單元測試的原因。

但問題來了,我在養成班或是許多剛進入開發領域的工程師身上,大多碰到一個問題。就是…他手上寫的程式碼幾乎都是很基本的資料庫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)的過程中,你將會有數不盡的單元測試必須做。』我笑著回答。

2022年11月23日 星期三

搶救...我自己

enter image description here

這張圖片很有意思。

我有些朋友很有勇氣,會在每年年底的時候,在FB列出自己今年度成就了哪些事情,例如 : 寫了幾篇部落格、錄了幾支影片、出了幾本書、完成什麼專案…等等等。

可能是因為,不管是MVP、LAE或是其他的Award,大概都需要這些具體的數字,才有獲選的機會。因此有許多人,平時都習慣整理和累積這些KPI。

我們在指導養成班轉職的學員寫履歷表的時候,也常常建議同學,你已經畢業一段時間了,履歷上不能只寫學經歷,要盡可能寫出你過去曾經"成就過(完成過)" 哪些事情。

具體的數字和成果,才是大部分企業想看到的內容。

但許多學員可能從來沒做過軟體專案,因此養成班才會規劃大量的實作,累積專案經驗。因為真正的實力,永遠都是從戰場上操練出來的。

前幾天在一個研討會現場,有位講師鼓勵聽眾,如果有機會,嘗試把你自己寫的程式真的放到市場上銷售(這年頭確實有很多管道)。當我們這麼做,會學習(突然間領悟)到很多事情,你可能會發現,要讓用戶心甘情願的持續掏錢,不一定如同想像般的容易,不管你程式碼寫的有多快、自覺技術能力有多強、架構設計的多美…在面對真實市場時,所有人都必須低頭謙卑

之前FB有位朋友回覆,提到了 “從真實世界中得到的反饋,才會有助於提升品質”,我想,應該也是一樣的意思。

在工程的領域,一切都是很務實的。

履歷上只寫著自己有經驗、會做事、有熱誠這些口號般的內容,不如具體寫出自己曾經成就了什麼專案,為過去服務的企業帶來什麼價值與成果。

在職場上,沒有誰一定有責任要搶救誰;也沒有規定一定要給什麼人一個機會。能給未來自己機會的,永遠是過去的自己。吃飽飯,休息一下,再繼續努力,未來的我,還等著現在的我去搶救呢~

2022/11/23

2022年11月22日 星期二

如何讓老闆重視軟體品質,而非只是想趕時程快速上線?

enter image description here

在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的最好辦法。

如何讓老闆重視軟體品質,而非只是想趕時程快速上線?

enter image description here

在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的最好辦法。

2022年11月12日 星期六

一人當多人用!? 敏捷專案的多工問題如何解?

#多工問題怎麼解 #老闆不願加人手怎麼辦
enter image description here
看到網路上有人詢問到 “部門人力不夠,老闆不願意加人,導致同仁水深火熱” 的問題。感覺提問者問的聲淚俱下,但其實這問題並非特例,幾乎每家公司都有這個狀況。

我們在企業導入敏捷時,常碰有團隊面臨多工(一人接多個專案),或是人力不足的問題。

同仁提出後,問我,敏捷(或Scrum)專案該怎麼面對這個問題?

我其實很想跟同仁說 : 這問題跟敏捷一點關係都沒有。敏捷也不是設計來解決這些問題的。

然而確實,當你採用敏捷或Scrum,這些原本被公司 “掩蓋的很好” 的人力(人事)問題,就會被你凸顯出來。(這也是一種透明度的展現?)

有人覺得,那為何以前在瀑布開發的時候,人員可以參與多個專案,可以多工,看起來沒什麼問題,但為何現在敏捷就不行???

再強調一次,不是敏捷不行,也不是瀑布式開發可以,而是瀑布式開發把透明度降低了,讓問題被掩蓋(隱藏)了起來,直到驗收結案時(前)一次償還這個被掩蓋問題所要付的代價(專案延遲、品質降低、團隊士氣低落…etc.)。而這時你根本分不出問題的 root cause 是什麼,是人力不足、是太多技術債、是專業能力不足、是插單…?

其實是專案中這些所有的問題所帶來的後果,一次一起呈現在你面前。

而敏捷則會在專案一開始,就讓你知道,當你把人同時投入多個專案多工時,會付出什麼代價?

但,這個問題該如何解決?

你得換位思考,把自己當老闆的角色,去思考這個問題。

你可能會發現,人夠不夠最終往往不是工程需求或計算工時的問題(所以任憑你做出再怎麼精緻的人力使用率報表,上面充斥著紅色的加班時數,也不見得有用)。而是資源(錢)怎麼分配,和資源(現金)夠不夠的問題。

也就是說,我們去證明人力不足,是工程思維;但設法證明,在我的部門若有更多的人,將會為公司帶來更多的價值(錢),或是人太少會讓公司虧很多錢,這是商業價值。

而主管大多在意 商業價值 > 工程需求。

"老闆好像總覺得我們部門有能力空間去支援OOO"<=== 這往往凸顯出的是,老闆覺得這個部門再多花點錢請人"不划算",暫時用加班可以解決問題就好。

當然同時也意味著,老闆可能還看不到這個部門人力使用的透明度,你確實應該使用一些工具(像是看板、CFD、燃盡圖)把工時的透明度呈現出來。但最終老闆願不願意增加人,則得看你和你的部門,能夠為企業帶來多少價值?

最近,你聽到北美很多公司在裁員,meta、twitter、MS、google…幾乎所有科技產業都在精簡人力,你覺得是因為,這些人力突然間都變的很閒? 突然間都沒有事情做了? 因為沒有工作所以被裁掉? 不是的,是因為市場變了,這些人預期能夠為產生的價值(獲利)將要變低了,導致企業非得先裁員不可。

其實說穿了,從企業的角度思考,人力的增減往往跟你的工作量多寡無關,而跟你的工作能為企業帶來的價值有關。無論我們在哪一個職位,除了花時間工作,更得花點時間證明自己為企業帶來的價值。

順帶說一句 : "薪資高底也往往跟你的能力無關,而是跟這家聘請你的公司有多需要你有關。"

2022年11月4日 星期五

HackMD.API C# SDK nuget package

enter image description here

前陣子,一群朋友吃飯,在座一位友人問到,大家假日都在幹嘛?
我說: 『在寫 Code 啊。』
她不解:『什麼意思? 你都一直在加班寫程式?』
我說: 『不是,是我自己的 side project,就是興趣啦。』
對方有點不可思議地看著我:『你平常上班沒寫夠? 假日還寫興趣的?』
我說:『這不同,平常寫程式是工作,而假日寫 side project 是舒壓。』

他不信。

我說,真的,我最近在寫一個可以自動產生網頁報表的程式,這樣我就可以自動把學員的成績單,輸出成 HackMD 的網頁格式,不賣錢的,純粹就是喜好而已。而且為了寫這個功能,我還順手幫 HackMD 寫了套C# SDK,然後又寫了單元測試…

一票人愈聽愈目瞪口呆…

哈哈哈哈,你們真的不懂工程師的世界。真的啦,不蓋你們,HackMD.API C# SDK nuget package 套件開源專案網址如下:

https://github.com/isdaviddong/HackMD.API

真的,不唬爛。

熱門文章