好文: 實戰敏捷開發 整理

感謝 ihower 辛苦的讀書心得, 不管是任何角色的人, 都建議看看, 粗略看看也會獲益良多~ 🙂

實戰敏捷開發 整理

  1. 實戰敏捷開發 Practices of an Agile Developer (1) 專業態度篇
  2. 實戰敏捷開發 Practices of an Agile Developer (2) 需求篇
  3. 實戰敏捷開發 Practices of an Agile Developer (3) 測試篇
  4. 實戰敏捷開發 Practices of an Agile Developer (4) 程式篇
  5. 實戰敏捷開發 Practices of an Agile Developer (5) 除錯篇
  6. 實戰敏捷開發 Practices of an Agile Developer (6) 團隊開發篇

相關文章 (文章中提到的進階閱讀文件)

相關文章 (其它的相關文章)

摘錄

下述內容節錄自上面文章, 這些只是內容的一小部份, 覺得有趣又實用, 特別節錄下來~:)

註解的目的

註解是用來寫目的、限制條件跟預期結果等,而不是寫出以下這些程式一行行會做些什麼(請不要拿註解再寫一次程式碼在寫的事情)。一個簡單的判斷方式是:寫在函式 “裡面” 的註解多半是不需要的 (尤其是註解寫 what? 而不是註解 why?)。在重構一書更直言回答哪裡需要重構?那就是有註解的地方:如果程式碼前方有一行註釋,就是在提醒你,可以將這段程式碼替換成一個函式,而且可以在註釋的基礎上給這個函式命名。

你要做的事情應該是讓 source code 本身容易了解,而不是透過註解。透過正確的變數命名、好的空白間隔、邏輯分離清楚的執行路徑等手法,我們很少需要在函式裡面註明這些程式在做什麼,我自己的經驗除非是有參考外部的程式碼或複雜演算法,我會多註明參考來源(網址)。否則沒有必要的註解對我來說就像噪音一樣,妨礙閱讀。

架構設計師一定要寫程式

作為一個架構設計師,要實際了解設計真的可行才算是負責。真正的 architect 是團隊中的導師,有能力解決較複雜的問題,但絕不放棄 coding。絕對不要用不 coding 的架構設計師,不實際 coding 了解系統是不可能設計好軟體的。

作者: Tsung

對新奇的事物都很有興趣, 喜歡簡單的東西, 過簡單的生活.

在〈好文: 實戰敏捷開發 整理〉中有 4 則留言

  1. 您好:
    在您的網站看到您有支持 Agile 的文章,
    先前曾經發過邀請,但不知是否沒有收到,冒昧再發一次。
    我有個推廣 Agile 給台灣軟體界的計劃
    http://christorng.ning.com/group/data/forum/topics/ji-hua
    ,不知您是否有興趣參與?
    http://christorng.ning.com/
    如果有興趣參與,可加入會員,我就知道了。
    如果沒興趣,是否也能回覆一下,讓我知道您的意願。
    ChrisTorng

發表迴響

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料