6.輕鬆工作-自動化部署

今天要講的東西跟 時下所說的CI/CD有點關係

其實先不要去看 CI/CD是什麼

這都是被創造出來的名詞

總之就是想要輕鬆有效率的工作

說真的要特別解釋我還真不會

但是會做都比這些重要多了

我們由情境來看 比較實在

一般來說 我們要將開發好的程式發佈至測試機或正式機需要如圖這些步驟

但這些如果透過人手動去做 步驟很多 也不易管理

一樣 如果把這些工作交付給代理人 要說明的東西就需要很多

我們在做程式設計要懂得方便管理

所以可以透過工具 也許是VSTS 或是 Jenkins來設定好這些自動化的步驟

最後再直接選擇建置 就發佈 就方便多了 一些參考圖如下

實際怎麼做網路有很多資源 邊查邊做 做中學 這知識才真的是你的了

這邊不多寫了(其實是懶 XD)

成就感就在於 以後發佈任何程式 都可以氣定神閒

說沒問題啦 ! 這就是專業 !
按一下就OK
(然後看手動的人手忙腳亂還容易出錯…(因為在多主機都需要複製下)也是一種成就感吧 XD)

5.從生活面來看為什麼要做單元測試?

為什麼要做單元測試

先來想看看 不要去管這樣的名詞

也不要管要怎麼做

假設今天我們突然要承接某同事開發的系統

然後他沒有做單元測試

這時候我必須在系統上加個功能

可能會改到他寫的程式

但是改了卻很有可能不知道會影響到那個地方

如果這個系統更龐大 就越有這樣的可能

這時候自己上線的功能經過測試沒有問題

但是一上線就不小心那個功能不能用了

這時候老闆只會覺得是你的問題 不是以前人開發的問題…

這時候如果你講出 這是以前是誰誰誰的問題是沒有用的

只會顯得自己更Loser

因為成熟的開發者與維護者就是要解決問題

所以只能也必須吞下這個就是你的錯失啦

這在以前ASP 或 WebForm的時代 是非常常見的問題

甚至是到了MVC時代把它當成是ASP和Web Form的方式開發

也難怪系統品質不穩定也不高

但是一定要用單元測試嗎?

原則上有做當然是比較好的

當我們看到有做單元測試的系統

豈碼比較可能確定這個開發者是有一些好的程式開發概念

看到的程式碼的每一個函式 會比較能清楚知道會有什麼樣的輸入和輸出

而不是會看到很多的void函式

不清楚這個函式有什麼樣的輸入與產出

就算是說有的沒有做單元測試

但也可以看得出來是有做單元測試的訓練過

因為懂得做單元測試

通常也可以驗證自己寫的程式

是不是容易好懂

這就是今天想分享給大家的

寫程式不是越努力越好

在設計程式時 必須要能在你請假或交付系統給其他人開發時

能馬上 非常快的馬上讓對方能完成你的工作

那才是一個好的程式開發者

4.為什麼要做分層架構?

為什麼要做分層架構呢?

就是讓菜鳥和其他同事

容易看懂和開發你寫的程式

也就是所謂的

方便系統的程式共用維護

系統擴充

最後讓程式可以做單元測試提高系統品質

我們從下圖來看看 沒有系統分層概念程式的寫法

這在以前的ASP時代或是轉成MVC的時代

還是可以看見的寫法

假設要取得會員資料(如圖)

將輸入的參數檢查,從DB讀取的資料

邏輯處理都放在一起

邏輯處理較複雜的程式說不定好幾百行

當看到這樣的程式肯定心情也很複雜

更別說在維護有時候只是想改個參數檢查

或撈取DB的方法

但改了看到這麼多行的程式還真擔心會不會改壞什麼

然後上線後還真的不小心有Bug

老闆還以為你不專業

但其實每個人改都有風險…

所以我們應該要讓每個程式每個定義負責的更為明確

才能確保系統品質

我們來看看如果有做分層架構如圖

讓每一個層面各自負責該做的事

這樣程式也就容易懂得多了

就好像家裡書桌如果有多個抽屜每個抽屜放了不一樣類別的東西

要找也就很方便了

3.SqlBulkCopy提高新增資料速度

在工作的經驗當中,有時候需要結轉其他單位的資料

做一些特別處理後到自己單位的資料庫

處理完後如果用迴圈一筆一筆去新增的話

當資料量很大的時候時間就會比較久

這時候可以使用SqlBulkCopy來提升速度

上圖為一筆一筆新增資料

接下來我們來使用SqlBulkCopy
1.首先先準備讀取來源資料並將它轉換成DataTable

2.SqlBulkCopy設定

結論
實際結轉17萬筆資料
如果一筆一筆新增大約1分鐘
但如果使用SqlBulkCopy約2-3秒

所以當新增大量資料時可以選擇SqlBulkCopy來使用

程式效率提升也是菜鳥跟有經驗工程師的差別喔!

2.程式品質-code review (1)

寫程式的時候

應該要在程式的輸入參數定義清楚,不要讓這個功能混入不應該有的輸入參數

有時候在工作的時候會看到類似這樣的程式

圖中有兩個API

一個是取得影音資料,另一個是取得影音列表資料

但是輸入參數類別都為同一個RequestParameter

這在維護上就有很大的問題
我們必須思考一個問題
如果有一天程式要交給其他人負責時
無論是菜鳥,資深人員
可以一看就懂 這才是好的程式

不要說還要翻手冊 做文件 (相信我大家都不會想看,這只是增加不該增加的工作成本)

我們從圖中可以看出來這兩個API共用一個RequestParameter Class

但以直覺來看程式 其實看不出那一個API應該會用到那一個輸入的參數

所以我們應該要分別定義不同的輸入參數如圖
取得影音資料的輸入參數為VideoDetailParameter
取得影音列表資料的輸入參數為VideoListParameter

這樣就可以很直覺的就知道那一個API應該輸入什麼參數
那天要把工作交給別人維護開發
也就不用多說明

1.程式與生活

程式與生活

為什麼會開始寫程式與生活

主要是希望能幫自己的學習與創作留下記錄(方便以後換工作能力的展現)

程式的本質其實是要解決問題

雖然有很多程式的技術名詞我也不是很懂

但重點還是在於會不會用

能不能幫使用者解決問題

就像我常去的推拿師傅 並不是什麼有名的醫大畢業

但就是能發現我的痠痛問題並解決

這才是最重要的

所以我想用生活化的角度去想想看如果自己要做什麼樣的系統

可能會遇到什麼樣的問題

來寫這個部落格