相信在，大部分是工程師，而不是科學家。
同時，本文是軟體工程革命的三部曲系列之一，當第三部結束後（預計10年底），您將能領會到我提出的，尚未有人涉足的乙個新的工程革命！
原始開發模式：
我乙個人開發了乙個mis系統，部署到客戶端。客戶提出需求，我直接在源**上修改編譯，然後提著usb，或者直接傳個package過去公升級。如果我有需要修改**，也是直接在**上修改，然後編譯，發布。
可是如果我面對著10個顧客，很快就會力不從心，有時候改了，自己以為所有影響都考慮到了，可是部署到了客戶端，第二天就打**來說啟動不了。然後只好親自去客戶現場乙個個修改。（親身體會）
工程模式：
每次修改**的時候，首先寫乙份分析報告，包括需要修改的**部分，修改的目的，受影響的其他依賴dll檔案。
（省略n步的開發、回歸測試、功能測試）
結束後，傳到實驗室的測試機進行穩定性測試。一般要進行3天到乙個星期。實驗環境和客戶環境是一致的。然後再部署到客戶端。
對比：
明顯工程級別的開發煩瑣很多，而且「不用腦」的更多了，我們胸前帶著光榮的「software engineer」 （軟體工程師），表示我們幹的東西就越不用腦子，越機械。
所以，我就得到了工程的核心思想。
核心思想是：在萬變中尋找不變，並不用思考的服從。
無論是開發軟體過程、還是開百貨連鎖店、還是任何大規模的專案，必定符合工程的思想，就是盡可能的不用腦子。
所以，問題就來到了與工程相關的技術這一點上了。
與工程相關的技術包括什麼？例如orm框架、持久層框架、金色海洋的自然框架、 hibernate、spring、基於角色的許可權系統（rbac）、資料探勘（不包括分析）、甚至.net平台也是工程的產物，而不是科學的產物！
現在就讓我乙個個去分析這些工程技術的本質共同點。
上吵的最厲害的，無非就是資料訪問和許可權。
首先您的許可權框架無論用什麼死人技術、無論多麼的方便甚至吹的天花亂墜，您的技術必定要提供乙個功能：
根據當前登入的使用者名稱（username），是否擁有對應的資源編號（resourceid），如果有，表示能操作、如果沒有、表示沒有許可權。
在很早的act理論裡面，提供了乙個訪問控制列表。簡單的模型，就是設定了每乙個使用者對應的資源列表。然後判斷許可權的時候去檢視這個列表是否包含了資源編號。
user <------> resourceid
可是偉大的工程師們發現，這個user非常不穩定，小張今天是科長，明天是處長；小李今天在庶務二科，明天就到了庶務三科。這樣變得經常修改許可權列表。怎麼解決？您動動腳趾頭就想到了，新增乙個中間層去隔離變動。於是出現了rbac
user <------> role <-------> resourceid
調整之後，由於role/resource之間的變化是很小的，剩下的變化就存在了user/role之中，瞬間就解決了50%的工作量。
一項技術不過癮，我再解釋下資料探勘。
首先我先列舉一些讓這個技術與外行人隔離的術語。
olap / etl / 資料倉儲 / 事實表 fact table / 維度表 dimention table 。。。
首先，假設資料庫的銷售資料表是
pos_salesreceipt
{merchantcode //商家編碼
merchantname //商家名稱
shopcode //門店編碼
shopname //門店名稱
itemcode //商品編碼
itemname //商品名稱
salesqty //銷售數量
salesprice //銷售**
createdate //建立日期
讓我們回想下，如果要查詢銷售資料怎麼查？寫sql貝。例如
a. 查詢時間段內的銷售記錄，不就是
select sum(saleprice) from pos_salesreceipt where createdate > :datefrom ...
b. 查詢某門店的銷售記錄，不就是
select sum(saleprice) from pos_salesreceipt where shopcode = :shopcode ...
如果門店有地區的區分，則使用join去鏈結地區的表，然後修改一下查詢條件。 剩下的例子就不舉了。
可是偉大的工程師們又發現，這些銷售記錄往往是百萬千萬級別的，但是查詢條件是百、千級別的。如果每次查詢都需要遍歷整個銷售資料表，就太慢了。而且當業務發生變化，例如國內企業變成了國際企業，則銷售資料需要新增國家的字段等等。
怎麼辦？讓我們在動動腳趾頭吧！新增中間表，然後加外來鍵！
首先我們把銷售表拆分成以下（先拆3張吧）：
pos_salesreceipt ---- dm_shop（門店表） ---- dm_merchant（**商表） ---- dm_datetime（時間表）
---- dm_item（商品表）
然後對應的表結構變成：
pos_salesreceipt
salesqty //銷售數量
salesprice //銷售**
dm_shop_pkcode //外來鍵指向門店表
dm_merchant_pkcode //外來鍵指向**商表
dm_datetime_pkcode //外來鍵指向時間表
dm_item_pkcode //外來鍵指向商品表
dm_datetime
pkcode //主鍵
origdatetime //原銷售時間
dateofweek //銷售時間的周
dateofmonth //銷售時間的月
dateofyear //銷售時間的年
dm_shop
pkcode //主鍵
shopname //門店名稱
locationname //位址名稱
districtname //區域名稱
countryname //國家名稱
（剩下的表結構就不列舉了，反正就是簡單的拆分）
現在我們查詢，首先是搜尋拆分的表，然後通過join鏈結的銷售表，就可以獲得銷售資料，例如
a. 查詢時間段內的銷售記錄
select sum(pos_salesreceipt.saleprice) from pos_salesreceipt inner join dm_datetime on pos_salesreceipt.dm_datetime_pkcode = dm_datetime.pkcode where dm_datetime .***xx
最多加幾個group by（貌似sql的誕生就是為資料探勘服務的。。）
怎麼樣，現在覺得夠簡單了吧。這個就是資料探勘。。。my god....
所謂的etl，即使如何從一張原始銷售資料表拆分成為多張表。
所謂olap，就是如何去用一些（助記符 ）更加方便的拼sql
所謂fact table（事實表）就是pos_salesreceipt，dimention table（維度表）就是dm_datetime ...
工程技術可以一直講下去，其本質不過就是那些，咱們動動腳趾頭也能想到的。篇幅有限，我先轉戰到.net的設計。
估計各位看到這裡，會有一種醍醐灌頂的感覺，沒錯，這就是工程的核心思想。
計算機硬體不同，那麼執行的指令一定不同，不同的作業系統支援的指令也不一樣。如果要針對不同的硬體、平台去寫不同的**，估計大多數人會崩潰的。
於是偉大的工程師又出來露露臉了。無論計算機的硬體如何設計，必然遵循著一定的規律，比如暫存器、堆疊等等，那麼通過引入中間層il，讓il對映到目標**（這部是非常簡單的），然後我們的業務邏輯再對映到il，是不是工作量就減少了50%？所以為啥il長的有點像彙編之類的就是這個道理。
其實對於技術進步，我實在想不明白為什麼會這麼慢。例如.net，竟然要2k年前後才出現，而電腦在195x年就有了。不知道那些偉大的工程師們什麼時候還會再出來露露臉。
下篇，我會針對現在軟體工程中乙個薄弱環節提出自己的工程化理論，並且分析。這項環節相信大多數人都會經歷並且無可奈何。不是做不到，而是很多人沒有去「工程化」。
軟體工程三部曲
經常在反覆的做一件事情，但是沒有停下來總結的習慣，而只是處於乙個當局者的位置忘了自己的初衷，所以經常停下來想想當初做這件事情的想法，可能會更能理順我們的思路。從開始接觸軟體工程巨理論的知識，到雲山霧罩的畫uml設計圖，再到設計模式的深入學習，接著是三層架構的理解，最後是運用這些學到的東西將機房收費系...
軟體工程革命三部曲 即使定做平台設計 計畫書
整個定製流程包括 使用者反饋 過程控制 系統公升級 1.小型企業 特點 產品服務需求，規模小，不規範。定製流程 在產品中繼承反饋系統 中間控制簡單 快 系統自動公升級 2.大型企業 例如ibm 特點 產品服務需求，規範 定製流程 使用專門的協作平台 中間控制嚴格 審批 使用公升級包公升級 3.小型開...
軟體工程 軟體工程概述
一.軟體 定義 計算機系統中的程式及其文件 程式 計算任務的處理物件和處理規則的描述 文件 為了便於了解程式所需的闡明性資料 特點 軟體的種類 按功能劃分 系統軟體 支援軟體 應用軟體 二.軟體工程的起源和概念 早期電腦程式 現在人們認為 在資訊產業中，微電子是基礎，計算機和網路是載體，軟體是核心 ...