應用軟體開發 7 宗罪

如何提高應用軟體開發的產出

7項應用軟體開發流程的錯誤

  1. 軟體規格書缺乏使用情境的資訊
  2. 軟體規格書缺乏對時間事件功能性驗証的描述
  3. 不合時宜的招募策略與分工方式
  4. 不知道該如何評估成效
  5. 過早的最佳化
  6. 分不清楚 simple 與 easy
  7. 盲從潮流、執著於教條

缺乏使用情境的資訊

我曾經被案主委託過一個軟體開發案,案主最初與我詳談的重點,全都放在使用者界面,他不斷地告訴我,使用者界面 (UI) 對他來說,超級重要,沒有好的 UI,團隊的工作是如何如何地受影響;之後的功能都可以日後再討論,先請我無論如何幫他把 UI 刻出來搭配一個簡易的 CRUD (create, read, update, delete) 功能。過了兩個月後,案主則告訴我,使用者界面不太重要,報表可以用 Excel 的格式下載即可。後來,我才理解,其實該專案最核心的價值創造部分,在於產出商業智慧 (Business Intelligence) 的報表。以這個案例來講,如果讓我重做一遍,軟體規格書最初描述的重點,自然是先放在最關鍵的報表部分。而我後來自己檢討,是我自己沒有想清楚,因為該案主就是 BI 團隊的負責人,

軟體規格書缺乏對時間、事件、功能性驗証的描述

客戶有時候會用不適用的工具,來試圖描述所需的軟體。我曾有一位客戶,總是指派他信任的下屬來寫規格書給我。這些規格書往往是用 PowerPoint 寫的,對使用者界面的部分,描述過多的實作細節,卻完全沒有描述遠比使用者介面更重要的:時間, 事件, 功能性驗証。我拿到規格書之後,看到許多的 UI 元件,UI 元件描述了它們該做什麼,卻沒有明確地講清楚先後次序與 UI 事件發生彼此的依賴關系,這就是缺乏時間與事件的描述。

不合時宜的招募策略與分工方式

有一些中小企業認為,既然大公司招募軟體工程師考 codility 或是 leetcode ,我們也應該如此做,才能招募到能力優秀的軟體工程師。然而,大公司由於開出的薪資偏高,一旦有新職缺,應徵者相當多,所以先用白板考的方式,快速篩掉大量的應徵者,以集中有限的資源來面試剩下來高可能性的應徵者。中小企業如果沒有理解上述的方式是一種權宜之計,而單純地認為,善長白板考就等於專業能力,很可能會在招募上遇到許多挫折。

不知道該如何評估成效

在『彼得原理』對於「不知道該如何評估成效」導致的狀況,有獨到的見解:不適任的主管在評估下屬時,是以下屬在工作投入 (input) 的程度來評估;因為該主管已經不適任了,所以他也不了解什麼是正確、應然的工作產出 (output)。

過早的最佳化

有的軟體開發人員認為,所謂『過早的最佳化』只是指效能改進而言。只要效能改進等到系統完成再來做,就不會造成『過早的最佳化』。我則持另一種看法,我認為如果只需要達成 60分的應用卻採用了可以達成 95分的技術,都可以視為是『過早的最佳化』,比方說:

  1. 複雜的軟體架構,比方說: microservices、甚至是 kubernates
  2. 極致的使用者體驗,比方說:mobile application 或是 SPA (single page application)
  3. 過多的效能、可擴展性 (scalability),比方說:NoSQL 或是 IaaS
  4. 100 % 的測試覆蓋、複雜的型別系統

分不清楚 simple 與 easy

在軟體工程的老生常談是要把系統做得簡單 (simple)。然而,簡單 (simple) 與容易 (easy) 這兩個概念實在是非常容易混淆。也因此,實務上,很多工程師做到了 容易,卻以為自己達成的是簡單。easy 是軟體開發者對難度的感受,這個因人而異,而且常常跟熟悉、熟練度有關。simple 則是指系統內部,是否有相對清楚、不交錯的依賴關系。easy 是一種主觀的感受,而 simple 則是一種客觀的性質。

  1. 直接手寫 SQL,這是 simple 卻不 easy 的解決方案
  2. 透過 ORM (Object Relational Mapping) 之類的工具來產生 SQL ,則是 easy 但是不 simple 的解決方案。
  1. 軟體開發者對 ORM 的了解
  2. 軟體開發者對 SQL 的了解
  3. 軟體開發者對 ORM 相對少見例外的充分了解
  4. 軟體開發者對 ORM 難以處理例外發生時,該怎麼處理的充分了解

盲從潮流、執著於教條

盲從潮流,有時候跟大公司強大的行銷能力頗有關系。

該怎麼避免這些錯誤?

每個軟體開發團隊的任務特性不同,不會有一種方法適用於各種團隊。要避免上述的 7 項錯誤,需要在採用某一特定的工作方法之前,先仔細地思考任務的應用情境,與某一工作方法是否相契合。

  1. 客戶的需求常常變動、使用者常常難以在最初把需求徹底地講清楚
  2. 使用者介面的極致體驗、軟體運行的效能、軟體是否容錯這些事的重要性,低於軟體的準時交付與正確性。
  1. 軟體規格採用 event modeling method
  2. 評估成效採用 the four key metrics
  3. 前端採用 htmx
  4. 後端採用 Clojure
  5. 資料庫採用 Postgres 或是 XTDB (如果需要時間迴溯與 bitemporality 的功能的話,可以考慮 XTDB)
  6. 分散式的應用,採用 Actor-based 的方式來開發,而非 Microservices

--

--

軟體開發/資料工程/顧問諮詢 https://replware.dev

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store