2019年4月6日星期六

約耳趣談軟體 筆記一

前言

第一本非理財類既書既筆記, 而且我都五記得我由邊到知道呢本書. 不過, 我諗無乜人在意呢件事…. 所以我都係開始寫返我既筆記. 呢本係翻譯書, 作者就叫約耳. 約耳趣談軟體, 大意就係作者對自己業界既分享/調侃.
本書大部份內容都係由佢個BLOG到剪出黎. 識英文既朋友, 我建議大家都係買返英文版或者直接上佢個BLOG睇, 因為中文版實在譯得麻麻地, 詳見下面讀後感.

讀後感

雖然書中大部份內容均有十年既歷史, 但是大部份既觀點與建議依然適用於現今這個行業. 不過, 翻譯果個就麻麻地. 襯感受猶新, 我決定先行紀錄那些”有點東西” (最近睇TOYZ, 花輪台學返黎既) 的句子.
前23章睇既內容都有種異樣既違和感, 行文用字硬係有點突兀. 不過, 總體來說也不致令我有衝動查閱譯者來頭. 直到見到24章既神聖的垃圾, 我當堂打左個突: 你個翻譯夠竟係乜野水平.
馬上睇返譯者簡介, 譯者居然係在職資安碩士, 仲要係約耳官方認可之一. OH MY GOD …. 他媽的, 這一定是譯者個人風格, 本著忠實反映約耳用字既譯法黎.
本著上面既直譯風格, 讓我們繼續看下去, 同一篇BLOG就出現了真他X的醜… 佢今次無直譯, 反而譯返道地既台灣形容詞 … OK, 我放棄思考了.
除了上述我覺得比較離譜的譯文之外, 其餘的譯文都中規中矩, 沒有那些令我留下特別深的印象.
後話, 如果比我譯HOLY MESS 既話, 我會譯做他媽的一團糟或者亂糟糟的. 它們都比神聖的垃圾更貼近原文語意.
講完翻譯既問題, 就講過時既內容問題.
約耳既過期既原文寫於2000年3月, 而更新左既文章則寫於2007年既10月. 係原文既網址上, 約耳亦都清楚指出新文既做法比較好, 我們應該睇新文既做法.
我睇既中文版本為首版四刷, 出版時間係2011年8月. 這裏足足有接近四年既時間讓出版社以新文替換掉原文關於時程既作法. 但是, 出版社既四刷依然在列印過期既時程內容. 請問一下, 再刷的意義何在? 過期既內容不用更新的嗎? 這樣的出版社好像不太靠譜的吧?
還好, 這書我是借圖書館的, 一蚊都五洗比. 如果五係, 呢一本譯書係第一本我想退錢既書.
好. 廢話就講完, 係時候MARK 返D筆記.

普及Unicode既教程 (原文)

坦白講, 去到2019 既今日, 我都係五識unicode. 直至睇到約耳講返unicode既歷史, 同用途, 我先有豁然開朗既感覺. 難怪窮查里的普通常識一書指出, 要學習一門知識最好先看背後既歷史. 長話短說咁講, UTF-8係最常見既字串編碼方式. 寫CODE時, 如果無特殊既需要, 我地都應該用UTF-8.
題外話, UTF-8 能夠在多款編碼方式中跑出, 成為業界常見既做法, 其中一個理由應該係佢既Backward Compatibility. 另一個隨筆[雞生蛋蛋生雞一文中][egg_chicken]就論述左向後兼容既重要性, 以及向後兼容對客戶接受度既影響.

邁向高品質編程既十二個步驟 (原文)

這12步驟構成了一個簡單既評核機制. 約耳用它們來評估軟體開發團隊既運作/執行效率. 每個步驟既設立原因, 操作流程就請讀者去睇返原文, 這裏就不再覆述. 反而, 我想補充下關於執行呢十二條步驟上既問題.
如果你係公司位高權重, 你可以直接跳落去下一點, 因為根本無人可以阻擋到你想推行既政策. 相反, 如果你係SMALL POTATO, 但又想提升團隊既編程水準, 我建議你睇一睇約耳呢一個BLOG. 簡單黎講, 就係由自己做起, 然後讓其他同事感受到這十二個步驟既優點, 繼而說服他們支持你既革命. 一旦其他同事應同你既做法, 再一起向管理層革命, 成功既機會率便會大大提高.
2019年既今日, 我推介gitlab 比咁多位有志革命者. 一套免費既軟件, 簡簡單單咁集DEBUG DATABASE, SOURCE VERSION CONTROL, DAILY BUILD 等功能於一身. 當然, 你都可以用github既服務. 不過, gitlab本身免費提供PRIVATE 既repository, 反而github 免費提供只有PUBLIC 既repository. 如果, 你公司對擺CODE上網非常過敏的話, 可以自行架設LOCAL 既GITLAB SERVER.

軟體開發時間表 (原文)

在商言商, 軟體開發時間表既管理非常重要. 不過問題是, 軟體既開發時間表表跟政府工程竣工時間一樣, 經常被一拖再拖, 沒有準確度. 故此很難說服程序員去編寫一份連自己也不相信的時間表.
約耳在此提供了一個Evidence Based Scheduling 既建議, 原理與做法就請參閱原文, 這裏就不再詳述. 我覺得聽落都尚算可行, 所以決定親身實驗一下呢個做法. 有機會再係到更新返呢個做法有無效.
想同我一齊實驗既朋友, 我比個現成既EBS EXCEL大家, 省郤大家起呢個EXCEL 時間.

點解要寫同如何寫SPEC

Painless Functional Specifications 開頭既BLOG POSTS. 約耳講述寫SPEC既重要性, 同示範點樣寫出一個有用既SPEC.
我大致明白佢寫SPEC既概念, 不過問題係, 佢實際演示既做法, 我執行上亦都相當花時間, 以及我預計五到有咩實際得著. 日後有機會既話, 再係到更新相關心得

仲有既係…

我特別有感受既BLOG POST 都寫哂係上面, 以下係我覺得有得著既BLOG POSTS, 不過我未諗到有咩特別感受要追加, 所以就單單列出它們既網址. 日後有機會既話再寫筆記跟進

推介既書

  • 人月神話 (the mythical man month)

沒有留言:

發佈留言