.NET Walker

近代軟體開發大多以套件或框架為基礎，不管你採用哪一個語言。最近這五年，我們在專案的相依性管理上已經有了很大的成熟度和改變。如果你回憶十幾年前的軟體開發，可能常常看到專案中有底下這樣充滿相依性的設計： 說明一下，在上圖中，WebBMI.sln內共有三個專案，HealthMgr(上圖A)它是一個類別庫(Class Library)，而HealthMrgTests是該類別庫的UnitTest，WebBMI則是Web UI的主程式(上圖B)。 由於主程式中使用到了HealthMgr，因此它是相依於HealthMgr的，也就是說，主程式在建置時，必須要參考到HealthMgr內的一些類別與方法。 如果你開啟Visual Studio來看會更清楚： Visual Studio 2019本身有著很好的相依性檢視工具，你可以看到主程式WebBMI相依於同一個.sln中的HealthMgr，而且是以專案形式相依，這點是我們不喜歡的。 目前，WebBMI以『加入參考』的方式： 把同一個.sln中的HealthMgr給加入到WebBMI當中： 這雖然讓WebBMI可以輕鬆的使用到撰寫於HealthMgr內的類別和方法，但這是很古典的作法，不能說不好(如果把HealthMgr內的類別直接全寫在WebBMI主程式中可能更不好)，但最近幾年我們已經不再鼓勵開發人員這樣作了。 最主要的原因有幾點： 第一， 這使得WebBMI這個Project在Build的時候，非得跟HealthMrg專案綁在一起，兩者無法分割，形成高相依性。兩三個專案你看起來還好，但我就看過.sln的solutions中有近百個專案的。 第二， 如果HealthMrg專案又被另一個B專案所參考使用，未來很可能造成潛在的版本衝突。例如，當WebBMI專案因為某些理由，必須修改HealthMrg專案中某個類別的運算邏輯，但因為除了WebBMI專案之外，B專案同時也在使用HealthMrg中同一個類別，導致若修改了HealthMrg就會與B專案不相容，不改又不符合WebBMI新的需求，進入兩難的狀況。 砍斷針對專案的相依 因為前述的原因，近代在我們作軟體開發時，幾乎都已經不會再如同過去這樣， 直接 對某一個專案作參考(reference)，造成專案之間的潛在相依性衝突，而是改為針對套件(Package)的相依。 砍斷 對專案 的相依

凡事都可行，但不都有益處：凡事都可行，但不都造就人。(林前 10:23) 前陣子有位好友特別到我辦公室，跟我討論他最近想要做的某個軟體產品。他知道我過去這幾年有非常多產品開發(我想估計是失敗的)經驗，所以他說想跟我請益一番。 一如既往，只要人到了我辦公室，我肯定熱情接待、滔滔不絕、知無不言。談過了他的想法與企圖，也給了一些建議，茶過三巡，我也就不客氣地分享了我最近想做的另一個資訊服務，話還沒講完，他拍案大讚，說到：『David你這個案子會成，要不要做? 我有興趣。』 他的熱情讓我愣了一下，我有點猶豫地說，我還在思考一些問題，像是…為什麼我目前沒看到市場上有類似的服務? 台灣那家知名的網路商城P公司，該是最有資格做這個案子的，不管是倉儲、物流、和我這個案子最關鍵的庫存品，都一應俱全，我不太懂他們為什麼不做? 朋友說了一句話：『P公司太大了，他們什麼都能做。什麼都能做，就代表什麼都做不了。』 他話才說完，我就明白了。 (有時候跟頻道接近的朋友聊天就是有意思，話不用講太多，彼此一點就懂。) 我明白了朋友說的意思，但也看到了我自己的限制。 這一直以來是我的問題，我意識到這個問題，但卻始終沒有去面對。 前陣子流行『斜槓青年』，你可以在網路上找到這個字的意思。但我慢慢發現自己實在斜槓太多的領域了(而且也不是青年了)。過去這幾年，我寫書(手上正在寫一本)，做企業顧問(目前一家進行中，一家洽談中)，同時也帶人做軟體專案(目前三個案子進行中，好在差不多都是結案階段了)，我也喜歡上課(下個月開始預計有兩個排定的課程)，另外每周我給自己的目標是產出三到五篇的貼文、blog文章和數個教學影片檔，為了提供給線上課程和電子書… 然後，我還一直很想做產品。 雖然盡全力把每一個手上的任務做好，但很明顯的，我發現瓶頸在哪裡了。的確，瓶頸就在自己身上。 問題來了，我要割捨掉哪一塊? 我太明白多工與多重目標所帶來的陷阱和限制。回頭翻自己的貼文，還有底下這兩張照片呢： 但怎麼當要去面對這些問題的時候，自己也變得難以割捨了? 管理方法的道理和邏輯永遠是那麼鮮明，但執行的困難卻往往不是不懂這些，而是在情感上的拉扯和限制。 剛開始工作的第一年我就發現，除非自己選擇放下，否則手上的工作 永遠 不會有作完的那一天的。而當人(企業)能做的事情看似愈來愈多，就愈是得克制每一件事情(每一個目標)都想去做的衝動。 我記得從

Fork在Github中是常見的功能，使用的情境大多是我們想修改或學習他人的程式碼時。只要我們有權限，就可以Fork他人的Repos到自己的帳號底下。Fork和Clone不同，Fork可以追朔到來源的Repo，讓新建立的Repo與來源之間有所連結。 對於開源的open source專案來說，Fork是很有意義的功能，但對於企業來說也有需要嗎? 有的。 這幾年企業內部盛行InnerSource [1] 的觀念，過去企業常常把source code視為不可觸碰的機密，甚至要求source code不可離開Lab(或特定部門)。在那個年代，你可能在某大型軟體公司工作了好幾年，卻還是看不到與自己部門(所開發的產品)無關的其他系統的任何一行程式碼。 但，現在時代不同了。 近年來，開發人員(和他們的主管)明顯地發現了open source所帶來的價值。同時，對於程式碼的安全性與開發規範也日漸成熟(如今，上道的程式設計師幾乎都懂得機密資料不該寫死在程式碼中)，這使得企業也開始對於程式碼的開放不再感到懼怕。因此也在對企業內部員工開放程式碼後，獲取了很多前所未有的好處。 最顯著的好處是，員工可以透過檢視同事的程式碼進而學習和成長，回顧你自己過去的學習經驗，你會發現，其實大部分的程式設計師，都是透過 看別人的程式碼 來學習的(而非單單只是看書、上課、或是自學)。一旦停止觀摩，開發人員的成長就遇到瓶頸了，也就是說，觀摩其他人寫的程式碼，可以說是最好的學習方式(沒有之一)。 如果你覺得這沒什麼，認為讓員工成長這種事情對企業也沒啥好處，那你可以再反過來想。當企業內的所有開發人員，都知道自己的程式碼有可能會被其他人檢視(review)時，對於一個稍有廉恥心的開發人員來說，這是一個很大的提醒。當企業內培養出這個文化之後，大部分有自尊心的開發人員，都會在簽入程式碼之前，再看一下有沒有不該出現的code，以及是否有因為偷懶或取巧而品質不佳的程式碼。這使得軟體開發人員無形中更加的謹慎，對程式碼的自我要求將提高，而不只是 讓程式能動就好 。久而久之一旦養成習慣，在無形之間也提升了程式碼品質。 還有另一個典型的情境，也非常有價值。 近代的軟體開發往往是基於組件或套件的重用，在企業內也是，我們常常會用到他人所撰寫的套件或工具，這可以讓開發速度和時程加快，同時也提高重用性(提高重用性就是意謂著降低成本，切記)

除了使用Visual Studio，.net core開發人員也可以採用VS Code，它是跨平台的開發工具，在開發.net core程式的時候頗為好用。事實上，現在也頗多Python、Node.js開發人員使用它。 由於是跨平台的，所以你可以在MAC或Linux環境執行，而無須一定要使用windows環境。 從VS Code上連結Azure DevOps也非常簡單，前面的步驟都相同： 你可以在(上圖D)的地方先完成初始化，然後透過(上圖A)直接在右方選擇『Clone in VS Code』即可。你可能會發現，按下(上圖D)的Initialize之後，畫面就變了，別擔心，你可以點選右上角的Clone來進行一樣的功能： 點選後，會出現底下視窗： 請點選『Clone in VS Code』即可，接著系統會試圖開啟VS Code，請選擇開啟： 如果出現底下畫面，依舊選擇『開啟』： VS Code被開啟之後，會出現底下畫面，讓你選擇要把Clone下來的檔案放在哪個資料夾： 請自行選擇，完成後，你會看到底下視窗(一般出現在VS Code右下角)： 這時候就在複製Azure DevOps上的Repos了，完成後，請選擇: 開啟新視窗之後，你會看到果然整個專案已經被Clone下來： 你一樣可以在VS Code環境中進行所有版控相關的工作。 例如，你可以透過F1或ctrl+shift+P，即可開啟命列選擇視窗： 其中有『Git:Sync』指令，點選後，會出現底下視窗： 當你選擇確定，會發現果然把伺服器端其他開發人員最新簽入的程式碼給同步回來了(下圖A)： 同樣的，如果你改了一些程式碼，也會發現： 已變更的檔案數量會被顯示出來(上圖C)，被修改過的檔案也會被標記為M(上圖B)。 這時，你一樣可以透過『Git:Sync』指令，把你修改過的異動更新回伺服器端。你可以先點選下圖A的地方，會出現讓你輸入comment的畫面(上圖B)，請輸入後，按下Ctrl+Enter： 如果出現底下畫面，請選擇『是』: 完成後，表示程式碼已經committed到用戶端，接著可以sync到伺服器端，這時VS Code的左下角(下圖A)會出現已committed但尚未push/sync的change： 這時候你一樣可以透過F1或Ctrl+Shift+P，開啟(上圖B)的選單，進行同步(Sync)，完成後，你會發

Azure DevOps是微軟自家的雲端服務，那使用號稱地表最強的微軟開發工具Visual Studio 2019連上Azure DevOps自然沒什麼問題。 開啟Visual Studio 2019，輸入你的帳號，在Team Explorer頁簽的位置 (下圖1)，點選管理連線(下圖2,3,4)，即可連結到Azure DevOps的Repos，不管你是用哪一個版本的Visual Studio(免費或付費的)都行： 連結時會出現底下畫面： 在(上圖1)的地方，請選擇正確的帳號，該帳號必須是你要連接的Azure DevOps專案的Owner或Member(總之必須是團隊成員)，Visual Studio會列出所有你有權限存取的專案。 然後，請點選你要連接的專案(上圖3)，將其展開，會看到該專案底下所有Repos，如果是Git Repos會以紅色Git符號呈現(上圖4)，如果是TFVC Repos(上圖5，未來我不建議在新的專案中使用)版控，則會是灰色符號呈現。 點選好你要連接的Repos之後，請在路徑(上圖6)的地方輸入該專案你想要Clone到本機的哪個路徑，設定完成後按下『複製』鈕即可。 成功Clone專案之後，你會看到類似底下這樣的畫面： 由於一開始剛初始化的專案中，並沒有.sln, .*proj之類的專案檔，因此會先以上圖這樣的資料夾檢視模式來顯示，你會看到剛才我們建立好的README.md和.gitignore檔案都已經在其中(上圖1)。 這時，你可以點選(上圖2)的Team Explorer，會切換到底下畫面： 你可以在這個畫面中，透過『新增…』連結(上圖1)，來建立一個新的專案(或方案)，當你的專案建立好之後，可以透過『同步』(上圖2)功能，將用戶端的檔案同步到Azure DevOps雲端的Git Repo中。 例如，底下我們隨意建了一個.net專案(project)： 這是一個基本的console專案，建立好之後，你可以看到，在方案總管中，有新建立的程式碼(上圖1)，而上圖右下角的地方，你會看到目前有哪些尚未Commit的檔案(上圖2)，以及當前連結的repo(上圖3)和目前正在使用的分支(Branch, 上圖4)。 你可以透過點選上圖2,3,4這些圖示，來進行相關的操作。例如可以點選上圖2進行Commit，當您點選之後，會出現底下畫面： 你可以在上圖B