規劃任務的最佳方式？

Question

由於我對編程非常陌生，所以我很好奇學習編程的最佳方法/實踐。

每當我想編寫任何程序時，我都會直接從編碼開始，而有些人則說您應該在開始編碼之前先計劃您的程序。

但我不明白創建類圖和所有類型的東西真正的價值因爲我認爲最終我必須編寫代碼。

你們可以請你分享一下你的經驗嗎？我的意思是當你啓動一個應用程序時，你的第一步是什麼？

Answer 1

有時候一項艱鉅的任務讓人望而生畏，甚至可能只是「編寫代碼」而無法計劃，因爲你只是不知道從哪裏開始。我記得幾年前，我曾經被困在一些嘗試新事物的年齡段，因爲我的位置已經提升，我的主要工作是提高功能 - 我沒有使用空白畫布的經驗。這是癱瘓的，無法採取一種方法，因爲它可能是一個次優的設計選擇。

但無論如何，現在我傾向於坐下來用紙和迭代設計。

如果它很大，我將開始勾畫出它的各個部分將如何單獨工作，並最終將這些部分連接在一起。我嘗試將它轉化爲類或模塊，然後我會發現設計中存在冗餘，或者那裏有些東西不起作用。所以我重新開始，用更好的方法寫下來...並找出更多問題。我一直在迭代，在每一次掃描中更好地理解問題。 （白板可以很好地幫助你解決問題，在解決棘手問題時是物理上的。）

當我有一個非常詳細的psuedocode /流程圖設計，它沒有明顯的問題 - 那是我開始編碼的時候。在一個正式的環境中，最終的設計草圖就是我將變成一個規範並分發給用戶/開發人員進行審查。

通常，具有複雜的設計，我將改變這個設計草圖到的意見來指導我，因爲我的代碼，這比具有更快，更準確地進行協商每2秒我的筆記：

// open file 
// read header line 
// check header is right (watch for int problem) 
// select right config object 
// loop over lines, read each line into config object 

而且我將每個評論轉換爲代碼。

這比將自己編入死路並且不得不寫入並重寫僅僅是因爲從一開始就沒有處理這個問題。這並不意味着設計不會再發生變化 - 您仍然會發現問題 - 但是在您訪問IDE之前，一些主要的設計錯誤可能會被摧毀。

有很多方法來設計，這只是對我有用。什麼是最好的可以根據項目類型和團隊的規模而有所不同。

Answer 2

我是CRC Cards的粉絲。

CRC代表類，責任，協作。您使用一組明信片，每張卡片代表一個類別，並列出其負責的內容，以及與其他類別的合作方式。

給出一個功能列表和/或一組使用案例，CRC卡可以很容易地「執行」軟件的各種功能，確保存在執行所需操作的類，以及關係這些類別之間存在着允許他們一起正常工作。

Answer 3

我正在使用類似「reallife」的CRC卡片 - 我只拿了幾張紙和一支筆，開始繪製類和它們的方法以及所有依賴關係的草圖。其他論文用於更詳細的功能信息。

Answer 4

如果您不熟悉編程，那麼從基礎開始：學習編程。寫一些小的"hello world" programs並擴展你的知識到網站或Windows應用程序。學習編寫符合您要求的程序。如果您沒有任何要求，請在開始之前寫下它們，否則您的程序將沒有終點線。

當您準備好接受更大的項目時，您可以使用UML採取課堂和對象設計，並學習test-driven development以編寫更實用的代碼。瞭解有關不同開發方法的更多信息，如Agile和Scrum。更大的項目需要規劃和良好的設計，所以你必須瞭解你的理論。

Answer 5

不要停留在類圖等等上，花點時間思考你想做什麼的主要目的是能夠在強大的產品中組織你的應用程序。當你坐下來想事先想要做一些用例來說明你的程序應該做什麼時，你可以從另一個角度有效地尋找，這樣你可能會發現不那麼明顯的事情。一個抽象問題

如果你直接開始編碼，你最終會陷入實現的細節，並可能忘記創建一個非常狹窄和脆弱的解決方案的目標。

有點像你在從A到B的叢林中劈開你的路，當你到達那裏時疲憊地將自己扔在地上，然後創建了一條從A到B的路徑，但是你真正想要的是一條鋪好的公路從A到B

規劃和準備

Answer 6

有兩點：

• 爲了確保您和客戶共享的問題同樣的觀點。
• 爲了揭示您的想法如何解決問題的潛在問題。

它是如何你做視情況而定，但關鍵是要實現上述兩點儘可能便宜。繪製草圖，討論，製作低成本原型，create a pilot system。

Answer 7

如果你想編寫一個好的程序，尤其是你可能想要稍後改變和改進的程序，那麼在潛心編寫代碼之前，你會做一些設計是值得的。

「創建類圖和所有類型的東西」實際上只是一種在紙上寫下你已經在想什麼的方法：你需要什麼類，它們將存儲什麼數據，以及類如何關聯到彼此。你不必遵循任何正式的流程 - 我發現粗糙的箱子和箭頭對於組織我的想法很有幫助。當我花更多時間在一個程序上時，我發現我發現了一些更好的數據組織方式，或者改進了類之間的關係。發生這種情況時，最關鍵的一點是，潦草地寫出和重新繪製幾個盒子比扔掉用精心調試過的C++編寫的200行文件並重新開始更容易和更快。