我們應(yīng)該對(duì)這些新技術(shù)感到振奮。它們解決了許多它們出現(xiàn)之前存在的問題。它們的網(wǎng)站上都是各種宣稱生產(chǎn)效率如何之高的廣告語，類似于15分鐘創(chuàng)建一個(gè)博客應(yīng)用；2分鐘快速教程等。比起過去21天才能學(xué)會(huì)XXX，現(xiàn)在它們?cè)谏鲜蛛y度上早已大幅度降低。
需要潑冷水的是，本文開篇提出的問題，在上述任何一種外出和OA對(duì)接這塊需要二次開發(fā)軟件的技術(shù)下，都如幽靈般揮之不去。采用Ruby on Rails 的某高效團(tuán)隊(duì)在10人團(tuán)隊(duì)工作半年之后，構(gòu)建時(shí)間從當(dāng)初的2 分鐘變成兩個(gè)小時(shí)致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/之前采用Microsoft .NET 3.5（C# 3.0）的一個(gè)項(xiàng)目，在產(chǎn)生2 萬行代碼的時(shí)候，構(gòu)建時(shí)間已經(jīng)超過半小時(shí)。我們的一些客戶，工作在10年股票大盤演示軟件的代碼庫(kù)上——他們竭盡全力，保持技術(shù)棧與時(shí)俱進(jìn)：Spring、Hibernate、Struts 等，面對(duì)的困境是他們需要同時(shí)打開72個(gè)項(xiàng)目才能在Eclipse中獲得編譯；由于編譯打包時(shí)間過長(zhǎng)，他們?nèi)サ袅舜蟛糠值膯卧獪y(cè)試——帶來了巨大的質(zhì)量風(fēng)險(xiǎn)。
如果你真的在一個(gè)長(zhǎng)期的股票大盤演示軟件項(xiàng)目工作過，應(yīng)該清楚地了解，這種痛苦似乎是任何一種框架都不能夠根本性解決的。這些新時(shí)代的框架解決了大部分顯而易見的問題，然而在一個(gè)長(zhǎng)期項(xiàng)目中所面對(duì)的問題上，它們無能為力。一步一步：架構(gòu)是如何腐化的無論架構(gòu)師在任何時(shí)代以何種絢麗的方式描述架構(gòu)，開發(fā)中的項(xiàng)目都不會(huì)超出圖1 所示架構(gòu)。
下面為一些基本的準(zhǔn)則。
? 為了降低耦合，系統(tǒng)應(yīng)當(dāng)以恰當(dāng)?shù)姆绞竭M(jìn)行分層。目前最經(jīng)考驗(yàn)的分層是MVC+Service。
? 為了提供基礎(chǔ)的訪問，應(yīng)該引入一些基本的、平臺(tái)級(jí)別的API，用Spring 之類的框架來做這件事情。
? 用AOP 進(jìn)行橫向切分業(yè)務(wù)層面共性的操作，例如日志、權(quán)限等。
? 為了保證項(xiàng)目正常構(gòu)建，你還需要股票大盤演示軟件構(gòu)建的數(shù)據(jù)庫(kù)、持續(xù)集成服務(wù)器以及對(duì)應(yīng)的與環(huán)境無關(guān)的構(gòu)建腳本和數(shù)據(jù)庫(kù)遷移腳本。
滿足這個(gè)條件的架構(gòu)在初期是非常令人愉悅的。前面我們描述的框架都符合這種架構(gòu)。這個(gè)階段開發(fā)非?？欤?/span>IDE打開很快，開發(fā)功能完成很快，團(tuán)隊(duì)這個(gè)時(shí)候往往規(guī)模較小，交流也沒有問題。所有人都很高興——因?yàn)橛昧诵录夹g(shù)，因?yàn)檫@個(gè)架構(gòu)是如此簡(jiǎn)單、清晰、有效。
