當你開始思考一個編程項目時，你首先會做什麼？

當你開始思考一個編程項目時，你首先要做什麼？你拿出一張紙並開始勾畫出建築物嗎？你有想法的筆記本嗎？你開始編碼嗎？或者你是在一個奇特的軟件包中建模軟件。來，澄清你的想法...當你開始思考一個編程項目時，你首先會做什麼？

來源

2008-12-02 stuartcw

看到這個問題：http://stackoverflow.com/questions/284578/design-or-prototype-first。 – 2008-12-02 23:30:49

爲了開始思考架構或設計，我傾向於寫假設的代碼片段，我想「只是工作」，以解決核心問題的應用。

例如，我的設計數據庫時，我通常會盡量想一些例子查詢我想到寫，而不是抽象地考慮數據實體和關係。

這種方法可以幫助我（個人）避免第一遍抽象化太多。你可以稱之爲「美麗的代碼優先」方法。它與TDD有着相似之處，除了您首先針對表達性，簡潔的代碼，然後構建體系結構和抽象以支持它。

這是我個人認爲的表現，清晰的代碼是從長遠來看比笨重的，徹底的測試代碼更可取。當然，這些並不是相互排斥的。只是不要讓美麗的「架構」的願望導致您的業務邏輯笨拙的客戶端代碼。

來源

2008-12-02 23:26:32 Larsenal

+1：數據優先（通過查詢） – 2008-12-03 00:10:40

有人給出了這個名字......「Readme driven development」http：//tom.preston-werner。com/2010/08/23/readme-driven-development.html – Larsenal 2012-01-27 21:33:00

我幾乎總是從繪製一個粗略的對象模型開始，給我一個關於系統結構的視覺概念。然後從那裏建立。

來源

2008-12-02 23:28:13 flesh

我坐下來開始編碼......然後我刪除了所有項目文件並轉到白板，並開始映射對象和關係。

來源

2008-12-02 23:29:31 EBGreen

這肯定是值得懷疑的方法，但我也這樣做。弄清楚爲什麼會很有趣。 =））） – Din 2008-12-03 20:59:45

哦...我永遠不會推薦這種方法。 – EBGreen 2008-12-03 21:10:10

我寫下的功能列表，然後進入它詳細一點的，然後我開始我的對象的一些塗鴉，他們會如何相互交流，那種半arsed DFD ..我所有的圖紙是一團糟！

來源

2008-12-02 23:30:31 Tablet

我會谷歌它首先看到的東西存在以相同的方式/甚至更接近和了解更多關於它。利用當今可用的語言和框架的強大功能，任何普通程序員都可以編寫代碼，但質量將取決於您用來實現該解決方案的多少'最佳實踐'。你實現結果的速度也很重要。

所以我覺得谷歌搜索將是在SDLC過程:)

來源

2008-12-02 23:30:44

一個重要週期我搶本子和筆，並開始素描筆記和流程圖，沒有什麼特別的，只是可視化概念模型從那以後，我嘗試在更簡單和更簡單的任務中打破每個部分。

一旦我無法進一步簡化了任務，我開始寫輸僞代碼和粗糙了數據庫方案。只有這樣我才能開始編碼樣本/測試代碼。

來源

2008-12-02 23:34:42 Mason

我把我寫的一切我都在想法的筆記本電腦。我一般寫一兩頁關於項目/產品/等密集的筆記，然後息事寧人，因爲我沒有時間做任何事情。在實際設計事物的時候，我會重讀我的筆記並嘗試在UML中創建類圖。通常這會失敗，這會導致更多頁面的筆記改進想法，解決奇怪的邊緣案例和未定義的事情等。沖洗並重復。一旦我有一個可以記錄所有主要參與者的類圖，我就開始編寫代碼。

來源

2008-12-02 23:34:55 rmeador

我想想用戶和他們想要什麼，他們會得到。

他們不關心後端或花哨的語言，直到你已經計算出到底是什麼程序會做，爲什麼會有人想使用它，沒有別的真正重要的。

來源

2008-12-02 23:40:01

通過編程項目，我要承擔起「爲客戶」，而不是一個嗜好/個人項目。

我通過讓客戶介紹給我，他們想要什麼高級語言的第一次啓動。我尋找諸如「我想要一個有多個部門並允許通過電子郵件進行回覆/更新的票務系統」的東西。東西快速簡單。

從那裏開始規範文檔的初稿。我開始詢問客戶的問題，以幫助完善原始草案並降低到更細化的水平，直到系統最終完全被指定出來。完全地，我的意思是客戶無法給我更多關於他們想要的信息。

對於個人或愛好類的項目，我通常會花幾天圍繞滾動的東西在我的頭，設計在紙上或在我的模擬程序的一些基本的數據庫模式。我喜歡在幾個晚上睡覺，看看它是否會繼續有興趣發展，而不是在它完成之前放棄。一旦我確定它是我會看到的，我會繼續起草自己的規範並從那裏開始。

來源

2008-12-02 23:47:17 Alarion

嘗試分析buisiness域。即應用程序試圖解決的業務問題的結構。它需要操縱/管理哪些實體，它們是可變的/不可變的嗎？應用程序需要實現哪些流程（從業務角度來看）？每個進程需要哪些實體，以及每個進程對該實體做了什麼？等等。

來源

2008-12-02 23:51:14

收集requrements
定義優先級
估算努力
開始工作
跟蹤和評估進展

來源

2008-12-02 23:52:40 Din

我開始記錄一個視覺，一描述項目的簡短文檔，圍繞它的業務以及它的成功標準。

這有助於優先功能，並給出了同一個方向大家對項目的工作。

來源

2008-12-05 20:42:33 philant

我總是解釋什麼，我認爲它是我試圖與該項目給別人，最好另一位開發人員來解決。除非我能夠清楚地解釋我想要做什麼，否則我不會希望地獄有機會創造能夠解決問題的東西。不得不將其描述給另一個人的行爲經常會引發我對問題領域知識的空白，並暴露出我有未經證實的假設。如果我有一個方便，這通常涉及到我如何在白板上看到問題。

來源

2011-09-22 22:50:14 Actel

當你開始思考一個編程項目時，你首先會做什麼？

回答

相關問題