qileilove

          blog已經(jīng)轉(zhuǎn)移至github,大家請訪問 http://qaseven.github.io/

          一個游戲開發(fā)者的反思—缺陷與出路

           編者按:
            這篇文章脫胎于一個叫《游戲人成功學(xué)》的系列文章,它是作者長期身處游戲開發(fā)行業(yè)、親歷游戲行業(yè)痼疾后不吐不快的隨筆。世界上的任何事情都是這樣,當(dāng)一個人對某個事物了解越多,他也就越能清晰地看到這個事物的缺陷。編者報道游戲行業(yè)也有數(shù)年時間,覺得作者這篇文章雖然有過于“專業(yè)”的嫌疑,但比起那些行文淺顯、美化游戲行業(yè)、特意以“玩家”為對象談?wù)撚螒蛐袠I(yè)本象的文章來說,這篇文章對我們的讀者和游戲玩家也更有意義。從刊物的角度說,盡最大可能展現(xiàn)、記錄這個行業(yè)的方方面面,本來也是媒體份內(nèi)的責(zé)任。以上就是我們選登這篇文章為本期專題的原因。
            由于原文涉及到的專業(yè)術(shù)語很多,我們對之進行了幅度較大的修改,以期能使讀者更好地理解本文。
            “游戲開發(fā)成功論”?
            我曾寫過幾篇類似《給進入游戲行業(yè)新人的八個忠告》的文章,被個別朋友吹捧了幾下之后,自己頗有點傳道育人的成就感。但后來仔細琢磨,發(fā)現(xiàn)應(yīng)該被教育的恰恰不是新人,而正是如我一般或比我高大睿智的所謂的老人、前輩、制作人和領(lǐng)導(dǎo)。新人終究有超過一半的機會通過試用期,但勤奮刻苦的中國游戲制作人們所領(lǐng)導(dǎo)的上百家開發(fā)公司,窮多年之力,到今天為止,真正成功的產(chǎn)品仍寥寥無幾,其中世界級的產(chǎn)品,數(shù)量等于零。對比可見,老人、前輩、領(lǐng)導(dǎo)和偽高手們比新人更需要教育。有了被教育的覺悟,首先做的是反省和自我教育,本文即是一個從業(yè)有些年頭的冒牌高手——我的幾點零碎感悟,希望能以點博面,給讀者少許啟發(fā)。
            是為序。
            一、從D&D看游戲的底層設(shè)計
            把一個所謂的游戲意義上的偉大創(chuàng)意在游戲產(chǎn)品上付諸于實現(xiàn)的前提,是所有的設(shè)計應(yīng)該符合游戲工業(yè)設(shè)計規(guī)范。
            ——龍云峰《EEE&Lumines: Design for Business》
            這是我第一次看到有人這么明確且重視地提出游戲工業(yè)設(shè)計規(guī)范。在中國游戲發(fā)展這么多年的情況下,到2006年才由一個入行不久的“準老人”提出,對于所有在職的“老人”和“大師”們,都是一種絕妙的諷刺。
            可能很多玩家都奇怪,為什么一個國產(chǎn)游戲會拖期再拖期呢?為什么拖期之后出來的卻是個Bug不斷的半成品呢?為什么一款網(wǎng)絡(luò)游戲開發(fā)到后期,連畫面風(fēng)格都要做出調(diào)整呢?游戲開發(fā)目前幾乎所有項目的癥結(jié),歸根結(jié)底都與游戲設(shè)計的架構(gòu)和流程有關(guān)。其實玩家們不知道,在國內(nèi)游戲項目的進程中,下面這些糟糕的狀況經(jīng)常會出現(xiàn):
            1)項目中期發(fā)現(xiàn),如果編輯器支持一個特殊功能將能節(jié)省美術(shù)1/3的工作量;
            2)做到第25個月發(fā)現(xiàn)所有美術(shù)風(fēng)格相比某游戲已完全落伍,不得不重做;
            3)你和所有的人都知道游戲有什么功能,但沒有人能說出游戲為什么好玩;
            4)一個程序的離職導(dǎo)致全部渲染底層需要重寫;
            5)你的MMO內(nèi)測中,發(fā)現(xiàn)玩家只要1星期就能練到100級,而這是游戲的最高級別;
            6)游戲最終版本與提案書對比,只有不到30%的功能得以實現(xiàn)。
            這些只是幾個我曾經(jīng)聽到的例子,而很多更加荒誕的情況都在不斷上演、不斷重復(fù)。我曾經(jīng)跟一個在做項目管理的朋友說過,我們一直在重復(fù)你們過去曾經(jīng)犯下的錯誤。似乎所有團隊都必然要交這樣或那樣的學(xué)費,可悲的是更多的人交了學(xué)費仍不反省,仍然采取僥幸態(tài)度忽視游戲初期設(shè)計的作用。也因此,我們今天看到的國產(chǎn)游戲成功者仍然寥寥無幾。
            要避免后期開發(fā)中的混亂局面,在游戲設(shè)計的初期,就需要首先建立軟件工程規(guī)范化的概念。什么叫軟件工程?它是一門研究用工程化方法構(gòu)建和維護有效的、實用的和高質(zhì)量的軟件的學(xué)科。它有三大要素。
            1.目標:生產(chǎn)具有正確性、可用性及開銷合宜的產(chǎn)品。
            2.過程:生產(chǎn)一個最終能滿足需求且達到工程目標的軟件產(chǎn)品所需要的步驟。
            3.原則:是指圍繞工程設(shè)計、工程支持及工程管理在軟件開發(fā)過程中必須遵循的原則。
            游戲軟件的開發(fā)與其他軟件開發(fā)相同,都要符合軟件工程的規(guī)律。游戲的最根本本質(zhì)是一個軟件,文化產(chǎn)品只是軟件完成后的附加屬性——很顯然的,OpenGL不僅能用于開發(fā)主視角射擊游戲,也能開發(fā)工業(yè)CAD軟件甚至遠程醫(yī)療軟件。商業(yè)軟件的系統(tǒng)分析是針對用戶實際的特點,來決定用戶的現(xiàn)實需求如何能在軟件開發(fā)中實現(xiàn),而游戲軟件的開發(fā)也是同樣的道理。一款游戲是否能順利開發(fā)完成,取決于它的結(jié)構(gòu)是否符合軟件工程規(guī)范,這是降低游戲開發(fā)難度和項目復(fù)雜度的前提。因此,我將游戲設(shè)計符合軟件工程的要求,定義為游戲工業(yè)設(shè)計規(guī)范的一個基本條件。
            而這對現(xiàn)在的中國游戲人而言,無疑是一個非常苛刻的要求,或許更有人會說這在目前的國內(nèi)游戲行業(yè)也是個空想。但我們不妨仔細研究一下D&D這種老牌的桌面游戲規(guī)則吧!它至少符合一個嚴格的軟件工程所需要具備的基本特征。仔細研究D&D,你會發(fā)現(xiàn),所有的對象,通過基本屬性、天賦、適用規(guī)則等(內(nèi)涵構(gòu)件)進行定義;通過規(guī)則操作,如魔法攻擊(接口)進行相互作用;通過模板、種族、職業(yè)(類關(guān)系)進行衍生和統(tǒng)一。由于設(shè)計者將本來錯綜的游戲世界高度概括成數(shù)字化的規(guī)則(生物/人造/自然物件的基本屬性和基本屬性作用規(guī)則),因此在面對整個游戲世界這個巨大的復(fù)雜系統(tǒng)時,D&D具備幾乎無限的擴展能力,可以適應(yīng)不同科學(xué)發(fā)展度,不同文化的背景設(shè)計。
           理論上,構(gòu)建一個虛擬的世界,它的基本要素越是高度概括和定義的,那么底層設(shè)計工作的重用性就越高,擴展性也越大,同時,由于每次依靠本層次控件和規(guī)則構(gòu)成往上一個層次時都可能與最初的設(shè)想有極小的偏差,因此最終層次的表象控制就越難。如果我們把當(dāng)前的宇宙視為一個游戲項目,那么,上帝至少在設(shè)計之初將“夸克”視作最底層的材料,而我們看到的整個世界都是由幾種基本的“夸克”構(gòu)成的(看來上帝的美術(shù)工程師很省工)。由于層次非常多,這個世界最后的面貌很可能與上帝的提案書差距非常大。當(dāng)然,上帝可以在最高層直接添加規(guī)則來更改這個差距。
            D&D代表了目前游戲設(shè)計能夠高度概括到的極限(或許《進化》能打破這個紀錄,還沒有看到游戲,不知道具體情況)。我們做游戲設(shè)計,沒有必要做到這個層次,只需要抽象到玩家看到的具體控件的下面一層就可以。例如MMO中有設(shè)計紙娃娃的需求,里面有襯肩,那么,我們只要比常用的做法更進一步,將襯肩再向下一個層次,分為貼圖風(fēng)格、形狀、特效種類、特效顏色4個基本控件,那么,只要每個控件做少量幾種就能組合成很多種類的襯肩,這樣規(guī)劃可大量減少美術(shù)的工作量。而常規(guī)做法只能是一個個襯肩去建模和繪制。
            概括和定義底層是游戲設(shè)計對商業(yè)需求分析后最簡單的一個步驟。在分析商業(yè)需求過程中,我們可針對各個方面抽象出類似的關(guān)鍵問題:
            1)NPC、怪物、Boss和玩家角色是否屬于共同的類?如果是,這個類如何定義?其子類如何定義和區(qū)分,基本屬性、骨骼、模型、紙娃娃、動作是否通用?各子類是否有必要定義各自的子類?這些所有定義對于美術(shù)和程序工作的影響何在?
            2)職業(yè)、種族作為通用模板如何對上述的類中的對象進行作用,其作用是否與子類的定義相關(guān)?
            3)作為場景設(shè)計的需求,有多少建筑對象以構(gòu)件組合方式可以作出變化?如是,組合需要支援多少種風(fēng)格?有必要單獨設(shè)計的建筑有多少?
            4)有無可能以一種統(tǒng)一的升級規(guī)則操作基本屬性來控制所有的平衡?
            這種問題還有很多,根據(jù)游戲類型的不同,進行設(shè)計時的需求也有很大變化。
            游戲設(shè)計符合軟件工程的要求,需要項目負責(zé)人有基本的軟件工程知識,并有相應(yīng)領(lǐng)域的專家加以配合。很多Boss和Leader喜歡拿到提案書就開始督促手下人干,事實上,如果給大家?guī)讉€月的時間實現(xiàn)一個規(guī)范的工業(yè)設(shè)計,就能避免以后無數(shù)的問題,節(jié)省大量返工的成本。
            前面說到的是游戲開發(fā)這個項目的初步設(shè)計問題,接下來我想談一下我對于游戲設(shè)計過程具體管理的看法。
            游戲工業(yè)的理想狀態(tài),應(yīng)該是流水線生產(chǎn)、精益生產(chǎn)、個體創(chuàng)造的結(jié)合,在策劃階段、游戲架構(gòu)階段、試生產(chǎn)階段、測試階段需要采取不同的策略,從而最大程度降低風(fēng)險、降低成本及控制開發(fā)時程。注意“面向過程的管理”這個精益生產(chǎn)的實質(zhì),正是游戲開發(fā)未來所必須追求的目標,也是實施游戲工業(yè)設(shè)計規(guī)范所不可缺的部分。長久以來,游戲業(yè)內(nèi)的管理是“面向人的管理”或“面向目標的管理”,甚至有的連目標管理都沒有,而不用說進行真正的過程管理。
            肯定有讀者會說:誰說中國游戲開發(fā)沒有過程管理?沒有月表么?沒有開發(fā)計劃么?沒有工作日志么?我要說的是,并不是表述了過程就可自認為進行了過程管理,也不是每天跑去問程序進度如何就是做了過程控制。“面向過程的管理”包括非常多的技巧和細節(jié),這需要管理者去研究、規(guī)劃和控制。
            二、項目開發(fā)中的混沌和秩序
            我們可能都聽說過這些說法:“你不可能不勞而獲”“覆水難收”或“天網(wǎng)恢恢,疏而不漏”。如果這些諺語對你說來不算陌生,而且在日常生活中你也反復(fù)有過這樣的親身體驗,那么你就懂得了熱力學(xué)第一定律和第二定律。
            ——《熵:一種新的世界觀》
            在游戲開發(fā)過程中,很多人應(yīng)該有過這樣的經(jīng)歷:整個項目的細節(jié)越來越多,但沒人知道整體是個什么樣子;自己做的工作越多,越感到?jīng)]有信心和無助;不斷修改、修正和返工。其實,這就是熱力學(xué)第二定律所表述的,整個項目的無序性在增加,如果不加以控制,那么最后的結(jié)果就是進入最無序的狀態(tài),也就是整個系統(tǒng)的平衡態(tài),即完全裹足不前的狀態(tài)。事實上,無論游戲制作人意識到與否,游戲能否正常開發(fā)完成、能否達到立案之初的目標,很大程度上取決于游戲團隊對抗熱力學(xué)第二定律的能力。
            之所以熵增原理對游戲開發(fā)影響如此之大,是由游戲開發(fā)本身的特殊性所決定的。以制造業(yè)為對比,制造業(yè)發(fā)展到現(xiàn)在非常成熟,其整個工程的無序性和不確定性并不隨著規(guī)模的增長而質(zhì)變,原因在于:
            1)產(chǎn)品各部件的質(zhì)量定義非常清晰(目標清晰,需求明確);
            2)每道工序?qū)τ谧罱K產(chǎn)品的作用易于進行量化評估;
            3)成熟的流程管理或過程管理機制;
            4)專業(yè)化的團隊;
            5)最重要的,足夠的理論指導(dǎo)和經(jīng)驗積累;
            以上是使傳統(tǒng)制造業(yè)免于熵增原理荼毒的幾個關(guān)鍵因素,而游戲開發(fā)業(yè)顯然不具備這些因素。結(jié)果就是,制造業(yè)常規(guī)狀況下都能完成產(chǎn)品的量產(chǎn)和銷售;但只有不足一半的游戲正常開發(fā)完成,而達到立案目標的可能不足2成(僅僅從國內(nèi)的狀況而言可能更少)。
            大型的游戲項目從立案到策劃案,到程序架構(gòu)設(shè)計、底層開發(fā)、工具開發(fā)、上層邏輯編寫,到美術(shù)資源制作、到整合、到測試,經(jīng)歷了一個單向資源流動的過程,這個過程類似一條河流在流動過程中不斷吸納支流,最終匯流入海。在資源傳遞的過程中,由于傳遞的層次很多,在語言和文字的表述無法絕對精確的狀況下,多次的傳遞不僅容易產(chǎn)生錯誤、遺漏,還會不可避免地出現(xiàn)誤解。每個層次資源傳遞中出現(xiàn)一點的偏差,匯總到最后可能出現(xiàn)若干巨大的錯誤,這就是“差之毫厘,謬之千里”。
            在缺乏成熟管理機制的游戲開發(fā)業(yè),使得熱力學(xué)第二定律在這方面有了很大的發(fā)揮空間。某些策劃懶得寫必要的文檔,依靠口頭說明辦事;部分團隊沒有工作總結(jié);很多策劃不知道能通過非語言手段(圖片、拓撲等)表述信息;更多公司從來不寫會議紀要和討論紀要;絕大多數(shù)制作人都沒有項目關(guān)鍵詞定義的概念。
            因此,要首先重視定義,才能制定有效的溝通機制。
            在論壇里或朋友之間,我們經(jīng)常能聽到某個朋友說:“如果XX游戲這樣設(shè)計就好了”,或抱怨說:“XX游戲為什么沒有繼承前一代的某種優(yōu)點?”在游戲開發(fā)中,我們用“功能模塊”來表示玩家所提到的這種樂趣點。一個功能模塊往往代表了玩法的一個方面,當(dāng)足夠多的模塊被整合之后,玩家所看到的就是我們希望展示的游戲世界。很多設(shè)計者試圖堆砌足夠多“好玩”的獨立系統(tǒng)來形成一個“足夠好玩”的游戲。“好玩”的獨立系統(tǒng)隨著新游戲的推出在不斷增加,因此形成一個“足夠好玩”的游戲需要的部件越來越多了。由于每個游戲模塊都會通過某些接口來操作游戲?qū)傩?游戲進程,從而發(fā)生作用,這些操作與其他模塊的操作可能產(chǎn)生相似/互斥的結(jié)果,甚至可能改變其他模塊的開關(guān)狀態(tài)。因此理論上,每個新模塊被整合進入系統(tǒng)時,制作者都必須檢查所有與此模塊具備公共操作區(qū)域的原有模塊,甚至必須檢查所有操作可能帶來的屬性變更對依賴屬性的原有模塊的影響,這在系統(tǒng)足夠大的時候是不可能完成的工作。
            這帶來了另外一個熵增的根源,項目的復(fù)雜度隨著模塊數(shù)量的代數(shù)遞增作幾何遞增。即制作人對項目的控制力和把握會隨著項目規(guī)模的加大而迅速降低,當(dāng)復(fù)雜度到達一個臨界點時,制作者追加任何模塊,其整合成本對團隊都是無力承擔(dān)的。在這種狀態(tài)下,依靠堆砌的制作人會在一個階段之后突然發(fā)現(xiàn),大量問題突然的、集約的出現(xiàn)。
            相對穩(wěn)妥的做法是:確認核心需求,并圍繞核心設(shè)計必要的外圍需求,從底層構(gòu)架一個層次分明的需求,避免堆砌大而全的四不象,突出重點。
            熵增原理作用的一個重要來源是缺乏計劃性。由于缺乏經(jīng)驗和理論指導(dǎo),加之相對漫長的開發(fā)過程導(dǎo)致市場的快速變化,在開發(fā)過程中,游戲制作者經(jīng)常主動或被迫頻繁地調(diào)整策劃細節(jié),這種藐視計劃性的做法直接導(dǎo)致軟件開發(fā)目的的不確定性遞增。而不確定性反過來作用于游戲團隊本身,使開發(fā)人員泄氣和疲憊,降低工作效率和主動性,最終沒人會相信工作計劃,也沒人會盡力做好自己的工作,因為這個工作隨時會扔進馬桶(被新的需求取代)。一種極端的狀況是,有些團隊連基本的工作計劃和里程碑都沒有,每周的工作完全是項目經(jīng)理來臨時安排;另一種狀況是,一個既定的計劃不會被尊重,開發(fā)計劃幾乎每星期都會推倒修改。很顯然,這兩種狀況下開發(fā)已完全失控,其無序性遠遠超出了正常范圍,開發(fā)團隊必須付出幾倍的預(yù)算和時間才能獲得一線生機。
            所以,像對待承諾一樣信守你的計劃——千萬別輕于承諾,但承諾了就要做到。
            以上說的是3個常見的現(xiàn)象,本章我們討論的熱力學(xué)第二定律,其實代表了項目開發(fā)中混沌和秩序的對決,而對抗熱力學(xué)第二定律的實質(zhì)是,追求設(shè)計規(guī)范所帶來的秩序和控制力,減少無序性和不確定性。
            三、游戲設(shè)計的量化問題
            我們談過了游戲開發(fā)過程中面臨的諸多問題,但這里還有一個基本問題是——是不是所有開發(fā)工作都能被量化?
            很多游戲從業(yè)者都對此問題持否定的態(tài)度。游戲產(chǎn)業(yè)是一個創(chuàng)意產(chǎn)業(yè),創(chuàng)意和藝術(shù)創(chuàng)作怎么能被量化?所以就有很多號稱牛人所寫的文章、接受的采訪,大談游戲開發(fā)管理的難度,主要根據(jù)是,設(shè)計工作/藝術(shù)創(chuàng)作無法被量化。
            真是這樣么?
            在長度度量衡沒有被發(fā)明之前,我們可以猜想,人類只能使用簡單的表述來說明距離或長度,例如“高”“很高”“遠”“很遠”“非常長”等,在現(xiàn)代人看來,這種表述“十分不量化”,但在當(dāng)時的人類認知中,長度應(yīng)該是無法量化的,因為缺乏一種單位標準,可以使得不同的人能對長度進行同樣精確、相同認知的表述。這里,我們可以看出,至少在數(shù)學(xué)概念的量化上,需要“單位標準”的確定作為前提。
            在上面的例子中,一旦加減法被發(fā)明出來,度量衡就會出現(xiàn),人們會定義長度的單位和換算方式,此時長度就變?yōu)榭闪炕瘑挝涣耍吹竭@里,會不會覺得《文明》系列中的科技缺了不少?)。
            所以,認為游戲開發(fā)工作不能被量化的游戲開發(fā)牛人們,要么是對游戲開發(fā)工作根本不懂;要么就是對其他行業(yè)的研究成果視而不見,坐井觀天;有更多的混子們覺得“不能量化”是糊弄投資商和Boss最好的擋箭牌。
            大家可以去Google查查“量化管理”,這已經(jīng)是項目管理學(xué)最基本的概念,但居然還有這么多游戲業(yè)的牛人、老人嚷嚷無法量化,只能說悲哀,這行業(yè)的現(xiàn)狀讓人欲哭無淚。
            關(guān)于如何“量化”的攻略不管是在網(wǎng)上還是網(wǎng)下都已非常多了,也非常系統(tǒng)了,這里且不多說。大家去搜索一下,注意多看廣告和網(wǎng)站的,人家本質(zhì)上也是創(chuàng)意產(chǎn)業(yè)……看完以后你保證有抽那些“無法量化”牛人的沖動。
            在整個游戲開發(fā)設(shè)計過程中,沒有一個階段是絕對無法量化的,不過存在一個量化成本的問題。因為量化需要度量,度量過程需要建立標準、對比標準,對于很多無法用數(shù)字表述,必須借助統(tǒng)計甚至拓撲來表述的量化目標來說,這個操作過程的成本很高。所以在游戲最初設(shè)計的階段,也就是量化成本最高的階段,不必使用“量化”的概念去管理和操作。但在后續(xù)開發(fā)中,必須將程序、美術(shù)等工作都做到量化管理,這是使游戲成為工業(yè)化生產(chǎn)的前提,也是我們進行規(guī)范的前提。
           四、專業(yè)精神
            有位被稱為物理學(xué)大師的老先生曾經(jīng)放言:“中國高校對于中國發(fā)展作出的貢獻,遠遠大于美國最好的大學(xué)對于美國發(fā)展作出的貢獻”。先不說老先生如何得出這個結(jié)論,單單只看字面的意思,很容易發(fā)現(xiàn)一個邏輯常識問題,就是用“中國高校”這個大集合與“美國最好的大學(xué)”這個小集合進行對比。這種連小學(xué)生都能發(fā)現(xiàn)的錯誤居然被多家媒體轉(zhuǎn)載引用,實在令人匪夷所思。由此可見,現(xiàn)代人對于邏輯嚴謹、謹慎求證的基本研究態(tài)度的缺失十分驚人。
            一個諾貝爾物理學(xué)獎獲得者總說類似如此不專業(yè)的話(之前還說過“中國科技落后的原因是易經(jīng)”“清華學(xué)生強于哈佛”等),使我這樣一個物理系畢業(yè)生非常慶幸自己沒有資格搞物理研究。但高興未過半,反過頭來一看中國游戲行業(yè),亦如是也!不加考證、沒有數(shù)據(jù)、沒有案例,太多人開口就可以大肆放炮,提出各種貌似有理的結(jié)論,事實上,仔細看看他們的文章或言論,除了結(jié)論,什么都沒有……
            所以,請在你看跟行業(yè)有關(guān)的所有文章時(包括本文),仔細看看結(jié)論之前的論證過程是否存在,是否合理。
            上文似乎與正題無關(guān),但其實關(guān)系大得了不得。因為立項、開發(fā)中的陷阱,其來源往往是這種看似理直氣壯,卻無法抽象、無法量化、無法證明的結(jié)論。舉個例子,根據(jù)我的觀察,一旦游戲產(chǎn)品的游戲性在測試中不被認可,大部分“資深”策劃都會歸結(jié)于“我們的系統(tǒng)太少,不夠豐富”,結(jié)論是“要增加《魔獸世界》(或其他XX游戲)也有的系統(tǒng),甚至更多”。類似的論調(diào)往往能獲得很多贊同和喝彩,而很顯然的,這樣的結(jié)論可以洗脫所有人之前的責(zé)任,也能為混工資的項目高層多爭取一些時間。但至于這個結(jié)論是怎么得出來的卻沒人關(guān)心,或以一句“這是經(jīng)驗”代替了論證——結(jié)果常常是項目因此而滑向“全而疏”的失控深淵。
            “知其然”重要,“知其所以然”更重要。因為不能“知其所以然”,那個“其然”很可能是某感知力不足人的直覺。兵無常勢,水無常形,在變化如此迅速的行業(yè)中,任何只有個別案例的經(jīng)驗總結(jié),如果不能被抽象、推演或證明,其作用就值得懷疑。
            事實上,現(xiàn)階段的年輕人,大抵是喜歡“攻略式”的成功捷徑,樂于研究表象之“術(shù)”而并非深層之“道”,因此只有結(jié)論的填鴨文章倒成了最受歡迎速成的武功心法。可以想象,如果我寫個游戲開發(fā)必勝100招,只寫一堆狗屁結(jié)論,必定人氣旺到爆,且留言中的崇拜者、仰慕者、流口水者、要求合作創(chuàng)業(yè)者必定多到叫喊“中國游戲業(yè)沒有人才”的行業(yè)資深人士們羨慕的地步。
            填鴨成功學(xué)給所有畏懼困難和缺乏鉆研能力的人一個海市蜃樓,這個看似美妙的綠洲幻境后面,掩藏著無數(shù)投資者和熱血青年的尸骨,而這些尸骨的游魂如同“為虎作倀”的“倀鬼”一樣,繼續(xù)以他們的所謂血淚和經(jīng)驗拼湊新的填鴨成功學(xué),引誘下批冒險者。
            填鴨成功學(xué)只是從一個側(cè)面反映出我們多么缺乏真正專業(yè)的制作者和決策者。
            我們先來考慮第1個問題:
            黑社會和街頭混混的區(qū)別是什么?
            我們知道《教父》中的黑社會有很多特征,是任何街頭混混都無法比擬的,列舉幾個:
            1)嚴密的組織分工,每個人都有自己的專責(zé)(有組織結(jié)構(gòu)和職位說明書);
            2)黑白道的關(guān)系網(wǎng)(有行業(yè)背景);
            3)固定的灰色收入渠道(有盈利模式);
            4)有專門的用于行業(yè)聯(lián)絡(luò)的黑話(使用行業(yè)術(shù)語交流)
            5)成員有自制力、紀律性、信仰“我們的事業(yè)”(有企業(yè)文化);
            這些種種特征,加上黑社會成員的事業(yè)心和敬業(yè)精神,我們其實看到的“專業(yè)精神”在行業(yè)中的體現(xiàn),換言之,黑社會和街頭混混的區(qū)別是,一為專業(yè),一為業(yè)余。
            第2個已經(jīng)不用回答的問題:
            游戲從業(yè)者和玩家的區(qū)別是什么?
            我常常問提出建議和意見的同事,你的想法跟玩家有什么區(qū)別?
            黑島,以“忠于RPG,忠于玩家”聞名,能夠忠于自己的職業(yè)和角色,這就是游戲從業(yè)者專業(yè)最基本的表現(xiàn)。游戲行業(yè)的工作涉及到方方面面,游戲外盒設(shè)計者是否以專業(yè)外觀設(shè)計師的標準要求自己?游戲項目經(jīng)理是否具備軟件項目管理的基本理念和技能?游戲QA是否制定了專業(yè)的反饋流程和機制?以這種標準來看,中國不僅缺乏專業(yè)的從業(yè)者,甚至連專業(yè)的公司都寥寥無及。
            專業(yè)從業(yè)者應(yīng)該首先把自己從玩家的身份中升華出來,能總結(jié)玩家的反應(yīng),能將玩家眼中混沌的系統(tǒng)分離成為清晰的個體,能將實際抽象為理論,能將感受量化成數(shù)據(jù)。如果一個從業(yè)者的作用只是傳遞玩家的信息或把自己作為玩家感受的信息整理出來,那么這個從業(yè)者實質(zhì)上對于整個團隊是沒有價值的。如果你做的僅僅是玩家能做的,那么組織要你干嗎?
            第3個值得我們探討的問題:
            我們用什么去定義“游戲從業(yè)者的專業(yè)精神”?
            任何行業(yè)的“專業(yè)”二字,都不僅僅是技術(shù)的體現(xiàn),按照大前研一的定義,技術(shù)精通者應(yīng)稱為專長者。英文過專八的研究生,未必能進行專業(yè)的翻譯;同理,一個會寫策劃案或營銷計劃的人,未必是專業(yè)的游戲從業(yè)者。
            對于不同職位的從業(yè)者,我們不能苛求一種專業(yè)的標準,但無論GM還是總經(jīng)理,專業(yè)與否最直接的判斷就是,專業(yè)者為尋求最精益最科學(xué)的工作結(jié)果而奮斗。如果考慮到個人與組織的協(xié)調(diào),我們可以加上第二層的判斷:專業(yè)者為個人工作結(jié)果促進組織成長作用最大化而奮斗。
            就這么簡單。
            可是有幾個人能做到呢?
            對希望自己成為游戲業(yè)內(nèi)專業(yè)人士的讀者,推薦大前研一的《專業(yè)主義》。
            五、戰(zhàn)略的價值
            戰(zhàn)略的定義和價值問題一直是企業(yè)家和專業(yè)人士理解不太清晰的幾個事中的兩件事。學(xué)者和咨詢公司把它說得神乎其神,實業(yè)家﹑經(jīng)驗主義者又往往對戰(zhàn)略嗤之以鼻,認為它一錢不值,對于戰(zhàn)略家的高談闊論不屑一顧。
            ——鄭文斌
            戰(zhàn)略是一個可以被多層細分的名詞,最被中國企業(yè)所常常提到的是“管理戰(zhàn)略”“市場戰(zhàn)略”“企業(yè)戰(zhàn)略”等,這些是針對企業(yè)不同環(huán)節(jié)或不同層次對戰(zhàn)略的細化。在游戲行業(yè),我們常常聽到的是“概念”“目標”被冠以“戰(zhàn)略”。例如,盛大曾經(jīng)提出要做“網(wǎng)上迪斯尼”,被很多人稱為戰(zhàn)略,其實僅僅是個長期目標而已。如果蘇軍在衛(wèi)國戰(zhàn)爭的戰(zhàn)略僅僅是“打敗法西斯”,我估計二戰(zhàn)的歷史都要被改寫了。中國游戲圈是我所見到的最喜歡通過濫用各種術(shù)語以拔高自己身份的自卑群體。而戰(zhàn)略這個詞被濫用造成的結(jié)果就是,幾乎所有人都搞不清楚什么是戰(zhàn)略,戰(zhàn)略有什么用。
            我們先從戰(zhàn)爭來看看什么是戰(zhàn)略。《戰(zhàn)爭論》對戰(zhàn)略定義為“戰(zhàn)略就是為了達到戰(zhàn)爭目的而對戰(zhàn)斗的運用。”針對戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系,《戰(zhàn)爭論》提出“戰(zhàn)略是對整個戰(zhàn)爭的籌劃”“戰(zhàn)術(shù)是對某一作戰(zhàn)行動的籌劃。”在戰(zhàn)爭中,大本營/總參需要針對自己和敵方的態(tài)勢、情況,決定如何達成戰(zhàn)爭的目的,并加以貫徹。在二戰(zhàn)中,德軍的“閃電戰(zhàn)”、蘇聯(lián)紅軍的“大縱深”、日軍的“火力優(yōu)勢作戰(zhàn)”、我國的“人民戰(zhàn)爭”都屬于戰(zhàn)略層面。而相對應(yīng)的“先鋒旅指揮”“機械化波動進攻”“側(cè)翼突破”“游擊戰(zhàn)”就屬于戰(zhàn)術(shù)層面。戰(zhàn)術(shù)服務(wù)于戰(zhàn)略,而戰(zhàn)略則指導(dǎo)了戰(zhàn)術(shù)。
            在企業(yè)中,戰(zhàn)略影響也非常大,往往決定一個企業(yè)的盛衰。在游戲業(yè),戰(zhàn)略也有血淋淋的案例擺在眼前,華義、大宇等老牌廠商對于大陸市場的喪失,與其戰(zhàn)略可以說不無關(guān)系;盛大的所謂IPTV戰(zhàn)略(稱為戰(zhàn)略還是大了,IPTV應(yīng)該看作盛大多元化戰(zhàn)略的一個關(guān)鍵戰(zhàn)術(shù)調(diào)整),間接幫助網(wǎng)易成為行業(yè)老大。
            對于游戲公司,戰(zhàn)略可沿用鄭文斌博士的定義。“戰(zhàn)略是確定企業(yè)長遠發(fā)展目標,并指出實現(xiàn)長遠目標的策略和途徑。戰(zhàn)略確定的目標與企業(yè)的宗旨和使命必須相吻合。”在此定義的基礎(chǔ)上,我認為,游戲開發(fā)公司的領(lǐng)導(dǎo)者必須明確以下問題:
            1)公司發(fā)展的終極目標是什么?對應(yīng)此終極目標員工的愿景為何?
            2)公司的核心競爭力是什么?此核心競爭力如何保持和加強?
            3)在游戲行業(yè)中,公司的位置和面臨的態(tài)勢?未來如何改善這個態(tài)勢?
            4)保證實現(xiàn)目標的資源有哪些?如何組織這些資源?
            5)風(fēng)險有哪些?如何通過制度和福利降低風(fēng)險?
            6)開發(fā)流程的管理采取什么樣的模式才能最大程度發(fā)揮核心競爭力?
            7)游戲產(chǎn)品的定位,開發(fā)什么題材、什么類型的產(chǎn)品?產(chǎn)品之間如何互補?
            先明確了這幾個問題,才能制定公司的戰(zhàn)略,戰(zhàn)略應(yīng)該圍繞目標來制定,同時也要考慮自己公司的實際情況和外部環(huán)境。例如最簡單的,有些公司“兩條腿走路”,引進產(chǎn)品和資助開發(fā)結(jié)合,就是最基本的產(chǎn)品戰(zhàn)略,是總體戰(zhàn)略的一部分。
            再強調(diào)一遍,戰(zhàn)略是非常重要的。很多戰(zhàn)略經(jīng)常變動、戰(zhàn)略有問題或戰(zhàn)略落實不足的游戲公司,已經(jīng)給我們做了反面教材。我曾經(jīng)聽說,一個大裁員的公司老總抱怨,裁員的原因是,被開的員工腦子全部停留在單機時代的設(shè)計理念,根本做不出好網(wǎng)游,只能開掉。理由似乎合理,但其實非常荒唐,員工是誰請來的?公司管理層請的,在公司提出相應(yīng)戰(zhàn)略之后請的;員工是怎么干活的?是在管理層的意志下干活的,是在公司戰(zhàn)略指導(dǎo)下干活的。做出的項目失敗是管理層的戰(zhàn)略失敗,怎么能怪員工思想保守呢?可現(xiàn)實往往是,高層的戰(zhàn)略失敗,偏偏由員工買單,被裁掉甚至被拖欠工資,這似乎已成了IT的一個規(guī)則。
            所以說,就算你不是高層也不想做高層,只想進入游戲行業(yè)踏實打工,了解公司戰(zhàn)略也是很重要的,不然下次給垃圾戰(zhàn)略買單的就可能是你。
            說到底,某些高層根本沒有想過以游戲立業(yè),他們甚至連自己的核心業(yè)務(wù)是什么都不清楚,他們的規(guī)劃中根本沒有長期戰(zhàn)略,更充斥著各種不切實際的短期盈利狂想。在這種情況下,決定公司方向的就是能不能賺快錢,能不能忽悠投資商和股民,也因此很多概念和口號被包裝成為他們的所謂“戰(zhàn)略”。至于游戲業(yè)務(wù),只是很多“有奶便是娘”的奶媽之一。
            這個行業(yè)真正需要是“忠于游戲”“以游戲為業(yè)”的公司和團隊。一些公司和團隊無法存活,表面上看來是人有問題(最常見的就是“策劃不夠?qū)I(yè)”),但事實上往往是公司的戰(zhàn)略和定位缺失。假使戰(zhàn)略問題繼續(xù)得不到重視,我們這個行業(yè)將陷入低水平重復(fù)的泥潭。
            篇后記:
            在游戲開發(fā)的圈子里,見識了很多被游戲開發(fā)所成就或傷害的精英,也看了他們所寫的形形色色文章、書籍、Blog。其中多有怨天尤人的、譏諷謾罵的、自賣自夸的、乞求玩家買正版的、裝大師大談成功攻略的,唯獨老老實實總結(jié)點經(jīng)驗并愿意共享出來的很少。
            而很現(xiàn)實的狀況是,幾乎所有中國游戲制作團隊都在重復(fù)犯前人的錯誤。
            所以起意寫本文的初衷就是想能整理一些給其他業(yè)者有用的,也供自己反省的東西。因個人能力和時間所限,斷斷續(xù)續(xù)寫了很久才攢了5節(jié)。

          posted @ 2014-08-26 09:39 順其自然EVO 閱讀(225) | 評論 (0)編輯 收藏

          軟件配置管理之管理什么

           軟件配置管理是對軟件開發(fā)階段的演化和變更進行管理;貫穿軟件整個生命周期,從立項、需求定義、計劃、設(shè)計、實現(xiàn)、測試再到發(fā)行,配置管理需要記錄每一次里程碑轉(zhuǎn)變的條件和結(jié)果,并且要能通過配置管理系統(tǒng)記錄的文檔和過程可以重現(xiàn)某個過程,也就是要能完整的記錄整個研發(fā)過程,配置管理系統(tǒng)在定義配置項時要將項目中的每一個變化都反映到配置管理系統(tǒng)中;
            目前公司存在的問題是
            1、各個階段的配置項依賴關(guān)系沒有辦法追蹤,只知道有這些配置項,但是并不知道這些配置項之間的關(guān)系,哪個配置項先確立、哪個后確立;
            2、各個階段之間的配置項的依賴關(guān)系也沒有記錄,只是有各個階段的入口條件;
            3、沒有統(tǒng)一的系統(tǒng)來管理諸如代碼、文檔、需求、測試、發(fā)行版本等;每一種配置項都存放在不同的管理工具中,如代碼用CC來管理,文檔由PDM來管理,發(fā)行版本流程也由PDM來管理,發(fā)行版本的存放由windows共享來管理,變更則由CQ來管理;各個管理工具不統(tǒng)一使得基線的創(chuàng)建困難重重,目前我們基線的創(chuàng)立僅僅是文檔的到位,基線創(chuàng)建時對應(yīng)的版本是什么只能去查找文檔內(nèi)容,而不能使整個基線內(nèi)容一目了然;
            解決的最佳方案是:
            建立單一的配置管理系統(tǒng),或者各個系統(tǒng)之間能建立自動的聯(lián)系;各個配置項的依賴關(guān)系也能一目了然;

          posted @ 2014-08-26 09:39 順其自然EVO 閱讀(151) | 評論 (0)編輯 收藏

          對TCP/IP網(wǎng)絡(luò)協(xié)議的深入淺出歸納

           前段時間做了一個開發(fā),涉及到網(wǎng)絡(luò)編程,開發(fā)過程比較順利,但任務(wù)完成后始終覺得有一些疑惑。主要是因為對網(wǎng)絡(luò)協(xié)議不太熟悉,對一些概念也沒弄清楚。后來 我花了一些時間去了解這些網(wǎng)絡(luò)協(xié)議,現(xiàn)在對TCP/IP網(wǎng)絡(luò)協(xié)議有了初步的認識,在這里總結(jié)出來,可以梳理一下我對網(wǎng)絡(luò)協(xié)議的理解,加深印象.
            話說兩臺電腦要通訊就必須遵守共同的規(guī)則,就好比兩個人要溝通就必須使用共同的語言一樣。一個只懂英語的人,和一個只懂中文的人由于沒有共同的語言(規(guī)則)就沒辦法溝通。兩臺電腦之間進行通訊所共同遵守的規(guī)則,就是網(wǎng)絡(luò)協(xié)議。
            那么誰來制定這個網(wǎng)絡(luò)協(xié)議?
            國際標準化組織(ISO)定義了網(wǎng)絡(luò)協(xié)議的基本框架,被稱為OSI模型。要制定通訊規(guī)則,內(nèi)容會很多,比如要考慮A電腦如何找到B電腦,A電腦在發(fā)送信息 給B電腦時是否需要B電腦進行反饋,A電腦傳送給B電腦的數(shù)據(jù)的格式又是怎樣的?內(nèi)容太多太雜,所以O(shè)SI模型將這些通訊標準進行層次劃分,每一層次解決 一個類別的問題,這樣就使得標準的制定沒那么復(fù)雜。OSI模型制定的七層標準模型,分別是:應(yīng)用層,表示層,會話層,傳輸層,網(wǎng)絡(luò)層,數(shù)據(jù)鏈路層,物理 層。
            雖然國際標準化組織制定了這樣一個網(wǎng)絡(luò)協(xié)議的模型,但是實際上互聯(lián)網(wǎng)通訊使用的網(wǎng)絡(luò)協(xié)議是TCP/IP網(wǎng)絡(luò)協(xié)議。
            TCP/IP 是一個協(xié)議族,也是按照層次劃分。共四層:應(yīng)用層,傳輸層,互連網(wǎng)絡(luò)層,網(wǎng)絡(luò)接口層。 那么TCP/IP協(xié)議和OSI模型有什么區(qū)別呢?OSI網(wǎng)絡(luò)協(xié)議模型,是一個參考模型,而TCP/IP協(xié)議是事實上的標準。TCP/IP協(xié)議參考了OSI 模型,但是并沒有嚴格按照OSI規(guī)定的七層去劃分標準,而只劃分了四層,個人覺得這樣會更簡單點,當(dāng)劃分太多層次時,你很難區(qū)分某個協(xié)議是屬于哪個層次 的。TCP/IP協(xié)議和OSI模型也并不沖突,TCP/IP協(xié)議中的應(yīng)用層協(xié)議,就對應(yīng)于OSI中的應(yīng)用層,表示層,會話層。就像以前有工業(yè)部和信息產(chǎn)業(yè) 部,現(xiàn)在實行大部制后只有工業(yè)和信息化部一個部門,但是這個部門還是要做以前兩個部門一樣多的事情,本質(zhì)上沒有多大的差別。TCP/IP中有兩個重要的協(xié) 議,傳輸層的TCP協(xié)議和互連網(wǎng)絡(luò)層的IP協(xié)議,因此就拿這兩個協(xié)議做代表,來命名整個協(xié)議族了,在說TCP/IP協(xié)議時,是指整個協(xié)議族。
            TCP/IP協(xié)議分為四個層次,但我們并不需要了解所有層次的協(xié)議,我覺得主要關(guān)注應(yīng)用層和傳輸層的協(xié)議就可以了。拿寄送郵件舉例, A寄郵件給B,A關(guān)心的是用什么格式寫什么內(nèi)容給B(應(yīng)用層內(nèi)容),是寄掛號信還是寄平信(傳輸層內(nèi)容),但是A是不會去關(guān)注郵件傳送過程中采用了那條路 線,郵遞員是如何把信件遞送到B手里的(互連網(wǎng)絡(luò)層,網(wǎng)絡(luò)接口層)。
            先說傳輸層,傳輸層有多個協(xié)議,但最主要的是TCP和UDP協(xié)議。兩則的區(qū)別在于TCP協(xié)議需要接收方反饋,UDP協(xié)議不需要接收方反饋。TCP就像掛號 信,A電腦發(fā)信息給B電腦后,需要得到B電腦的反饋,這樣A電腦就能知道B電腦是否已經(jīng)收到信息。UDP就像平信,A電腦發(fā)信息給B電腦后,B電腦并不給 A電腦發(fā)聵,A電腦發(fā)送信息出去后并不知道B電腦是否已經(jīng)收到。 因此,TCP傳輸比UDP傳送更可靠,但是TCP傳輸?shù)男示筒蝗鏤DP了。至于,在傳送過程中具體選擇哪種傳送方式,需要具體問題具體分析。在不可靠的 網(wǎng)絡(luò)傳送過程中一般選擇TCP傳送方式。在講求效率,或者不在乎傳送失誤的情況下可以選擇UDP方式來提高傳輸速率。
            應(yīng)用層的協(xié)議有很多,每一個協(xié)議代表一種類型的服務(wù)。HTTP協(xié)議,萬維網(wǎng)服務(wù)。FTP協(xié)議,文件傳送服務(wù)。POP3,郵件服務(wù),SOAP協(xié)議webService服務(wù)。
           在理解TCP/IP協(xié)議的過程中,我遇到了三個困惑。
            1.什么是socket?
            以前有聽說過socket編程這種說法,也有的說套接字編程。我在搜索關(guān)于socket的資料時,發(fā)現(xiàn)有的說socket是指一個連接,有的說 socket是一指一個端點。拿打電話做比喻,A電話機和B電話機正在通話,那么socket是指的A和B之間的連接線呢,還是指電話機(端點)?
            我現(xiàn)在的理解是,socket就是一個連接中的一個端點,一次通訊(連接)a,b端都會有一個socket。一個socket對應(yīng)一個連接。
            2.http協(xié)議屬于應(yīng)用層還是傳輸層?
            http 超文本傳送協(xié)議,聽上去像是傳輸層的協(xié)議一樣。但事實上大家都知道http和ftp一樣都是屬于應(yīng)用層的協(xié)議,我先前很納悶的是,既然是應(yīng)用層的協(xié)議,怎 么就取這樣一個誤導(dǎo)人的名稱啊。在對TCP/IP協(xié)議還不熟悉的時候,這很容易讓人誤解和納悶的。后來,我在wiki上發(fā)現(xiàn)這么一段話:
            http中文譯名問題
            HTTP 在中國大陸被翻譯為“超文本傳輸協(xié)議”,因為“transfer”在中文里有“傳輸”的含意。但依據(jù) HTTP 定制者之一的 Ro Fielding博士的論文[1](6.5.3節(jié)),作者專門強調(diào)“transfer”表示的是“(表述狀態(tài)的)轉(zhuǎn)移” (Representational Stat Transfer),而不是“傳輸”(transport)。故其中文譯名“超文本傳輸協(xié)議”恰恰引種反映了這種誤解。更符合原義的譯名應(yīng)該為“超文本轉(zhuǎn) 移協(xié)議”。
            這段話解除了我的疑惑。那么http協(xié)議當(dāng)然是應(yīng)用層的協(xié)議。
            3.SOAP可以使用HTTP協(xié)議進行傳輸嗎?
            在了解SOAP協(xié)議的過程中,看到介紹說soap可以通過tcp,udp,http協(xié)議來傳送。這也是讓人困惑的描述。一看這句話,就會感覺http怎么 和tcp,udp協(xié)議并列了呢?難道http還是屬于傳輸層的協(xié)議?再加上http中文譯名的問題,名字聽上去像傳輸層,初學(xué)者又要開始頭大了。
            事實上,http是應(yīng)用層的協(xié)議,這一點可以毫無懷疑。那么現(xiàn)在新的問題來了。soap和http都是應(yīng)用層協(xié)議,怎么說soap能用http協(xié)議來傳輸呢?應(yīng)用層的協(xié)議可以用應(yīng)用層的協(xié)議傳送嗎?
            我查閱了資料,是這樣一回事情,soap將信息進行XML的序列化后,再用http協(xié)議的方式再打包進行傳送,傳送的方式還是tcp或者udp。做個比喻 就好理解了。tcp 和 udp 都是公路,暫且把tcp認為是一般公路,udp高速公路,soap和http就都是汽車,那么soap和http都可以在tcp和udp上跑。說soap 可以通過http來傳送,實際就是說soap是小轎車,http是裝轎車的卡車,把soap的信息裝到http里面,然后再運輸,當(dāng)然走的道路還是tcp 或udp。
            說soap可以通過http協(xié)議來傳輸,這句話不太準確,比較準確第說法是:soap信息可以通過http協(xié)議包裝后通過tcp或udp傳輸。

          posted @ 2014-08-26 09:37 順其自然EVO 閱讀(167) | 評論 (0)編輯 收藏

          解決Bugfree不能定期發(fā)送統(tǒng)計郵件的問題

          使用Bugfree2.1后發(fā)現(xiàn)配置好郵件參數(shù)后,在指派bug時能正常發(fā)送郵件,但始終無法使用其定期發(fā)送統(tǒng)計郵件和通知郵件的功能,雖然照官網(wǎng)上說的配置了計劃任務(wù),修改了shell目錄下的兩個bat文件,但仍然沒有解決。后來裝了個php調(diào)試器,逐步調(diào)試終于找到問題原因:
            1、創(chuàng)建項目時沒有填寫“通知郵件”的屬性,導(dǎo)致執(zhí)行statbug.php文件時找不到接受信息的電子郵件地址;
            2、statbug.php文件的第251行中$CSSStyle=出現(xiàn)了多余的字符串‘PWD’刪除后即可;
            3、shell目錄下的statbug.bat文件中命令缺少一個默認的參數(shù):http://www.bugfree.org.cn
            修改后的statbug.bat文件內(nèi)容為:
            c:/xampp/php/php.exe c:/xampp/htdocs/bugfree/StatBug.php http://www.bugfree.org.cn
            這樣再次運行后就可以正常發(fā)送統(tǒng)計郵件了,下面是效果圖:

          posted @ 2014-08-26 09:37 順其自然EVO 閱讀(276) | 評論 (0)編輯 收藏

          如何做到測試人員心中好的開發(fā)人員

          作者在這篇文章中, 列出了七個項目, 指出怎樣的開發(fā)人員, 才是測試人員心中的好的RD.
            1. 不要考驗?zāi)愕臏y試人員
            即使你和測試人員的關(guān)系不好, 也不要故意制造bug, 來考驗?zāi)銣y試人員的程度.
            2. 自己做自己的驗收測試
            通常開發(fā)人員知道要去進行單元測試, 但是往往忽略了GUI測試以及usability testing. 建議開發(fā)人員每次要記得去進行小規(guī)模的驗收測試, 來及早發(fā)現(xiàn)一些usability的issues
            3. 不要一直犯同樣的錯誤
            測試人員最討厭的是開發(fā)人員老是一直犯樣的錯誤. 每當(dāng)功能有修改時, 測試人員常常能預(yù)測開發(fā)人員會忘記處理哪些事情. 開發(fā)仁要記得從中學(xué)得教訓(xùn)
            4. 他們并不想傷害你
            開發(fā)人員通常認為測試人員都是在找他們的問題或是麻煩. 所以她們很害怕進行測試, 但是事實上他們需要與測試人員合作, 以確保整個系統(tǒng)的質(zhì)量.
            5. 不要把質(zhì)量的責(zé)任推給測試人員
            另一件不好的事情, 是開發(fā)人員對于客戶遭遇到的問題不感興趣, 認為這是質(zhì)量的問題. 必須要記住, 質(zhì)量是整個團隊的責(zé)任, 開發(fā)人員不是只是要寫code, 也要負擔(dān)起質(zhì)量的責(zé)任
            6. 要撰寫批注和可讀性高的程序代碼
            7. 提供有敘述性的錯誤警報
            若是開發(fā)人員在顯示錯誤訊息時, 能夠更具體更有意義, 會幫助測試人員測試工作的進行. 不要老是顯示相同, 或是沒有意義的訊息.

          posted @ 2014-08-26 09:36 順其自然EVO 閱讀(185) | 評論 (0)編輯 收藏

          原生AJAX基礎(chǔ)講解及兼容處理

           AJAX = Asynchronous JavaScript and XML (異步的JavaScript和XML)。
            AJAX不是新技術(shù) ,但卻是熱門的技術(shù)。它可以在不重載(刷新)整個頁面的情況下與服務(wù)器進行數(shù)據(jù)交互并更新網(wǎng)頁模塊。
            AJAX的優(yōu)點有很多:可以局部刷新、按需加載,這樣就減輕了服務(wù)器的數(shù)據(jù)流量。并且在頁面更新的同時,用戶可以瀏覽器網(wǎng)頁的其它內(nèi)容而不受影響,也減輕了結(jié)構(gòu)負擔(dān)。AJAX也不是萬能的,在有以上優(yōu)點的同時SEO也受到了影響。
            在學(xué)習(xí)AJAX之前,必須先有HTML/XHTML、CSS、JavaScript/DOM的基礎(chǔ)。
            AJAX與服務(wù)器進行數(shù)據(jù)交互,必然涉及到服務(wù)器端,與此同時也就涉及到了服務(wù)器請求對象的創(chuàng)建(new XMLHttpRequest())、確認請求方式(open())、發(fā)送請求(send())以及響應(yīng)請求(responseText)。
            創(chuàng)建對象:
            IE9+及其它瀏覽器支持使用new XMLHttpRequest()的創(chuàng)建對象方式,而IE8及以下則使用new ActiveXObject()的方式進行創(chuàng)建。
            看了網(wǎng)上許多人使用如下代碼進行兼容:
          1 try {
          2     xml = new ActiveXObject("Msxml2.XMLHTTP");
          3 } catch(e) {
          4     try {
          5         xml = new ActiveXObject("Microsoft.XMLHTTP");
          6     } catch(e1) {
          7         xml = new XMLHttpRequest();
          8     }
          9 }
            筆者用IE11調(diào)試功能測試IE10及以下不寫new ActiveXObject("Msxml2.XMLHTTP")也是沒問題的,于是在創(chuàng)建對象時可以使用代碼:
            var xml = window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
            確認請求:
            xml.open('get', 'url', true/false);
            第一個參數(shù)表示:string. 訪問方式,有兩具值:get/post,大部分的時候使用get
            第二個參數(shù)表示:string. 要連接的服務(wù)器網(wǎng)址
            第三個參數(shù)表示:boolean. 表示是否需要異步請求(true為發(fā)起異步加載)
            發(fā)送請求:
            xml.send();
            如果需要發(fā)送數(shù)據(jù)則采用xml.send(str);
            響應(yīng)數(shù)據(jù):
            xml.onreadystatechange = function() {
            if (xml.readyState == 4 && xml.status == 200) {
            alert(xml.responseText);
            }
            }
            status返回鏈接的狀態(tài),一般返回200與404,200表示成功返回,404表示未找到頁面。
            readyState有5個值,分別為:0、1、2、3、4。而每當(dāng)值改變時都會觸發(fā)一次onreadystatechange。
            readyState的5個值含義分別為:
            0: 請求未初始化
            1: 服務(wù)器連接已建立
            2: 請求已接收
            3: 請求處理中
            4: 請求已完成,且響應(yīng)已就緒
            也就是當(dāng)請求完成,并且找到頁面時,然后才獲取服務(wù)器上的數(shù)據(jù)。

          posted @ 2014-08-26 09:35 順其自然EVO 閱讀(412) | 評論 (0)編輯 收藏

          Linux的動態(tài)定時器-時間輪

           定時器—有時也稱為動態(tài)定時器或內(nèi)核定時器—是管理內(nèi)核時間的基礎(chǔ)。定時器是一種軟件功能,即允許在將來的某個時刻,函數(shù)在給定的時間間隔用完時被調(diào)用。注意的是定時器并不會周期運行,它在超時后就自行銷毀,這也是定時器被稱為動態(tài)定時器的一個原因。動態(tài)定時器不斷地創(chuàng)建和銷毀,而且它的運行次數(shù)也不受限制。
            定時器在內(nèi)核代碼中屬于一個基礎(chǔ)組件。要想完全弄清楚linux2.6中內(nèi)核定時器的實現(xiàn),得先從初始化開始。
            在start_kernel(void)-->init_timers(void)
          void __init init_timers(void)
          {
          int err = timer_cpu_notify(&timers_nb, (unsigned long)CPU_UP_PREPARE,
          (void *)(long)smp_processor_id());
          init_timer_stats();
          BUG_ON(err == NOTIFY_BAD);
          register_cpu_notifier(&timers_nb);
          open_softirq(TIMER_SOFTIRQ, run_timer_softirq);
          }
          在timer_cpu_notify(&timers_nb,(unsigned long)CPU_UP_PREPARE,
          (void*)(long)smp_processor_id());
            中執(zhí)行
            init_timers_cpu(cpu) //初始化本cpu中的timers
            初始化的主要代碼是:
          spin_lock_init(&base->lock);
          for (j = 0; j < TVN_SIZE; j++) {
          INIT_LIST_HEAD(base->tv5.vec + j);
          INIT_LIST_HEAD(base->tv4.vec + j);
          INIT_LIST_HEAD(base->tv3.vec + j);
          INIT_LIST_HEAD(base->tv2.vec + j);
          }
          for (j = 0; j < TVR_SIZE; j++)
          INIT_LIST_HEAD(base->tv1.vec + j);
          base->timer_jiffies = jiffies;
          base->next_timer = base->timer_jiffies;
            這段代碼的主體是base,base的定義是:structtvec_base *base;
            這個tvec_base是動態(tài)定時器的主要數(shù)據(jù)結(jié)構(gòu),每個cpu上有一個,它包含相應(yīng)cpu中處理動態(tài)定時器需要的所有數(shù)據(jù)。為簡化分析僅考慮單cpu。給出這個數(shù)據(jù)機構(gòu):
          struct tvec_base {
          spinlock_t lock;
          struct timer_list *running_timer;
          unsigned long timer_jiffies;
          unsigned long next_timer;
          struct tvec_root tv1;
          struct tvec tv2;
          struct tvec tv3;
          struct tvec tv4;
          struct tvec tv5;
          } ____cacheline_aligned;

          posted @ 2014-08-25 10:13 順其自然EVO 閱讀(531) | 評論 (0)編輯 收藏

          SQL Server 計算機間移動數(shù)據(jù)庫

           注意:支持將數(shù)據(jù)從SQL Server 2000遷移到Microsoft SQL Server 2000(64位)。您可以將一個32位數(shù)據(jù)庫附加到一個64位數(shù)據(jù)庫上,方法是:使用sp_attach_db系統(tǒng)存儲過程或sp_attach_single_file_db系統(tǒng)存儲過程,或者使用32位企業(yè)管理器中的備份和還原功能。您可以在SQL Server的32位和64位兩種版本之間來回移動數(shù)據(jù)庫。您還可以使用同樣的方法從SQL Server 7.0遷移數(shù)據(jù)。但是,不支持將數(shù)據(jù)從SQL Server 2000(64位)降級到SQL Server 7.0。下面分別介紹這幾種方法。
            如果您使用的是SQL Server 2005
            您可以使用相同的方法從SQL Server 7.0或SQL Server 2000遷移數(shù)據(jù)。但是,Microsoft SQL Server 2005中的管理工具與SQL Server 7.0或SQL Server 2000中的管理工具有所不同。您應(yīng)該使用SQL Server Management Studio(而不是SQL Server企業(yè)管理器)以及SQL Server導(dǎo)入和導(dǎo)出向?qū)?DTSWizard.exe)(而不是數(shù)據(jù)轉(zhuǎn)換服務(wù)導(dǎo)入和導(dǎo)出數(shù)據(jù)向?qū)В?/div>
            備份和還原
            在源服務(wù)器上備份用戶數(shù)據(jù)庫,然后將用戶數(shù)據(jù)庫還原到目標服務(wù)器上。在備份過程中時可能有人使用數(shù)據(jù)庫。如果用戶在備份完成后對數(shù)據(jù)庫執(zhí)行INSERT、UPDATE或DELETE語句,則備份中不會包含這些更改。如果您必須傳輸所有更改,那么,假如您既執(zhí)行事務(wù)日志備份又執(zhí)行完整數(shù)據(jù)庫備份,您可以以盡可能短的停止時間來傳輸這些更改。
            1.在目標服務(wù)器上還原完整數(shù)據(jù)庫備份,并指定WITH NORECOVERY選項。
            注意:為防止對數(shù)據(jù)庫做進一步的修改,請指導(dǎo)用戶在源服務(wù)器上退出數(shù)據(jù)庫活動。
            2.執(zhí)行事務(wù)日志備份,然后使用WITH RECOVERY選項將事務(wù)日志備份還原到目標服務(wù)器上。停止時間僅限于事務(wù)日志備份和恢復(fù)的時間。
            ◆目標服務(wù)器上的數(shù)據(jù)庫將與源服務(wù)器上的數(shù)據(jù)庫大小相同。要減小數(shù)據(jù)庫的大小,您必須在執(zhí)行備份前壓縮源數(shù)據(jù)庫的大小,或者在完成還原后壓縮目標數(shù)據(jù)庫的大小。
            ◆如果您將數(shù)據(jù)庫還原到的文件位置不同于源數(shù)據(jù)庫的文件位置,則必須指定WITH MOVE選項。例如,在源服務(wù)器上,數(shù)據(jù)庫位于D:/Mssql/Data文件夾中。目標服務(wù)器沒有D驅(qū)動器,因而您需要將數(shù)據(jù)庫還原到C:/Mssql/Data文件夾。有關(guān)如何將數(shù)據(jù)庫還原到其他位置的更多信息,請查看相關(guān)資料。
            ◆如果您想覆蓋目標服務(wù)器上的一個現(xiàn)有數(shù)據(jù)庫,則必須指定WITH REPLACE選項。
            ◆源服務(wù)器和目標服務(wù)器上的字符集、排序順序和Unicode整序可能必須相同,具體取決于您要還原到SQL Server的哪種版本。有關(guān)更多信息,請參閱本文中的“關(guān)于排序規(guī)則的說明”一節(jié)。
            Sp_detach_db和Sp_attach_db存儲過程
            要使用sp_detach_db和sp_attach_db這兩個存儲過程,請按下列步驟操作:
            1.使用sp_detach_db存儲過程分離源服務(wù)器上的數(shù)據(jù)庫。您必須將與數(shù)據(jù)庫關(guān)聯(lián)的.mdf、.ndf和.ldf這三個文件復(fù)制到目標服務(wù)器上。參見下表中對文件類型的描述:
            文件擴展名
            說明
            .mdf
            主要數(shù)據(jù)文件
            .ndf
            輔助數(shù)據(jù)文件
            .ldf
            事務(wù)日志文件
            2.使用sp_attach_db存儲過程將數(shù)據(jù)庫附加到目標服務(wù)器上,并指向您在上一步驟中復(fù)制到目標服務(wù)器的文件。
            ◆分離數(shù)據(jù)庫后將無法訪問該數(shù)據(jù)庫,并且復(fù)制文件時也無法使用該數(shù)據(jù)庫。在進行分離的那一時刻數(shù)據(jù)庫中包含的所有數(shù)據(jù)都被移動。
            ◆在您使用附加或分離方法時,兩個服務(wù)器上的字符集、排序順序和Unicode整序都必須相同。有關(guān)更多信息,請參閱本文中的“關(guān)于排序規(guī)則的說明”一節(jié)。
           關(guān)于排序規(guī)則的說明
            如果您使用備份和還原或附加和分離方法在兩個SQL Server 7.0服務(wù)器之間移動數(shù)據(jù)庫,則兩個服務(wù)器上的字符集、排序順序和Unicode整序都必須相同。如果您將數(shù)據(jù)庫從SQL Server 7.0移到SQL Server 2000,或者在不同的SQL Server 2000服務(wù)器之間移動數(shù)據(jù)庫,則數(shù)據(jù)庫將保留源數(shù)據(jù)庫的整序。這意味著,如果運行SQL Server 2000的目標服務(wù)器的整序與源數(shù)據(jù)庫的整序不同,則目標數(shù)據(jù)庫的整序也將與目標服務(wù)器的master、model、tempdb和msdb數(shù)據(jù)庫的整序不同。
            第1步:導(dǎo)入和導(dǎo)出數(shù)據(jù)(在SQL Server數(shù)據(jù)庫之間復(fù)制對象和數(shù)據(jù))
            您可以使用數(shù)據(jù)轉(zhuǎn)換服務(wù)導(dǎo)入和導(dǎo)出數(shù)據(jù)向?qū)韽?fù)制整個數(shù)據(jù)庫或有選擇地將源數(shù)據(jù)庫中的對象和數(shù)據(jù)復(fù)制到目標數(shù)據(jù)庫。在傳輸過程中,可能有人在使用源數(shù)據(jù)庫。如果在傳輸過程中有人在使用源數(shù)據(jù)庫,您可能會看到傳輸過程中出現(xiàn)一些阻滯現(xiàn)象。
            ◆在您使用導(dǎo)入和導(dǎo)出數(shù)據(jù)向?qū)r,源服務(wù)器與目標服務(wù)器的字符集、排序順序和整序不必相同。
            ◆因為源數(shù)據(jù)庫中未使用的空間不會移動,所以目標數(shù)據(jù)庫不必與源數(shù)據(jù)庫一樣大。同樣,如果您只移動某些對象,則目標數(shù)據(jù)庫也不必與源數(shù)據(jù)庫一樣大。
            ◆SQL Server 7.0數(shù)據(jù)轉(zhuǎn)換服務(wù)可能無法正確地傳輸大于64KB的文本和圖像數(shù)據(jù)。但SQL Server 2000版本的數(shù)據(jù)轉(zhuǎn)換服務(wù)不存在此問題。
            第2步:如何傳輸?shù)卿浐兔艽a
            如果您不將源服務(wù)器中的登錄傳輸?shù)侥繕朔?wù)器,當(dāng)前的SQL Server用戶就無法登錄到目標服務(wù)器。目標服務(wù)器上的登錄的默認數(shù)據(jù)庫可能與源服務(wù)器上的登錄的默認數(shù)據(jù)庫不同。您可以使用sp_defaultdb存儲過程來更改登錄的默認數(shù)據(jù)庫。
            #p#
            第3步:如何解決孤立用戶
            在您向目標服務(wù)器傳輸?shù)卿浐兔艽a后,用戶可能還無法訪問數(shù)據(jù)庫。登錄與用戶是靠安全識別符(SID)關(guān)聯(lián)在一起的;在您移動數(shù)據(jù)庫后,如果SID不一致,SQL Server可能會拒絕用戶訪問數(shù)據(jù)庫。此問題稱為孤立用戶。如果您使用SQL Server 2000 DTS傳輸?shù)卿浌δ軄韨鬏數(shù)卿浐兔艽a,就可能會產(chǎn)生孤立用戶。此外,被允許訪問與源服務(wù)器處于不同域中的目標服務(wù)器的集成登錄帳戶,也會導(dǎo)致出現(xiàn)孤立用戶。
            1.查找孤立用戶。在目標服務(wù)器上打開查詢分析器,然后在您移動的用戶數(shù)據(jù)庫中運行以下代碼:
            exec sp_change_users_login 'Report'
            此過程將列出任何未鏈接到一個登錄帳戶的孤立用戶。如果沒有列出用戶,請?zhí)^第2步和第3步,直接進行第4步。
            2.解決孤立用戶問題。如果一個用戶是孤立用戶,數(shù)據(jù)庫用戶可以成功登錄到服務(wù)器,但卻無權(quán)訪問數(shù)據(jù)庫。如果您嘗試向數(shù)據(jù)庫授予登錄訪問權(quán),則會因該用戶已經(jīng)存在而出現(xiàn)下列錯誤消息:
            Microsoft SQL-DMO (ODBC SQLState:42000)
            錯誤15023:當(dāng)前數(shù)據(jù)庫中已存在用戶或角色'%s'。上面介紹了如何使用sp_change_users_login存儲過程來逐個糾正孤立用戶。sp_change_users_login存儲過程僅能解決標準的SQL Server登錄帳戶的孤立用戶問題。
            3.如果數(shù)據(jù)庫所有者(dbo)被當(dāng)作孤立用戶列出,請在用戶數(shù)據(jù)庫中運行下面的代碼:exec sp_changedbowner 'sa'此存儲過程會將數(shù)據(jù)庫所有者更改為dbo并解決這個問題。要將數(shù)據(jù)庫所有者更改為另一用戶,請使用您想使用的用戶再次運行sp_changedbowner。
            4.如果您的目標服務(wù)器運行的是SQL Server 2000 Service Pack 1,則在您執(zhí)行附加操作或還原操作(或兩種操作都執(zhí)行)后,企業(yè)管理器的用戶文件夾中的列表中可能沒有數(shù)據(jù)庫所有者用戶。
            5.如果目標服務(wù)器上不存在映射到源服務(wù)器上的dbo的登錄,您在嘗試通過企業(yè)管理器更改系統(tǒng)管理員(sa)密碼時,可能會收到以下錯誤消息:
            錯誤21776:[SQL-DMO]名稱'dbo'在Users集合中沒有找到。如果該名稱是合法名稱,則使用[]來分隔名稱的不同部分,然后重試。
            警告:如果您再次還原或附加數(shù)據(jù)庫,則數(shù)據(jù)庫用戶可能會再次被孤立,這樣您就必須重復(fù)第3步操作。
            第4步:如何移動作業(yè)、警報和運算符
            第4步是可選操作。您可以為源服務(wù)器上的所有作業(yè)、警報和運算符生成腳本,然后在目標服務(wù)器上運行腳本。要移動作業(yè)、警報和運算符,請按照下列步驟操作:
            1.打開SQL Server企業(yè)管理器,然后展開管理文件夾。
            2.展開SQL Server代理,然后右鍵單擊警報、作業(yè)或運算符。
            3.單擊所有任務(wù),然后單擊生成SQL腳本。對于SQL Server 7.0,請單擊為所有作業(yè)生成腳本、警報或運算符。
            您可以用右鍵單擊選擇為所有警報、所有作業(yè)或所有運算符生成腳本。
            ◆您可以將作業(yè)、警報和運算符從SQL Server 7.0移到SQL Server 2000,也可以在運行SQL Server 7.0和運行SQL Server 2000計算機之間移動。
            ◆如果在源服務(wù)器上為運算符設(shè)置了SQLMail通知,則目標服務(wù)器上也必須設(shè)置SQLMail,才能具有相同的功能。
            第5步:如何移動DTS包
            第5步是可選操作。如果DTS包在源服務(wù)器上存儲在SQL Server中或存儲庫中,您可以在需要時移動這些包。要在服務(wù)器之間移動DTS包,請使用下列方法之一。
            方法1
            1.在源服務(wù)器上將DTS包保存到一個文件中,然后在目標服務(wù)器上打開DTS包文件。
            2.將目標服務(wù)器上的包保存到SQL Server或存儲庫中。
            注意:您必須用單獨的文件逐個地移動這些包。
            方法2
            1.在DTS設(shè)計器中打開每個DTS包。
            2.在包菜單上,單擊另存為。
            3.指定目標SQL Server。
            注意:在新服務(wù)器上,包可能無法正常運行。您可能必須對包進行更改,更改包中任何對舊的源服務(wù)器上的連接、文件、數(shù)據(jù)源、配置文件和其他信息的引用,以便引用新的目標服務(wù)器。您必須根據(jù)每個包的設(shè)計逐個包進行這些更改。
            本文中介紹的步驟不移動數(shù)據(jù)庫關(guān)系圖以及備份與還原歷史記錄。如果您必須移動這些信息,請移動msdb系統(tǒng)數(shù)據(jù)庫。如果您移動msdb數(shù)據(jù)庫,則不必執(zhí)行“第4步:如何移動作業(yè)、警報和運算符”或“第5步:如何移動DTS包”。

          posted @ 2014-08-25 10:12 順其自然EVO 閱讀(197) | 評論 (0)編輯 收藏

          SQL Server 計算機間移動數(shù)據(jù)庫

           注意:支持將數(shù)據(jù)從SQL Server 2000遷移到Microsoft SQL Server 2000(64位)。您可以將一個32位數(shù)據(jù)庫附加到一個64位數(shù)據(jù)庫上,方法是:使用sp_attach_db系統(tǒng)存儲過程或sp_attach_single_file_db系統(tǒng)存儲過程,或者使用32位企業(yè)管理器中的備份和還原功能。您可以在SQL Server的32位和64位兩種版本之間來回移動數(shù)據(jù)庫。您還可以使用同樣的方法從SQL Server 7.0遷移數(shù)據(jù)。但是,不支持將數(shù)據(jù)從SQL Server 2000(64位)降級到SQL Server 7.0。下面分別介紹這幾種方法。
            如果您使用的是SQL Server 2005
            您可以使用相同的方法從SQL Server 7.0或SQL Server 2000遷移數(shù)據(jù)。但是,Microsoft SQL Server 2005中的管理工具與SQL Server 7.0或SQL Server 2000中的管理工具有所不同。您應(yīng)該使用SQL Server Management Studio(而不是SQL Server企業(yè)管理器)以及SQL Server導(dǎo)入和導(dǎo)出向?qū)?DTSWizard.exe)(而不是數(shù)據(jù)轉(zhuǎn)換服務(wù)導(dǎo)入和導(dǎo)出數(shù)據(jù)向?qū)В?/div>
            備份和還原
            在源服務(wù)器上備份用戶數(shù)據(jù)庫,然后將用戶數(shù)據(jù)庫還原到目標服務(wù)器上。在備份過程中時可能有人使用數(shù)據(jù)庫。如果用戶在備份完成后對數(shù)據(jù)庫執(zhí)行INSERT、UPDATE或DELETE語句,則備份中不會包含這些更改。如果您必須傳輸所有更改,那么,假如您既執(zhí)行事務(wù)日志備份又執(zhí)行完整數(shù)據(jù)庫備份,您可以以盡可能短的停止時間來傳輸這些更改。
            1.在目標服務(wù)器上還原完整數(shù)據(jù)庫備份,并指定WITH NORECOVERY選項。
            注意:為防止對數(shù)據(jù)庫做進一步的修改,請指導(dǎo)用戶在源服務(wù)器上退出數(shù)據(jù)庫活動。
            2.執(zhí)行事務(wù)日志備份,然后使用WITH RECOVERY選項將事務(wù)日志備份還原到目標服務(wù)器上。停止時間僅限于事務(wù)日志備份和恢復(fù)的時間。
            ◆目標服務(wù)器上的數(shù)據(jù)庫將與源服務(wù)器上的數(shù)據(jù)庫大小相同。要減小數(shù)據(jù)庫的大小,您必須在執(zhí)行備份前壓縮源數(shù)據(jù)庫的大小,或者在完成還原后壓縮目標數(shù)據(jù)庫的大小。
            ◆如果您將數(shù)據(jù)庫還原到的文件位置不同于源數(shù)據(jù)庫的文件位置,則必須指定WITH MOVE選項。例如,在源服務(wù)器上,數(shù)據(jù)庫位于D:/Mssql/Data文件夾中。目標服務(wù)器沒有D驅(qū)動器,因而您需要將數(shù)據(jù)庫還原到C:/Mssql/Data文件夾。有關(guān)如何將數(shù)據(jù)庫還原到其他位置的更多信息,請查看相關(guān)資料。
            ◆如果您想覆蓋目標服務(wù)器上的一個現(xiàn)有數(shù)據(jù)庫,則必須指定WITH REPLACE選項。
            ◆源服務(wù)器和目標服務(wù)器上的字符集、排序順序和Unicode整序可能必須相同,具體取決于您要還原到SQL Server的哪種版本。有關(guān)更多信息,請參閱本文中的“關(guān)于排序規(guī)則的說明”一節(jié)。
            Sp_detach_db和Sp_attach_db存儲過程
            要使用sp_detach_db和sp_attach_db這兩個存儲過程,請按下列步驟操作:
            1.使用sp_detach_db存儲過程分離源服務(wù)器上的數(shù)據(jù)庫。您必須將與數(shù)據(jù)庫關(guān)聯(lián)的.mdf、.ndf和.ldf這三個文件復(fù)制到目標服務(wù)器上。參見下表中對文件類型的描述:
            文件擴展名
            說明
            .mdf
            主要數(shù)據(jù)文件
            .ndf
            輔助數(shù)據(jù)文件
            .ldf
            事務(wù)日志文件
            2.使用sp_attach_db存儲過程將數(shù)據(jù)庫附加到目標服務(wù)器上,并指向您在上一步驟中復(fù)制到目標服務(wù)器的文件。
            ◆分離數(shù)據(jù)庫后將無法訪問該數(shù)據(jù)庫,并且復(fù)制文件時也無法使用該數(shù)據(jù)庫。在進行分離的那一時刻數(shù)據(jù)庫中包含的所有數(shù)據(jù)都被移動。
            ◆在您使用附加或分離方法時,兩個服務(wù)器上的字符集、排序順序和Unicode整序都必須相同。有關(guān)更多信息,請參閱本文中的“關(guān)于排序規(guī)則的說明”一節(jié)。

          posted @ 2014-08-25 10:10 順其自然EVO 閱讀(182) | 評論 (0)編輯 收藏

          學(xué)好Java的10個建議

           1.克服慣性
            將大塊任務(wù)細分為微任務(wù)。
            2.關(guān)注大牛
            你想學(xué)的或許是一門新的編程語言、應(yīng)用框架或者是新的工具,一旦你確定了想要的是什么,就立刻去收集相應(yīng)的優(yōu)秀群體所做的一些優(yōu)質(zhì)的工作成果。這些可以從YouTube、Vimeo、HackerNews、各種博客,甚至是你的微博好友那里獲取。關(guān)注別人做了些什么可以給你強大的信心,讓你覺得 “You can do it, too!”
            3.建立知識網(wǎng)
            當(dāng)你對自己要學(xué)習(xí)的東西建立了信心之后,接下來要做的就是做一塊海綿,然后開始瘋狂地吸收知識。從Google搜索關(guān)鍵詞“beginner tutorials”開始吧,搜索一些跟你要學(xué)習(xí)的知識相關(guān)的入門教程。如你所知,Nettuts+上面有成千上百的各種教程供你選擇,StackOverflow上面也有很多學(xué)習(xí)資源。此外,Quora也是一些不錯的選擇。通過瀏覽這些網(wǎng)上的資源之后,如果想要集中精力學(xué)習(xí)某一方面,這時就需要閱讀一些相關(guān)的書籍了,個人推薦在Amazon上面尋找一些評分較高的專業(yè)書籍來提高自己。
            4. 多聽多看
            隨著你對技術(shù)的深入挖掘,你可能會想利用更多其他形式的學(xué)習(xí)資料,比如podcasts,screencasts等等。我的建議是多用 iTunesU,這上面有很多很專業(yè)的知識可以讓你對于特定的領(lǐng)域進行深入的探索。
            目前,有很多的網(wǎng)站都有提供在線教育服務(wù),你可以在下面幾個網(wǎng)站上找到自己需要的教程:
            · Udemy
            · CodeCademy
            · CodeSchool
            此外,你也可以看一些免費的會議視頻材料,比如YouTube上面的Google IO,以及Confreaks!
            5. 行動起來
            用你所掌握的技術(shù)做一個個人的小項目,設(shè)計一些簡單的功能并且實現(xiàn)他們。毫無疑問,你會遇到很多的絆腳石,當(dāng)遇到它們的時候,在StackOverflow或者Google上面搜索之,解決之。你已經(jīng)踏上一條成為某一領(lǐng)域?qū)<业穆贸蹋龅降睦щy挫折越多,你會變得越睿智。有句老話說得好,“專家是犯錯最多的人”,這意味著他們嘗試了很多瘋狂的事情來探索這門技術(shù)的極限,最后,對于這門技術(shù)是如何運作的就可以知根知底。擁有這種洞察力之后,他們便可以隨心所欲的運用這項技術(shù)去按照自己的意愿完成想做的事情(當(dāng)然,是做好的事情)。
            6. 寫博客
            如果你想走的更遠(比如想像Nettuts+上面的職業(yè)作者一樣),你也可以制作屬于自己的screencasts。總的來說,寫博客能夠提升你的個人溝通能力,這與你學(xué)到的技術(shù)同樣重要。
            7. 感受技術(shù)的脈搏
            社交網(wǎng)絡(luò)已經(jīng)廣泛應(yīng)用于人們的日常交流以及發(fā)現(xiàn)新鮮事物。Twitter和Facebook是信息的主要來源,與此同時,有很多的網(wǎng)站提供更專注的資訊,如前面提到過的Quora網(wǎng)站,這上面有很多涉及面很廣的一些話題供人們評論。在這上面可以找到很多知名大牛的建議以及觀點。

            8. 參加聚會以及會議
            盡管社交網(wǎng)絡(luò)很棒,但是沒有任何事物可以取代面對面的交流。在你住的附近參加一些小組聚會,在這里你可以找到志同道合的伙伴。你可以知道他人在做的一些有趣的項目,同時也可以在他人的幫助下解決一些自己遇到的難題!同樣的,技術(shù)會議對于分享經(jīng)驗以及增長技術(shù)大有幫助!
            9. 擁抱GitHub
            GitHub是全世界開源項目的標志性“建筑物”。它是知識以及優(yōu)質(zhì)代碼的寶庫。當(dāng)你對某項技術(shù)自我感覺良好的時候,下一步便是在GitHub中瀏覽尋找有趣的項目。閱讀開源代碼,盡可能多的閱讀。這樣做的話,你能夠?qū)W到很多東西,比如說:
            · 如何管理規(guī)模較大的項目
            · 項目中應(yīng)用的有趣的庫
            · 代碼規(guī)范以及代碼全局設(shè)計
            · 文檔風(fēng)格
            · 測試規(guī)范
            · 解決詭異問題的方法,以及發(fā)現(xiàn)項目中有問題的地方
            所有的這些知識都在等待著你去挖掘。有趣的是,這些知識的通過一個簡單的標簽就可以得到,那就是“好奇心”。
            10. 專注學(xué)習(xí)
            如果你擔(dān)心上述的學(xué)習(xí)過程太遲緩,那么你也可以嘗試一下快速學(xué)習(xí)模式。你或許聽說過“24小時學(xué)會某某某”,但是這種方式不是我所推薦的。我認為更合理的是用幾周的時間去學(xué)習(xí)。你可以嘗試一下類似“七周學(xué)會七種語言”或者是“七周學(xué)會七種數(shù)據(jù)庫”等學(xué)習(xí)方法。盡管這些講的是語言以及數(shù)據(jù)庫方面的學(xué)習(xí),但是你在學(xué)習(xí)其他技術(shù)的時候也可以運用這種思維。
            有一個不太相同的學(xué)習(xí)風(fēng)格是“困難學(xué)習(xí)模式”,這種觀點的前提是沒有人可以真正掌握一門技術(shù),除非每天都練習(xí)。所以,想要成為專家,你就需要不停地進行練習(xí)。異曲同工的是你可以查看Katas 和 Koans,他鼓勵的使用你學(xué)的知識來解決問題。這些可以讓你更好地入門以及接受那些陌生的概念,勇敢走出自己的舒適區(qū),開始學(xué)習(xí)新知識!
            學(xué)習(xí)一門交叉的技能
            編程是一項左腦的運動,它利用的是大腦的分析能力,一步一步地尋找解決問題的方法。為了發(fā)揮右腦的功能,你可以嘗試從事一些創(chuàng)造性的活動,比如說畫畫、3D建模、折紙、樂器甚至是制作家庭相冊等。事實上,編程同樣需要大量的創(chuàng)造力。或許你曾經(jīng)遇到過類似的事情,你在睡夢中找到了問題的解決方案。這是因為你的右腦處理問題的方式很不同,它可以從各種地方獲得信息。敏捷開發(fā)權(quán)威人士Andy Hunt就這個話題寫了一本書《程序員的思維修煉》。如果你想點燃你的每一個神經(jīng)元,建議你開始學(xué)習(xí)一門交叉的技能。
            總結(jié)
            掌握一門新技術(shù)振奮人心,這是一項影響你思維的新的體驗。但是首先,你必須克服你的慣性,一旦你做到了,你便開啟了從web的每個角落學(xué)習(xí)知識的旅程。我希望上面講的十點能夠給你的學(xué)習(xí)旅程帶來一些幫助或啟發(fā)。

          posted @ 2014-08-25 10:09 順其自然EVO 閱讀(185) | 評論 (0)編輯 收藏

          僅列出標題
          共394頁: First 上一頁 59 60 61 62 63 64 65 66 67 下一頁 Last 
          <2025年7月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導(dǎo)航

          統(tǒng)計

          • 隨筆 - 3936
          • 文章 - 404
          • 評論 - 179
          • 引用 - 0

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          •  

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 十堰市| 平邑县| 久治县| 穆棱市| 西华县| 财经| 宜城市| 天长市| 蒙山县| 若羌县| 鸡泽县| 望都县| 嘉兴市| 泗洪县| 许昌县| 进贤县| 慈利县| 高密市| 青浦区| 明星| 永胜县| 开封市| 洪泽县| 女性| 巴中市| 广水市| 北票市| 长顺县| 金华市| 东丰县| 广汉市| 砀山县| 饶平县| 闵行区| 息烽县| 雅安市| 桑日县| 察哈| 长白| 威宁| 娄烦县|