Clean Code Craving

在 Dcard 上發了一篇文結果引起超多網友回應想要看試算表，我就來整理一下我追蹤台股用的 Google 試算表給大家。 這個試算表我目標是以 "簡單" 為主，底下我也會講解公式的運作原理，希望大家能以此試算表輕鬆擴充自己想要的功能。 功能 未實現損益 (Unrealized Gain/Loss 表) 不管同一支股票是不是有部分已經賣出，只要你還持有未賣出的股票這邊都看的到。 已實現損益 (Realized Profit/Loss 表) 我過去的績效如何? 在這個表一目了然。 未實現損益: 詳細資料 (Unrealized Stats 表) 我還持有多少股? 每股市值多少? 每股的成本是多少? 在這個表可以快速追蹤。 手機友善 (Mobile Friendly) 我為了在手機上也可以快速看我想看的資訊，把 "Unrealized Gain/Loss" 做成比較窄的版型。 只要下載 Google Sheets app 打開試算表就可以了。 Google Spreadsheet 連結 Google Drive 連結 Stock Tracking 使用方式 請先點 "檔案" -> "建立副本"，copy 一份試算表到你自己的 Google Drive 將 "Current Price" 表單中填上你想要追蹤的股票代號和名稱 將 "Transactions" 表單中刪除範例資料，但請務必留下第 2 列 (因為有公式)，然後慢慢往下填入你的資料 Step 1: 檔案 -> 建立副本 Step 2: 新增/刪除股票代號和名稱 (紅框圈起處)，灰色底欄位代表有公式 Step 3: 在 "Transactions" 表填入資料到白色底欄位 (紅框圈起處)，灰色底欄位代表要讓公式自動計算 未實現損益的正確算法 其實在發 Dcard 文之前我自己也像 另外一個表單 犯了同樣的錯誤，就是只有在股票全部賣光光 (持有 0 股) 後計算的未實現損益才會正確。還沒全部賣光怎麼辦? 難道就不顯示了嗎? 飲料的例子 只要股票中途賣出一部分，目前還持有部分股票的話，感覺計算就突然變得很複雜。但不用怕，我們來用飲料當作股票舉個超簡單的例子 (1 杯=1...

上次 用 Google Apps Script 做的 side project 就比較商業化，這次來做一個比較有趣的 side project 。上次比較可惜的是沒有完整記錄做 side project 的過程，這次我從 idea 到做完的經過都把它紀錄下來，跟大家分享一下做這個 side project 的種種過程與挑戰。 最終成品 直接用一張 GIF 展示最快 (28MB 看不到請等他一下): Online Demo:  https://sc420.github.io/jellify-ur-website/ GitHub:  https://github.com/sc420/jellify-ur-website Idea 發想 做 side project 最難的就是無中生有，做人家做過的好像就沒什麼挑戰，做人家完全沒做過的也不知道能不能做出來。 一開始的構想 其實一開始我是想做 ANTLR + HTML canvas 的 side project。因為公司剛好也正在做 ANTLR 來 parse 一些東西，但對於這個 library 不熟自然就想多玩玩看，想說藉著 side project 也可以練習到。 不過 ANTLR 能做的事基本上還是要 parse 一種程式語言，不管是 C++ 程式碼還是 JSON 甚至到自訂格式的計算機。想了想覺得如果要用網頁的方式呈現還是對大部分的人有點生硬。 原本是想說讓大家在網頁上隨便輸入一串 JavaScript，讓大家一步一步看他被 syntax highlighting 的過程。後面想說更有趣的話我可以搭配 canvas 和變成考題的方式，類似之前有看過 JavaScript quiz，輸入正確的 JavaScript 否則寫錯的程式碼就會在網頁上炸開來。 如果要讓字母爆炸就代表我需要自己知道 JavaScript 每一個字要上什麼顏色，就會需要 ANTLR。要爆炸需要一個物理引擎。 延伸的構想 後來覺得實在太困難，ANTLR 我又不熟、物理引擎我也不熟，這樣兩個不熟加起來就很容易做不出來，而且好像也不太有趣。 但是為了調查能不能做出來的時候我有跑去看一個找到的物理引擎 Matter.js 的 demo，還有看到 Matter.js GitHub 的 gallery 那邊也有大家有趣的應用，看到一...

前言 很多敘述都是說 100% code coverage 雖然可以達成，但是會花非常多時間，所以往往 project 的 code coverage 都設定在 80-90% 左右。 但這前提是 source code 非常亂的情況下，才是 true。 現在我習慣讓新 projects 達到 100% code coverage，並不會多花時間，反而減少了許多 bugs，而且整體上程式碼也變得非常好讀，甚至讓任何新人進來看都看得懂。 我用一個簡化的 python 例子來描述怎麼做到這件事。 100% 不合理的案例 現代化的軟體通常少不了與外部軟體的整合，所以我們可以設計一個簡單化的 application: 用 REST API 取得某個使用者的發文 把 raw data 轉成 application 內部 data 用一些邏輯去搜尋發文 就會寫出下面這樣的程式碼，看似簡單: # complex_find.py from dataclasses import dataclass import requests @dataclass(frozen=True) class Post: id: int title: str body: str def find_posts_with_keyword(user_id: int, keyword: str) -> list[Post]: # Get a list of posts with REST API base_url = "https://jsonplaceholder.typicode.com/posts" params: dict[str, int] = {"userId": user_id} response = requests.get(base_url, params) try: response.raise_for_status() except requests.HTTPError as e: raise RuntimeError(f"Failed to call API with params: {params}") fr...