爲什麼代碼質量不受歡迎？

Question

我喜歡我的代碼是正確的，即正確格式化，可讀，設計，測試，檢查錯誤等。事實上，我對此很狂熱。 （Maybe even more than fanatic...）但根據我的經驗，幫助代碼質量的行爲很難實現。 （代碼質量指的是你每天生產的代碼的質量，整個軟件質量與開發過程等問題的範圍更廣，而不是這個問題的範圍。）

代碼質量似乎不受歡迎。從我的經驗的一些例子包括

• 也許每個Java開發人員都知道JUnit中，幾乎所有的語言實現xUnit框架，但我知道所有的公司中，只有極少數的適當的單元測試存在（如果有的話）。我知道，由於技術限制或按期限來編寫單元測試並不總是可能的，但在我看到的情況下，單元測試就是一種選擇。如果開發人員想爲他/她的新代碼編寫一些測試，他/她可以這樣做。我的結論是開發人員不想編寫測試。

• 靜態代碼分析通常用於小型項目，但並未真正用於強制執行編碼約定或在企業項目中發現可能的錯誤。通常甚至編譯器警告（如潛在的空指針訪問）都被忽略。

• 會議發言人和雜誌會談論很多關於EJB3.1，OSGI，雲和其他新技術，但幾乎不涉及新的測試技術或工具，新的靜態代碼分析方法（如SAT求解），開發過程幫助保持較高的質量，遺留代碼的一些討厭的野獸是如何被帶到測試中的......（我沒有參加很多會議，對於敏捷主題的會議可能看起來不同，因爲單元測試和CI等都具有較高的價值。 ）

那麼爲什麼代碼質量如此不受歡迎/被認爲無聊？

編輯：
感謝你對你的答案。他們中的大多數都涉及單元測試（並已在related question中討論過）。但是還有很多其他的東西可以用來保持代碼質量（參見related question）。即使您無法使用單元測試，您也可以使用每日構建，爲您的IDE或開發過程添加一些靜態代碼分析，嘗試配對編程或強制執行關鍵代碼的審查。

Answer 1

• 懶惰/考慮鏜
• 管理感覺這是不必要的 - 無知「僅僅做是正確的」的態度。
• 「這種小項目不需要代碼 質量管理」變成「現在 這將是成本太高實現這個大 項目 代碼質量管理」

我不同意它的平淡，雖然。堅實的單元測試設計使創建測試變得輕而易舉，並使其運行更加有趣。

Calculating vector flow control - PASSED 
Assigning flux capacitor variance level - PASSED 
Rerouting superconductors for faster dialing sequence - PASSED 
Running Firefly hull checks - PASSED 
Unit tests complete. 4/4 PASSED. 

任何事情一樣可以得到無聊，如果你做太多的，但花10分鐘或20分鐘幾個小時編碼後寫一些複雜的功能，一些隨機測試是不會從你吸創意生活。

Answer 2

單元測試需要額外的工作。如果程序員看到他的產品「有效」（例如，沒有進行單元測試），爲什麼要這樣做？特別是當它是幾乎沒有執行程序中的一個功能一樣有趣，等大多數人只是往往是懶惰的，當它歸結到它，這是不太好東西......

Answer 3

代碼質量無論人們試圖做出多少努力，它都是特定於上下文的，並且很難一概而論。

它與理論和應用的區別很相似。

Answer 4

我想答案是一樣的問題「爲什麼代碼質量不受歡迎？

我認爲最主要原因是：

開發商

• 懶惰。爲什麼要花時間準備單元測試，查看解決方案，如果已經實施？
• 管理不當。爲什麼要求開發人員處理代碼質量問題，如果有成千上萬的新功能請求，程序員可以簡單地實現某些功能，而不是考慮已經實現的功能。我見過，而通常（但從來沒有從那些已經質量癮君子程序員）

Answer 5

一個態度是，編寫單元測試只是強迫你寫更多的代碼沒有得到任何額外的功能所付出的努力。而且他們認爲，在產品中增加功能而不是僅僅創建「元代碼」會更好。

這種態度通常是作爲單元測試趕上你知道會很嚴重並且很難在生產環境中找到更多的bug消退。

Answer 6

這讓我想起這個Monty Python小品的：。。。

「興奮不，這不是它的呆板單調呆板我的上帝是沉悶的，它是如此拼命枯燥和乏味和悶熱和無聊和DES-per-吃完了DULL「。

Answer 7

代碼審查不是一門精確的科學。 Metrics用於某種方式是有爭議的。某處：「您無法控制無法測量的東西」

假設您有一個包含35個參數的5000行的巨大函數。你可以單元測試你想要的多少，它可以做它應該做的事情。無論輸入是什麼。所以基於單元測試，這個功能是「完美」的。除了正確性之外，還有其他一些quality attributes you might want to measure。性能，可擴展性，可維護性，可用性等。你有沒有想過爲什麼軟件維護是如此惡夢？

真正的軟件項目質量控制不僅僅是簡單地檢查代碼是否正確。如果你檢查V-Model of software development，你會注意到編碼只是整個等式的一小部分。

軟件質量控制的可以去到項目的整體成本就高達60％。這是巨大的。相反，人們寧願削減到0％，回家認爲他們做出了正確的選擇。我認爲爲什麼這麼短的時間致力於軟件質量的真正原因是因爲軟件質量尚未得到很好的理解。

• 有什麼來衡量？
• 我們如何衡量它？
• 誰來衡量它？
• 從測量中得到/失去什麼？

許多編碼血汗工廠並沒有意識到「現在減少錯誤」和「稍後獲利更多」之間的關係。相反，他們所看到的只是「現在浪費時間」和「現在利潤較少」。即使在顯示相反的圖像時也是如此。

此外，軟件質量控制和software engineering作爲一個整體是一個相對較新的學科。到目前爲止，很多編程空間都被網絡牛仔採用。你聽過多少次「任何人」都可以編程？任何人都可以編寫代碼，但並不是每個人都可以成爲程序員。

編輯*

我遇到this paper (PDF)這是從誰說：「你無法控制你無法衡量的東西」的人。基本上他說，控制一切並不像他想象的那樣理想。這不是一個確切的烹飪方法，你可以盲目地應用於像軟件工程學校想要讓你思考的所有項目。他只是增加了另一個參數來控制「我想控制這個項目嗎？是否需要？」

Answer 8

我會說很多原因。首先，如果應用程序/項目很小或者沒有在大範圍內傳送非常重要的數據，那麼編寫測試所需的時間就會更好地用於編寫實際的應用程序。

質量要求達到要求進行單元測試的水平有一個閾值。

還有許多方法不易測試的問題。他們可能依賴數據庫中的數據或類似數據，這就造成了設置模型數據以供給方法的麻煩。即使您設置了模型數據 - 您是否可以確定數據庫的行爲方式相同？

單元測試在發現尚未考慮的問題方面也很薄弱。也就是說，單元測試在模擬意外情況時很糟糕。如果您沒有考慮停電時會發生什麼，如果網絡鏈路發送仍然是CRC正確的錯誤數據。爲此編寫測試是徒勞的。

我都支持代碼檢查，因爲他們讓程序員分享其他程序員的經驗和代碼風格。

Answer 9

「有沒有寫測試的常見藉口，但他們只是藉口。」

他們是？讓八個程序員一起在一個房間裏，問他們一個關於如何最好地保持代碼質量的問題，並且根據他們的年齡，教育和偏好，你會得到九個不同的答案。 20世紀70年代計算機科學家們會對單元測試的概念感到嘲笑;我不確定他們會錯的。

Answer 10

這是疼痛的基本心理學。當你跑步達到最後期限時，代碼質量就會佔據最後一個席位。我們討厭它，因爲它沉悶乏味。

Answer 11

當程序員忘記或者很天真，並且像他們的代碼一樣在稍後的日子（或者他們自己的月/年下線）不會被別人查看時，會產生很多問題。

此外，評論並不像實際編寫一段漂亮的代碼那麼「酷」。

Answer 12

我沒有看到提及的一個重要因素是任何流程改進（單元測試，連續集成，代碼評審等等）都需要在組織內部擁有一個致力於該技術的倡導者，在組織內部有影響力，並且願意做工作來說服其他人的價值。

例如，我剛剛看到一個工程組織真正認真對待代碼審查。那家公司有一位軟件副總裁，他是一位真正的信徒，他會參與代碼評審，以確保他們能夠正確完成任務。他們偶然有我工作過的任何團隊的最佳生產力和質量。

另一個例子是當我在另一家公司實施單元測試解決方案時。起初，沒有人使用它，儘管管理堅持。但是我們中的一些人真正努力地談論單元測試，並且爲想要開始單元測試的任何人提供儘可能多的幫助。最終，一旦他們開始看到單元測試的優點，一些最受尊敬的開發人員簽名。之後，我們的測試覆蓋率大幅提高。

我剛想到另一個因素 - 一些工具需要大量時間才能入門，而啓動時間可能很難實現。靜態分析工具可能會很糟糕 - 您運行該工具，並報告2000個「問題」，其中大部分都是無害的。一旦正確配置了工具，假陽性問題就會大大減少，但有人必須花時間，並且承諾隨着時間的推移維護工具配置。

Answer 13

堆棧溢出部分的一個明顯的答案是它不是論壇。它是一個問題和答案的數據庫，這意味着重複的問題試圖避免。

關於代碼質量，您可以想到多少個不同的問題？這就是爲什麼沒有關於「代碼質量」的50,000個問題。除此之外，任何聲稱會議發言人不想談論單元測試或代碼質量的人都顯然需要參加更多的會議。

我也見過關於持續集成的文章。

有不 編寫測試的常見的藉口，但他們只是 藉口。如果想要寫一些 測試爲他/她的新代碼，那麼就可能

哦，真的？即使你的老闆說「我不會因浪費時間進行單元測試而付出代價」？ 即使你正在一些沒有單元測試框架的嵌入式平臺上工作嗎？ 即使你在緊迫的最後期限之下工作，試圖達到一些短期目標，即使以長期代碼質量爲代價？

不可以。編寫單元測試並不總是可行的。它有許多常見的障礙。這並不是說我們不應該嘗試來編寫更多更好的測試。只是有時候，我們沒有機會。

就個人而言，我厭倦了「代碼質量」的討論，因爲它們往往

• 太在意假設的例子，以及一些個人的過於頻繁的心血結晶，誰真的沒有考慮過如何適用於其他人的項目，或與他正在編寫的不同尺寸的代碼庫，
• 傾向於過於情緒化，並且讓我們的代碼具有太多人性特徵（想想術語「代碼氣味」，對於很好的例子），
• 被寫作可怕的臃腫，過度複雜和冗長的c因爲太多的抽象層次，或者誰會通過「看起來我可以把這塊代碼用於未來項目中」來判斷代碼是否可重用，而不是更有意義的「我實際上已經能夠獲得這塊代碼並在不同的項目中重用它「。

我當然有興趣編寫高質量的代碼。我只是傾向於被通常談論代碼質量的人關閉。

Answer 14

另外幾個人碰到的事情是，大多數開發工程師都是可怕的測試人員。他們沒有專業知識或想法來有效地測試自己的代碼。這意味着單元測試對他們來說似乎不是很有價值 - 因爲他們的所有代碼都會通過單元測試，爲什麼還要寫它們呢？

教育和指導可以提供幫助，測試驅動的開發也是如此。如果你先寫測試，你至少主要考慮測試，而不是試圖完成測試，所以你可以提交代碼...

Answer 15

我還沒有看到單元測試寫在一個常規基礎。之所以這樣做，是因爲在項目開始時代碼變得過於廣泛，所以每個人都放棄編寫單元測試，直到一切都穩定下來。之後，每個人都很高興，不需要進行單元測試。因此，我們有幾個測試作爲歷史記錄保留在那裏，但它們未被使用，可能與當前代碼不兼容。

我個人認爲，爲大項目編寫單元測試是不可行的，儘管我承認我沒有嘗試過，也沒有與做過的人交談過。業務邏輯中有很多規則，如果你只是稍微改變一些東西，你就無法知道哪些測試要更新，除了那些會崩潰的東西。誰知道，舊的測試現在可能不能涵蓋所有的可能性，並且需要時間來回憶五年前寫的東西。

另一個原因是缺乏時間。當你在任務分配的地方寫上「完成時間：O，5個人/天」時，你只有時間來實施它並進行淺層測試，而不是想到所有可能的案例和與其他項目部分的關係，必要的測試。實際上可能需要0.5天的時間才能完成某些工作，並需要幾周的時間才能完成測試。除非你專門給出了創建測試的命令，否則沒有人會明白這會導致大量的時間浪費，從而導致大聲喧譁或者糟糕的評論。不，對於我們複雜的企業應用程序，我無法想象在五分鐘內完成任務的良好測試覆蓋率。這需要時間，可能對大多數應用程序模塊有深入的瞭解。

因此，我所看到的原因是時間損失，這不會產生有用的功能，而且是維護/更新舊測試以反映新業務規則的噩夢。即使有人願意，只有經驗豐富的同事才能撰寫這些測試 - 至少一年深入參與該項目，但真正需要兩三個測試。所以新的同事不管理適當的測試。創建不好的測試沒有意義。

Answer 16

爲什麼代碼質量如此不受歡迎？

因爲我們的職業不專業。

但是，是那些關心代碼質量的人。你可以從Software Craftsmanship運動的discussion group找到志同道合的人。但不幸的是，大多數軟件業者並不瞭解代碼質量的價值，或者甚至不知道什麼構成了良好的代碼。

Answer 17

代碼質量不受歡迎嗎？讓我反駁這個事實。

Agile 2009等會議在持續集成，測試技術和工具方面有大量的演講。像Devoxx和Jazoon這樣的技術會議也對這些主題有着公平的分享。 甚至有整個會議致力於持續集成&測試（CITCON，在3大洲每年發生3次）。事實上，我個人的感覺是，這些談話非常普遍，他們正處於對我完全無聊的邊緣。

在我作爲顧問的經驗中，關於代碼質量技術&工具的諮詢實際上很容易推銷（雖然不是很高的薪水）。儘管我認爲Code Quality是一個受歡迎的主題，但我寧願同意開發人員不會（通常）做好測試或足夠測試的事實。我對這個事實有一個相當簡單的解釋。基本上，這歸結爲這些技術仍然是相當新的（TDD是15歲，CI小於10），並且他們必須與1）管理者競爭，2）開發者的方法「運作良好到目前爲止足夠「（無論如何）。用Geoffrey Moore的話來說，現代的代碼質量技術在採用曲線中還處於早期階段。整個行業採用它們需要時間。

不過，好消息是，我現在遇到了剛剛接受過TDD教育並且對其真正感興趣的大學新生。這是最近的一次發展。一旦有足夠的這些產品上市，行業將別無選擇，只能改變。

Answer 18

在別人x年前寫的神祕密碼叢林中，一天之內發現一些極其重要的隨機「特徵」，一天之內沒有任何線索，發生了什麼問題，爲什麼會出錯並且完全沒有任何想法當它應該在幾個小時內結束時，什麼可以解決它。當它完成時，沒有人會因爲巨大的延遲而感到滿意。

那裏 - 看到了。

Answer 19

簡答：這是那些無形的東西之一，只有經驗豐富的其他開發人員和工程師纔會讚賞，除非出現問題。在這一點上，管理人員和客戶一片譁然，並要求正式流程沒有到位。

較長的答案：這種短視方法不限於軟件開發。美國的汽車行業（或者剩下的）可能就是最好的例子。

當項目作爲一次性工作或拋棄時，正式的工程過程是很難證明正確的。當然，在項目完成之後很久，隨着不同業務部門開始依賴於自己的業務流程，它需要自己的生命（並且變得突出）。

何時需要設計新的解決方案;但沒有使用這些工具和良好實踐的做法，這些工具就沒有用處了。它們成爲一個耗時的障礙。在IT團隊支持業務的公司中，我經常看到這種情況，在這種情況下，開發往往是反動的而不是主動的。

編輯：當然，這些壞習慣和其他許多問題是像Thought Works這樣的諮詢公司能夠像他們一樣繼續發展的真正原因。

Answer 20

當你考慮工程諺語「好，快，便宜：挑二」時，這很簡單。根據我的經驗，98％的時間是快速和廉價的，而另一方面則必須承受。

Answer 21

我不知道。你見過Sonar？當然這是Maven具體，但指出你的構建和繁榮，很多指標。這是一種將促使這些代碼質量指標成爲主流的項目。

Answer 22

您被大學生或外包工作者更便宜的新鮮取代的可能性與您的代碼的可讀性成正比。

Answer 23

許多在代碼質量方面的現代寫作中強調的概念忽略了代碼質量的主要指標：代碼必須首先發揮功能。其他一切都只是達到目的的一種手段。

有些人不覺得他們有時間學習軟件工程領域的最新時尚，並且他們已經可以編寫高質量的代碼。我不能評判他們，但在我看來，如果人們無法閱讀，理解和改變代碼，很難長時間使用您的代碼。

Answer 24

管理層需要花費更多時間來節省時間。由於他們實際上不能測量「錯誤未修復」，所以他們通常更關心的是滿足他們的即時截止日期，而不是項目的長期質量。

Answer 25

也許每個Java開發人員都知道的JUnit ...

雖然我相信大多數或許多開發商都聽過的JUnit/NUnit的/其他測試框架，較少知道如何編寫使用這樣一個框架的測試。而從這些人中，很少有人很好地理解如何使測試成爲解決方案的一部分。

我已經知道單元測試和單元測試框架至少7年了。我在5-6年前嘗試在一個小型項目中使用它，但只是在過去的幾年中，我已經學會了如何做對。 （即發現，對於我和我的團隊工作的方式......）

對我來說，其中的一些事情：

• 查找有可容納單元測試的工作流。
• 在我的IDE中集成單元測試，並具有運行/調試測試的快捷方式。
• 學習如何測試什麼。 （比如如何測試登錄或訪問文件，如何從數據庫中抽象出自己，如何做模擬和使用模擬框架，學習提高可測性的技術和模式。）
• 進行一些測試比根本沒有測試要好。
• 當發現錯誤時，可以稍後寫入更多測試。編寫證明錯誤的測試，然後修復錯誤。
• 你必須練習才能更好地訓練它。

所以，直到找到正確的途徑;是啊，這是平淡的，非獎勵，很難做到，耗時等

編輯： 在這種blogpost我深入去一些這裏給出對單元測試的原因。

Answer 26

缺少「代碼質量」不費用戶，銷售員，建築師也不代碼的顯影劑;它減慢了下一次迭代，但我可以想到幾種成功的產品，似乎是由頭髮和泥土製成的。

我發現單元測試讓我更有效率，但是我看到很多格式不好，不可讀的設計不佳的代碼，它通過了所有的測試（通常是多次修補的長期代碼） 。通過測試，您將獲得一輛值得擁有道路的斯柯達，而不是Bristol的工藝。但是，如果您的「低代碼質量」並通過測試並始終如一地滿足用戶的要求，那麼這就是一個有效的商業模式。

我的結論是，開發商不想寫測試。

我不知道。一定程度上，在軟件整個教育過程沒有測試驅動的，大概應該是 - 而不是要求必須交給在運動，給單元測試給學生。在數學問題中運行支票是正常的，爲什麼不用軟件工程？

的另一件事是，單元測試需要的單位。一些開發人員發現模塊化和封裝難以做好。一個好的技術領導者會創建一個模塊化的架構來定位一個單元的範圍，因此可以很容易地單獨測試;許多系統沒有很好的建築師誰方便的可測性，或者沒有經常重構不足以減少單元間耦合。

它也很難測試分佈式或GUI驅動的應用程序，由於固有的耦合。我只有一支隊伍表現出色，並且擁有與開發部門一樣大的測試部門。

靜態代碼分析通常用於小型項目，但並未真正用於強制執行編碼約定或在企業項目中發現可能的錯誤。

我見過的每一套沒有被自動化的編碼約定在邏輯上都是不一致的，有時甚至會變得無法使用 - 甚至有人聲稱在幾個項目中「成功」使用了這些約定。非自動編碼標準似乎是政治性的而不是技術性文件。

通常甚至編譯器警告像潛在的空指針訪問被忽略。

我從來沒有在容忍編譯器警告的商店工作。

Answer 27

我認爲代碼質量過高。我做的越多，對我意味着越少。代碼質量框架更喜歡過於複雜的代碼。您從不會看到像「此代碼太抽象，沒有人會理解它」的錯誤，但例如PMD表示我的班級中有太多方法。所以我應該把這個類切成抽象的類/類（這是PMD不關心我做什麼的最好方式），或者根據功能來切斷類（最糟糕的方式，因爲它可能仍然有太多的方法 - 一直存在）。

靜態分析非常酷，但它只是警告。例如FindBugs在投射時出現問題，您應該使用instaceof來使警告消失。我不這樣做只是爲了讓FindBugs開心。

我覺得太複雜的代碼不是當方法有500行代碼，但是當方法使用500個其他方法和許多抽象只是爲了好玩。我認爲，代碼質量大師應該真正努力尋找代碼太複雜並且不太關心小事情的東西（您可以用正確的工具真正快速地重構它們）。

我不喜歡代碼覆蓋的想法，因爲它真的沒用，使單元測試無聊。我總是測試具有複雜功能的代碼，但只有代碼。我在一個100％代碼覆蓋的地方工作，這是一個真正的噩夢來改變任何事情。因爲當你改變任何東西時，你必須擔心單元測試的破裂（寫得不好），你永遠不知道該如何處理它們，很多時候我們只是將它們評論出來並添加todo來稍後修復它們。

我認爲單元測試有其自己的位置，例如我在我的網頁解析器中做了很多單元測試，因爲我一直髮現不同的錯誤或不支持的標記。測試數據庫程序真的很難，如果你也想測試數據庫邏輯，DbUnit真的很痛苦。

Answer 28

代碼質量是主觀的。主觀主題總是單調乏味。

由於目標僅僅是使某些工作成功，因此代碼質量總是排在第二位。它增加了時間和成本。 （但我並不是說它不應該被認爲是一件好事。）

99％的時間，沒有第三方的質量差的代價（除非你是製作空間轉換軟件或火車轉換軟件） 。

• 它工作嗎？ =混凝土。
• 漂亮嗎？ =在旁觀者的眼中。

閱讀弗雷德布魯克斯的神話人月。沒有銀彈。

Answer 29

在網絡世界中，我認爲這是因爲上市時間至關重要。錯誤可以在飛行中修復。重點是讓事情變得更快。如果資金飛向你，你可以修復它。但首先你想看看你的項目是否「堅持下去」。如果沒有，你會做一些新的事情。但是如果你有像Twitter或Facebook這樣的熱門遊戲，那麼你就會認真對待工程。

但是有各種編程任務。如果您要發送盒式磁帶或光盤，那麼（大多數情況下）一旦進入野外就不能進行修復。

Answer 30

人們對代碼的「好」意味着什麼沒有一個常識。很多人會下降到「我跑了」的水平，甚至「我寫了它。「

我們需要有某種好的代碼是什麼共享的意義，以及它是否事項的第一部分，我已經寫了一些想法：

http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

由於不管它是否重要，這已經被大量討論過了，如果你的代碼要活得很長，如果它真的不會銷售或者不會被部署，那麼它顯然不會。不值得這樣做，這不值得做好。

但是如果你不練習寫良性的代碼，那麼你就不能這樣做事項。我認爲人們從事的是不良工作，而不知道其他什麼。

Answer 31

我認爲，隨着代碼的質量或測試真正的問題是，你必須把大量的工作進入它，你會得到任何回報。減少錯誤==減少工作？不，總有事情要做。減少錯誤==更多的錢？不，你必須換工作才能獲得更多的錢。單元測試是英雄，你只會對自己感覺更好。我正在管理鼓勵單元測試的地方工作，但是我是唯一一個寫測試的人（我想改善它，這是我做這件事的唯一原因）。我明白，對於其他人來說，寫測試只是更多的工作，你得到沒有回報。瀏覽網頁聽起來比編寫測試要冷。

有人可能會打破你的測試，並說他不知道如何解決或註釋掉它（如果你使用maven）。

框架並不適用於真正的Web應用程序集成測試（單元測試可能會通過，但它可能無法在網頁上運行），所以即使您編寫測試，您仍然需要手動測試。

你可以使用像HtmlUnit這樣的框架，但它使用起來真的很痛苦。 Selenium會隨着網頁的每一次更改而中斷。 SQL測試幾乎是不可能的（可以爲5聯接是大量的工作，有沒有簡單的方法來產生它的DbUnit做到這一點，但首先你必須爲它提供的測試數據。測試數據）。我不知道你的網絡框架，但我們正在使用的一個真的很喜歡靜態方法，所以你真的必須努力測試代碼。

Answer 32

我的簡短答案是：除非你是寫支票的人（即自由職業者，擁有一家公司等），否則大部分時間的解脫速度對你的僱主來說更重要。鑑於這個事實，程序員有時需要在面臨最後期限時採用「快速和骯髒」的方式。

其他因素（如分析不佳和想出最後一分鐘更改的客戶）使「質量」代碼的生產更加困難。

Answer 33

我總是用高質量的代碼，而且我喜歡符合標準。即使我的html有一個文檔類型，並沒有多少人可以這麼說。

我曾遇到過代碼，它不是在數據庫的每個條目中都打印文本，而是將該文本附加到變量上，並在循環後打印出來。

代碼失敗了。它超出了內存限制。

Answer 34

代碼質量不會讓供應商賺更多的錢，其他的方式來看待它，供應商想通過指向的惡意代碼質量原因要求更多的人，更多的時間。

總之，IT服務業務規模（在過去的二十年）通過惡意代碼的質量實現，他們被允許做的事情凌亂正式，因爲客戶是在過程和認證機構出售。

除非有新的IT商業模式出現超出牛逼&計費的男，我們不能指望代碼質量將有自己的位置。

我的一些想法如何IT離岸外包的業務模式應該改變是在

http://communities.nasscom.in/discussion/topics/531869/messages

總之考慮從時間和身體（T & M）移動業務的時間和結果問責（T & A）