今天，我讀到了兩篇有趣的文章：@unclebobmartin寫的The Cost of Code 和 @DocOnDev 寫的 Code as a Cause of Project Failure (讀者可以分別在這里和這里閱讀它們的中文版。)。

　　他們?cè)谟酶鞣N的論據(jù)來證明所有項(xiàng)目的失敗都是由于程序的原因。他們主要的論點(diǎn)是：如果程序沒有成本，輕巧易改變，項(xiàng)目就不可能失敗。是的。但這些是極端情況，很顯然在現(xiàn)實(shí)中是不可能的。我們并沒有生活在一個(gè)能夠時(shí)空穿梭的自由世界里(很遺憾)。現(xiàn)實(shí)生活里，程序是有成本的，而且很大，而且相信下個(gè)世紀(jì)也將會(huì)是這樣，所以這種論證證明不了什么。理想世界里不需要程序。理想世界里即使沒有計(jì)算機(jī)和其他復(fù)雜的東西，你也可以瞬間找到解決方案。所以我不認(rèn)可他們的論據(jù)。在現(xiàn)實(shí)里，程序不是項(xiàng)目失敗的主要原因。

　　程序是有成本的。程序是昂貴的。但我們并不是賣源代碼，我們賣的是解決方案。如果不需要程序代碼就能產(chǎn)生解決方案，那是再好不過了。我們以一個(gè)處理現(xiàn)實(shí)目標(biāo)的行業(yè)為例。汽車行業(yè)并不是出售碳物質(zhì)和鐵塊的 – 那是汽車。他們出售的是一種解決交通問題的方案。時(shí)空穿梭機(jī)是一個(gè)理想的方案，但很遺憾，這種方式除了能傳輸電子外，什么都傳輸不了。我們買汽車是為了能從A處到B處。我們買的是一種解決方案。

　　程序 != 解決方案

　　我認(rèn)為失敗的項(xiàng)目的主要問題是他們要么提供了糟糕的解決方案，要么根本就不是個(gè)方案。沒有人現(xiàn)在還提供驛站馬車，那已經(jīng)不是一種有效的解決方案。如果一個(gè)項(xiàng)目不能解決任何問題，它就會(huì)失敗。如果一個(gè)項(xiàng)目能解決某些問題，但做的很爛，不可用，那也是失敗。你可以用最簡(jiǎn)潔的代碼創(chuàng)造出世界上絕對(duì)最優(yōu)美的架構(gòu)。你可以做到100%的測(cè)試覆蓋率，功能相互完全不依賴，繼承關(guān)系平滑，方法沒有二義。所有的優(yōu)點(diǎn)你都具備，但如果你的程序不能有效的解決用戶的問題，項(xiàng)目仍然會(huì)不幸的失敗。

　　你也許會(huì)爭(zhēng)辯說，整潔的代碼可以讓你快速的進(jìn)行重構(gòu)，一切都可以改變。但通常，如果程序解決了錯(cuò)誤的問題，你需要完全重寫它。你不可能在驛站馬車上改造來使它跟汽車競(jìng)爭(zhēng)。

　　另一方面，如果項(xiàng)目解決了正確的問題，但有缺陷，這時(shí)整潔的代碼非常的重要。沒有整潔的代碼你不可能做迅速的調(diào)整。但你不可能按人們的需求改變更多的東西。

　　別誤會(huì)我，我相信整潔的代碼是很重要的事情，但在軟件開發(fā)的活動(dòng)中它不是最重要的資源。

　　[英文出處]：Do Really All Projects Fail Because of Code?

it知識(shí)庫(kù)：所有項(xiàng)目的失敗真的都該歸咎于程序嗎？，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。