electronic_blue

用了 octopress 就沒理由再不寫 blog

回應「建築師蓋房子要畫藍圖,難道工程師寫 Code 不用嗎?」

|

原文

不知道為什麼 techorange 會登這麼沒 sense 的文章。

  1. 軟體當然有藍圖,也叫 specification,但有常識的人不會把它翻成「注釋」,而是「規格書」。
  2. 除了規格以外,工程師也會針對系統的架構與運作流程進行設計並製作文件。UML 就是為此而存在。所謂「很少有程式設計師會在他們開始編碼之前規畫藍圖」
  3. 以前做大型軟體就是像蓋房子這樣一步一步來的:分析規格、設計架構、寫程式、除錯、出貨,這種開發流程叫 waterfall,現在不流行這套了 XD
  4. Waterfall 的確可以做出軟體,但關鍵是產出的東西往往不是客戶要的。因為軟體開發與蓋房子之間有決定性的差異,你拿蓋房子的流程去開發軟體會是悲劇。
  5. 為什麼有了規格書後,工程師還是做不出客戶想要的軟體呢?因為人類對房屋的理解能力,與對軟體的理解能力是不一樣的。人類容易理解具體化的東西,只要看到房間的佈置圖、看到樣品屋,他可以很容易地想像出房子會長怎樣。
  6. 但軟體規格卻是抽象的。一般人很難理解「如果●●●發生時,程式會做出○○○的反應」,甚至連使用者自己也不知道他們想要怎樣的軟體,大部份的需求通常是在實際使用後才出現的。
  7. 更有甚者,沒有人會等房子蓋了三層才跟建築師說他希望一樓挑高改做樓中樓,但同樣的事在軟體開發的世界中卻天天上演。
  8. 放眼所及,各位現在在使用的軟體,幾乎沒有一項是畫完整張藍圖後才開始實作。每個成熟的軟體,都是在傾聽大量使用者的抱怨後,經過無數次的蛻變、進化,讓他們一點一滴更貼近人性的需求。
  9. 軟體開發並不像是在蓋房子,反倒比較像是在玩美少女夢工廠(?)。
  10. 回到原作者的主題,註解的確會影響到理解程式碼的速度,但它終究只是一種溝通工具。軟體開發的瓶頸通常在於規格清不清楚、架構好不好、以及我們做的東西究竟符不符合客戶的需求。
  11. 作者反對「用程式碼解釋程式碼」,但我反而鼓勵這件事,亦即 self documentation。這意思並不是叫你不用寫註解,而是當你把程式碼寫得非常簡單非常容易理解,那根本連寫註解的必要性都消失了,這才是註解的最高境界。

迴響