這不是一個直接的編程問題，但編程社區的一點幫助將不勝感激。如何在「快速和骯髒」和「漂亮＆一般」代碼之間找到適當的平衡點？
我患有過度廣泛性疾病。我不能停止花費寶貴的時間，使我的代碼最普通和抽象。我也可以稱之爲工具包/圖書館疾病。我傾向於把每一個編程任務變成一個普遍的問題，並試圖「編寫一個工具包」，這可以解決許多類似的問題。
我知道這是一件好事，如果有足夠的時間，但有時我應該寫一個快速原型，並且似乎無法編寫適用於特殊情況的快速和髒代碼。我經常對一個讓代碼更加通用和用戶可配置的想法感到興奮，並且低估了以這種方式實際實現代碼的時間。
其他人有這種經驗嗎？我如何強迫自己在「快速入侵」和「好的解決方案」之間找到適當的平衡點？
編寫快速和骯髒，並測試它是否工作，重構，直到你不爲代碼感到羞恥。
Test-driven development（又名TDD）是一個有用的抗衡過度推動共性 - 它灌輸一個做法，即，引述維基百科條目我只是指出，
這是代碼重要書面 只是爲了通過測試而設計的;沒有 進一步（因此未經測試） 功能應該預測和 「允許」在任何階段。
一旦你嚴格練習了一段時間（如果可行的話，最好在配對編程中，合作伙伴強化彼此的動機以遵循實踐！），你可以超越這一點。
這是通常的學習循環：shu，「retain」，在那裏你練習一種技巧，直到你掌握了它;哈，「分離」，你在哪裏平衡技術;並最終ri，「超越」，超越這種明確的學習，掌握並內化所有 - 它同樣適用於編程，就像它最初構想的No劇院一樣（大多數人West熟悉shu-ha-ri概念的人可能是在武術領域遇到過的，但從歷史上看，這已經是原來的巨大延伸;-)。
我認爲這是很多程序員面臨的問題。這就是爲什麼我們需要了解業務的項目經理。不幸的是，我們的工作環境並非純粹學術。所以我們所做的工作只有在及時滿足業務需求時纔有用。
你必須找到正確的代碼「正確」和實際交付工作軟件之間的平衡點。
符合您的期限。如果您沒有截止日期，請自行創建。
程序員不能在真空中工作，他們在那裏大部分時間都是爲了滿足業務需求。
我通常會先完成一個快速交付解決方案，然後，如果我有時間，我開始清理它的過程（確保不要中斷功能。在截止日期的最後一個好版本是運輸版本。
相信我，第一對夫婦的追尾或其他不良績效考覈的靴子會教你這個:-)
我傾向於這樣做太的重要性。但是當我開始使用重用我的「泛化」代碼時，我通常發現它不是我在新情況下所需要的。
這些天，我嘗試要等到我實現了東西幾次想應該如何推廣之前。這樣我就可以更好地瞭解我應該覆蓋的真實用例。
問題也提醒從查爾斯·摩爾在this blog post報價的我。每次你重新實現一些東西，你就會更多地瞭解它，並且你可以改進你的實現。在將實現粘貼到庫中之前，您可能應該多次重新發明輪子。
工作代碼比精心設計，但非工作代碼好。即使是最粗略的實施方式，也比沒有工作或甚至沒有完成的事情好得多。
從原型/快速和骯髒的實現很容易做到的重構和結構上的改進，因爲有一個加工基準測試反對。
正如其他人寫的，TDD是非常有用的，因爲沒有適當的測試，它很難使任何重構項目取得成功。
但最後，它計算的整個網域內的程序運行問題域和推廣中的獨立概括是非常重要的。
很多時候項目重塑到數據結構，算法，網絡協議等等，而不是使用現有的實現/庫溶液結束。
我見過許多例子，程序員實現自己的hashmaps，http實現等，而不是使用現有的。有時也許庫和應用程序之間缺乏兼容性，但可以使用facade模式來封裝外部庫的使用。
最佳答案我總是發現代碼要持續多久？您不必編寫整個框架，只需確保其可維護即可。
過度泛化有時會導致軟件反模式http://en.wikipedia.org/wiki/Softcoding – Ernelli 2010-04-18 16:14:38