今天來個靠北軟體工程師專屬的辦公室英文吧! 相信大家寫程式的時候, 都有 code review (稱為程式審核或代碼審核) 的經驗. 所謂 code review 就是寫好的程式給組裡另外一位工程師看一下, 給個意見. 這算是軟體界一種學徒制的變形, 寫程式當然是寫完請其他的工程師看一下, 廣納意見, 學得最快.
Code review 在我的組裡還有另外一層意義: 我的組是寫開源 framework (就是類似 React, Django 這樣, 開放給其他人使用並自由更改的 framework, 當然我們沒那麼有名啦). 像我們這樣有開源的組, 會有另外一種 code review 的狀況: 就是非本組組員的 PR/merge request (其他人寫的東西很不錯, 想要併入 framework 本身). 例如: 我們的 framework 也有公司內其他組的人在用, 當我們想鬼混…ㄟ不是, 人手不夠的時候, 其他組的人寫了好用的功能, 大家也覺得非常棒, 乾脆就併入 framework 本身, 不就很理想嗎? 這時候其他組的人就會送 merge request (就是他們寫的東西要放進 framework 之前, 先給我們過目的程序). 這一類的 code review 當然不能大意啊~ 過程動輒幾星期到幾個月都有可能.
然後身為軟體團隊的主管, 我就常常接到其他 team 的主管來打 pass, “那個 xyz merge request 拖了好久耶, 可以請你們動作快一點嗎?” 我們也是很想快, 但是 framework level 的變動, 每一行都要仔細看, 需要時間的啊! 一看到有 regression 的可能, 還得跑 regression tests 才行呢! 必須說如果不熟 framework 本身的設計架構跟目的, 一切看起來都 ok 卻在 regression tests 敗掉要重改, 是很常見的. 雖然這樣, 我們也不想要太吹毛求疵, 因此有些評論會在前面加一個 “Nit:”
Nit 這個詞來自於 nitpicking, 中文是”吹毛求疵”. 所以加在 Nit 後面的那一段, 就是”小小建議”的意思. 也就是說, “我這樣建議是吹毛求疵啦, 你不一定要改”這樣的意思. 這個詞在軟體業界非常常見, 谷歌的 code review 標準都有提到. 但軟體界之外不建議使用, 應該沒人看得懂?
[同場加映]
話說我怎麼這麼無聊, 一個 Nit 寫這麼多? 算是新年剛開工, 大家都工作很懶散(疑?), 多聊個兩句…我是不是應該斜槓農場文章比較對 haha 上面的圖片我把組員的大頭照換成歷史人物. 今天就來看兩個跟電腦科學有關的歷史人物:
布莱兹‧帕斯卡 – Blaise Pascal
法國科學家, 神學家, (還有一大串其他名號), 對於計算機的製作有重大貢獻. 大家知道電腦最早期大部分是拿來當數學計算機用的吧. 來, 自己去讀維基百科: https://zh.wikipedia.org/wiki/%E5%B8%83%E8%8E%B1%E5%85%B9%C2%B7%E5%B8%95%E6%96%AF%E5%8D%A1
愛達·勒芙蕾絲 – Ada Lovelace
英國數學家, 她最有名的作品是幫當時的計算機(稱為 Charles Babbage’s proposed mechanical general-purpose computer) 寫了演算法, 是公認史上第一位軟體工程師.
https://zh.wikipedia.org/wiki/%E6%84%9B%E9%81%94%C2%B7%E5%8B%92%E8%8A%99%E8%95%BE%E7%B5%B2
在另外一篇辦公室英文裡, 有提到 Charles Babbage 這號人物, 現代電腦的設計很多源自於他發明的機器.
Leave a Reply