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

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

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

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

最近遇到在 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

今天要記錄的是介面隔離原則，顧名思義是和介面高度相關的原則。因此在閱讀本篇之前，可能需要先對 介面 有一點了解呦。

事情就從上一篇 里氏替換原則 的鳥類物流公司開始說起。老闆痛定思痛，決定先用介面先規定好物流士們的應徵條件，例如裝貨、卸貨、飛行、必須有帥氣的喙等等。

這道命令下來後，倉庫們的企鵝都慌了，來檢查的編譯器瘋狂跳出 Error:「您未實作 IBird 的 Fly() 方法！」這下怎麼辦呢，為了要保住飯碗，企鵝們就必須實作出飛行才行，可是企鵝真的就不會飛呀！

這下子企鵝們只剩下兩個選擇：不實作飛行，但是就不能被當成物流士，最後就會被開除；或是……空實作。

public class Penguin : IBird
{
    public void Fly()
    {
      // Do nothing;
    }
}

企鵝們終於騙過了編譯器檢查員，然而當送貨的命令下來之後，企鵝們再一次卡在倉庫門口發呆，最終物流公司仍然踏上了虧損的老路，再度面臨倒閉危機…

不能信任那些 Terminal 或編輯器用白底的人。
—— JokeKappa

這禮拜推薦了個常用的 chrome 套件給同樣喜歡黑色背景的同事，這邊也推薦給大家。

絕對不是因為隻狼更新了不小心砍太爽，結果來不及寫介面隔離只能介紹套件水一下，Heiya～

今天要介紹的就是這款 Dark Reader，這是我用 chrome 時首選的暗黑模式擴充套件，在俺寫文的這時候已經超過了三百萬次的下載次數，現在就讓我來記錄一下這款擴充套件的一些特色唄。

里氏替換原則 (Liskov Substitution Principle)

子類別必須能夠替換父類別

里氏原則還包含了一個概念：子類別替換父類別後，不需要改變，也不會發生任何錯誤或異常。

從定義就可以看出來，這項原則是來替我們處理繼承問題的。因此，在開始本篇之前，可能需要先對 繼承 以及 多型 有基本的認識。如果可以的話，也請先看過 介面。

那麼，就讓我們從很久很久以前開始說起…

我的子類別進入叛逆期了，怎麼辦？

很久很久以前，有一間公司受到 鴿子封包 所啟發，打算發展鳥類運輸技術，強勢打入無人機市場，用生物智慧掀起對人工智慧的革命。既然鳥類都會飛行，理所當然可以藉由飛行來進行空運，甚至還可以偷偷擊墜那些無人機對手，野心勃勃的老闆立馬徵了一批鳥類物流士，打出「凡是鳥類都可應徵」的旗號，各式各樣的猛禽響應而來，一時之間掀起整個物流業的風暴！

但是好景不常，公司營運之後發貨狀況不佳，頻繁發生丟包問題，甚至有些貨根本就出不了倉庫，虧損越來越大，心急如焚的老闆下令徹查，這才發現—

開放封閉原則 (Open-Close Principle)

軟體實體（類別、模組、函式等等）應該對擴展開放，而對修改封閉

在我們了解什麼是「對擴展開放」和「對修改封閉」之前，先讓我們談談：什麼是擴展，什麼又是修改呢？

用白話一點的方式來形容，修改就是把東西拆開來改，像是手術；而擴展就是對東西額外加裝模組，像是添購設備。我們用飛行來舉例，像是鳥類直接用翅膀飛行，如果有需要修改飛行方法的話就得對鳥直接進行手術；但如果今天是一個裝備了噴射背包的人，我們只需要把噴射背包換成噴射鞋子、甚至噴射翅膀就可以了，不需要去修改人這個本體。

這邊可以發現開放封閉原則是針對「改變的時候」去做一個行動的建議，例如需求追加和變更等等。凡是變化都有成本，例如變動的難易度、變動造成的影響範圍等等都會影響到成本，若是程式碼冗長、內部邏輯複雜，類別之間互相耦合、影響範圍很廣，導致綁手綁腳或壞東壞西等等狀況，使得修改很困難，成本就會變高，進而使得開發效率變低。

然而，軟體並不是製造完畢就完工的東西，而是隨需求而生、隨需求而變的動態作品，因此程式碼的修改或重構相當頻繁。就像我們在 內聚耦合篇 提過的：軟體面對改變的能力，就像基因適應環境並生存下去的能力。因此，程式必須具有彈性，也就是需要盡可能降低修改的成本。

那麼讓我們回到前面：動手術跟換道具，哪個的成本比較高呢？

面對需求，對程式碼的改動是透過增加新程式碼進行的，而不是更改現有的程式碼　　
（《大話設計模式》）

Markdown 是一種寫作用語言，特色是只要用簡單的符號就可以替文章進行排版，例如 # 就代表了標題，因此能相當簡潔迅速地應用 Markdown 語法來撰寫出文件，目前已經被廣泛使用在各個撰寫文章或是文檔的場景中。

例如 Github 用來說明專案的 Readme.md，從副檔名 md 就已經告訴你這是一篇 Markdown；又像是這個部落格的文章，也都是使用 markdown 來寫的。除此之外，像是 Facebook 和 Line 都開始支援簡單的 Markdown 語法了 —— 因為它實在是太方便好用了。

使用Markdown格式撰寫的文件應該可以直接以純文字發佈，並且看起來不會像是由許多標籤或是格式指令所構成 —— markdown.tw

既然用簡單的符號就能完成這些簡潔的排版，我們自然就能把專注的重心挪回到撰寫文章本身，這也就是 Markdown 最大的魅力：專注於內容。

也因為 Markdown 的特色就是非常的簡潔乾淨，文檔本身的可讀性就相當的高，撰寫起來也很直覺容易。就如同其說明文件所說的：「Markdown 的目標就是實現『易讀易寫』」

這篇就來稍微紀錄一下 Markdown 的常用語法和好用的編輯環境吧！

這週入手了新玩具，在這邊記錄下～

我們家大神大大跟我說部落格就當推特發就對了，唉呀我也是深表認同吶

像我這種被實驗室和公司寵壞的人，已經習慣了雙螢幕的好。結果不管是在放不下兩台螢幕的家裡書桌，還是帶著筆電出門，尤其是一邊寫東西一邊查資料，需要來來回回切換視窗時，總是會想「唉呀真想把這丟到另一個螢幕啊！」

因此！幾經掙扎之後，還是入手了外接螢幕！

開場先說心得，雖然尚未有外出機會，但目前的使用相當滿意。這邊就說說個人體會的好壞：

2021.01.30 補充：外出也相當方便，只是桌面的空間就需要大一點

我們在前面的 內聚和耦合 有提到過，內聚並不是無腦把相關的程式碼都封在一起就好了，也有分成健康的和不健康的。但我們要怎麼知道這個類別是否足夠健康呢？單一職責原則就是很好的檢驗方式，這篇就讓我們來紀錄一下。

單一職責原則 (Single Responsibility Principle)

「單一職責」原則顧名思義，就是一個類別應該只負責一個職責。

但是這樣太過籠統了，「職責」相當容易產生誤會，容易變成各說各話。畢竟咱們工程師最愛戰定義了嘛。

「你這類別不優，它有兩個職責！登入跟登出！」

『沒有啦，我這個類別就是負責帳戶管理的啊』

「OSSO。乾脆你全部放一起，然後說是負責網站管理算了，呵」

『……你存心來找碴的是不是？』

為了避免像這樣產生職場糾紛，我們需要先定義一下什麼是「職責」。經過前輩們的努力（解釋）之後，單一職責的定義就成了：

就一個類別而言，應該只有一個引起它變化的原因

另外，我也看過「一個類別應該只對一個角色負責」的說法，這兩者的核心概念是一樣的。

因為隔壁介紹原則的部分有點卡住了，所以這週來紀錄一下挺常用到的方便東西：Tuple

這篇的 Tuple 指的是 C# 7.0 後提供的 ValueTuple 和相關語法，舊版得用 Tuple.Create 建立，成員的名稱也只能使用 Item1, Item2…，實用性並不是很高。但新 Tuple 出現後，方便程度大大提升，這邊就稍作紀錄一下。

註：此處使用的 Dump 是 Linqpad 提供的輸出方法，把它當成 Print 就行了。

var student = (1, "王小明");
student.Item1.Dump(); // 1
student.Item2.Dump(); // 王小明

student.Dump();

可以看到 Tuple 的建立相當簡單，只需要用小括號 () 括選起來即可。建立後的內容就會像這樣：

但這樣使用就和之前一樣，取出來時只能拿 Item1, Item2，放個幾天根本就不記得 Item1 裡面是啥東西了。這時我們就可以替成員們取名字：

(int ID, string Name) student = (1, "王小明");
student.ID.Dump(); // 1
student.Name.Dump(); // 王小明

如此使用的時候就和一般操作物件的習慣沒有差別，也增加了可讀性。