這是俺整理公司新訓內容的第一篇文章，目標是整理 Git 相關的筆記。

前言、推薦資源

說來慚愧，前陣子 PTT 和臉書社團都有討論到相關科系畢業卻不會 Git 會不會太誇張，我正是畢業之後才開始用 Git 的那類人囧，相信像我一樣的人並不少，因此這個系列就決定從「新訓時學到的 Git 的基本操作」開始記錄。

開始之前先感謝公司前輩和完善的新手教學，還有第一天就先學 Git 的優良傳統。另外，也感謝相當多優秀的 Git 學習資源，說明得也更為詳細深入，想好好了解 Git 的朋友也可以逛逛，這邊就先推薦一波：

• 為你自己學 Git
  • 對新手非常友善。網站點進去後往下拉，可以看到大部分章節都能免費看，佛！
  • 最有價值的是裡面的各種狀況題。畢竟當你用 Git 不只需要基本操作的時候，呃，祝你好運
• 連猴子都能懂的 Git 入門指南
  • 從入門到進階篇跟過一次的話，基本操作就沒有問題了
  • 圖解讓人很好理解，而且在教學的實作部分會提供儲存庫讓你下載實作
• 黑暗執行緒的 Git 分類文章
  • 同場加映：黑暗執行緒的 Git 指令筆記
  • 黑大出品，品質保證
• Learn Git Branching
  • 用遊戲通關的方式認識 Git，對於一些分支的概念會很有幫助
• 30 天精通 Git 版本控管
• Pro Git

接下來我們就從認識 Git 開始吧！

什麼是 Git？

你發生過以下狀況嗎？

• 從沒做過版本控制，結果突然要改回前一版，不知所措
• 使用資料夾／壓縮檔板控
  • 20201201.rar, 20201215_v2.rar, 20201215_首頁.rar……
  • 空間越吃越兇，東西越來越雜，事情越想越不對勁，但是不敢刪除
  • 其實不知道每一份實際上改了哪裡，要復原某一段的時候要找半天，不如直接重寫一段
• 團隊合作／分組報告，各自負責一個區域，結果複製來複製去組不起來，不只需要看眼科，修 BUG 還比寫的時間還多
• 看到一段程式碼
  • 完全不知道為什麼要這樣寫
  • 或是氣到要死，抓不到戰犯

那麼，你很有可能需要 Git！

Git 是一套分散式的版本控制，就像是打電動時的存檔。讓我們可以在面臨重要選擇的時候存檔、打王之前存檔、打贏的時候也存個檔。當然，像是那種有多劇情多結局的遊戲，也可以針對不同路線各自存檔。

同時它也支援雲端存檔，你可以在電腦上存個檔，然後有網路的時候就丟上去雲端備份一下。而這個雲端備份是共用的，所以你可以跟朋友一起玩同一款遊戲，各自攻略不同的 BOSS，再把存檔和朋友互相交流交流，合成一個有兩份戰利品的存檔。

這些功能在 Git 有著聽起來比較厲害的名字，例如認可（Commit）、分支（Branch）、分散式、合併（Merge）等等。我們後續再慢慢了解它們。

長夜將至，我從今開始守望。
　　　　　　　　　　　　　　　　　　　　　　　　　——《冰與火之歌》守夜人誓詞

年初整理完物件導向系列後，休息（沉迷遊戲）了好一陣子，終於要繼續整理公司新訓的內容啦！

因為這個系列會是公司新訓時期的筆記整理，所以會是比較簡易的實作紀錄，並不會太過深入，需要的時候會用延伸閱讀的形式補充上去。如果看文的過程中覺得有什麼能夠補充的，也歡迎告訴我呦。

本系列預計會從 Git 的基本操作開始，簡單建立一個 Web Api 為主軸，逐步介紹相關的部份，例如簡單地引入套件、簡單地分層等等。基本方針就是直接抄襲 隔壁同事的部落格。

後續有更新的文章，就會整理到這篇目錄中。或是也可以從 菜雞新訓記 裡面做系列文的查詢。

那麼，就從第一篇：Git 入門這樣做 開始吧！

苦難終於告一段落了，開心到 PO 一篇來紀念一下！

接下來…… 就坐等血源詛咒上 PC 啦（等得到嗎？）

延伸閱讀

• 就是要逼你正面對決 《隻狼》如何用設計讓玩家展現勇氣？
• 《血源詛咒》如何善用內在動機讓玩家甘願受虐？

今天從同事們那邊學到了書籤這個方便功能，趁還記得的時候來做個紀錄。

那麼馬上就來操作一次：

使用 Ctrl K, Ctrl K 可以在指定的行號上加上一個「書籤」

隨著 2020 進到了 2021，菜雞與物件導向也推進到了五大原則結束，可以暫時告一段落了。

最初和朋友約好了要把公司新訓學到的東西做個整理（廣告一下他的部落格：Sian），只是沒想到因為太常發廢文偷懶，大半年才推進到物件導向的基礎而已，甚至占不到新訓內容的十分之一。希望 2021 能繼續推進，把這部份的坑給填一填，然後把前面的文章也重構一下，只是按照我的個性，可能又會忍不住開新的坑吧，哈哈。

至於物件導向相關的心得和紀錄，也就是這個系列，偶而有想到或是有所體悟的時候再發上來吧，暫時想先把前面隨手寫凌亂文章給整一整先。在這個十幾篇的短系列，記錄了從類別與物件開始，到耦合、內聚及五大原則，每個主題的心得。這邊稍微做個小整理：

類別、物件

• 物件就是用來表達「我們知道的某個東西」，物件導向是用物件彼此互動的方式來建立架構
• 類別去定義我們要的物件有什麼特徵、有什麼功能，再從類別中實例化（也就是根據設計圖產生）物件出來使用

建構式、多載

• 建構式用來在建立物件時就進行一些我們想要的操作，例如狗狗的毛色等等天生的東西，或是這個建立這個物件的必須素材
• 多載指的就是可以有很多個同樣名字的方法，各自去接不同的參數，讓同個目標的函式可以根據傳入的參數不同做不一樣的處理

在上一篇我們紀錄了依賴反轉原則，到此五大原則介紹完畢…是這樣嗎？太天真了！就像四天王總是五個人一樣，五大原則當然也有第六個！

今天的主角就是五大原則中Ｌ位的第一候補：最少知識原則，也被稱作迪米特法則。

最少知識原則 (Least Knowledge Principle)

只和直接的朋友溝通，不和陌生人說話

那麼所謂的朋友是什麼呢？就是指這個物件或方法有直接相關的物件啦。例如當我們使用一個方法時，這個方法應該只認識：

• 該方法所屬的類別
• 該方法所接收的參數
• 該方法中建立的類別
• 該方法所屬的類別所依賴的對象

除此之外對這個方法而言都是陌生人。什麼情況會遇到陌生人呢？有一個蠻常遇到的狀況就符合定義：當我們使用依賴對象的方法，該方法給了我們另一個類別時，我們就正在接觸毫無關係的陌生人。

在聊依賴反轉之前，先讓我們聊聊什麼是依賴：

例如說如果有個像我一樣的肥宅每天一定要來一片雞排才能療癒身心，那我就是依賴雞排；
同樣的，如果有個大叔不抽菸就會全身不舒服，就是對香菸有所依賴。

當有「必須要藉由某個人事物來達到目的、受到某個人事物的影響和牽制」時，就是依賴。

而在程式設計裡面的概念也一樣，如果Ａ模組直接受到Ｂ模組的影響，我們就稱Ａ依賴了Ｂ，最明顯的狀況就是Ａ模組需要藉由Ｂ模組的實例來完成某個功能的時候。

例如「匯出報表」功能建立了一個「Excel 控制類別」的實例以建立檔案；
或是「會員查詢」功能建立了一個「DB 連線」的實例來進入資料庫取得會員資料

遇見這種「必須要藉由某個模組的實例來完成想要的動作」的狀況時，就是依賴。

依賴與耦合

我們在之前的 耦合篇 提過，如果模組和另一個模組之間有關連，那這兩者之間就耦合。以此來看，依賴就是一種耦合的關係，那麼，依賴是健康還是不健康的耦合呢？

現在讓我們用 多型篇 用過的「老闆徵工程師」的例子來舉例一下：現在有間小小公司，老闆請來了小明當工程師，並請他開工撰寫產品程式碼。

當「撰寫產品程式」對「工程師」直接依賴的時候，狀況可能是這樣的：

public Product Work()
{
    Ming programmer = new Ming();
    var product = programmer.Programming();
    return product;
}

過一陣子，老闆發現小明寫出來的東西似乎不太行，於是把小明趕走，另外請了小華。這時候因為「工程師」這個實作類別不一樣了，我們就必須要改一次程式碼：

public Product Work()
{
    Hua programmer = new Hua();
    var product = programmer.Programming();
    return product;
}

故事是這樣的——

Win10 工作列的合併設定有這些選項：

當選擇「一律、隱藏標籤」時，工作列上同樣的程式就會摺疊起來：

而「永不」和「當工作列滿時」則會將工作列展開：

好的，那麼像我個性這麼麻煩的人，如果覺得顯示名字很佔位置，可是又不想要摺疊之後按兩次才能打開我要的應用程式，偏偏又很愛開一整排 IDE 的話，有沒有什麼簡單的辦法不要讓圖示合併，但也不要顯示名字呢？

如果有個小工具，可以讓這些工作列的設定更彈性就好了，會有嗎？

無論喜不喜歡自己的工作，都應該好好思考自己和工作的關係，畢竟每天花三分之一的時間做這件事，如果和它處得不好，人生也不可能會變好。

這本書並不是那種精神勝利法，又或是超猛接案全攻略之類的書；反而給我的感覺比較像是作者藉著這本書，分享他這一路摸索的心得，和遭遇到的一些困難，看的時候有種像在和作者聊聊天的感覺。

也因為這本書比較接近作者分享他選擇的道路、內容比較廣雜，遇到的部分都稍微說一些，但不是那種針對某個議題深入探討的書籍，所以比較適合想稍微了解自由工作的朋友閱讀。同時也必須了解到，自由工作者也只是眾多職業道路的其中一種，每個人的條件也不盡相同，因此抱持著好奇的心情閱讀，會更有收穫的感覺。

從 博客來 的書籍簡介就可以看到，目錄真的把自由工作遇到的議題都碰了一些：從適不適合接案工作，到報稅、勞保、合約、工作場所都聊了一點。因為真的挺廣的，這邊我就只記錄一些我比較感興趣的話題。

最近遇到在 Amazon Linux AMI 要安裝 .net Core 3.1 環境的時候，會一直跳出
Requires: openssl-libs 而無法安裝的問題，儘管明明已經有 openssl 了，但還是解析失敗找不到依賴，過程一直碰壁，因此在這邊紀錄一下。

過程中嘗試了安裝 openssl-libs（會找不到該套件）、下載 Dotnet 的 tar.gz ，再直接對執行檔下 Dotnet 指令起站台（雖然網站起得來，但執行者會是當下的登入身分，也就是 ‘’@連線進來的IP-伺服器位置，而非由本機執行。後續如果有連線資料庫等檢查權限的地方就很容易出錯）

最後在 Dotnet Core 的 issue 翻到這篇 Cannot install .NET Core 2.0 on Amazon Linux AMI 才成功解決。

首先先將 openssl-libs 的 SPEC 抓下來，然後給 RPM 建置一下。這兩句可以參考一下這篇 RPM 打包︰由一竅不通到動手濫用 (二) 的說明。

wget https://github.com/dotnet/core/files/2186067/openssl-libs-ami.spec.txt
rpmbuild --bb openssl-libs-ami.spec.txt