背景和概述
傳統開發模式逐步引入Struts/Spring、分層分離框架、面向切面編程（含過濾器、攔截器和偵聽器）等眾多"敏捷開發"的努力，都是在改變垂直堆疊的模式為橫向擴展模式，轉相互緊密依賴為松耦合，但都不夠徹底。
尤其在雲計算、Iaas/SaaS/Paas雲服務乃至移動雲開發風起雲湧時，傳統開發模式逐步變成反面模式，阻礙了開發的有效戰略和卓越品質。
移動網際網路和“雲開發時代”的來臨，編程開發模式必須進行顛復性創新。
雲開發雲時代對開發的期望、困擾和矛盾
移動互聯帶來用戶終極體驗為王？
移動網際網路催生軟體開發的思路轉變，要求軟體產品必須站在用戶體驗的角度，遵循“體驗為王”的法則，否則做得再多都是垃圾，耽誤時間和金錢。
如果開發者沒有站在產品用戶體驗的高度，產品經理抓也沒用，因為細節體驗等問題再怎么測試也有漏網之魚，而很多開發者往往不願面對或者無法面對？
實際上，開發者必須站到客戶第一線，做“難做”的事情，甚至親自跳到“坑”里，找到解決疼點的多種方案，並提出不要傾向、客觀和合適的建議。
因為體驗繁雜而想逃脫，就不可能做好開發工作！
雲時代激化了軟體開發中溝通和反饋的矛盾
雲時代締造了雲上虛擬溝通的通道，人們更習慣這種不見面的溝通。
溝通往往是軟體開發中最頭痛的問題，成功不在開發本身而是即時溝通和有效反饋，包括客戶（或用戶）、產品設計部門和開發團隊內部，但客戶往往沒時間跟你一起逐一深入這些需求，產品經理的意見本身往往也代表不了客戶，團隊內部更是一些埋頭苦幹不“好”交流的開發者。
傳統把團隊集中一起並加強管理和控制，以保證需求把握、開發計畫和產品品質的方式成本高昂，更關鍵的是這樣並不就能帶來有效的溝通和反饋。
傳統開發模式已經與雲時代嚴重脫節。
競爭的是時間？疊代速度要快點、更快點...那快到什麼程度？
移動互聯時代，產品競爭的首先是時間，但怎么衡量時間成本呢？因為我們並不一定知道方向，可能南轅北轍；即使方向正確，它也受各種因素的影響--有些時間是必須的如需求明確、產品設計和溝通反饋等，因此很難量化。
但“唯快不破”，快速回響變化、最快推出demo版、試錯後儘快推出基本功能的穩定版... 這一切都要求疊代得快點、更快點。
傳統動輒3周（或1個月）的進度、縮小功能需求點甚至犧牲性能保功能的所謂“敏捷”開發，讓人難以忍受。
能否讓開發“快”到保證連續不斷的溝通和反饋並進一步“驅動”需求變化呢？
需求總是在變化，不控制需求，往往帶來開發過程、軟體質量等不可控；一旦進行控制，這一行為在雲時代的軟體產品開過過程中，卻大大阻礙了更好產品的誕生。
實際上，變化本身就應該無需控制，相反要接受變化、鼓勵變化、擁抱變化，要控制的是前瞻得太遠的“大需求”，無法理解和無從下手的“偽需求”，帶著各種天生異味的“錯需求”...
最終放開對變化的束縛，讓變化驅動開發，快速適應真正的需求。
設計並用文檔形式體現，是一種傳統開發管理中重要的輔助手段，能建立起系統間的接口調用標準，提前對設計本身互為推進，預檢查命名等從而加強規範的統一，甚至明確中間的關鍵技術實現等。
但設計和文檔化這一方式不但非常麻煩，而且面對變化時帶來潛在劇烈的衝突，在所有敏捷開發中基本上產生巨大的爭議，形同雞肋。
如何有效的簡化設計和加強文檔自動化過程，成為關鍵。
多少人、什麼樣的團隊？
投入成本和收穫價值一般是成正比的，但在網際網路模式下，只有被最終用戶認可才能“開始”收穫，否則全部都是“沉沒成本”，由此導致前期投入人力往往更加謹慎；而且，移動互聯時代，軟體往往具備非常複雜的周邊環境，很多時候合適的人本身就更是缺乏。
雲時代，我們需要什麼樣的人和團隊呢？核心人員要一個就能幹過一個團隊，而且最好是個普通工程師人就能獨當一面，無需他去考慮甚至構造所謂的層次、框架、中間件等跟業務無關的構件而又能保證代碼品質，在穩定期又能快速地培養、擴大和鞏固隊伍來最佳化既有軟體體系...
能跟公司一起快速度過軟體試錯和探索期的人和團隊如何存在？
產品品質保證尤其反覆疊代後？
雲時代，人們可從各種渠道、不同方式進行多樣化的互動使用，這種便捷的體驗帶來了全新的用戶習慣，再加上周邊各種更加複雜的軟硬體環境，最終導致軟體面臨的訪問壓力和複雜性幾何級數增長，此時的軟體產品品質能始終如一嗎？
現實中由於趕時間、新功能開發或者盲目系統重構，往往導致問題不斷、顧此失彼、焦頭爛額乃至失去管控，直到推倒重來；所謂的代碼評審，畢竟只是一種後期人為補救措施，最多只能延緩這一過程。
如何提供始終如一的雲品質保證，不管產品疊代到哪個階段？
新技術要求如何與時俱進？
雲時代，移動終端基本普及，各種新技術也層出不窮；軟體套用要兼顧手機、兼顧雲套用、兼顧傳統整合等，技術總體難度增大，傳統開發方式面臨衝擊。
開放和可控？
雲時代提倡開放，代碼只有開放，才沒有黑匣子，才有基本可控性，才可以持續最佳化其中問題以兼容並蓄更多最新雲技術...
一旦開放，如何防止編碼過度自由而逐步紊亂最終失去控制？如何防止互相修改帶來交叉引用的風險？如何控制更少的關注點從而簡化開發難度？如何確保關鍵源碼壁壘防止代碼流失？
開放似乎可控，但最終可能導致失控！
都是開發者的事嗎？
雲加大了開發的複雜度、加快了開發的節奏並增加了開發的工作範圍；傳統開發模式下下，開發者面對層出不窮的問題，哪怕是定位、需求、產品設計、產品使用、運維支持、後期服務...等問題，開發者都難辭其咎，哪怕無人強調但自己辛苦構建的軟體淪為垃圾，依然備受挫折感折磨。
一切問題最終都需要開發者自行面對和消化，哪怕開發者根本不知道或沒上心的事；雖然逃避問題不是開發者乃至任何人願意的，但如何能真正做到共同、積極和全程的面對問題呢？
簡單的以人為本往往只是口號，只有改變開發者和開發的定義，才能真正帶來“尊重”。
雲開發的核心價值觀
線上連續協同共生>溝通>個體/互動>過程和工具
產品為王，體驗至關重要，我們需要更多人(包括無關者)從一開始就(儘早)不間斷的參與--連續溝通、有效反饋、協同工作，並通過自動量化統計分析能力進一步保證這種參與，形成一種連續協作的氛圍，共同推進產品的誕生和成長;這種連續協作氛圍遠比割裂的溝通、低效的互動、乾巴的規定、冗長的會議和強制的管理更加重要。
雲品質小版本的可見即可得>簡單>可以工作的軟體>面面俱到的文檔
怎么樣簡單、簡潔和快速地搞出一個可用的軟體版本來顯然是共識，因為前期出不來效果、得不到反饋、面臨高風險度...，相反成本卻是最大，如何簡單到可想、可見、可得地快速產生軟體小版本，並穩定運行地證明出價值(避免在取得效果前可怕的體驗讓人拒絕而破壞所有商機)，才可以進入產品正常的生命周期，迎來更多更多投入和良性循環，直到成長為可以工作的軟體。
超越客戶(用戶)和服務交付>反饋>客戶合作>契約談判
傳統客戶(用戶)和開發方壁壘森嚴，開發階段和使用階段巨大鴻溝，造成客戶(用戶)在開發階段的嚴重缺失而無反饋和不合作，開發者在使用階段的惰性和不回響而產品成長中斷，我們希望打破客戶(用戶)和開發者的壁壘--自己就是客戶客戶就是自己改變交付模式消除階段鴻溝--服務交付(可以項目和產品前期免費)，換位思考、互相尊重、共同責任，聯手締造產品的更大價值!
自驅動變化即變化驅動和驅動變化>勇氣(擁抱變化)>回響變化>遵循計畫
為什麼回響變化需要勇氣呢?因為變化往往會影響很多環節的改變，傳統不控制變化往往導致失控;但變化是永恆的不變的是變化本身，擁抱變化最好的方式讓變化化身成開發的良師益友，讓變化自動驅動軟體的成長，同時軟體成長過程又自動驅動新的變化，並且獲取效益後為了適應各種客觀要求而完全容納各種跨越式重構和最佳化的大變化。
雲開發的假設和原則
只關注產品
[假設]
產品體驗為王、口碑致勝，否則就是垃圾（客戶或市場是判斷的唯一標準)，但開發者往往只關注代碼邏輯，技術骨幹也往往只關注框架模式，未站在用戶角度去深入體驗和精緻要求，"盲目"或"無所謂"地遵從產品設計，可實際上產品設計本身就是反覆探索、試錯和試驗的過程，於是形成了開發與產品設計的森嚴壁壘，並在反覆證錯的過程中，進一步激化了產品和開發的矛盾，營造出料一種產品惡性進化的氛圍。
[原則]
把所有注意力只需且必須集中在產品上
無縫互動驅動開發
[假設]
客觀上產品都是逐漸成長的，阻礙這一過程的就是必須鎖定特定版本的傳統開發模型，即特定需求驅動開發，特定時間、地點和人員進行一種蹩腳的產品發展的推進，溝通和反饋這一過程淹沒在時斷時續的互動障礙中，遑論隨需而變。
[原則]
不限制時間、不限制地點、不限制人員的溝通和反饋
極限疊代
[假設]
用時間和成本的方式簡單的評價軟體開發速度和軟體階段版本毫無意義，雖然面對用最少時間和最低成本儘快疊代出一個可供"溝通和反饋"的試錯版本直到一個有基本價值的穩定版卻是日益明確的要求，因為疊代速度的量化標準模糊不堪，而且每次疊代的結束由於其他環節跟不上而帶來較大的中斷並不能有效觸動進一步疊代的開始。
[原則]
確保連續溝通和反饋的快速疊代
粗暴式簡單
[假設]
簡單往往最容易理解，只有理解才有可能更好地開發、使用、推廣、維護和發展，軟體系統做到足夠的“簡單”，往往最穩定和高效，只有最簡單穩定的東西才有可能被使用；同時，簡單往往最小工作量，少做就是最好，因為可能需求不清楚、場合沒必要、使用有爭議，不能穩定化的需求儘量延後，畢竟，開發者對需求的把握、系統的把握也是一個成長的過程，不可能一步到位，否則容易帶來巨大爭議和質量問題。但什麼才是簡單，每個人的秤都不一樣，簡單之道不簡單！
[原則]
真正的簡單
，要簡單到粗暴，可以不限特定人、人員數目和技術細節的簡單化
四輪驅動質量控制
[假設]
傳統編程模式下如果沒有顯式規範並加以培訓的代碼必將遵循"墨菲定律"--反其道而為之，而編碼人員個體的惰性、倦怠、得過且過和自我否定勇氣不夠，程式代碼往往存在眾多質量"異味"， 在對速度又有額外要求時將更容易忽略眾多潛在風險而形成產品的"炸點"；實際上，沒能監督約束的代碼肯定會累積較大風險，而風險代碼之間相互依賴將進一步放大風險，傳統代碼評審耗時費力且難以全面兼顧，而互審由於責權利問題更是不能落實，最終反覆疊代後無法繼續重構而失去控制只能推倒重來！
[原則]
軟體規範顯式自動約束，標準質量監查無縫滲透，代碼完備測試透明累積，同一品次代碼杜絕依賴，從四個方面自驅動代碼質量控制
自動化質量跟蹤
[假設]
引入任何改變，不管大小，則bug必然存在，且可能非開發者的直接原因引起，隱藏很深，危機重重，所以，任何代碼改變，如果沒有相應措施進行確認，普通開發人員將毫無信心，直到改變的勇氣喪失殆盡！
[原則]
任何代碼改變必然伴隨一次完整的自動化質量檢查並形成質量跟蹤報告
復用同步和節制
[假設]
復用雖是提升品質的根本，但低質量復用很容易引入並帶來嚴重問題，而且復用容易過渡追求而耗費更多時間且最終變成雞肋，復用一旦跟創新結合更容易變成過於創新，少量使用後往往尾大不掉難以否定。
[說明]
在復用接口基礎上，按軟體本身階段同步驅動復用化，在產品非正式版前節制通用化投入！
可控的開放
[假設]
只要是不開放（無關免費）的東西，中間隱藏的單點故障就會存在，甚至有可能就是放不開的垃圾，除非有良好的服務支持；因此，運行時要避免封閉的中間件（無關信任），避免對作業系統的限制（能靈活、快速安裝部署升級），如果暫時存在則至少解耦可替換，從而確保完全的可控性。
[原則]
要保持開放--全松耦合但建立耦合質量標準
共同設計和統一路線
[假設]
技術模式和實現路線不被認可，哪怕再“好”，往往也存在不接地氣的毛病，是必須拋棄或說服的，否則，著急的落地和推進，將導致眾多的問題，這些問題不被理解將進一步放大問題，從而進入惡性循環；尤其是對接其他系統的，如果為了趕時間，導致很多技術路線未完全統一，如字元集、資料庫、套用整合、數據整合...，這將形成“致命”的軟體缺陷；實際上，如果開發團隊技術定位和框架偏向未預設，應儘量保持大部分開發者的習慣，理解公司高層心理定位，爭取開發團隊的完全理解。
[原則]
共同進行框架、路線和構件的設計，尊重現實、優先復用、融合分歧和分解矛盾以統一路線，達成相互理解和共同期望
服務是產品的延續
[假設]
傳統的交付多是階段性交付，從而造成產品成長的割裂。
[原則]
產品的真正開始是對產品使用的支持
改變思路才有出路
[假設]
傳統的開發過程，我們一定會發現：無意義的重複帶來厭倦，按規範手動調整多個地方必定帶來一致性衝突，可選擇的越多就將出現自由選擇障礙，無監管的自由將帶來破壞即互為復蓋破壞，對同一事物的無邊界的修改將導致責任不清分工困難，沒有評審的口頭規範將逐步失控，熬夜等過度加班等將導致節奏失調直到失控，不能對全部進行整體認可、參與而負責的往往就會相互推諉而千瘡百孔，不能全部把握的就會帶來越來越強的牴觸，人為的層次遷變和錯位將隨著時間的流失而變得越來越成本巨大，沒有經過第三方檢驗的代碼充滿憂慮，以人為本和充分尊重等口號毫無意義...
[原則]
思想決定命運，只有根本改變開發者的"開發"這一個行為，建立起對傳統開發顛復性的開發體系，才有可能重塑開發者的定位（擺脫碼農的命運）--完全平等和相互尊重
，才有可能真正積極、主動和有力地面對雲時代的挑戰。
"雲"軟體過程管理
[假設]
人有惰性，代碼逐漸熵化，傳統管理往往脫離實際。
[原則]
對開發過程要實施連續不斷的管理--自動化開發過程的管理
雲開發活動中的核心實踐及具體實踐
概述
傳統框架、編碼乃至極限編程是垂直堆疊，所謂的橫向機制基本只是一種嘗試（你必須知道如何進行代碼垂直堆疊哪怕攔截至少你得關注而雲開發則無需知道也能加上），我們需要改變傳統開發的思想即把垂直堆疊解耦成水平擴展，為此提出三種創新實現方式為：
一種是增加運行容器，容器中可配置各種運行功能，這裡通過增加雲計算能力即雲計算容器實現，該容器可進一步容納現有各種容器（如spring等），可以配置各種安全、許可權、緩衝、防瀏覽器緩衝、變數初始化控制、外部接口如cmd或調用外程式的QOS、統一錯誤碼處理、統一日誌處理、異常跳轉後控制等功能，從而把傳統垂直堆疊的功能引入完全解耦，實現水平配置式開發！（參見核心實踐四）
第二種就是自定義規範化框架，框架本身的產生可忽略垂直編碼，而其中可插入各種功能，這是對傳統垂直堆疊模式的抽象，即把層次按規範進行隱藏，使得編碼者無需關注，只用關注關鍵業務的代碼編寫！（參見核心實踐二）
第三種就是指定功能實現標準並通過各種手動如代碼嚮導加強標準的貫徹，實現特定靈活邏輯具體代碼規範，實現特定處理的全局工具包，都在這個範疇！（參見核心實踐三）
這三種方式離不開高度復用的構件（一種高度可復用充分松耦合可插拔的東西包括框架），且一旦複雜度超出已有範圍，將進一步驅動構件的產生、發展和成熟，推進卓越復用和有效戰略！（參見核心實踐五）
這種創新開發過程，由於聯動改變高頻度改變整體代碼，越是開始越必須線上進行，同樣線上的各種活動才能充分發揮其優勢!（參見核心實踐一和核心實踐六）
線上編碼無縫協作
提供一種線上開發和協作的環境，確保線上連續設計、開發、集成、測試、交付等開發動作，並讓客戶、產品、管理乃至更多的人無中斷體驗產品的全生命過程，從而得到最充分、及時的交流和反饋，自驅動極限疊代開發過程。
[開發]
線上開發-設計、編碼、調試、測試...等所有活動均線上進行，任何動作同時其他人線上提示。
集中代碼倉庫-上面開發的結果，將與標準版本伺服器對接，從而進一步支持傳統開發活動。
按變化集成、部署和交付-任何開發和改變，只要遞交修改，即自動編輯、集成、部署和交付，但可不包括運行時。
[團隊]
虛擬團隊-開發團隊的各種角色均在雲上參與，形成貫穿全部軟體生命周期的虛擬團隊，形式上不在一起，但無時、無地保持緊密溝通；不能限於技術團隊、不能限於會議形式，讓更多人利用非正式時間同等參與而驅動開發。
跨部門互動-除開發團隊外，產品部門、市場部門、銷售甚至客服部門，當然包括非IT管理者等，形成復蓋非開發層面的成員，促進更大範圍的互動。
遠程客戶可視化體驗-不管是否在現場，也不管什麼時候想，客戶均可遠程訪問任何階段的產品，並以可視化的方式體驗，促進客戶參與和需求挖掘。
[自動化]
*統一無縫協作空間-確保開發過程中的自動化信息公示、問題標註、交流反饋等能力，並提供開放可擴展的接口以對接其他專業化ALM（軟體全生命周期）工具。
反饋監管-任何問題提出和交流發起，通過監管確保有效、及時地反饋，從而驅動整個開發的連續進行。
自動化統計分析-可根據各種管理目標反覆提升自動化水平，確保客觀和效率。
面向截層水平實施和按規範自動化堆疊
從一個業務驅動的截層開始，迅速自動化堆疊其他關聯層次和關聯活動對象，全員平等、並行的水平推進軟體系統的全生命周期，開發變成為一個不用費時效果最大的行為。
[規範標準]
統一層次和框架規範-面向截層統一規範品質管理的自動化模型，框架規範化，編碼標準化。
[截層模型]
面向單一業務-截層最大程度貼近業務邏輯本身的驅動，且只關注業務自身，從而將開發集中到產品和業務邏輯設計上；同時截層中每一個截塊只面向單一業務，減少截塊耦合帶來的複雜性，避免傳統業務控制可以集中到一個檔案而帶來的失控。
垂直框架層次自聯動-基於截層的變化，實現關聯垂直堆疊層（如data、xml、dao、daomain、service、manager、action、...）的自動化生成、修改、清除等自動透明的聯動。
關聯軟體全生命周期活動-截層是軟體全過程活動的集中濃縮，圍繞截層，從需求驅動代碼的自動產生，到單元測試功能測試，到代碼檢驗、自動測試、QOS報告、設計文檔、進度監控-redmine、自動培訓、規範自檢、工作日報..，均能有效關聯，從而便於不同層次的並行協作和自動化模型。
脫離具體框架實現-支持極速的代碼、語種、框架的快速重構化，哪怕換開發團隊和體系；支持全開放源碼生成，快速適應當前主流框架，與當前主開發體系技術路線映射一致。
[水平實施]
平等參與-全員對截層進行分塊即截塊，平等、公開地參與軟體開發全程，包括需求、設計、開發、測試和支持。
設計即開發-在開發的開始，就是截塊的設計，設計就是開發，系統模型在開發過程中不間斷完備和完善。
主體代碼的水平配置、定義和定製實現-為實現業務截塊的代碼，從主體骨架開始，通過配置控制雲計算容器層功能，通過定義固化框架通用功能，通過定義引入標準代碼塊或函式實現靈活功能，標準代碼中可以注入各種規範控制。
內業務微編碼-在主體代碼基礎上，通過微小的跟業務更緊密相關的編碼，實現完整業務邏輯，微小才能控制標準和質量。
水平擴展複雜編碼-微編碼中達到一定複雜度，則轉向定製嚮導、框架中可復用重構（構件），容器中可可復用構件的橫向方式上水平擴展。
面向切面編程-複雜編碼自然要求可復用和透明的特點，從而自驅動AOP編程。
業務功能水平重用-各種截塊，承擔獨立的業務功能。可以支持各種獨立、水平的重用。
全員並行-截層自動關聯衍生各個層次和各種活動，從而打破串式開發過程，全部可以並行推進。
*切入式編程--不是結對了解和提議，而是隨時從一個專業度切入,打開所有人的編碼切面，提出專業化意見，甚至直接改變。
按需求自驅動開發、測試和跟蹤
通過驅動，實現編碼簡單到粗暴的程度，無專業編程能力的人都可以參與，同時通過自動化測試體系增強軟體質量和開發者信心，並能快速發現、跟蹤、調試和處理運行時異常。
[自驅動開發]
截層驅動開發-基於需求，轉化為截層，這一過程要具備自驅動能力，保證簡單、直接、簡潔。
數據模型驅動開發-從數據設計開始即可進行快速開發。
功能代碼塊嚮導-支持各種基本功能的嚮導封裝，從而可以簡單到粗暴驅動代碼編寫，並面向非編程人員推出更加高效、透明地無編碼開發的定製模式。
功能水平實現輔助-支持各種典型復用功能的構件可以更容易引入和配置的輔助手段。
表現層驅動開發-需求以原型的形式直接表達，支持可見即可得的調整，甚至支持表現層從零開始的搭建能力和工具，此時表現層定義必須足夠簡單清晰而不能用太複雜方式，尤其前期表達時。
業務層驅動開發-如流程/表單驅動開發，支持多種無編碼的可視化截層工具如流程、表單等驅動無代碼開發。
跨檔案重構工具--支持多種快速重構工具如重命名，無逢重構並自動保持不同版本運行代碼。
[自驅動測試]
自動化用例錄製-代碼運行依託模板化進行輸出，並對結果按照匹配規則自動進行檢測，並允許手動確認結果，這個過程本身將自動形成典型測試用例，特定情形如代碼變動、部署升級、系統重構時要求輸入輸出完全可以重演。
自動單元測試代碼生成-在用例錄製過程中，按照接口引用、功能復用、間接訪問、內部函式以及標識疑點等自動生成單元測試代碼（實例）。
按功能自動化測試-代碼遞交時進行按功能的功能測試和單元測試，發現bug驅動開發。
部署全自動化測試-產品部署時進行全部功能的功能測試和單元測試，發現缺陷驅動開發。
極限測試和自動缺陷發現工具-自動放大用例中的條件，乃至程式中的變數，進行極限測試，以自動發現缺陷；後者，針對各種邏輯不完備和異常，均可能發現。
跨框架（語言）自動化比對測試-可發現一些框架、語言層的問題。
[自驅動跟蹤]
單一條件日誌-支持單一行為、單一人員、單一輸入參數的運行時日誌分離。
按行為命令行調試-支持特定行為的運行時的命令行模式的調試跟蹤。
*異常運行自動報警和容錯-支持非穩定期運行時的自動報警、自動容錯。
標準化提煉高復用的專業構件
按照標準建立構件集，指導開發過程中對可復用功能的充分解耦、廣泛使用，提煉高度專業化但是又通用的構件，通過成熟的東西的高品質，真正保證實現卓越運營和有效的戰略。
[標準]
以標準化的接口形式提供服務-不允許命令行等，不允許操作檔案系統，不允許控制資源等！
標準錯誤、異常和日誌記錄能力-復用構件的日誌、錯誤返回和異常處理機制的截層接入控管
基本接口可簡單快速實現-通用構件的設計，要簡單到為開發者把握了解和把握，從而確保可以快速實現
可快速更替-開發者可對通用構件進行松耦合調用，從而快速更替無縫更換，以徹底改造一些核心構件性能，甚至吸收更多的其他優異構件來替換，完成關鍵能力的飛升
保持異構能力-因為標準接口，同時可快速替換，就松耦合模式，確保異構耦合...
[構件集]
建立常用處理方法的構件集-工具集
建立框架規範對應的構件集
建立雲計算容器中的構件集-構件支持雲計算容器即可以獨立掛載到雲計算層提供獨立分離、前置處理和可檢測服務==雲計算層次的標準（如過濾攔截截面）等高模式外的雲計算代理及服務等全面徹底解耦，是對傳統框架的一種集中雲計算解耦區，使得各層充分解耦，適應雲計算特點，從而確保開放包容！
建立快速驅動開發的構件集-為非普通業務邏輯代碼塊建立通用化路線
[提煉]
"微代碼"開發驅動構件重構-復用構件的任何變化將驅動所有參與者的交流和反饋
疊代路線跟當前所屬系統保持同步
累積疊加跨項目的單元測試代碼
跨項目追蹤的復用重構協同-從簡單和完備的持續重構-提升代碼質量，驅動重用重構,重構本身處理過程的推進，需要及如何促進代碼重構？根據QOS率驅動重構！
多版本容錯-構件的改變容易引起根本問題看，所以保持容錯！
跨語言工具包調用容器-跨語言包--可選多種語言工具包，支持隨需而變的整合和對接...，所有流行跨語言工具包無縫使
推進開放獨立的雲運行容器
雲運行容器作為一張重要構件，設計簡潔，確保快速起步，穩定、自主和獨立的推進其向雲計算支撐能力的靠攏。
落實運行時雲服務支持
雲服務能力從一開始的線上連續即進行了建立，這種能力必須進一步對客戶標準化，並按需落實、依用收費。
雲開發的活動和過程
在上述實踐下的開發由傳統各種串列活動集中到編碼活動中，其他環節通過自動化、驅動等方式弱化，從而使得開發過程變為從單一截層出發的並行。
活動
1.簡潔需求定義
概括場景，提出關鍵點設計等，明確路線圖；無需等待和反覆論證，無需傳統詳細需求定義、頁面設計等細化需求。
2. 快速設計
選定框架（濃縮了規範和標準），明確截塊化和分工；避免傳統的詳細設計、解決方案和數據模型設計等，甚至完備的數據表定義、業務流定義，這些都將變成編碼開發的一部分，並自動產生各種設計文檔。
3. 自驅動的編碼
各種適合不同能力和定位的人員的自驅動開發模式，包括製作即開發-頁面製作、設計即開發-數據設計、頁面即開發-如頁元需求驅動、接口驅動開發、流程驅動開發、表單驅動開發、邏輯微編碼-簡單到粗暴編碼到構件提煉開發等。
4. 復蓋式跟蹤調試
支持瀏覽器下調試和測試，支持線上代碼的線上命令行跟蹤，集中版本獲取可離線可視化跟蹤--以上均為代碼模式當然可以斷點運行跟蹤的調試和崩潰匯報模式，當然也支持瀏覽器監控模式，兼容傳統線下編程和調試，塊編碼提示能力很強。
5. 自動化測試
全自動透明化單元測試和功能測試（並行測試--性能測試--安全測試）。
6. 不中斷的集成、部署和交付
連續交付，雲計算容器運行，並進行容錯處理--自動調度將實現負載正確的新線路，新迴路不對將自動切向正確的運行版實現容錯。
7. 運行時雲支持服務
進行雲監控和雲服務。
8. 連續互動體驗驅動極限疊代
無極交流和反饋，反覆驅動重構==重構必須反覆進行，但必須自動化驅動重構？我不想親自做那些冗餘的事包括庫設計-html導入-邏輯塊=但能否構建功能測試QOS率並報警，我似乎也沒有更好的辦法監管這些代碼的品質並反覆重構提升=只要單元測試日誌等地方就將給出報告並引起關注，從而量化最佳化控制。
9. 雲品質要求驅動重構
自驅動重構機制-並行解耦重構而進化。
過程
從截層出發；
並行開發-傳統受[模組黑盒子+串列設計+垂直堆疊]的限制，雲開發則把模組內部都進行了橫向切割，大家全部以並行參與，全員平等並行設計；
靈活專業切入-替代原來的評審；
驅動模式-面向截層水平自動驅動,從而使得測試、重構等內部驅動力加大，更快向高質量產品演進；
無縫變革式飛躍-松耦合機制確保可替換，松耦防干擾，版本共存，自動容錯，定向版本，質量演進；
管理自動化-自動產生各種統計報表分析開發狀態的監控和管理。
雲開發的效果和優勢
建立以用戶體驗和產品質量為中心的團隊，極限疊代，締造新型的軟體交付模式：連續協作促進產品用戶體驗-->不能連續無縫進行產品代碼質量交流反饋--產品體驗和品質不能開放式交流反饋監管--連續線上協作推進溝通交流和管理；截層開發進一步作為開發模式的核心是一種創新，保證了質量、極限，進一步保證了服務就是開發的交付；傳統開發對開發人員和團隊規模有要求,不能真正做到無縫的極限疊代--簡單粗暴頁元驅動開發！-全面提升其產能；高度重視雲服務的新型交付模式，不但反過來促進產品本身的進化，更重要的是創造產品本身的連續商業價值；
加強規範和標準的統一，減少輪子的重複製造，確保雲計算的卓越品質：自動垂直堆疊加強框架規範，而面向截層開發編碼標準控制；統一了很多其他層和本層常用功能的輪子，同時通過復用性的驅動機制，大大減少重複製造輪子；質量保證... 同時對可復用的地方經常動易導致變亂而質量風險，使得軟體質量存在累積疊加的可控性隱患，各種通用技術技巧全靠重複手動而無法標準引用；按雲計算的要求來解耦，復用帶來的卓越的雲計算的品質保證，降低風險；
避免重複工作，快速提升，專注於核心價值的貢獻：提煉原有價值，避免溝通反饋的消耗而只用關注業務的開發；
統一線上開發，自動全程跟蹤，建立雲軟體全生命周期監管模型。
雲開發的特點
有創新的踐行截層水平實施和自動垂直堆疊的開發理念：要能超越傳統的一切都是對象，提出一種新型軟體構建的基礎理念，從而大大簡化傳統軟體的開發；
有典型的簡單到粗暴的驅動式開發模型和工具：整個開發過程，必須有各種的工具支持，能做到無編碼開發，且其中的概念不能太多太專業；
具備獨立雲計算能力的運行時容器：雲開發的前置條件就是同時能提供默認的雲服務框架和環境，能迅速把上述開發成果轉化成雲軟體、雲套用和雲服務；
提供了典型的專業構件集：常規軟體中包含的一些專業核心軟體技術，如全文檢索、自然語言、統一用戶等，必須變成專業的SaaS，供開發者快速整合；
開放兼容傳統開發過程和技術積累：既然是開發，除了不懂編碼的人可控外，更應該讓有編碼能力人感到強大、靈活和可復用，從而要求雲開發過程其可兼容傳統程式語言；要有充分的開放性，作為開發方式，當然能夠看生成全部開發的源碼，可以選擇各種框架甚至自己定義的框架，同時還能夠與各種開放框架耦合；
從線上開發開始通過連續互動驅動開發：驅動模式的開發。
雲開發的適用性分析
不適用
信任自由發揮：信任高手，完全自由，只要他進行保證，並相信他的保證，相信他的穩定，且不考慮讓他的能力接管、雲化和推廣，從而讓他能發揮更多作用
單一成熟的產品：已經開發到一定程度，且自身團隊具備容納能力，而無需根本的重構...
單一作用的構件：...
標準適用
高質量軟體的構建
固定框架雲模式化：框架雲化？讓牛人的能力和作用將被進一步擴大，而又不陷入勞累或瓶頸或拒絕! 好框架雲化和推廣，如同把其變成真正意義的雲框架，就能更容易的套用，增強自身同時增加各種面向切面構件，進行雲提升和改造，且形成規範...更多牛人，要專門改造和提升特定的構件，儘量用雲模式，面向截面方式最佳化和提升？要確保該改進都可以對大家起作用，否則改著改著沒有那個功能了！產品強力團隊不同階段？--先按雲架構進行設計並做快速產品雲試用模型，然後用內部框架進一步重構和最佳化...
成熟團隊效率提升
管理的規範自動化：統一編程規範的貫徹，質量檢驗，自動測試，QOS，文檔輸出，進度監控，各種自動化的東西越貼近越好...如果我管理開發同時省去培訓工作！
優先適用
產品試錯：新產品試錯迎來更多拍磚，即有很多不明確的地方，要儘快推出，讓各層人員參與，有利於交流和反饋快速推進產品體驗，防止方向出錯。
人力不夠而時間緊：普通新人為主即可並行分工來工作，否則管理者就是瓶頸，你能更加關注監管和產品模型，而普通開發者能更全局參與學習提升並保證出效果。
團隊能力不夠缺少成熟框架積累：有新小團隊開發新項目，團隊能力要提升，同時缺少對當前項目的成熟開發方式包括框架積累，建議採用驅動化的雲開發模式。
特別麻煩的項目又不能實現分團隊開發：如web頁面較多，如綜合網站類的系統，可優先推進。
過渡技術路線嘗試：如果可能換框架、融合新框架、融合新的雲技術等，建議同樣把業務模型構建視為重中之重，畢竟會可預期就會進行重建性動作。
雲開發的爭議
侵入性問題和自由的崇尚?-完全開放，框架和構件自定義，編碼過程工具同時支持傳統模式，對自由定義了規範，但規範可以開放控制！
對時間怎么沒節省？時間是受各種因素影響的，敏捷實際上貫穿整個軟體開發歷史而不好量化界定，只從雲開發過程說起而判斷！
編程是藝術非專業開發者怎么能開發？開發是一個整體過程，需要非開發專業的其他專業，包括不懂代碼的客戶參與，這才是決定開發成敗的關鍵，讓他們也能用開發者的角度參與。
松耦合設計與簡單發生衝突？通用化的復用，往往是否需要想得太遠呢？雲開發模式更強調的是接口和按產品階段遞歸的復用。
