1. 不管路走了多遠,錯了就要重新返回
文章上來就引用了一句土耳其的諺語“不管路走了多遠,錯了就要重新返回”， 這個說的容易， 做起來真的很難， 尤其是已經做了很多的時候， 放棄真的很不捨得…所以在開發一個軟件之前最好要把需求整明確了， 而且開發過程中過段時間就要停下來審視一下目前的工作符不符合需求， 也就是敏捷開發中常說的多和客戶進行溝通， 及早發現問題， 修改起來代價也小…
說到開發過程中過段時間就要審視的問題， 我又想到之前遇到的問題， 就是開始時爲了趕時間， 代碼寫的很亂， 有得直接copy一段過來， 不用的就注掉， 有些註釋也都和代碼不搭調， 一直想着開發完在去整理代碼， 可是等開發完了， 也測試的差不多了， 這時候有時間了， 但發現現在不敢動代碼了， 怕動出問題來， 也沒那心思去整理了， 導致代碼簡直可以用慘不忍睹來形容…所以還是要在開發過程中一步一步走，一段時間後在回過頭來重新review下代碼， 格式上， 邏輯上都看看， 這樣心裏也踏實， 即使花上休息的時間也值得， 利人利己…
文章上來就引用了一句土耳其的諺語“不管路走了多遠,錯了就要重新返回”， 這個說的容易， 做起來真的很難， 尤其是已經做了很多的時候， 放棄真的很不捨得…所以在開發一個軟件之前最好要把需求整明確了， 而且開發過程中過段時間就要停下來審視一下目前的工作符不符合需求， 也就是敏捷開發中常說的多和客戶進行溝通， 及早發現問題， 修改起來代價也小…
說到開發過程中過段時間就要審視的問題， 我又想到之前遇到的問題， 就是開始時爲了趕時間， 代碼寫的很亂， 有得直接copy一段過來， 不用的就注掉， 有些註釋也都和代碼不搭調， 一直想着開發完在去整理代碼， 可是等開發完了， 也測試的差不多了， 這時候有時間了， 但發現現在不敢動代碼了， 怕動出問題來， 也沒那心思去整理了， 導致代碼簡直可以用慘不忍睹來形容…所以還是要在開發過程中一步一步走，一段時間後在回過頭來重新review下代碼， 格式上， 邏輯上都看看， 這樣心裏也踏實， 即使花上休息的時間也值得， 利人利己…
《高效程序員的45個習慣:敏捷開發修煉之道 》讀後感
http://www.88dev.com/forum-viewthread-tid-322-fromuid-1.html
http://www.88dev.com/forum-viewthread-tid-322-fromuid-1.html