全端Web開發：快速開發實踐

 “在一句話中找尋我的家，一個簡潔的句子，猶如金屬鍛造。并非為了迷惑什么人。并非為了在后代之中獲取永恒的聲名。一個未命名的事物需要秩序、韻律、形式，這三個詞反對混亂和虛無。”

開發者的生產率

簡潔、高效、簡單，是當代文化所高度推崇的。或許這是因為和以前相比，現代社會變得相對豐富和復雜了。代碼簡潔、流程高效的Web應用會讓最終產 品易于維護、易于修改，最終會幫助獲取更高的利潤。同樣，程序員的工作流程和工具也應該高效，避免無謂的復雜。由于選擇太多，開發者暫時從編碼中抽身，認 真思考一下工作流程是否優化、是否高效，就變得特別重要了。

隨著Web開發方式向客戶端-服務器端架構的轉變，開發流程也面臨不斷的改變和提高。通過去掉很少用到的配置選項、使用合理的缺省值，減少了大量 不必要的工作。簡化的工作流程帶來更緊湊及時的反饋循環，頻繁的反饋讓人及時發現和解決產品中的問題。及早發現和修復缺陷提高了生產效率——也讓程序員更 加開心。更進一步說，它讓原本需要大量時間和資源才能開發維護的復雜且高質量的軟件，現在有可能花費較少的時間和資源就能做到。

大多草草了事 ……

眾所周知，衡量程序員的生產效率很難。工作時間、每日代碼量或者解決的缺陷數目，這樣的指標雖然可量化，但不是很有用。由于項目的目標、時間和其 預期壽命的不同，很難對它們做比較。沒有一個指標能適用于所有項目，足夠客觀、公正，準確地反映出程序員的工作效率。在實踐中，大多數軟件開發經理根據開 發者給出的估計和實際產出，“藝術地”維護著一張電子表格以準確估計這兩者之間的關聯度。這樣就能理解，為什么通過改進流程會提升個人和組織的效率這個假 設會被大家所接受了。

敏捷開發最早是以糾正瀑布式開發的缺陷的形式出現的，瀑布式開發傾向于一開始就負重前行，花費大量精力，組織大量活動，項目反而不會取得有意義的進展。這 種趨勢再發展就是“分析癱瘓”，當敏捷開發被初次引入時，其立即著手開發一個可工作的產品的觀點令人耳目一新。遺憾的是，隨著時間的推移，這一概念被發展 成為一種“做了再說”的方式，早期的很多活動都沒有一個定義清晰的目標。因此，如果想要生產提高效率需要，可能這樣說有違直覺，需要先 放下工作 。顯然，這不是指讓你真的放下工作，這是為了項目的質量和長期生產效率，而對暫時的衡量指標和可見進度做出犧牲的能力。

這樣做很有挑戰性。管理層希望看見手頭的項目進展，開發者喜歡編寫代碼，客戶希望看到前者真的著手開始工作了。但是過早開始可能會導致工具和開發方式選型 錯誤（或者不是最理想的）。將不適用的約定或傳統引入項目遺害無窮。早期的一點點偏差，都會讓項目偏離正確的軌道，隨著項目的進展，問題會越積越多。認識 到暫時 放下工作 ，先做一些分析，會讓工作效率更高，產品質量更高，這是需要一些遠見的。

預先分析因為采用 偽敏捷開發 （pseudo-agile）而飽受詬病（“偽”字是指這里所講的并不違背敏捷開發實踐）。凡事要三思而后行，這適用于多個層面。開發團隊領導者需要做出 項目相關的決定，每一個開發者需要了解最佳實踐和新興技術，這對他們的手頭工作可能有用。有了正確的工具和方法，會減少完成初始工作的時間和精力，如果做 對了，從長遠看會開發出一套簡單、易于維護的系統。不可將全部精力和注意力放在最緊急的任務上，而應做出根本性調整以高效地工作。在項目中可以采用敏捷開 發中歡迎變化的方式，但基礎的技術決策和相關開發流程不應有大的改動。

避免孤立地看待生產效率

顯而易見，只關注生產效率是不夠的。如果絕對孤立地看待生產效率，什么也不做或許是最好的選擇！軟件質量、可靠性、流暢的交流、功能的正確性、對 流程的遵守和約定俗成的規則同樣重要。假設其他條件一樣，最好能用最少的動作、最少的資源完成一件任務。因此，任何以提高生產效率為名義，對流程的改變， 都應該放在一個更廣闊的視野下來審視。而且，一個真正高效的流程也同樣強調質量、可靠性和其他重要的因素。

沒有一個簡單的計劃或者理論會馬上提高生產效率，這多少有點讓人失望。真正能提高生產效率的東西都是在實踐中，在具體的項目中變干邊學，發現和制 定的。先把工作完成，日復一日，就看出了流程什么地方需要完善，完善它，這樣周而復始。這些積攢下來的知識，會成為在其他項目中提高、優化流程和去除不合 理之處的源泉。

理論上說，一個軟件項目需要完成若干任務，因此在理想情況下會盡可能以最高效的方式完成。劃分成任務后，更容易理解和衡量生產效率。每一項軟件開 發任務都需要若干人，使用若干臺電腦完成。在做項目時，人與計算機，人與人，計算機與計算機之間可進行交互。所有這些，從地理上看可能分布在不同地方，如 圖7-1所示。

圖1 人與計算機的交互

考慮到這一點，就可以在如下交互之間提高生產效率：

• 人與人；
• 計算機與計算機；
• 人與計算機。

人和計算機是完成一項任務所需要的資源，如表7-1所示。為了提高生產效率，需要：

• 重新定義任務；
• 提高（給定資源或資源之間交互的）效率；
• 增加資源；
• 花費更多精力（通過加班讓單位資源的產出更高）。

表1 能提高生產效率的地方

認識到這些地方的重要性的理由很多。在某個地方沒有提高生產效率（比如最近一段時期在計算機領域沒有重大的技術創新），會影響到人的生產效率（通過加班或增加人手）。想一下這些因素和項目的關系能幫助人們有效地行動起來，可能花費相對較小的代價就能帶來顯著的提升。

這種全盤考慮的方式，能避免過份強調某一方面，去解決所有問題。一個大家都知道的例子是在項目后期，冀希望于增加工作量和人手來趕一個太具有野心 的最后期限。另一個例子是自大的開發者陷阱，他們認為不管任務的性質如何，都可以閉門造車，讓其自動化。本書強調的重點放在計算機上。

優化開發者和團隊的工作流程

迭代是一種向著最終目標邁進（最終實現目標）、不斷循環的過程。項目的每一部分都被分解成任務，經過多次迭代完成，如圖7-2所示。這種方式適用于軟件開發的方方面面，包括需求收集、設計、開發、測試和部署。

圖2 項目迭代

你需要將如下幾條謹記在心。

• 迭代需要以一種可見成果作為終結。迭代完成后的結果需能與上一個迭代的狀態，和最終希望的結果做比較。如果結果是不可見的，就說明有問題了。 可見的東西才能度量和提高。不可見的東西無法衡量、修復和提高。從這個意義上來說，可將迭代看作一種反饋循環，以行動開始，以可衡量的響應結束。
• 迭代（或反饋循環）可大可小。開發者對某段代碼的細微改動可看作一個小的迭代，而最終發布的一套完整的大型系統則是一個相對較大的迭代。部署 后的反饋可基于自動化，也可人工處理。自動化的反饋能提供一個大概的信息，顯示系統是否如預期的那樣運轉正常。但是，自動化代替不了真實用戶的反饋。
• 短周期迭代能得到更多的反饋。更多的反饋意味著看得更多。獲取更多反饋的原因很多。它能快速定位問題（或者機會），更容易在項目早期糾正方向性的錯誤。循環的周期越短，就越能及時得到反饋，效果就會越好。
• 從本質上來說，迭代中的每一點進展都會讓整個項目取得進展，因為迭代是不斷重復進行的。如何發現那些迭代中不斷重復的任務，并且改進那些對整個項目影響最大的任務，是一個挑戰。
• 對項目中任何一項任務而言，優化都是值得的。對那些重復多次的任務做優化，好處更多。如有可能，應盡力將任務自動化處理。與其“好好干”，不如減少那些不必要的任務，這聽起來看可能有違直覺，但事實卻是如此。

這些都顯而易見，是簡單的常識。但正如那些涉獵軟件開發的人所看到的，開發者是習慣的生物。很多人都習慣了某種開發流程或某些工具。這會導致大量不必要的工作，讓項目復雜化，最多只能得到次優的結果。

越快越好

我們中的大多數人都無緣發明什么重大創新，給軟件開發流程帶來革命性的改變。但是跳出自己的編程文化至少可以開開眼界，有很多現成的改進可供使用，深入研究那些成熟技術，可以讓個人獲益良多，更不用提對項目的幫助了。讓我們通過幾個例子來看看。

例子：修復Web應用

現在需要修改一個JEE Web應用（由一個包含多個WAR的EAR構成），該應用使用Maven構建，部署在JBoss應用服務器上。負責修改的開發者需要對代碼做幾處改動（在 這個過程中或多或少會犯點錯誤）。解決該問題有一種方法，需要下面幾步。首先，修改代碼。其次，鍵入命令啟動一個標準的完全構建，然后部署該應用。根據應 用的規模、單元測試的數量、構建過程和其他因素，完成第二步也許要花上幾分鐘。讓我們看看怎樣做能改善該流程。

• 首先，有很多Shell命令可用，最先想到的是命令行歷史（和搜索）。
• 構建中的每一步是否都需要執行。比如，在Maven中，使用-DskiptTests參數可顯著縮短構建時間。
• 是否需要一次完整的部署。或許不需要一次完整的構建來測試改動，可以熱部署改動代碼。
• 改動是否需要一個初始的部署環境。初始的測試也許可以在瀏覽器里完成（如果改動主要涉及HTML、CSS和JavaScript）。對于服務 器端的代碼，可以連上遠程調試器，在上下文環境中觀測相關的對象和變量，可能這就足以發現問題，避免不必要的迭代。Java代碼可以脫離完整的部署環境， 用單元測試驗證其正確性（這表明了測試驅動開發可以提高生產效率）。

例子：測試集成

這個例子還是圍繞上面項目的，但進展順利。人們一致認為應該加入測試，作為軟件開發生命周期的一部分。這可以發生在軟件開發的各個階段和層次。

• 測試人員和開發人員可以結對測試，驗證最初的需求是否和實現匹配，但是人很難保持一致，或者窮盡所有場景。
• 創建（使用JUnit）單元測試。單元測試能更全面地測試，但如果不能持續運行，效果就大打折扣了。
• 將單元測試集成進Maven構建中。在一臺持續集成服務器上構建，如果有代碼變更破壞了構建，開發者會立即受到警告。然而這還是無法說明測試覆蓋范圍有多廣，價值有多大。
• 單元測試覆蓋率報告能給出代碼覆蓋率的情況。但是測試集中于服務器端，當項目中瀏覽器端的代碼占大頭時，這就成了一個問題。
• 幸運的是，足智多謀的前端開發工程師已經開始使用Jasmine來做單元測試。使用一個插件，就能將其集成進Maven構建中。而且，JavaScript開發者可以使用在自己的工作站上安裝Karma，用它來運行客戶端代碼的單元測試。
• 隨著項目的進展，工作流程也趨于穩定，此時就可以編寫功能測試來反映用戶的使用體驗。使用Selenium可以在各種瀏覽器上運行功能測試。

這種測試場景將關注點放在如何增加對項目狀態的反饋，而不是項目的質量上。優化的價值顯而易見，缺陷被更快地發現和修復。而且，需求和實現的不一 致也能快速被發現。新的開發者能快速融入該項目，因為通過觀察和運行測試，他們能相對獨立地理解代碼。一個單元測試覆蓋率高的項目能在大規模重構后很好地 活下來。能進行如此重構的信心來源于這些自動化的測試，它們保證了功能的完備。

例子：綠地開發

作為新項目的架構師，你需要負責挑選最適用的工具，建立起系統的初始架構。對于云部署的、高擴展性的Web應用，可采用本書描述的客戶端-服務器 端架構。團隊采用一些新的工具和流程是允許的，而采用Java作為編程語言是必需的，因為這是經過實踐的，在內部被證明是能夠勝任工作的（這就除去了使用 Rails和Grails等依賴其他JVM語言的可能性）。

• 首先我們想到了Maven/JEE。雖然JAX-RS也適合開發服務器端程序，但JSF會誘導開發者使用會話，這不是我們想看到的。
• 一番調查之后我們發現，可使用Spring Roo或Play這樣的服務器端框架，來減輕構建和部署應用服務器的負擔。這里我們選用了Play，生成服務器端API，使用一些存儲在文件系統之中的示例JSON文件向外提供數據。這些模擬的服務會被稍后集成后端的服務替換。
• 前端項目使用Yeoman創建，并可能會用到JavaScript框架和相關的HTML5項目。鍵入npm search yeomangenerator會返回一些備選項，使用它們生成一個或多個客戶端項目——各自在獨立的目錄底下。通過幾個小時的調研（將前端項目集成到現 有服務上），就能大概了解每個項目的價值，然后選擇一個最適用的項目。
• 最后做一些清理工作收尾，包括提供服務器端和客戶端的示范單元測試，文件保存后就能自動運行；使用工具讓Java和JavaScript的文 檔自動化；將代碼提交到SVN，在持續集成服務器上注冊和配置項目；代碼構建完成后，服務器生成文檔并發送到統一的文檔服務器；并創建一份IDE模板，包 含經過一致同意的代碼規范默認選項。

這些前期工作完成后，在開發者實現具體的業務需求前，很多重大決策就已經定下來了。這些決策允許客戶端和服務器端進行相對獨立（并行）的開發。通 過單元測試和具體的例子，開發者為新功能添加測試時可以直接復制，得到快速反饋；也允許發布自動生成的文檔和IDE模板，鼓勵大家相對一致地編碼和注釋。

這些例子都很主觀，隨著新技術的出現，毫無疑問會改變和提高。它們的意義在于證明了與其盲目地遵循前人的實踐和習慣，對流程做持續改進也是可行的。后面的幾節旨在幫助大家進行頭腦風暴，發現那些項目中有待提高的地方。

生產率和軟件開發生命周期

需要在軟件開發生命周期的各個階段思考如何提高生產效率。這是因為對于流程一個地方的改進，不一定會帶來其他地方生產效率的提升。總的來說，可以 將和提高生產效率相關的任務按照收益遞減的順序排出優先級。雖然項目和團隊各異，還是可以總結出一些會產生主要影響的因素。總的來說，管理方式和企業文化 是最根本的，然后是整體的技術架構、具體的應用設計和底層編碼以及平臺選擇。對任務有了準確的分析和優先級，就能按照影響生產效率的重要程度優化處理。

管理方式和企業文化

通常來說，從總體上把握由很多人參與的項目能帶來最大的收益。雖然這不是本書的重點，但是管理方式、團隊活力和工作文化對所要完成的工作影響深遠。這些環 境因素設定了工作目標、組織和個人的價值觀。它們效果顯著，常常是最應該重視的地方。統一目標是最大的挑戰，尤其對大型組織來說。 查理·芒格 ，商人和投資家，因與沃倫·巴菲特的關系而被人們所熟知，他描述過聯邦快遞將員工和組織的目標統一起來，從而消除延遲這一挑戰。問題的解決之道在于保證所有參與者得到適當的激勵：

還有其他一些“大的方面”需要考慮：那些基本的組織和管理原則依然適用。分工明確、文檔集中化管理、使用版本控制，這些看起來都很新鮮，但卻常常被忽略。

技術架構

系統的整體架構決定了后續技術的選型和實現。一個在大范圍、公開部署的高擴展、基于云的應用和組織內部使用的應用不同，需要更加復雜的配置，后一 種場景對錯誤的容忍度也高。如果成員需要在編碼時考慮那些永遠也不會發生的場景，或者在項目后期要適應沒預料到的架構要求，整個團隊的生產效率就會受到拖 累。架構選型時應該明確項目的范圍。

數據存儲方式的選型是另外一個相似的例子。人們對傳統的關系型數據庫理解相對充分，它提供了引用和事務完整性，開發者認為這是理所當然的。新出現 的NoSQL方案提供了優化的寫操作，以一種限制更小的方式存儲數據。每種方案都有自己的優勢，但是沒有一種錦囊妙計能覆蓋所有的情況。出于對數據擴展性 的考慮，可能采用NoSQL方案。但是如果一開始沒有考慮到報表功能，數據就不會以一種利于高效生成報表的方式存儲。開發者可能技術出眾、效率極高，但是 在完成具體的報表任務時，也無法逾越因為采用了錯誤的數據存儲方式而導致的鴻溝。

每一門語言都有自己忠誠的信徒，他們樂此不疲地為各自語言的優點辯論。可以確定的一點是，對于一項給定的任務，某門語言的特性能讓其在更短的時間 內，更簡單地完成任務。比如，如果不需要編譯（通過使用IDE的自動編譯選項或者腳本語言），任務就能用更短的時間完成。像Java這樣的語言，有大量現 成的函數庫可用，而其他一些新語言，比如Scala和Groovy，則夸耀和其他語言有根本性的不同，使用較少的代碼就能完成同樣的任務。像Ruby和 Python這樣的腳本語言則有它們自己的工作流，在它們的領域里效率很高，而且也影響到了其他語言所使用的工具和流程。

軟件工具

選擇編程語言、開發工具和框架是架構師確立項目方向的主要領域。每個程序員在開發項目過程中所具備的能力、所受到的限制都深刻地受到這些決定的影響。技術和與之相關的工作流程都有各自的考慮，生產效率不可避免地會受到這些選擇的影響。

在 Software Tools （Addison-Wesley Professional出版，1976）一書中，Brian Kernighan說過一句名言：“編程的精髓在于控制復雜度。”試圖降低復雜度的軟件工具遍及軟件開發生命周期的方方面面：版本控制系統、文檔自動化、 覆蓋率和質量報告、測試工具、事項管理系統和持續集成服務器，這里只是僅舉幾例。除過這些，每位開發者所掌握的日常工具也能讓他和同僚之間在效率上差好幾 個數量級。

每門編程語言都有與之相關的構建工具。雖然可以混用語言和構建工具，但是基于Maven的Java、Gradle的Groovy、SBT的 Scala、Rake的Ruby都是緊密聯系在一起的。每門語言都有開發客戶端-服務器端Web應用的相關框架。Java有JEE和Spring（借由一 款高度自動化的工具Roo），還有一些較新的框架，比如Play（同時支持Scala）。同樣，Ruby有Rails、Groovy有Grails、 Python有Django。多數框架包含一個嵌入式服務器，以方便開發流程。他們通常包含起始項目，顯著地減少了費時的樣板代碼。選擇合適的框架能減少 構建時間、省略不必要的完整構建、享受預處理資產管道所帶來的好處、方便地和測試進行集成。

IDE有代碼補全、智能搜索、代碼導航、重構（將一段代碼抽取成一個新方法、在不同種類的文件中重命名變量）、單元測試集成、后臺編譯等功能。它 們是Java社區的中流砥柱。在使用類似Java這樣的語言工作時，它們價值連城，以致有些開發者覺得程序員如果不使用IDE完成一項任務簡直難以置信。

使用腳本語言（尤其那些不是為JVM而開發的腳本語言）的開發者傾向于使用輕量級的 代碼編輯器 ，如果在*nix系統的命令行里工作 1 ，vi（或者vim）和Emacs和它們內置的一些小工具會為軟件開發提供類似（或者更好）的編輯功能。即使你不總是在命令行下工作，精通命令行也是很有必要的，因為很多支持的任務（部署服務器、查看日志、檢查服務器性能）都得在命令行下完成。

1對門外漢來說，星號在程序員的語言里是通配符的意思。?nix代表“Unix和類Unix系統，比如Linux”。?nix還包含蘋果公司的OS X，但是不包括Windows。可在Windows上運行類似Cygwin這樣的工具，讓其看起來像個Unix系統。

性能

性能越好的應用，調試起來越快。讓迭代周期（反饋循環的長短）最短，修改和驗證項目的機會就更多。優化性能差的代碼，能為開發者節省出時間干其他 的事，而不是在那兒干等著系統響應。一開始選擇的API、算法、數據存儲機制和相關的流程會自上而下影響性能。甚至編程語言范型的選擇都會影響性能，比如 函數式編程（它以避免產生副作用而著稱），通常可用來構建高效的緩存機制。它還可以使用非常簡潔、易于理解的代碼高效遍歷數據結構。它簡化了流程，使用更 少的代碼就能完成重構。應用的性能和代碼的可讀性都會因正確的技術（正確的團隊）選擇而受益。即使在一個成熟的項目中，也有可優化的地方。比如很多Web 應用的網絡性能都可通過壓縮或減少連接次數而受益。這些細節通常在項目的早期被忽視，但在后期可以通過非破壞性的方式來實現。對性能的提升總能帶來其他好 處，開發者能用節省下來的時間來編碼和測試，而無需等待系統響應。

通過更一般的應用設計，RESTful風格的應用也會提高生產效率。客戶端-服務器端的架構允許并行開發，調試和維護也更簡單，同時簡化了很多在 其他時候會很復雜的任務。這些益處對開發系統中獨立的模塊也適用。正確地將項目模塊化，會在前期高效地實現項目，而那些擴展性不好的方案可在后期重寫。良 好的設計會提高日后的生產效率。

測試

早先的測試很隨意，邊用邊測，現在測試已經成為一種正規化的操作了。自動化測試（包括將測試集成進構建過程）是有信心大規模重構系統所必需的，也是自動化 部署的基礎。自動化測試早先只是斷斷續續地在運行，頻率也不高。現在處理器能力增強了，每次項目構建（或文件保存）時運行測試也是可行的。測試的范圍會因 項目的成熟度而變化，但在大多數非平凡的Web開發中都是必需的。測試已經在JavaScript社區樹立了牢固的地位，它讓人們可以開發出大型的項目， 能在各種瀏覽器和設備上可靠地執行。為了應對基于云的部署，人們開發出新形式的測試，比如Netflix公司的 Chaos Monkey ，它通過主動觸發失敗，幫助開發出可恢復的服務。

合理地執行測試，能方便程序員和計算機之間的交流，也能方便程序在團隊之間進行交流。乍一看還不明顯，畢竟測試的目的是為了理解和驗證軟件的可靠性和功能 的。一些類型的測試會顯著提升大型項目的生產效率。當測試減輕了集成的痛苦、提升了產品質量時，效果就變得顯而易見了。遵循行為驅動開發范型的測試，能在 代表各領域的項目成員之間搭建一條一致的溝通渠道，通過一種更精妙的方式來提高生產效率。正如 The Cucumber Book: Behaviour-Driven Development for Testers and Developers 一書所說：

“當開發者和業務干系人能明白無誤地溝通時，軟件團隊才能以最好的方式工作。一種非常好的方式是合作編寫自動化的驗收測試來描述任務……當團隊能合作編寫驗收測試時，他們能發展出自己的特殊語言來描述領域內的問題，這可以幫助他們避免誤解。”

更好的溝通減少了誤解浪費的時間，更好的理解會產生更好的產品。

當測試影響生產效率時該怎么辦？

有時候運行測試會成為負擔，降低生產效率。編寫和維護測試需要時間，運行測試需要時間和資源。和其他開發任務一樣，測試的精力和時間本可以用在其他地方。這導致了開發者和其他人在很大程度上減少了測試。

現在將測試集成進Web應用已經變得相對容易，很多啟動項目都包含了測試相關的配置。為了最大限度發揮測試的價值，需要鼓勵形成尊重測試價值、將 維護測試當成真正的工作，并且認為這是物有所值的文化。不能說測試會直接提高生產效率，但對大多數擁有較長生命周期的項目來說，測試的價值是不能被低估 的。

底層平臺

操作系統和安裝的基礎軟件組成了底層部署平臺。具有一兩臺強大處理器的工作站（加上一臺額外的顯示器以增大屏幕的實際使用面積）就抵得上幾年前的 一臺超級計算機。為JVM分配足夠的內存、關閉不需要的程序節省資源，這些可能會有一定的價值，但是應用的設計常常才是更重要的因素。在有些情況下，一個 更快的文件系統會顯著影響構建時間。

是使用集中化的數據庫，還是使用開發者各自維護的備份也是一個重要的決定。在開發者維護的場景里，遷移時可使用FlyWayDB（ http://flywaydb.org/ ）這樣的框架。如果需要遠程使用資源，網絡就成了問題，和分散在各地的團隊一起工作時尤其如此。

小結

本章有意不提供示例項目。生產效率，或開發時的效率需要后退一步考慮現有的選項是否和手頭的項目匹配。項目的各個階段都有宏觀或微觀的任務可被簡化、自動化，或者更高效地完成。你最好能夠“上來透口氣”，它能讓你充分思考現有的選項，做出最佳的決策。

書籍簡介

JavaScript和Java這兩大生態系統之間如何協同，成為所有Web開發人員共同面臨的問題。本書應運而生，全面又簡練地為讀者展示了最 新的C/S應用開發范式。本書以Java和JavaScript這兩種最流行的服務器與客戶端開發環境為例，全面講解了最新的C/S應用開發范式。作者不 僅講解了很多實用的C/S開發架構，還通過各種實例進一步強化了讀者的認知。