代碼設計的步驟包括（代碼設計）

大家好，我是小夏，我來為大家解答以上問題。代碼設計的步驟包括，代碼設計很多人還不知道，現在讓我們一起來看看吧！

1、周期

2、 很多人簡單的把迭代理解為開發的分階段進行。有些項目經理會這樣說：我們打算通過4次迭代完成軟件的開發，第一次迭代，完成需求分析和軟件設計，第二次迭代，完成多少多少模塊的開發，第三次，完成其他多少模塊的開發，第四次，配置，部署，上線，測試，修正軟件bug。在這里，雖然他們言必稱“迭代”，但是這樣的迭代和過去傳統的瀑布型開發有多少區別？

3、迭代開發是要分周期分階段地進行，但是不能認為簡單地把開發周期劃分為幾個不同的階段就是迭代。

4、很多人對于迭代周期有一些誤解，比如：

5、認為迭代只適用于開發階段，而需求分析和設計工作則不在此范圍內。

6、認為迭代周期可以拉得很長，比如兩個月，三個月，甚至一個季度，半年。

7、將需求分析，設計，開發，測試，部署，用戶反饋，修改當作完整的迭代周期，并要求在前一階段工作完全（或者大部分）完成以后再進行下一步工作（迭代）。

8、在一個迭代周期內，我們可以做什么事情呢？可以說：所有的事情。如果你認為迭代需要在需求分析完成之后才能開始，或者系統集成必須在所有迭代完成之后才可以進行，你會獲得一個真正的瀑布流程開發。

9、 一個迭代周期意味著對一些特定功能（用例）的探索。“探索”一詞可能隨情況不同而有不同的含義。對于抽象級別較高，模糊程度比較高的用例，我們需要通過和用戶的討論將它逐漸分解為更加清楚和清晰的用例。對于目前我們認為已經得到了詳細定義的需求，需要選取合適的部分進行設計和實現，通過這些部分的實現，對需求定義和技術可行性進行反饋。對那些在上次迭代中已經開發完的模塊，應該盡可能快速地讓用戶提出他們的意見，以便了解是否真正解決了用戶面臨的問題，以及還有沒有可以改進的方面，再根據這些意見安排下一階段的工作。

10、 我們是否可以在開發進行之前把需求或者設計全部弄清楚呢？我認為很難。因為通常來講，用戶對于自己的需求只有一個模糊的概念。讓我們假設一個飲食業的例子，有一天餐廳經理把你叫入辦公室說：馬上設計一個新的菜譜，這個菜譜是為某某特定人群定制的，你要讓這些人感覺色香味俱全。不過在你把配料和烹調方法都設計出來之前，我們不打算讓大廚來具體做這道菜，我們不允許失敗，所以你的設計一定要一次成功，你可以用調查問卷，用戶面談等方法獲取最終用戶的需求，但是記住：你不能去做這道菜。

11、 這樣的事情你可能會覺得很滑稽，但是在軟件業，類似的事情人們卻認為是天經地義的。

12、迭代允許我們將開發本身也作為需求探索的一部分，通過用戶對已經實現功能的反饋我們和用戶都會逐漸明白什么樣的軟件是我們最終想要開發的。所以，不要等到所有（或者大部分）的分析完了才開始開發，而是盡早對已經捕獲到的需求進行細化，盡早開發，以獲得反饋。

13、 在安排迭代計劃時，應該指明，這次迭代的目標是什么，在結束時應達到的里程碑是什么。如果有任務提前達到了這個里程碑，我們可以提前結束迭代，或者順便在剩下的時間內安排其他的任務，但是要注意這種安排的合理性，不要因為這個而使得迭代周期被延長。

14、 在一次迭代到達所設定的結束日期時，就必須審視各項任務是否達到了里程碑的要求，如果有任務沒有達到，原因是什么，我們是否需要對需求和技術方案做出調整。對于沒有達到里程碑要求的任務，我們可以采取的辦法有兩種：

15、將剩余的工作列入下一次迭代計劃中去，

16、將本次迭代的結束時間向后延遲，等待任務的完成

17、前一種辦法適合于有很大工作量沒有完成的情況，這可能也同時說明計劃的制定有問題，在制定下次迭代計劃時應該考慮對任務完成時間進行調整。后一種辦法適合剩余工作量不是很大的情況。

18、 通常來說，一次迭代完成以后應該有一個產品的新版本可用。這也就意味著：將集成和發布分散到每次迭代中去。借助于一些自動化工具（比如ant），我們甚至可以做到每日構建。

19、 一個迭代周期應該有多長呢？這并沒有一個統一的說法，而是應該視目標和可用的資源而定。但是，迭代周期不宜過長，也不宜過短。迭代周期過長的話，會延緩反饋的時間，可能將許多問題隱藏或是堆積了起來。迭代周期過短，會讓人身心疲勞，事情難有大的成效。一般來說，迭代周期應該在2-6周之間。如果安排的迭代周期超過了兩個月，你可能就必須審視一下迭代計劃的合理性了。

20、 不要認為下一次迭代應該和上次迭代的時間差不多，刻板地把所有迭代規定一個統一的時間是一個很壞的做法。但是你可以把以前迭代周期中的工作效率作為估算下次迭代時間的一個依據。

21、 目標

22、 一次迭代必須有明確的目標：我們希望通過這次迭代達到什么目的。在制定目標時，應該同時考慮另外一個問題：如何檢查該目標是否已經達成。這就是所謂的“里程碑”。

23、 迭代計劃必須有明確而可行的目標。明確的意思是它應該是可度量的，不能太模糊，因為你很難檢查一個模糊的目標是否達成。比如，我們可以說，這次迭代的目標是對xxx方面的需求作進一步細化和評審，完成xxx模塊的開發以加入到軟件的下一版本中去。這樣的目標是明確而且可行的。反過來，如果我們這樣說：我們要通過和用戶的討論明確絕大部分愿景，同時要有一個初步的開發。“絕大部分”和“初步”這樣的詞讓人感到困惑：多少是絕大部分呢，在總量尚未明確的前提下，怎么能夠知道完成的確是“絕大部分”而不是“一小部分”？“初步的開發”似乎告訴我們這次開發量比較小，但是具體開發哪個部分，或者開發到什么程度，并沒有指出一個明確的概念。

24、 由此產生了一個困惑，軟件項目是一個不斷探索的過程，我們怎么能夠明確地對未來的事情作安排呢？譬如在項目初始調查用戶愿景時，為了實現“明確”的目標，是否這樣定義任務：完成20%的用戶愿景調查？

25、 很顯然，用戶愿景總量到底有多少我們并不知道，所以在這次迭代完成以后如果我們問：是否真的完成了20%而不是15%？很難得到答案。

26、 為了避免出現這種情況，你必須換個角度來看問題，比如我們可以說：對xxx部門和yyy部門的用戶做愿景調查。在迭代完成后，可以檢查是否這兩個部門所有用戶的訪談，調查都已經完成，是否這些部門每個人都認為自己表達了全部的意思。

本文到此講解完畢了，希望對大家有幫助。