這是俺整理公司新訓內容的第四篇文章，目標是簡單地使用 Swagger 工具來自動產生可互動的 API 文件。

API 文件與 Swagger

在 上一篇 我們建立了一個有簡單的 CRUD 的 Web API 服務，這篇我們就接續著 API 服務往下看吧！

之前我們介紹 API 的時候有提過：API 是為了讓兩個服務之間可以溝通、互動所產生的接口。而所有的溝通要有效，都一定要先有共識，隨著溝通的人數越來越多，或是內容的理解要越來越細，就會用文件或契約的方式來達成共識。

回到我們的 API 服務開發來說，就是你除了把服務生出來了，可以跑了以外，還有一個重要的點是：必須讓所有的使用者（包含幾個月後的你自己）知道怎麼使用這組 API 服務。

也就來說，就是要寫 API 規格文件 啦！

這是俺整理公司新訓內容的第三篇文章，目標是在 .NET Core 簡單地使用 Dapper 連線到資料庫並完成 CRUD 的功能。

接續 上一篇 的進度，我們接著要來連線到資料庫中完成我們的 Web Api 的 CRUD 範例。因為從新訓時期到現在工作團隊作業上主要都是使用 Dapper 來做連線資料庫的工作，這邊就直接用 Dapper 來推進吧！

Dapper 有多好用呢？它輕量、它簡單、它快速。總之先把大神們的介紹文直接拿來鎮樓：

• 短小精悍的.NET ORM神器 – Dapper - 黑暗執行緒
• 另一種資料存取對映處理方式的選擇 - Dapper - mrkt 的程式學習筆記
• 好用的微型 ORM：Dapper - Huanlin 學習筆記

那麼按照慣例，我們先來 吹捧今天的主角 說明一點簡單的前因後果吧。想直接實作的朋友，可以跳到正式開工的小節呦。

這是俺整理公司新訓內容的第二篇文章，目標是對 Api, Restful Api, HTTP 等相關的知識點做個筆記，並用 .net Core 建立一個簡易的 Web Api 專案。

前言、基本觀念

我們在 上一篇 記錄了新訓第一天的 Git 操作筆記。接著在這篇，我們終於要進入 .net Core 啦！

目前的規劃是先從建立一個可以使用的、最簡單版本的 Web Api 服務開始，再將各個工具擴增進來。所以後續的文章應該都會以這篇的簡易 API 為基底繼續延伸下去（如果順利的話啦）

這篇文章的前半段會用來記錄一些使用或開發 API 常用到的相關知識，如果對 HTTP 的部分已經有點頭緒，或是迫不及待想直接動手用 .net Core 開 Api 服務的朋友們，可以直接跳到 正式開工 的部份。那麼，我們開始吧～

什麼是 API

我們在物件導向的 介面 時有稍微聊過所謂介面（Interface）的概念：「在兩個系統，或是兩個分層之間要介接的時候，只需要提供我這個功能的接口／介面給對方，就能讓對方知道如何使用」

API（Application Programming Interface）也是同樣的道理：

在不同的應用程式或服務（Application）之間，使用程式碼（Programming）的方式提供一組 介面（Interface），讓提供方和使用方可以藉由這組介面銜接起來。

API 最貼切的比喻就是我們在 封裝篇 也用過的販賣機：販賣機會提供不同飲料的按鈕，當我們選擇了其中一個按鈕按下、投了錢之後，對應的飲料就會掉下來。

對應回來就是：我們到了某個服務（販賣機），去拿我們想要的資料（飲料），所以呼叫了該服務的某支 API（按鈕）並且提供了一些該 API 要求的資料（投錢），最後 API 就會把我們想要的資料交給我們（飲料）

再用更實際的例子來說就像是：假設我們想要做一款可以查詢台北市的公車動態的 APP，於是我們到了提供公車動態的服務 MOTC Transport API v2 去找我們想要的 API，過程中我們可能需要告訴服務我們要查的是台北市，最後服務就會將公車動態的資料交給我們。

關於 API 的部份，推薦可以先閱讀過 Huli 大大的這兩篇，將基本觀念說明的相當好懂且透徹：

• 從傳紙條輕鬆學習基本網路概念
• 從拉麵店的販賣機理解什麼是 API

另外，也推一下我在 CodingBar 看到的這篇 API 到底是什麼？ 用白話文帶你認識 和它所引用的影片：

當我們遇到比阿嬤的裹腳布還臭還長的類別時，常常會發生「需要一邊確認 Public 的 Function，但它用到的 Private Function 卻遠在天邊」，或是「SQL 字串／字串常數等等另外宣告在檔案最上端，導致瀏覽邏輯到一半的時候還要來回跳」的狀況。

在 上一篇 我們分享過用書籤的方式來記錄兩個地方來回飛躍，但如果是要互相比對或理解流程等等時候，就比不上分割視窗來的方便。

在 Visual Studio 用分割視窗的方式開啟不同的檔案，相信大家都已經駕輕就熟，尤其用過 Visual Studio 來進行 Merge 的朋友一定對這樣的排版不陌生。但是你知道就算對同一個檔案，也可以使用分割視窗來同時編輯兩個地方嗎？只需要動動滑鼠就可以囉！

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

• 前言、推薦資源
  • 什麼是 Git？
  • 什麼是分散式版本控制？
  • 先告訴 Git 我們是誰
• 建立一個新的儲存庫（Git Init）
• 把檔案加到 Git 的追蹤目標（Git Add）
• 提交變更（Git Commit）
  • Git Commit 的訊息該怎麼寫？
  • Git Commit 的時機？
  • Git Commit 和 Add 的 Combo 技
  • 加入 .gitignore 來忽略指定檔案
• 查詢 Commit 紀錄（Git Log）
• 查詢兩個 Commit 之間的差異（Git Diff）
• Git 的 HEAD 是什麼？
• Git Revert：讓我們往回走一步
• Git Reset：讓我們搭上時光機
• Git 的分支（Branch）是什麼？
  • 新建分支（branch）與切換分支（checkout）
  • Git Stach：讓我們快速存個檔
  • Git Merge：讓我們合併兩條分支吧
  • 什麼是衝突（Conflict）？
  • Git Rebase：讓我們移花接木
  • 我們現在有哪些分支（Git Branch）？要怎麼刪除分支？
  • 認識 Git 的斷頭（detached HEAD）
  • 關於 Git 的分支策略
• 什麼是 Git 的遠端儲存庫（Remote）？
  要怎麼把變更推送（Push）到遠端儲存庫？
• 要怎麼從 Git 的遠端儲存庫拿到變更？認識擷取（Fatch）、提取（Pull）
• 使用 Git Clone 直接把遠端儲存庫的 Repo 抓下來
• 認識 Git 的提取要求（pull request, PR）
• 小結
• 本系列文章
• 參考資料

前言、推薦資源

說來慚愧，前陣子 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)

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

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

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

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