More Related Content
Similar to Joel of Software 中文版 1~6章導讀 (20)
Joel of Software 中文版 1~6章導讀
- 2. Who is Joel? 美國出生，念大學之前回以色列當傘兵 退伍後回美國念大學，耶魯大學CS學位 1991畢業後即進微軟開發Excel (VBA之父) 1995年離開微軟替另外兩家公司工作 2000年起創業 2 ©2010 Meng-chiu Lee
- 3. 作者自己定義這本書 工程師 -> 管理階層 不喜歡/不熟悉/不知道如何管理軟體專案/團隊 包含技術以外的範圍 VP問:「為何不用Java取代Oracle，我聽說它比較一致」 新技術快速入手 (在2000年時) .NET, Unicode 處理問題的竅門與哲學 邊開火邊移動 非常主觀 – 但均來自經驗 3 ©2010 Meng-chiu Lee
- 4. Part 1. 程式設計實務 由 blog 上零散的文章集結而成 Part 2 = 如何管理RD Part 3 = 其它主題 Part 4 = 微軟 .NET Part 6 = Q&A Part 1 包括了： 程式語言、演算法、QA、Charset & Unicode 如何寫規格 daily build, debug, prototyping, framework … 「實務」就是實際做的時候會碰到的鳥事一堆事 = 如何處理 Real World 中的軟體開發 4 ©2010 Meng-chiu Lee
- 6. Ch 1. 選擇一種語言 程式語言 依用途選擇 語法 批評 .NET (反對票: ch. 1 & 43 vs. 贊成票: ch. 44 & 45) 6 ©2010 Meng-chiu Lee
- 7. Ch 2. 回歸原點 油漆工的故事 (請讀 p.7 灰色方塊) char OP_empl[1000]; OP_empl[0] = ‘’; strcat (OP_empl, “Ivan “); strcat (OP_empl, “Phantom “); strcat (OP_empl, “John “); strcat (OP_empl, “John “); 記憶體配置 演算法 反對 Java 做為電腦科系新生的入門語言 7 ©2010 Meng-chiu Lee
- 8. Ch 3. 約耳測試 簡單的「12個步驟」讓程式更好 每一步只要回答 Yes/No，全部只要花 3 分鐘 全做好不保證產品大賣… 產品還是得有人要 :P 目標：建立穩定交出產品、交出穩定產品的紀律團隊 「約耳測試」的用法 給自己的組織評分 確保或幫助自己的開發團隊在最佳狀態工作…manager 可專心負責其它事 評估未來的團隊、想投資的公司 發布 4 年後讀者回饋… RD拒絕到分數太低的團隊裡工作 :o 做得太超過 – 例如微軟?! 8 ©2010 Meng-chiu Lee
- 10. Ch 4. 絕對要會的 Unicode 和字元集知識 2003年撰寫 寫得又清楚又簡單的 Charset & Unicode 解說文章適合給新人、相關(非工程師)團隊成員閱讀 10 ©2010 Meng-chiu Lee
- 11. Ch 5. 無痛功能規格 1 of 4: 何必呢? 史快手和羅傑的故事 p. 46 ~ 47 負責自家新產品的向後相容(舊版也可以用) 第一個想法：讀舊版檔案，存成新版檔案 在 Word 裡改掉一段 vs. 改程式 (在 RD 的抗拒下) 11 ©2010 Meng-chiu Lee 11
- 12. 為什麼要先寫規格? 上一頁說明了：省時間 有效溝通、節省 RD 之外的人的時間 (p. 48 ~ 49) QA 是照 RD 口頭的話 (在他被打斷很不耐煩時) 測試… 無意義的 online help / manual 因為寫文件的人不懂… 詳細規格才能事先訂出時程而且可以容易解決一些設計上的爭論 alert 的方式和用詞，討論完畢、標出來，RD放心做下去 RD 如果先做沒有爭議的項目，最後只會造成把最難的押到最後，造成失敗 不喜歡寫規格的原因 不喜歡/不會寫作文 沒看過什麼功能規格書 12 ©2010 Meng-chiu Lee
- 13. Ch 6. 無痛功能規格 2 of 4: 規格是什麼? 「功能規格」 vs. 「技術規格」 功能規格 (functional specifications)由使用者的角度描述產品如何運作 (不管怎麼做出來的) 技術規格 (technical specifications)程式內部實作: 資料結構、DB Schema、程式語言或工具、演算法 確認「使用者體驗」是最重要的 p. 54 ~ 61 一份範例 (WhatTimeIsIt.com) 很多笑點… 例：首頁的Shockwave動畫會發包給某家紐約蘇活區二樓的、貴得要死的工作室，動畫右下角必須在大於十秒後才會淡入浮現「Skip」但是非常非常難點到… 13 ©2010 Meng-chiu Lee
- 14. 建議放在功能規格裡的項目 聲明：文件狀態說明：像介紹主講者出來前，給聽眾的背景說明 「一個」作者 ：表示負責，如果規格很大就分段發給不同人 情境 – 真實世界裡的需求及人們使用這系統的方式 選好客戶族群 完全虛構又完全典型、用很典型的方式使用產品 狀況儘可能清楚又真實 (描述細節) 這樣設計出來才會很讚 不包含的項目 – 刪掉的功能、這版本不處理的事故意把它們曝露出來 概要 / 目錄 / 流程圖 / 架構 細節 錯誤時要怎麼做：非常重要，因為重視「使用者的體驗」…寫規格時會幫助我們幫助 user、設計更好的體驗 14 ©2010 Meng-chiu Lee
- 15. 記得也放入規格的項目 還沒定義好的項目 特別標示以便於找出來修改 給特定角色看的註解 技術註解、測試註解 行銷註冊 規格必須是活的 大的 milestone 時，印出來、加上修訂標記，讓大家重新讀過但不用全部重讀 討論：規格變動怎麼辦? 討論：規格何時要凍結? (p. 65) 15 ©2010 Meng-chiu Lee
- 17. 原文連結 ©2010 Meng-chiu Lee 17 無痛功能規格 Painless Functional Specifications: Part 1: Why Bother? http://www.joelonsoftware.com/articles/fog0000000036.html Part 2: What's a Spec? #35 Part 3: But... How? #34 Part 4: Tips #33 約耳測試 The Joel Test: 12 Steps to Better Code http://www.joelonsoftware.com/articles/fog0000000043.html 書中未收錄的中文翻譯文章 程式師的使用介面設計手冊 第 1 章 讓 錯的程式看得出錯2005年5月11日 無 痛錯誤追蹤2000年11月8日
