簡評三十四

Shared Code:讓我們變成博格人吧

  • Sharded code 嘅好處
    • 高品質的 source code
      • 怕被人笑寫爛code
    • 提高工作分派的彈性
      • 個個都有掂過下唔同野
    • 提昇開發人員的技能
      • 輪流做唔同嘅野,互相學習寫嘅code
  • 引入Shared code嘅步驟
    1. 開頭按專長同興趣分組
    2. 引入CI
      • 確保唔同人寫嘅code可以integrate到
    3. 要求寫unit test
    4. 等系統雛型大致穩定之後,鼓勵大家 pair programming
      • 最少一到兩個月
    5. Keep住,直至每一個模組至少都有兩個人非常熟悉

停掉生產線

  • 產品的品質在做好之後便已經決定了,更多的測試並不會增加產品的品質,所以要提昇產品的品質便需要提昇產品製作流程與流程中的每個活動的品質。
  • 以『符合人性的方式』改善方法或是開發流程
  • Stop the Line(停掉生產線):
    • 如果一發現不良品,就馬上停止整條生產線,一直到找到問題的根源 (root cause) 為止
    • 如果不徹底找出產生不良品的原因,這些生產出來的不良品都是浪費
    • 好處:
      • 提高警覺
        • 由於一發現 bug 需要暫停所有人的工作,所以大家都不會希望這個 bug 是自己造成的
      • 提高共識
        • 所有人一起找出原因並且討論,對改善方案有共識

你的軟體架構有多軟

  • Agile methods 倡導 iterative and incremental development,因為:
    • 軟體專案不必也沒辦法等所有需求都確定才可以開始,因為:
      • 三心二意的客戶以及劇烈變化的市場隨時都可能改變需求
      • 客戶的需求通常在他看到或用到軟體之後會越來越明確
    • Agile 嘅軟體架構中心思想
      • keep irreversible decisions to a minimum and provide a framework that supports iterative development

軟體庫存

  • 軟體庫存係指未可以為user deliver value嘅task
    1. 部份完工的功能(partially done work)
    2. 額外功能(extra features)
    3. 過度設計(over design)
  • Agile 就係想減少庫存,盡快deliver俾user,費事夜長夢多,requirement change而做成更多浪費

Problem Domain vs. Solution Domain

  • Problem Domain: Software requirement
  • Problem Solution: Software design and implementation
  • 提醒自己概念是屬於 Problem Domain 或是 Solution Domain 有助思考與分析
  • 點解Software design 同 implement唔可以分開2個phase,要不斷iterate
    • 由於 Problem domain (requirement) 不斷改變 Solution domain (design) 需要不斷改變
    • Architect 需要得到design嘅feedback,不斷修正 design,所以需要參與implementation

老闆,軟體不是這樣開發滴

  • 『可預測性』卻是改變人們生活習慣的主要因素
    • 架車有時用10分鐘就到目的地,有時需要40分鐘
      • 為左準時到埗,乘客每次都要預40分鐘
      • 倒不如搭一架每次都要30分鐘嘅車
    • Predictable 帶黎 Reliable

Ten-Minute Build

  • Extreme Programming Explained: Embrace Change 提到
    • Automatically build the whole system and run all of the tests in ten minutes.
      • A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback.
      • A shorter build doesn’t give you time to drink your coffee.
  • 減少build time嘅方法
    • 用錢買好D嘅hardware
    • 改善build script
    • 調整要執行嘅test cases
      • 先行unit test
      • 要耗時較長嘅test係平時唔run,但要保證每日最少行一次完整嘅test case

例外處理之錯誤訊息描述:HTC One X拍照篇

  • 使用者認為的bug,不一定真的是程式邏輯的錯誤
    • 可能只是使用者不清楚程式內部運作的context或是precondition。
  • Tips on handling use message
    • 從使用者的使用情境來思考
    • 當錯誤發生時儘量顯示對於使用者有意義的訊息

找不到資料要傳回Null還是丟出Exception?

  • Exception在程式語言中用來代表error與failure,分別表示
    • 「目前可能處在不正確的狀態」
    • 「被呼叫的服務或函數辦事不力」
  • 尋找資料的函數正確執行完畢,只不過沒有找到符合查詢條件的資料罷了。
    • return null or null object

從軟體開發看河川汙染問題

  • 如果軟體的品質很差,增加更多的測試人員,並不會改善軟體的品質
    • 寫code嘅人唔care品質,檢查嘅人再努力都無補於事
    • CI/CD,pair programing,TDD/BDD,都係將software qualify嘅責任放係developer嘅身上
      • 令到Developer有改善嘅動力
  • responsibility assignment

讀了套用Pattern的程式碼,會不會見樹不見林?

  • 正確使用Design pattern,可以令複雜嘅系統更有規律,應該會容易明白左
    • 就算冇用Design pattern,複雜嘅系統本身就會令人見樹不見林,用左pattern 情況唔會更差
  • 點樣解決見樹不見林?
    • 幫系統建立起軟體架構區塊圖(architecture block diagram)
      • 就好似城市嘅地圖一樣
    • 寫各種不同層次的測試