怎麼不急於自己？

Question

我經常發現我對功能做的不夠全面，尤其是在設計階段。我發現有幾個原因：

1. 我過於樂觀
2. 我覺得有必要爲客戶提供快捷的解決方案，所以有時我騙自己，以爲設計爲防呆而事實上，它仍然是千瘡百孔，只是爲了更快完成工作。當然，我最終會付出高昂的代價。

我知道我的這種行爲一段時間，但我仍然發現我無法彌補。你有沒有遇到類似的問題？你如何解決它們？

Answer 1

我遇到過這個問題很多。

我的解決方案是筆記本。 （老式的紙類）。

我寫出來我是如何打算實施解決方案作爲項目符號概述列表，然後我嘗試和充實名單上的每一個點。

通常，在這個過程中，我遇到了我沒有想到的問題。

當然，80/20法則仍然適用......我還是遇到事情時，我實際上做沒有發生，我認爲執行，但有經驗的這些趨於減弱。

編輯：如果我仍然不確定在這個過程結束時，我把一個一次性原型測試平臺放在一起...重要的是要確保它是一擲千金，因爲否則你運行的風險包括一些討厭的黑客你的真實代碼庫。

Answer 2

我已經學會了，通過幾年的錯誤（但仍使他們），即幾乎所有的東西我想重複使用，或分發，需要進行適當的設計。所以燒得夠多就會結束你的樂觀。

當正從管理壓力，我告訴他們，我將不得不把在思想上無論如何，所以當它的價格便宜，我應該這樣做。我也在紙上思考，所以我可以證明我正在做一些事情，它讓我的手指保持在鍵盤上，這兩者都爲管理提供了舒緩的效果。 ;-)

Answer 3

這是很常見錯過邊緣的情況和細節，當你在一個項目的規劃階段的時候，尤其是在軟件開發領域。請不要認爲這是個人失敗;這是特有的。

爲了解決這個問題，許多軟件開發方法已經出現。最近，許多開發團隊轉而採用「敏捷」方法，重點在於快速開發，只需很少的前期技術設計（畢竟，只有在實際開始開發時纔會發現許多複雜性）。我目前使用Scrum的系統，該系統一直以優良的在我的小團隊：

http://en.wikipedia.org/wiki/Agile_methods

http://en.wikipedia.org/wiki/Scrum_%28development%29

如果您發現自己的組織不會接受他們可以作爲一個根本性的轉變，把方法，可能值得研究他們是否會同意開發原型系統。這意味着你可以編寫一個特性來調查涉及的技術，並判斷它是否可行，而不必承諾全面開發，質量標準，測試計劃等等。一旦可行性已被證明或推翻，原型應該被扔掉，那麼可以開始適當的發展，包括你在這個過程中學到的所有東西。

如果您的問題與時間管理更相關，那麼我會推薦Getting Things Done方法（http://en.wikipedia.org/wiki/Getting_things_done）。這是務實和簡單的，專注於提高您的工作效率，同時不會使您的信息與您當前的工作無關。我發現，有時候我會因爲項目/功能的想法而感到不知所措，並且在我有足夠的資源可以有效地工作時，將所有內容寫下來並存檔一段時間會非常有幫助。

我希望這會有所幫助，祝你好運！

Answer 4

風險聽起來明顯 - 悲觀。我有幾次經歷，我認爲「這應該需要幾個小時」，並且由於所有意外彈出的小事情，它最終需要幾天天。

到目前爲止，我發現管理事物的最佳方式是（非常像安德魯的答案）以設計和要求作爲出發點。然後，我會經歷並尋找設計中的薄弱環節，陷阱和其他用例等等。我嘗試將此視爲一個關鍵練習 - 尚未編寫任何代碼，因此，現在是時候完全無情地尋找每一個弱點。尋找您必須處理的錯誤情況，以及您認爲完成每個功能/功能需要的時間量，然後大量填充該量。我曾經有過幾次將我的初步估算翻倍，但仍然沒有達到這個標準。

作爲一名程序員，要真實地預測調試時間非常困難 - 編寫代碼很容易估計，但將其調試到功能有效的代碼是完全不同的。因此，我發現它並沒有確切的科學，但我只是把任務放在一堆，所以我有足夠的調試空間。

另請參閱Evidence Based Scheduling這是FogCreek爲其FogBugz產品開發的時間表中的一個迷人概念。

Answer 5

你和世界其他地方。

您需要更多更詳細的設計，更準確的估計以及接受的意願，有時最佳解決方案不一定是最佳解決方案（例如，您可以在彙編器中編寫一些循環以獲得最佳性能，但是這樣做採取比剛剛做的更長的時間

for (i=1; i<=10; i++) {} 

）。花費的時間真的值得用於導彈系統的會計套餐。

Answer 6

我使用了一些技巧。第一個是簡單的待辦事項清單。在早上，我寫下了我今天的任務。我嘗試着去完成一項任務，直到我能夠完成任務。只有當我完成我自己的滿意度時，我纔會把它消除。我的待辦事項清單幫助我保持專注。當中斷進入時，我可以有意識地選擇是否足夠重要，以打斷我現在正在做的事情。

我使用的第二種技術是放棄「完成」設計的想法。相反，我將重點放在我已經開始稱之爲「繼任」上，即設計經歷了可預測的階段。每個階段都很好地支持當前的功能，並且在下一階段的某個階段會成功。這讓我做得很好，我可以引以爲傲的工作，而不會過度設計。

我有直覺，有這樣演替（如http://www.threeriversinstitute.org/FirstOneThenMany.html），將覆蓋大部分設計的一個小目錄。與此同時，我試圖記住「足夠的一天是它的麻煩」。

Answer 7

我喜歡設計，但是隨着時間的推移，我發現前期的許多設計很像建造城堡到天空 - 它太多的推測，但是受過良好教育，缺少實際實施和使用設計。

所以今天我更接受的是，在實施設計的同時，將學習了很多關於它的新東西，並且需要將這種學習反饋到設計中。這樣做是一種有趣的技能，其中包括通過保持簡單設計的靈活性，避免重複和凝聚力以及解耦，以小的受控步驟改變設計（=重構）以及編寫必要的技巧廣泛的自動化測試套件，可以使這種更改變得安全。

對於我來說，這似乎是比「前期設計推測」更好的方法 - 另外，它使我同樣準備好了設計需要更改的不可避免的時刻，因爲這是一個簡單的不可預測的問題更改要求。

Answer 8

溝通。

不要急於自己進入編程錯誤的最好方式就是溝通。是的，良好的問責制。如果辦公室裏的另一個人參與了這個過程，那麼結果就越好。如果一個程序員只是承擔這個任務而不擔心任何其他人，那麼錯誤的可能性就更大。

問責清單：

1. 我們怎麼支持呢？
2. 誰需要知道發生了什麼變化？
3. 爲什麼我們要做這個呢？
4. 會不會有人不希望這個改變？
5. 有人會理解我是怎麼做到的嗎？
6. 用戶將如何感知和使用此更改？

一個skepticle comrad通常是足夠好的幫助。功能規格很好，他們通常回答所有這些想法。但是，有時與另一個人的對話可以幫助你，並且你可以更快地從門外獲得變化。

Answer 9

除，除，除。清單所有將被要求完成項目，然後列出所有步驟步驟那些步驟都需要進行總結，依此類推，直到你達到你有絕對的把握，你可以在一天或更短的時間完成原子項目。添加所有這些值的持續時間以達到一段時間。

然後加倍。現在你有一個數字，如果壓抑，至少有些現實。

Answer 10

如果發佈之前，可能「對設計的睡眠」。我離開工作後發現，我通常會想到我錯過的事情。這通常發生在我躺在牀上睡覺之前，甚至在第二天洗澡的時候。

我也覺得有價值有一個同行/朋友說，我相信檢討我有什麼分發它之前。其他人幾乎總是看到我沒有想到或誤傳的東西。

Answer 11

我喜歡像其他人所說的那樣做。用僞代碼寫下你的應用程序的流程。這立即突出了一些可能需要進一步關注的細節領域，這些領域並不明顯。

僞代碼對於可以驗證您的方法是否滿足其需求的業務用戶也是可讀的。

使用僞代碼還創建了一個很好一套可以放在作爲最終解決方案的接口使用方法。一旦僞代碼非常緊密，查找模式並查看一些常見的GOF模式。它們不必是完美的，但是使用它們會在修改過程中稍後重寫代碼時讓你感到羞恥。

只需服用一到兩個小時的寫入僞代碼，產生一些非常寶貴的時間節省件以後： 1.一種對象模型出現 2.程序的流被清楚地爲他人 3.定義它可以用作文檔您的設計有一些改進 4.評論更容易添加，並且對於其他人查看您的代碼將更加清晰。

祝你好運！

Answer 12

我發現，最好的方式，以確保你選擇了一個好的設計是爲了確保你理解這個問題，知道你有侷限性，並且知道什麼東西是必備與nice-對富人。

理解問題將涉及到誰說話有需要的人，讓他們掛靠在需要而不是先被做的他們是怎麼想它應該得到的所作所爲。一旦你知道實際發生了什麼，你可以回過頭來談談關於如何做的要求。

知道你的限制可能很容易：需要在iPhone上運行;必須是一個Web應用程序;需要與已有的Java代碼和部署設置集成;等等。這可能相當困難：您不知道您的用戶羣的潛在規模是多少（幾百？幾千？百萬？）;你不知道你是否需要本地化它（儘管如果你不確定，假設你將不得不）。

必備VS，可有可無富人：這可能是最困難的部分。用戶經常對「需求」（「應該看起來就像Excel」）有情緒上的依戀，而這些「需求」實際上並不是「必須發生」的東西的一部分。你經常需要兼顧功能和期望才能獲得可接受的實現。你不能總是給每個人一匹小馬。

確保你寫下所有這些！即使它沿着這個方向發展，或者設計很小，當你需要做出關於提交資源的決定時，有一個「這就是我們現在計劃要做的事情」的指南，這使得它更容易限制自己實施一個非常酷的專家級功能，而不是無聊的必備功能。

Answer 13

既然你認識，你覺得有必要提供一個快速的解決方案，也許它會讓你放慢腳步意識到，你或許可以解決問題更快，如果你在設計上花更多的時間的前期提供它越快。例如，如果您花費3小時設計和30小時書寫代碼，則可能意味着如果花費6小時設計，則可能需要花費10個小時編寫代碼。 （這些並不僅僅是實例）。您可能會嘗試在接下來的幾個項目中爲自己量身定製。做一些你平時表現的事情，看看你實際進行調試的設計/編碼/測試比例。然後在下一個項目中，有意增加您在設計階段花費的時間百分比，看看它是否縮短了其他階段所需的時間。因爲這些項目可能會有很大的不同，所以您將不得不嘗試幾個項目來獲得真正的基線。將其作爲測試，看看您是否可以在其他階段提高性能，從而在您花費20％以上的時間或50％的時間或100％的更多時間進行設計時提供更快的產品。

還記得後面的過程中，你發現設計的問題更難（更耗時），它是修復。