Jasonmel Blog - Page 18

去年八月，孩子知道爸爸會寫電腦程式後，就提議要來設計一款電腦遊戲。過程中，許多原本天馬行空的想法，請孩子想清楚規則之後，才能轉化為單純的 if-else，幾經修改之後才成了現在的版本。今天，在 GUI 版的圖片上完色之後，孩子表示可以 release 了，那就放到 github 上吧！新手出品，還請多多指教！

斷斷續續把超厚重的《破解基因碼的人（The Code Breaker）》讀完，有一種未來就在眼前的暈眩感。

全書以 2020 年諾貝爾化學獎得主珍 Jennifer Anne Doudna 為主軸，串起從 DNA 的發現、基因定序、基因編輯與治療、甚至是胚胎基因的改造，種種的精彩過程。所有的科學進展，都在一次次的科學競賽當中，加速前進。

2018 年，人類第一次的基因編輯嬰兒在中國誕生，新生兒基因當中的 HIV 受器基因被移除，獲得終身對 HIV 愛滋病病毒免疫的能力，而且能代代遺傳下去。雖然主事者賀建奎後來被法院判決關了三年、罰款 300 萬人民幣、並且終身不得從事生殖科學研究，但這也表示，人類技術早就能解讀並任意修改基因，只是還不敢放手這麼做而已。

這當中衍生的倫理道德與社會議題，需要時間來取得共識。畢竟，一旦基因編輯開放，有錢人一定都會想盡辦法把自己的兒女改造成完美無瑕的人，並且代代相傳下去，造成社會愈來愈不平等。另一方面，要是基因編輯過於普及，到頭來全世界的人就只剩下最強的單一品種基因，差異化變小，人類面對環境變化的能力就弱掉了。

從另一方面來說，針對像是 HIV、鐮刀型貧血症、阿茲海默症等等，這類很明顯不利於人類的基因進行編輯，難道有錯嗎？我們明明已經有能力處理，卻不去處理掉這些壞基因，讓這類病人一輩子活在痛苦之中，對這些人公平嗎？

基因要改與不改，當中的界線如何拿捏，都是人類需要好好思考的。核彈已經備妥，就看什麼時候要按下發射按鈕。

關鍵字：CRISPR-Cas9。

計畫中陪舅舅去走的草嶺古道之旅，天公不作美，還是硬著頭皮上路。

有了三年前的經驗，這次改變策略，從福隆車站出發，先買好福隆便當做為午餐，然後搭計程車直達步道口 (標準價一趟 200 元，可先和司機談好要進去到步道口，而不是只到遠望坑親水公園的廁所)，節省一個多小時的腳程。

幾乎全程下雨的情況下，出發沒多久鞋子就濕透了，姑且就盡情踩踏，放給他濕透吧！雨中的深山，別有一番滋味，讓人回想起大學時期去爬奇萊南峰的感覺。接近啞口時，由於接近中午，又難得遇到一個涼亭，就前往午餐。啞口附近如預期般風勢增大，索性還有很多山友作伴，大家就在根本擋不了風雨的涼亭下，一起背對著風雨，排排站著吃便當，有點克難又有點好笑。狂風挾帶著雨水之下，在虎字碑和啞口拍一些照之後，匆匆下山。由於比預期還早很多抵達終點大里車站，便臨時起意前往舅舅原定隔天要去的雙溪荷花園。陰雨綿綿的荷花殘枝倒影，正是舅舅想追逐的景象，完美！

風雨中的虎字碑自拍。

別有一番風味的荷花殘枝倒影。

軌跡記錄。

來聊聊 Google 的 code review 文化。

在 Google，要 submit 一個 CL (changelist, 等同於 git 裡的 pull request)，需要經過三關的 code review：1. 自動化程式 review, 2. team/project review, 3. readability review。第一關，由程式或 AI 就能針對不同面向，自動從 CL 裡面挑出一些顯而易見的錯誤，或是可以改善的地方。第二關，就好理解多了，主要是由 team members 去針對功能上部分做檢查。第三關，會依照 CL 裡面用到的語言，而需要請該語言的大神們來 review (由系統自動指定)，針對程式語法上可以改進的部分，給予建議。基本上這是蠻好的機制，強制大家都遵守同一套 coding style，以及套用一些像是 Effective Java 或是 Effective Dart 之類的 best practice。總之，就是無所不用其極地，避免各種髒 code 進到全公司共用的 monorepo 當中。同時，在神人們的指教當中，自己也能從中學到許多實用的技巧。

然而，這不是沒有代價的。這樣嚴格的把關，尤其是 readability review，勢必會大幅拖累開發的速度。有時候，當 reviewer 是其他時區的人，如果不巧對方又是個大忙人，一來一往可能幾天甚至一個多禮拜就過去了。再者，有些 reviewer 的標準之高，到了一種近乎苛求毫無道理的地步。舉例來說，常會有 reviewer 要求所有變數、函式都要寫 comment，即使變數名稱或函式名稱本身已經很清楚地說明了它的用途，於是就配合寫上跟變數名稱或函式名稱很像的 comment，然後又會被要求要多補充一些額外的資訊，不然乾脆不要寫，於是就得硬著頭皮再去扯一些可有可無的東西硬塞到 comment 裡。而 comment 的用字遣詞又暗藏了許多潛規則，像是 boolean 變數的 comment 一定要用 "Whether" 開頭、函式 comment 一定要以第三人稱單數的動詞開頭之類的，繁族不及備載。另外，有時還會遇到不同 reviewers 持相反意見的情況。而有時也會遇到 reviewer 對於選用的 solution 發表意見，早已超越了 readability 該審核的範圍，你如果不照他的建議調整他還不太高興，把你的 readability 分數扣分 (readability 分數是用來晉升到大神的主要參考依據。像我們這種初階平民，如果未來想要晉升大神去幫別人 review code，就要透過不斷 submit code，以獲得足夠多的大神們的分數累積後，才得以晉升)。不誇張地說，整個開發時程，大約只有 1/3 在寫主體，另外 1/3 在寫 test cases，還有 1/3 在搞 code review，而後兩者往往還會佔掉更多比例。

總之，這是一套有利有弊的機制，整體來說絕對是利大於弊，畢竟這麼大的公司，這麼多複雜的系統，實在容不下一點點的污點。這個世界上，能把 code review 做到這種地步，全公司上下都對程式品質苛求到一種變態的程度的，大概也只有 Google 了吧。

進 Google 以來，一直想記錄點什麼，但想記錄的東西好像都散散的，總覺得要累積多點東西，再系統性的整理一下，比較完整。可是時間一長，又有點擔心這樣累積下去，該不會最後就什麼都沒記錄下來。所以不管了，想到什麼就紀錄一下吧！

來聊聊最近的事，每年的這個時候，公司都會有個 Holiday Giving Campaign 的活動，提供每一位員工 US$400 的額度，去捐獻給想要支持的非營利組織。這就體現了一種公司隨處可見的 bottom-up 文化。可能公司本來就有一大筆預算要拿去捐獻，但問題是這麼大一筆錢，面對全世界成千上萬個非營利組織，要捐給誰？要怎麼分配？這實在太複雜了，乾脆交由每位員工去選擇，於是員工就會自己去研究，並在公司內部推廣自己認同的組織，由員工拿著自己的額度去捐獻給自己認同的組織。除了變相達成了群體決策讓資源做最有效的分配，也讓員工多了一些參與感，同時多去認識一些世界上需要關注的議題。

類似的概念，在公司裡還有 peer bonus 的制度。每一季，公司允許員工發送 5 次 peer bonus (NT$3000/次)，給對於自己或團隊有額外特殊貢獻的同事表達感謝。這讓有好表現的底層員工更有被實質認可的機會，也變相讓公司省下不知道該獎勵誰的困擾。

還有，像是大型會議的 Q&A，都會事先用一套 Dory 的內部系統來搜集問題 (曾經一度公開為 Google Moderator，後來又關掉，員工乾脆自己出來開了一間公司)，再由員工來投票，讓重要的議題在集體決策下浮上檯面。

類似的 bottom-up 的集體決策機制，幾乎可以說是整間公司的 DNA 了。我想這也跟公司最一開始的基礎 PageRank 搜尋演算法有關，利用網頁之間相互的集體決策，就能自動產出最好的搜尋結果。同樣的概念，很多東西一旦去中心化，就會有一隻看不見的手，自動調整出最好的資源分配。

懂的放手，反而能獲得所有。