前兩天貼了編碼、加密、雜湊的文章，今天接著貼它的續集：

聽說不能用明文存密碼，那到底該怎麼存？ - Starbugs Weekly 星巴哥技術專欄

這篇列了幾個方案，從編碼到雜湊，搭配圖文解釋，非常適合貼給同事然後叫他們密碼不要亂存。

真的，只要你同事一說「那我們就用 bas…」就直接把這篇甩在他臉上。

備註：剛剛收到另一篇，感覺也可以拿來甩：密碼存明碼，怎麼不直接去裸奔算了？淺談 Hash , 用雜湊保護密碼

此外黑大也有寫過相關的科普，有興趣的朋友可以參考參考：密碼要怎麼儲存才安全？該加多少鹽？-科普角度

按慣例，這邊也迅速節錄一下、收進筆記庫。

方案一：Base64 編碼

先回顧上一篇的這句：

所謂的編碼並不會修改資料、也沒有任何加密的效果，單純就是換個方式來表達資料而已

沒有加密效果！沒有加密效果！沒有加密效果！而且 base64 的 == 真的太好認了= =

經過 Base64 後的結果很常都是 = 或 == 結尾，所以如果有一天資料庫真的洩漏出去了，駭客也會在第一時間就發現可以用 Base64 解開，然後在很短的時間內得到原本的密碼

那如果不要用 base64，用一些比較冷門的編碼呢？

也不行，雖然這些編碼演算法比較少人在用，但頂多騙騙不懂電腦的路人甲乙。真正的駭客很可能會使用各種方法嘗試要 decode 密碼，所以不管用哪一種編碼都是不安全的，結論就是不要使用編碼來儲存密碼！

方案二：AES256 加密

那用加密呢？加密就會牽涉到保管 key 的問題：

因爲使用者要登入時，後端必須確認使用者輸入的密碼加密後跟資料庫內的 password 是否符合，所以還是必須把 key 放在 server 上。既然是放在 server 上，那駭客就還是有機會拿到

因為公司內的員工可能會知道 key，所以就可以從資料庫得到使用者的密碼。如果你知道 Facebook 的工程師只要想要就能得到所有人的密碼，應該也不太放心吧，尤其很多人都在多個網站使用同樣的密碼

結論就是因為無法保證 key 的安全，所以不建議用加密的方式保存密碼

方案三：SHA1 雜湊

雜湊代表是不可逆的，通常是拿到密碼之後再雜湊一次比對結果：

當使用者 Luka 要登入時，就把他輸入的密碼拿去經過 SHA1 雜湊，如果算出來的雜湊值跟資料庫內那一大串一樣，那就代表 Luka 有極高機率輸入了正確的密碼，所以就放行讓他登入

但因為現在的電腦已經很猛了，所以針對一些長度很短的、常出現的密碼，其實就可以直接拿來比對 SAH1，結果就還是會被猜出來

剛剛的 love1234 之所以可以被破解其實是因為他太簡單了，只要把長度為 8 的字串雜湊值都算過一遍就好。而且小寫字母加上數字也才 36 個字元，算一算 36⁸ 大約才 2.8 兆種組合，很快就可以建一個表出來

如果你的密碼又臭又長又亂、包含了大小寫甚至還有一些怪怪的字元，像是 -y]@7k[BSB@3m]r$.>“R，那以現在電腦的計算速度就還無法破解，因為長度 20 以內由數字、大小寫還有特殊字元組成的字串太多了，算到天荒地老都不見得能算出來

（只到這步的話，感覺平常只要密碼夠長就沒啥問題？）

補充：感謝前輩提醒，SHA1 已經在 2017 年被攻破（Announcing the first SHA1 collision - Security Blog），並在 2020 年被公認不再安全（Critical flaw demonstrated in common digital security algorithm）

因此建議不要再用 SHA1 了，請改用更舒適安全的雜湊，例如 SHA256 🤔

方案四：加鹽 & SHA256

哦？聽起來只要密碼夠長、夠亂就沒問題了，那我能不能自己產生隨機字串，把使用者的密碼加長呢？

答案是可以，這就是所謂的 加鹽（Salt）。如果今天有一個新的使用者要註冊，這時我們的後端系統就隨機生成一個長度十的字串稱作 Salt，計算 Hash 時就把使用者輸入的密碼跟 Salt 合在一起算

我現在碰到的密碼處理幾乎都是這種，安心實在。

原本攻擊者遇到簡單的雜湊，可能都已經把各個密碼對應的表都算好了（延伸閱讀：彩虹表）

但只要加了鹽，這張準備好的小抄就不能用啦～只要多一兩個步驟，就可以讓駭客算到天荒地老，何樂而不為呢？

方案五：Bcrypt

完全沒看過的東西！馬上節錄文章內的介紹：

雖然 Bcrypt 的名字裡面有個 crypt，但他並不是加密法，而是跟 SHA1 一樣是雜湊演算法，唯一的差別是他計算很慢

計算慢有什麼好處呢？前面有提到 SHA1 的雜湊值之所以可以被查表查出來，就是因為現今的電腦計算太快了，就連建個表反查也不需要太多時間

而 Bcrypt 則是可以透過設定疊代次數讓他變慢，以疊代五次的 Bcrypt 來說，他的計算速度大概比 SHA1 慢 1000 倍。也就是說，假如你原本用 SHA1 計算三天就能反查出所有使用者的密碼，現在卻要花大概八年的時間才可以

竟然就只是，算很慢？但想想還是很有道理，畢竟現在的玩法就是炸裂駭客的時間成本讓他去找別人，這樣看起來其實挺有用的？

補充：Argon2

這篇上推之後，發現蠻多朋朋提到 Argon2 這個香東西，第一次認識。怕忘記，先抓兩篇丟上來：

• Password Storage Cheat Sheet - OWASP Cheat Sheet Series
• What is Argon2 Hash? - debugpointer

目前看起來最大的特色是可以自訂 Time Cost、Memory Cost 跟 Parallelism Factor，然後因為太吃記憶體(?) 所以打擊用 GPU 的挑戰者特有效？

晚點再研究研究，先補充上來🤔

最後標一下總結的這一小句。我發現有很多朋友曾經跟我有一樣的迷思：
「安全是不是就等於完全無法被攻破？」但其實不是這樣的。

在資安領域沒有所謂絕對的安全，你只能不斷提高攻擊者的成本，當那個成本高到攻擊者無法負荷時（像是破解一個密碼要租超級電腦連續計算十年），那就可以說是足夠安全了XD

今天在群組剛好看有人在討論加密跟雜湊，馬上把收藏已久的這篇拿出來：

一次搞懂密碼學中的三兄弟 — Encode、Encrypt 跟 Hash - Starbugs Weekly 星巴哥技術專欄

這篇文章依序介紹編碼、加密和雜湊，並且都有給範例和應用，很適合剛認識的朋友。（也可以拿去丟給每次都講錯的朋友）

那按照慣例，我們也迅速筆記一下，讓我收到卡片庫裡：

首先是編碼。編碼其實就是換個方式表達資料而已。

例如跟朋友約好 ㄅ=A, ㄆ=B… 這樣轉換下去，基本上只要知道對應的內容就可以馬上轉回來，摩斯密碼就是這類。

（題外話，以前還在紙條上用過豬圈密碼 xD）

延伸閱讀：為什麼打開檔案時會看到亂碼？跟著小明一起從傳紙條學習編碼

接著認識一下二哥：加密。

加密不只是像編碼一樣單純轉換而已，而是需要使用金鑰。

例如 ㄅ=A, ㄆ=B 之後，這時候我們約好 key=2，代表字母要往下數幾格，這時候就變成 ㄅ=C, ㄆ=D，如果不知道 key=2 就可能會數錯了

當然現在用的加密還是比較正經一點，被暴力解都要跑超久那種的。此外，根據加解密是不是用同一把 Key，還會分對稱式跟非對稱式

有興趣的朋友可以閱讀內文，以及延伸閱讀：

• 基礎密碼學(對稱式與非對稱式加密技術) - Chan
• 圖解“非對稱”與“對稱”加密技術

最後是雜湊，雜湊沒在跟你還不還原的，直接就是打爛。

把各個欄位/字元 丟進去某個公式計算的方式就叫做雜湊（Hash），而這個計算公式就稱為雜湊函數（Hash function），過程可能會做各種加減乘除，最後算出一個值或字串。

因為最後一個數字是經由前幾個數字計算、濃縮出來的，所以理所當然不可能由雜湊後的結果回推出前幾個數字分別是什麼，所以雜湊的過程是不可逆的

這邊想貼另一篇的說明，也非常好懂：

[資料結構] 雜湊 (Hash)

舉例來說，雜湊函數就像一台果汁機，我們把蘋果香蕉你個芭樂 (資料) 都丟進去打一打、攪一攪，全部變得爛爛的很噁心對吧？！這時候出來的產物 (經過雜湊函數後的值)，是獨一無二的，沒有辦法反向組合成原來的水果 (資料)。倘若我們把蘋果改成紅龍果，出來的產物 (經過雜湊函數後的值) 就會跟著改變，變成桃紅色的，不再是原來的淡黃色。

我個人通常是在存密碼的時候碰到，反正就算要比對的話，只要照同樣步驟打爛兩次結果長的一樣就好了吧～

最後引用一下這篇文章簡潔有力的小結，結束這一回合：

• 編碼（Encoding）
  • 只是換個方式表達資料
  • 不需要 Key 即可解碼（不安全）
• 加密（Encrypt）
  • 用 Key 來保護資料的機密性
  • 加密跟解密都需要 Key
• 雜湊（Hashing）
  • 把資料丟進一串公式計算出一個結果
  • 無法反推回原字串

那麼，今天的轉貼就到這邊，明天見～

最近專案進行得熱烈，團隊間的溝通也比較頻繁。決定來轉貼這一篇：
第一天上班就該學會的精準提問術

這篇提供了我們菜鳥朋朋們一些工作上溝通要注意的事情，例如「讓對方感受到你有尊重他的時間」、「溝通頻率一天不要超過三次」等等。

除此之外，還列了一些小技巧。
例如想要從對方身上獲得資訊的時候，可以描述一下預期結果和實際結果的差異：

「你原本認知的事情是要跑 A 流程，但試著執行後卻發現出現預期外的 B 結果，想詢問自己認知是否有錯」

「我看了你的 UI 畫面，本來是認為從 A 頁面要連到 B 頁面應該是用 slide 轉場，但是我看到了 C 頁面好像跟我預期想像的動畫轉場好像不一樣，你可以描述你心目中的正確轉場方式嗎？」

或是要請別人替你處理事情時，可以試試提供選擇題：

「這個問題困擾了我很久，我想到 A、B、C 作法，但不知道哪個比較好，你可以幫我看看哪個比較適合呢？」

「主管你臨時插件的 B 案子我覺得沒問題，那你要先做這個 B 案子嗎？如果是這樣 本來 A 案今天下班前就可以給你，就會變成 後天下班前才能給你，這樣 ok 嗎？」

搭配同個系列的這兩篇服用，效果更佳：

• 專業就是連麻瓜都聽得懂的溝通術
• 工程師如何與 PM 溝通 - 菜鳥工程師必修的 30 堂溝通課

如果想繼續了解「我該怎麼發問」，或是希望自己至少上班的時候不要問出白癡問題的話，
絕對絕對要閱讀這一篇經典：

• 提問的智慧 (How To Ask Questions The Smart Way)

如果真的沒時間，至少可以看看〈好問題跟蠢問題〉以及〈不該問的問題〉兩小節。拜託。

反正我現在看到怪怪的問題都直接把這篇文甩過去

這幾天被某台新出的彩色電子閱讀器燒到，剛好眼睛也開始有點不太舒服，整個非常心動。

但其實我一直不是很懂電子書閱讀器的發光功能是要幹嘛用的，查資料翻到這兩篇，決定轉貼上來：

• 彩色電子紙的前光(背光)迷思 - Jack Black
• 彩色電子紙開前光是否就失去了護眼的意義？ - Jack Black

這兩篇還有科普了電子書的一些迷思，例如「光線太暗會傷眼」、「亮度越亮顏色越鮮豔」等等

但因為我之前的迷思主要在「如果我用閱讀器開了這個燈，那不是跟我用平板一樣？」，因此主要節錄一些前光和背光的部份來筆記就好。

首先讓我們看看電子書的發光方式：

所謂電子紙的前光源，是裝置在電子紙紙面側邊上方的 LED 燈珠，它發出的光會透過導光板均勻的分佈到紙面中間上方並照射墨水分子，而墨水分子再把這個光反射回來給我們看到，因此也是反射光

彩色電子紙的前光源其實跟環境的人工照明光源（如檯燈）並無不同，一樣都是光線照射到墨水分子後再反射墨水分子的顏色光到使用者的眼睛，與液晶螢幕、OLED、Mini or Micro LED 這些使用背光源照明直射成像的方式不一樣。

電子書閱讀器的是「前光」，就是其實有個很近的檯燈照到文字，再反射到眼睛上。

而不是像平板那種直接在液晶背後發光的「背光」，也就不會有背光為了顯示而必須比環境還亮、造成眼睛負擔的問題了

（當然，如果用前光或檯燈然後跟環境光源差異很大，例如房間超暗檯燈超亮，還是會造成負擔）

大概是這樣，今天認識了「前光」和「背光」。感覺從名字就能看出差異🧐

那我們什麼時候要把電子書的背光打開呢？

基本上開啟前光的時機只有一個原則：當螢幕距離眼睛必須要小於 30 公分才有辦法看清楚字或圖片的輪廓時，就必須要開前光，因為這個時候代表對比度已經太差了，開始要多用眼力與腦力的狀態。

當發現身子不由自主地一直想靠近的時候，應該就是警訊了。就像另一段所說的：

真正造成眼睛過大負擔的其實是近距離長時間用眼，例如字太小為了要讀清楚而拉近距離，或是太暗想看清楚而拉近距離，造成睫狀肌持續收縮得不到休息

不要離螢幕太近！不要離螢幕太近！不要離螢幕太近！
替每次都把整個把臉貼在螢幕上的朋朋默哀

大 Guy 這樣。今天的轉貼就來點豆知識，我們明天見～

今天要推薦的是這篇 CAP 的小故事：
A plain english introduction to CAP Theorem - Kaushik Sathupadi

為了怕有朋友跟我一樣對 CAP 不太熟，這邊先筆記一下。

首先讓我們認識 CAP 各自代表的意思：

• 一致性（Consistency）：使用者總是可以查到最新的資料
• 可用性（Availability）：使用者總是可以正常讀寫，不會突然送你個 Error
• 分區容錯性（Partition tolerance）：即使系統之間斷訊了，大家各自還是得做事，做完還要能同步

CAP 定理是指在一致性、可用性、分區容錯性這三項之中，我們只能滿足其中兩項 :(

通常來說，我們會先拿著 P 確保服務活著，然後在 C 一致性跟 A 可用性之間痛苦地抉擇

例如保證可以操作，但是還沒同步完所以會查到舊資料（AP）；或是被卡著乖乖等到資料同步完才能查（CP）等等

這部分想進一步了解的朋友可以參考最後的延伸閱讀。現在讓我們回到今天推薦的這篇文章

這篇小故事從「幫客人記得事情」的一人公司(?)開始，
隨著客戶數量變多，老闆決定請老婆進來一起幫忙記東西（殊不知這就是分散式惡夢的開端）

他們經歷了第一次查詢失敗危機、想出一些同步機制，然後面對可怕的休假等等

最後…… 結局就留給各位自己看了。

總之，以後有人問起 CAP 的問題，我決定就甩這篇給他們了 xD

延伸閱讀，想多認識 CAP 一點的可以繼續看看下面這些文章：

• The CAP FAQ - henryr
• CAP 定理 101 — 分散式系統，有一好沒兩好 - 後端新手村
• 什麼是 CAP 定理 - puritys.me

那麼，今天的轉貼就到這邊。我們明天見～

剛剛收件閘巡到一篇 Code Review 的文章，感覺挺適合轉貼上來分享給大家：
Code review 的好處與 bad smells - Huan-Lin 學習筆記

我們在 1/13 的時候分享過 Code Review 的這兩篇：

• 從 Code Review 的小事看大事
• Google 教我如何進行 Code Review

經由這些文章，我們能大約知道 Code Review 該看哪些東西，又有什麼好處等等（問就是 FOUR EYES!）

而今天轉貼的這篇 Huan-Lin 大大的〈Code review 的好處與 bad smells〉，則提到了另一個有趣的點：有問題的 Code Review 會有哪些壞味道？

文章裡面列了三項，並且每一項都用了一小段來解釋。這邊就按照慣例，簡單收一下筆記：

• 馬馬虎虎：我很忙，看個意思意思就好
• 合作無間：自個兒人，幫個忙唄
• 粗魯評論：挑毛病、戰習慣、叫你改就改

有採用 Code Review 的朋朋們，也可以觀察一下團隊有沒有提到的這些狀況

那麼，今天的轉貼就到這邊。我們明天見～

最近對「每個人的抽象化思考能力有所不同」蠻有感的。想轉貼之前 vgod 大大的這篇：
追求神乎其技的程式設計之道(七） - vgod’s blog

這個系列真的蠻好看的，但今天推的主要是文章中的這段：

我覺得所有的程式都可以看成一個巨大的金字塔，頂端是這個程式的最終目標，一個模糊的概念；底部是細節的程式碼。

而中間是一個經由不斷切割與抽象化所構成的高塔，每一個程式都是切割為許多的元件、模組，再切為更細的 class 和 function，再來是最底下的變數與邏輯判斷式。

接著讓我們看看像我這樣的菜鳥跟真正的專業人士，他們所看見的「金字塔」有什麼差別：

很有趣的是，不同的人看這個塔就會有不同的樣子。

初學者看到的塔只有兩層，他們和人溝通的方法是鉅細靡遺的描述程式碼：「我在這裡寫個 for，第一次把 i設成 0，在迴圈內每次檢查這個陣列的第 i 個元素…」

在他們眼中只有程式的目標和程式碼本身，所以還可能會寫出下面這種讓人哭笑不得的註解：

a = 1; // 把 a 設為 1

有些經驗後，會再多看到一層，利用 function 把一段程式碼包裝起來，賦予一個名字和獨特的意義。學會這個後，就可以利用抽象化後的 function 名稱來溝通，例如：「我在這個迴圈裡每次都用 isCaptial 來檢查這個字串是不是都是大寫…」

再接下去呢，可以再利用 class，利用 design patterns，利用更大的模組、子系統來溝通，認真說起來，這其實是一個無止境的切割。

隨著我們的經驗增長，我們漸漸可以切出更多的「層」或「模組」，從不同顆粒度的層次去檢視、溝通。這就是抽象化的力量。

最後再截一段我很喜歡的段落：

在資訊科學這個領域，抽象化是個無窮無盡的必要行為。因為世間萬物實在太多太複雜，我們只好不斷把東西歸類，並賦予一個名稱、一個意義，經由這樣的過程我們才能用抽象的語言和符號來溝通，避免每次都要從最底層的瑣碎細節開始說起。

而平凡和偉大的程式設計師，我覺得他們之間的差別就在於能看到多少這個高塔中間的分層。

厲害的高手都很善於切換自己思考的高度，一下能跟你討論高階的系統架構設計，一下又能深入到最底下的組合語言和二進位除錯。他們腦中除了有這高塔每一層的詳盡平面圖，甚至也非常了解不同樓層之間的交互關係。

平凡的程式設計師大多只能專注於自己所開發的範圍，對於其上的架構或其下的細節都不一定能理清頭緒，萬一出現 bug 也會搞不清楚到底是哪一層出了錯，而被完全無關的細節絆住手腳。

希望我們都能擁有更多不同層次的視野，共勉之。

這篇文章的後半段聊了一些被語言的慣例限制了思考方式的故事。

對於這方面，我也推薦 1/10 轉貼過的這篇：
一個語言如果不改變你的思考方式，就不值得學？

每一種語言，其實都是一種對資訊的選擇

那麼，今天的轉貼就到這邊。我們明天見～

今天玩 Azure Function 玩太晚了，11:50 才想起來還沒寫推薦= = 果斷來轉貼一則小技巧
如何讓 Git 可以用一個 git push 同時推送到多個遠端儲存庫 - The Will Will Web

其中我個人最常用的就是這段推送到多個 Remote Repo 的部份：

有時候我們會需要一次推送變更到多個不同的 Git 遠端儲存庫，你其實可以設定一個 git push 命令就能同時推送到兩個不同的遠端儲存庫！

簡單來說就是先看一下 Repo 現在都抓了哪些遠端：

# git remote -v
origin  https://github.com/User/demo01.git (fetch)
origin  https://github.com/User/demo01.git (push)

然後用 git remote set-url 來把 push 時要推的遠端多設一組就好了～

git remote set-url --add --push origin https://github.com/User/demo01.git
git remote set-url --add --push origin https://github.com/User/demo02.git

ps. 記得原本的 origin 也要先設一次，養成良好習慣 :)

我體感上這個實用小技巧還蠻常(?)用到的啦，分享給大家

團隊這幾天有發生需要回顧的問題，馬上收到這篇。剛好拿出來推給各位朋朋：
Postmortem Culture: Learning from Failure - sre.google

The cost of failure is education.

什麼是事後檢討（Postmortem）？什麼時候要寫？

事後檢討就是在翻車之後，把「我們翻車了，翻了三圈半、我們都幹了些什麼來把車翻回來、到底為什麼會翻車、後續要怎麼避免翻車」等資訊記錄下來的東東。

The primary goals of writing a postmortem are to ensure that the incident is documented, that all contributing root cause(s) are well understood, and, especially, that effective preventive actions are put in place to reduce the likelihood and/or impact of recurrence.

寫一份事後檢討的主要目標是確保事件被記錄下來，所有貢獻的根本原因都被充分理解，尤其是要採取有效的預防措施來減少再次發生的可能性和/或影響。

那什麼時候會需要寫檢討？這篇文章列了幾個狀況：

• 一定比例的使用者不能使用
• 掉資料
• 工程師被叫去 on-call 退版
• 花了有夠解還沒處理完問題
• 監控整個失敗，拖到被人發現

無責任文化

既然都要寫檢討了，大多時候就是有事情搞砸了。為了不要讓寶貴的學習機會淪為情緒發洩和攻擊別人的場合，這篇文前半段就開始提了「無責任（Blameless）」

用我們比較熟悉的話來說，就是「對事不對人」，把目光放在「我們的服務哪些方面還可以改進」，藉此得到變得更強大的機會

從另一方面來說，如果放任大家互咬、培養出互相指責的扭曲文化，那很多問題就會被蓋牌，這樣其實更危險🤔

For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior.

為了使事後檢討是真正無責任（Blameless）的，它必須專注於確定事件的發生原因，而不指責任何個人或團隊的不良或不適當行為。

A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had. If a culture of finger pointing and shaming individuals or teams for doing the “wrong” thing prevails, people will not bring issues to light for fear of punishment.

一份無責任的事後檢討假設參與事件的每個人都有良好的意圖，並根據他們所擁有的信息做出正確的決策。如果存在一種指責和羞辱個人或團隊做出“錯誤”決策的文化，人們將因為害怕受罰而不敢揭示問題。

補充：如果想要看一些反例，可以讀前陣子的這篇〈迷失在阿里雲的年輕人〉裡
「濫用的 Code Review 和故障復盤」這一小節。

事後檢討的審查標準

寫完檢討書 v1 之後，會先在團隊內請資深工程師幫看一下 O 不 OK。要看的點有：

• 相關的資料有沒有被收集起來給後人參考？
• 影響評估有沒有完整？
• 根本原因的分析有沒有足夠深入了？
• 後續的行動計劃和修復工作都列好了嗎？有排好優先順序了嗎？
• 我們有沒有跟利害關係人（stakeholders）說過結果了？

都搞定之後就可以開始散佈出去了，希望其他人能從我們翻車的姿態中學會教訓。

Wheel of Misfortune!

這句有點咒語的 Feel，不知道怎麼翻，「衰鬼之輪」嗎？

後半段一些文化相關的東西，像是讀書會、每月檢討等等的都很平常，但這個輪子還蠻有趣的

基本上就是大家（抓著新來的菜鳥 SRE）一起，把過去的某次事故報告給調出來，現場就開始當劇本來跑團：

New SREs are often treated to the Wheel of Misfortune exercise (see Disaster Role Playing), in which a previous postmortem is reenacted with a cast of engineers playing roles as laid out in the postmortem. The original incident commander attends to help make the experience as “real” as possible.

新進的 SRE（網站可靠性工程師）通常會參與「厄運之輪」的練習（參見災難角色扮演），在這個練習中，以前的事故回顧會被重新演繹，工程師們扮演著事故回顧中所規定的角色。原始的指揮官也會參與其中，以盡可能使體驗更加「真實」。

事故還可以放個幾年之後拿出來當桌遊(?)，有種挺歡樂的感覺。這樣我很願意好好寫檢討書耶 xD

今天嘗試用新的格式來推薦，本來想說看能不能縮短每次整理心得的時間

不過反正每次要打利害關係人，都會打成厲害關西人，選字的時間就比縮短的時間久了，根本沒差= =

今天朋友丟了卡米哥大大的另一篇文章給我，立馬選擇轉貼上來：
軟體開發者的價值 - 卡米哥

身為一個軟體開發者，我一直以來都想知道我的價值到底在那裡。在我長期的觀察和思考，終於有了一個初步的答案，若站在老闆的角度來看，我的價值其實就是我寫下來的程式碼總共幫老闆賺了多少錢。

因為老闆僱用你，就是希望你可以幫他打造一台自動賺錢機器，然後靠機器運轉來達成自動賺錢。若要深入探討的話，我想先談談什麼是價值，以及什麼是程式語言，從思考一行程式的價值開始，到思考軟體開發者的價值。

從這個出發點開始，作者大大一路思考：什麼是價值？什麼是程式語言？程式的價值呢？開發者的價值呢？

其中一個思路我覺得不錯，那就是「程式的價值 = 執行次數 * 執行一次生成的平均價值」，
也就是說：程式執行是會賺錢的（當然有些程式的價值可能是負的 xD）

而我們軟體開發者，就需要運用技術力來讓程式能夠繼續跑下去、繼續賺更多錢。
所以，開發者提升開發速度、提升程式碼品質等等，都是在提高讓程式能繼續跳表(?)的戰力

這個觀點也能夠解釋為什麼我們應該追求上一篇文章提到的那些價值觀（程式碼品質、維護成本、修改成本等等），因為這些都影響了我們產出的價值

此外，還有幾個我特別標記的點。其中一項就是關於技術債的部份：

在我之前的工作經歷當中，大部分時間是在做新創公司的案子，而新創公司的客戶數通常趨近於零，我曾經開發並且上線一個新的網站，卻始終沒有用戶真的去使用，經營了一兩年，結果測試環境上的資料還比正式環境上的還多，在這種情況下，即便程式的效能再好，沒人來使用的網站所產生的價值其實是趨近於零。

= 沒有人在用的程式，產值是零

當時是案主付錢委託我們開發網站，所以我們有收到錢，只是網站並沒有替案主賺到錢。我們採用的技術很好，自動測試也寫的很完整，卻做出了一個垃圾，而在此同時，我接了另一個案子的長期維護，這個專案裡程式的架構很亂，欠了一堆技術債，而且都沒寫測試，但是客戶人數足夠而且一直有下訂單，所以反而這個案子就有在賺錢。

= 即便是充滿技術債的程式也能產生價值

我發現像我這樣的菜鳥常常會有一種迷思：這專案的技術債有夠多！真沒價值！

但不是這樣的，並不是臭不臭就可以斷定程式的價值。只要這個專案還是收入來源，它其實就還在產生價值。你養蟲，蟲也養你

就像泳池的收入並不是取決於裡面的尿多不多，而是進來游的人多不多嘛

而我們的目標就是用我們的技術力和解決問題的能力，替它排除更多的障礙、讓它繼續產生價值，然後把錢帶回來給我們(?)

那如果我們做不到呢？例如上頭就是想要你寫一些沒人用的東西？

雖然你在一家公司內可能不能決定要寫什麼程式，但你可以選擇要去哪一家公司寫程式，去能被執行最多次，且單次執行所生成價值最高的專案寫程式，則可以最大化自己的價值。

沒錯！是時候歡迎我們 2/27 推薦過的這篇「上游思維」的結論：

1. Change your company, or
2. Change your company.

那麼，今天的轉貼就到這邊，明天見～