2009-09-02 72 views
6

現在,我非常沮喪,因爲我正在開發一些很酷的機制,通過減少計算次數來優化計算系統從大約五十萬到幾千。花了很多時間檢查和分析數據,寫下東西,做一些測試,一般只是做我的工作。 然後我們舉行了一個項目會議。我已經解釋了我想要做的事情,需要多少時間以及它可以改進項目的程度,甚至可以創建新功能。然後決定在下一個截止日期之前完成這一切的時間太長了。 (如果允許繼續,這個截止日期將不得不延長。)一場快速的頭腦風暴清楚地表明,有一個簡單的解決方法可以用來替代,這會延長几個月的優化時間。如何管理凍結/延遲無限期的項目

好吧,強硬!

好吧......我剛剛寫下了無奈。現在的問題是......我現在把這整個設計都放在了我的腦海裏。其中大部分內容僅僅是原理圖和一些帶有手寫文本的論文,一些打印文件,甚至還有一些SO的問題。這些想法會被凍結一段時間,但我需要再次記住它們。我可以有一天,也許有兩天清理筆記,並開始記錄事情。

因此,我需要關於如何最好地記住我的設計的建議。從現在起4個月。或者甚至可能是一年之後......寫下最重要的是什麼?還是文件? (考慮到我有很短的時間......)有什麼建議嗎?

爲什麼?否則我會在四個月後再次感到沮喪。 :-)

+1

我投票結束這個問題作爲題外話,因爲它不是關於編程。 – 2017-11-08 09:38:29

+0

首先,這個問題是6歲。其次,這是關於項目管理,這是編程的一個重要部分!每個程序員都必須處理像這樣的情況,即在一個項目再次被拿起之前,一個項目被放入冷凍機幾個月。 – 2017-11-09 10:01:00

+0

好的,這裏我們再去..請看看這個答案 - https://meta.stackoverflow.com/a/343841/1000551。你的問題不是一個編碼問題,它不是軟件開發所特有的。想象你是某種科學家(例如物理)和你處於相同的情況。 – 2017-11-09 10:07:24

回答

3

這取決於什麼對你有用 - 以及你喜歡如何學習。我喜歡使用圖表,所以在我設計了一個很酷的算法的情況下(儘管沒有這麼複雜!)我做了以下操作:

1)將算法繪製在紙上,或者寫出來。

2)向它添加註釋,以便它使完成對您有意義。

3)僅從您繪製的內容中向其他人描述算法。這阻止了你從你自己的算法知識中填補空白。

4)如果描述中存在空白,請隨時添加額外的細節,以便文檔成爲描述的綜合記錄。

5)將圖紙放置一週,看看它是否仍然有意義。在這一點上,它應該仍然足夠熟悉,可以添加缺少的細節。

在一年的時間內是否足夠清楚 - 或者您是否想要使用它 - 還有待觀察。

希望有幫助!

+0

好的提示!我已經在這個項目上花了兩個月的時間,首先了解域的問題,然後分析所有需要的數據,然後提出一個適當的算法。如果項目會繼續下去,我現在也會寫文檔,但也有一些簡單的代碼。我會有更多時間來處理文檔。現在,最令人沮喪的是,所有內容大部分都在我的腦海中,只需一天時間就可以將它放在文檔中......我只是不想匆忙...... – 2009-09-02 13:46:56

7

根據我的經驗,舊設計在撣掉時總是顯得陳舊。在未來的幾個月中,現有的代碼將會發生變化,需求也會發生變化,並且您將以程序員的身份進行更改。也許你應該寫一個簡短的解釋,並假設你將來需要徹底修改它。

不要因爲特定的項目而感到沮喪,請集中精力改善開發者的工作。和你一起去體驗。

1

描述所有輸入和輸出的詳細需求文檔可能是開始使用的最佳方法之一。如果它是一個非常獨特的代碼設計,元代碼可能是一個很好的步驟。即。

[Meta Object] 

    [Return String(string param1, string param2)] 

     Return param1 + " " + param2 

    [Return Integer(integer param1, integer param2, integer param3)] 

     Return (param1 + param3)/param2 

[End Meta Object] 

使它看起來類似的東西到你的語言W/O測試或任何東西,只得到了理論logc到紙上(記事本)這樣,你有一個跳板,當/如果你要回去呢...然後記錄它的日光。

+0

而不是元碼,我傾向於創建一個XSD與XmlSpy。它提供了一個很好的圖形化概覽,並且如果您對樣式表有經驗,那麼創建起來非常快速。 – 2009-09-02 13:42:04

2

在挫折方面 - 通常嘗試將項目視爲旅程而不是目的地。

如果你一直在關注,那麼到目前爲止,你會從項目中得到很多東西 - 你已經學到了有關技術和業務的知識,創建了可以重用的代碼模塊,你將會構建與團隊成員或用戶的關係,犯了不會再犯的錯誤等等。它可能會幫助你親自編寫一份你現在知道的項目清單,而不是在項目開始階段。

最終,公司可能沒有實施該項目,但作爲一個人和一名開發人員所獲得的很多收益仍然存在。事實上,通常你會更多地瞭解那些出錯的項目,以及那些並不比夢想中的項目更好的公司。

與生活的其餘部分一樣,你每天從事物獲得的滿足感越多,而只關注選取的成就越少,你會越開心。

我並不是說交付項目並不好 - 這顯然是爲什麼我們要編寫代碼 - 但它並不完全在我們的控制之內,所以您需要現實並平衡您對此有多大的影響。

(強制性鏈接的東西喬爾或傑夫寫道:http://www.codinghorror.com/blog/archives/001297.html

1

如果你已經找到了解決辦法一次,機會是很高,你會發現解決方案連得4個月下來了同樣的問題就行了。你不能錯過的是實際的問題。

您應該記下所有問題來源或實際問題的優化問題。你必須整齊地保持這些問題的注意。

現在,下一次[說4個月後]當你想再次回來。您只需要從筆記中讀取問題,並且您的大腦將像以前一樣開始朝着正確的方向工作。

爲了讓它更好,您可以嘗試在一兩個月內完成一次問題解答。這將訓練你的大腦朝着解決方案發展,因爲你會每次最終以解決方案結束,就像你第一次做的那樣。

此外,如果您可以記下問題或擔心的問題,這些問題或問題足以讓您爲解決方案而奮鬥,那就太棒了。