我發現只有大約30％的代碼實際上解決了問題，其餘的問題通過日誌記錄，測試，參數檢查，異常，錯誤處理等來解決。你是否在你的代碼中發現了這個問題，並且是否有一個IDE /編輯器允許你隱藏那些並不有趣的代碼？實際代碼與支持代碼的比例
OTOH是否有語言使支持代碼更容易管理和更小？
編輯 - 我想我們都知道業務邏輯和其他代碼之間的區別。我並不是說記錄等不重要。事情是，當我編碼時，我要麼執行業務邏輯，要麼確保事情不會中斷。對我而言，這是兩種不同的思考方式，其他人是這樣開發的嗎？是否有支持這種開發方式的IDE？
如果我的IDE可以隱藏「不感興趣的代碼」，我肯定會關閉該功能。你不會希望發生這種情況，我敢打賭:)
確實有語言可以最大限度地減少支持代碼的數量，但我不認爲你可以從Java切換到可以說JavaScript，因爲在JavaScript中你不會說'我不得不聲明每一個例外......我認爲將你的支持代碼放在原處是非常必要的。
哦，你可以有你的程序正式指定和數學上證明，那麼你就不會需要支持你的代碼太多; d
「關閉」支持代碼的功能將使業務邏輯更容易識別和理解。在查看我不熟悉的域中現有的代碼庫時，我發現這非常麻煩。 – MrTelly 2009-04-15 00:14:43
如果你的IDE會隱藏參數檢查，你不能最終看到代碼（在你不熟悉的域中），而只是因爲這個特性才理解它嗎？或者如果拋出異常將被隱藏。你難道不知道代碼中會發生什麼嗎？ – 2009-04-15 00:19:26
我不要試圖讓所有例程萬無一失，只有那些暴露到外面的世界。
http://en.wikipedia.org/wiki/Folding_editor
更高，更動態語言通常是更簡潔。弱打字也可以節省很多代碼。當然有折衷。
摺疊是一種拖拽......或者至少是在一些IDE中實現的。就像，我有一些由Eclipse摺疊代碼的方式造成的悲傷。 – 2009-04-15 00:21:17
我使用Visual Studio中的#region指令來摺疊不是主要焦點的代碼塊，例如，單元測試。使用log4net日誌記錄只能是一行。我還沒有找到任何方法來減少參數檢查代碼，儘管聽起來像C＃4有某種契約框架可以幫助那裏。
您所指的真實代碼通常稱爲「業務邏輯」。
在一個好的單元測試系統中，你的單元測試應該在他們自己的類中（可能是他們自己的程序集），所以這不應該是一個問題。
其餘大部分都是基於語言的。語言越先進，越能避免在某種程度上編寫支持代碼。此外，一個目標明確的開發系統可以幫助您避免編寫大量代碼（Visual Basic的屏幕生成器，Ruby on Rails，...），但這些抽象可能會崩潰並導致您編寫與其他任何代碼一樣多的代碼if您可以使用它來開發目標類型的應用以外的目標。 （VB &如果你計算素數，紅寶石並沒有那麼大的幫助）
除了語言/平臺，你有重構 - 消除所有支持代碼，你可以（以及冗餘在你的業務邏輯中）保持你的代碼基礎乾淨而小巧。
在練習高級重構時，最終可能會爲自己編寫工具。
有時將數據從代碼中抽象出來並存儲到某種結構化文件中可以消除大量的支持代碼，並將剩餘的代碼移動到「業務邏輯」中，因爲現在解析該數據並將其設置爲「業務」的一部分「你的程序確實如此。
這是一個很好的折衷方案，因爲這種類型的業務邏輯往往更具可讀性並且更易於考慮因素。這種抽象的另一個好處是，你所有的「配置」現在都是在數據中完成的，這些數據往往會使它成爲別人的問題。
作爲這種類型的工具的一個例子：Rails本身！它需要很多Web開發的樣板，並將其從代碼和因數據和簡單代碼驅動的庫中排除（Ruby模糊了代碼和數據之間的界限 - 它們的數據文件實際上循環回到在Ruby代碼中指定的地方！ ）
支持代碼與「真實代碼」一樣重要。通過支持代碼和其他任何東西一樣可以確定您的產品的質量。
考慮一輛汽車。就從A點到B點而言，這隻需要一個推車：一個框架，一個座椅，一個引擎，幾個輪胎。但現代汽車不僅僅是基礎知識。採用電子發動機定時的高效發動機。自動傳輸。鬥座。暖氣和空調。齒條和小齒輪轉向。動力剎車。防抱死制動器。安靜，舒適的小屋免受天氣影響。氣囊。褶皺區域和其他先進的安全功能。等等
即使在軟件中，細節和執行也很重要。如果你發現你的「支持代碼」往往看起來更像是黑客和黑客，那麼現在是時候重新考慮你的基本方法了。但最終的契合和完成決定了最終產品的質量。
編輯：你應該問自己的問題：
是您的「支持代碼」：
這些問題的答案可能會影響您對您的「支持代碼」的關心程度。
編輯：迴應戴夫·特維的評論：
我鼓勵重讀原題的上市「支持代碼」是「錯誤處理」的例子之一。考慮一下這一點。想象一下，例如汽車，微波爐甚至操作系統。應該將錯誤處理降級爲二等公民身份，因爲它具有某種抽象意義上的「支持」功能？在汽車中，安全功能是車輛基本設計的一部分，佔車輛價值的很大一部分。微波爐的安全功能和「錯誤處理」（實際上，微波爐的嵌入式軟件也是）其價值的重要組成部分。如果屏蔽不當，微波爐可以在適當的環境下烹飪食物，但這會對操作人員造成危害。
每一個工具（軟件或其他方式）的隱含的功能集包括這個名單：
一切任何人有過建造或使用了這些 特徵。如果不理解這一點，將會導致未能很好地執行這些功能，這些功能會導致低價值和低商業利益的劣質產品。沒有「支持代碼」這樣的東西，對功能的完成意味着什麼只有誤解。僅在實驗室條件下才能在摘要中使用的「特徵」是實驗，而不是產品的一部分。
漂浮在骯髒，醜陋的支持代碼沼澤上的純淨原始特徵的想法是軟件開發的錯誤形象。相反，您可以考慮精心打造，使用直觀，功能強大的高雅整合機械。
我有一些同事曾經被一位客戶啃過一個逾期未交的項目，向客戶吹噓說他們已經寫了5倍於操作代碼的測試代碼。
客戶不開心，「不開心」我的意思是他們的皮膚變成了綠色，他們長到了正常尺寸的5倍，他們的衣服也彈了出來。
您可以在檢查參數和事物的工具程序集中創建一個靜態類。例如在Spring框架中（這是我的想法），它有一個Assert類，它確保字符串參數不爲空或對象參數不爲空，確實很快。它清理驗證碼並減少重複的代碼，這是雙贏。
支持代碼很重要，但是當你不想要的時候，你不想讓它分心。有兩種技術可以提供幫助。
一個語言具有一流的功能將幫助你模塊化代碼，以便記錄，定時等可以實現一次，然後與許多其它模塊相結合。它也將幫助你編寫單元測試。學習這些技巧的一些好方法是閱讀文章Why Functional Programming Matters並瞭解QuickCheck工具。 （不，我不是約翰休斯的先生，但他確實做了很棒的工作。）
如果你不能使用功能強大的編程語言進行模塊化和重用，或者你不想使用，Don Knuth的Literate Programming技術將幫助您組織您的代碼，以便您可以按照自己想要的方式拆分部件，並在您需要時只注意想要的內容。文學編程工具支持任何可以用ASCII編寫的語言，以及這些語言的組合。
這就像你想前往派克峯頂。你可以帶溫尼巴戈，你可以帶你的SUV，或者摩托車，或者騎上你的自行車。一些方法是或多或少的昂貴的，更快的等等。有時你最終會帶走很多東西，嚴格來說，這些東西並不是爲了完成垂直進度而存在的。在冷藏室裏喝啤酒真好。但值得記住的是，你要對與你同行的一切負責。
Aspect Oriented Programming部分解決了這個問題。它允許您將代碼注入現有的源代碼/字節代碼。通過這種方式，您可以使日誌等任務出現在其自己的模塊中，而不是交織在業務邏輯中。
工作擴展填充它的容器。這聽起來像是一個經濟問題。 （即優化您的輸出 - 功能爲用戶和開發人員的功能）與昂貴的投入（花費時間寫功能，花時間寫水暖代碼。）
您必須包括用戶可見的功能，或者你沒有可行的產品或工作。一旦完成了部分完成，剩餘的時間預算將分爲具有可見的回報率和不可見的（但是肯定的）回報率的活動，如異常記錄，內存管理等。
什麼都可以語言使實現功能更便宜可能會增加您的功能/管道代碼比率。同樣，無論什麼語言使得實現管道代碼更便宜，可能會增加管道代碼的功能，因爲您已經騰出更多時間來編寫功能。
與所有優化問題一樣，您會產生2種效果 - 支持代碼大小的增加（因爲您使用便宜的代碼生成），並增加了功能相關代碼的大小（因爲您有更多的時間來寫功能），所以最終的比例可能難以預測。
我不吝惜90％的代碼是數據訪問管道，因爲它全部是可測試的，代碼生成且非常便宜，而手寫的特定於域的代碼只有10％。
你用來編碼的語言是什麼？ – 2009-04-15 00:06:42
我正在使用C＃，並且我在C++和Java中看到過相同的模式 – MrTelly 2009-04-15 00:13:11
IMHE，它主要發生在讓IDE爲您編寫代碼的情況下。然後，你負責。它有一個不隱藏的惡習。驚喜！很快你就沒有處理這個問題，你正在重新研究這個工具。 – dkretz 2009-04-15 03:34:11