好文: 實戰敏捷開發 整理

感謝 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) 團隊開發篇

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

• 物件導向程式的九個體操練習
• 如何有效地報告錯誤
• 簡單的法則 - 此連結的 PowerPoint 檔建議可以下載看看, 體驗 Rasmus Lerdorf 所言: Simple is Hard , 想想看 簡單是經過多少複雜的思考才產生出來的~

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

• 穩定的程式是偶然？

摘錄

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

註解的目的

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

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

架構設計師一定要寫程式

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