• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            Creative Commons License
            本Blog采用 知識共享署名-非商業性使用-禁止演繹 3.0 Unported許可協議 進行許可。 —— Fox <游戲人生>

            游戲人生

            游戲人生 != ( 人生 == 游戲 )
            站點遷移至:http://www.yulefox.com。請訂閱本博的朋友將RSS修改為http://feeds.feedburner.com/yulefox
            posts - 62, comments - 508, trackbacks - 0, articles - 7

            Author: Fox

            //-----------------------------------------------------------------------------------------------------
            夜深了,隨便寫寫……
            //-----------------------------------------------------------------------------------------------------

            大凡學過編程語言和網絡的TX應該都寫過自己的聊天程序,那時候大家都知道了套接字怎么selectconnectbind、listen、acceptsend、recv,也知道了TCPUDP的區別……稍微用功的TX或許還寫過多人聊天程序,知道了什么是阻塞I/O,真正致力于向QQ、MSN等即時聊天工具靠齊的大牛對本文提到的IOCP更是了然于胸。更多的TX或者有興趣繼續看下去。

            一、阻塞I/O(主要指TCP)

            1、當socket的recv buff為空時,進程會wait直到新數據到達;

            2、當socket的send buff已滿時,進程會wait直到空間足夠;

            3、當socket的accept沒有新連接到達,進程會wait直到新連接到達;

            4、當socket的connect沒有收到ACK,進程會wait直到收到ACK。

            而非阻塞I/O則是致力于提供高效的異步I/O。

            二、IOCP(I/O Completion Port,I/O完成端口

            IOCP是MS提供的Windows內核對象,內部使用線程池管理,并根據CPU的個數確定線程個數。當數據到達后,統一投遞到唯一的IOCP隊列,對應的若干工作線程用于處理這些數據,從而實現非阻塞異步I/O。

            簡單了解了IOCP的功能和原理,下面提供幾點線索,供有興趣的TX整理思緒J

            1、OVERLAPPED結構:

            2、CreateIoCompletioPort:用于創建IOCP,關聯連接來的socket句柄,用于接收數據;

            3、GetQueuedCompletionStatus:供工作線程調用,取到數據的線程會加入I/O完成隊列,IOCP的線程池管理這些工作線程。

            三、深入學習和使用

            1、Jeffrey Richter的《Advanced Windows》,第15章,誰看誰知道J

            2、Jim Beveridge & Robert Wiener的《Multithreading Applications in Win32》,第6章,誰看誰知道J;

            3、Google。

            //-----------------------------------------------------------------------------------------------------
            感覺用Office 2007編輯和發布Blog比Live Writer要方便很多,主要是Live Writer的編輯功能太少了,如果2007能夠對鏈接進行target設置,
            再支持EntryName就perfact了J。
            從新公司回來,還沒有完全適應這邊寬松的環境,這幾天好似夢游一般,先是IE出問題,Ghost了一道,后面是Outlook收郵件出問題。
            還是夜深人靜的時候,一個人燃著煙、聽著歌、喝著茶、敲著鍵盤有感覺……
            //-----------------------------------------------------------------------------------------------------

            posted @ 2008-03-06 01:18 Fox 閱讀(4432) | 評論 (7)編輯 收藏

            Author: Fox

            //-----------------------------------------------------------------------------------------------------
            因為要歸位回原公司了,手上便沒有什么工作了,難得清閑下來,就整理一些很雜的東西,準備下周回去了J
            //-----------------------------------------------------------------------------------------------------

            零、關于此文

            下面的東西很雜,但并非沒有關聯。

            一、關于《瘋狂的程序員》

            有些搞程序的人有個癖性:自負偏激,主觀絕對。

            早就看過一點兒,因為時間,沒有怎么關注,下午就找來CSDN的blog上面連載的《瘋狂的程序員》來看。

            正如很多人所評論的,在絕影身上,大家都找到了自己當初學程序的影子。哪個稍有點技術的程序沒有點自負的心理呢?絕影的性格很偏激,人很要面子,想法很陰暗,對世界的認識很主觀、很絕對。

            可惜的是,這個東西,只能當作小說看,其他不做評論……

            二、關于Windows的環境變量

            有些搞程序的人有個癖性:能用鍵盤的堅決不用鼠標。

            查看幫助,按F1,重命名,按F2,搜索,按F3,輸入地址,按F4,刷新,按F5……

            桌面上很干凈,沒有"我的電腦"的圖標,都用WinKey+E。沒有IE的圖標,都用WinKey+R,輸入iexplore,回車……

            快速啟動里面沒有"顯示桌面"的圖標,都用WinKey+D,或者WinKey+M,沒有Outlook的圖標,都用WinKey+R,輸入outlook,回車,Word就輸入winword,記事本就輸入notepad……

            打開大多程序,不用鼠標到處點擊,都是"運行"里面輸入命令行替代了。除了Windows默認的這些,自己常用的其他軟件怎么辦呢?Windows有個環境變量。下面我給大家show一下,怎么不用鼠標,完成自定義環境變量,實現命令打開任一軟件J

            1、WinKey+E,打開"我的電腦";

            2、Alt+Enter,打開其"屬性";

            3、方向鍵,選擇"高級";

            4、Alt+N,打開"環境變量";

            5、Tab鍵,選擇"系統變量";

            6、方向鍵,選擇"Path";

            7、Alt+I,打開"編輯";

            8、End鍵,移動到最后;

            9、輸入";targetpath";*

            10、Tab鍵,選擇"確定",回車,Tab鍵,選擇"確定",回車;

            11、WinKey+R,打開"運行";

            12、輸入"softname",回車;*

            13、Over。

            //-----------------------------------------------------------------------------------------------------
            其中,targetpath為soft所在文件夾絕對路徑,softname為軟件對應的exe文件名(.exe可省略)……
            //-----------------------------------------------------------------------------------------------------

            posted @ 2008-02-29 18:11 Fox 閱讀(1758) | 評論 (3)編輯 收藏

            Author: Fox

            //-----------------------------------------------------------------------------------------------------
            關于反外掛,這兩天在和幾位同事和網友討論的結果依然是,更多的要從策劃角度解決……
            //-----------------------------------------------------------------------------------------------------

            最近在考慮安全問題的時候,在《游戲編程精粹3》中看到Pete Isensee的《安全套接字》(即通常所說的Secure Socket Layer, SSL技術),又Google了一些IPSec的相關資料。盡管IPSec是部署在IP層的協議,但它還是可以為我們提供一些思路。

            一、IPSec的認證安全(AH+ESP)

            1、不可否認性:采用公鑰加密的數字簽名具有抗抵賴性。

            2、防止報文重放:使用序列號和滑動窗口以保證數據包的唯一性,即使數據包被截獲重發,也會因序列號的相同或者錯誤而被拋棄。

            3、完整性:IPSec使用單獨的鑒別頭部(Authentication Header, AH)信息進行校驗,防止報文篡改,校驗的算法主要是MD5、SHA-1等單向哈希算法。

            4、可靠性:通過加密封裝安全有效載荷(Encapsulating Security Payload, ESP),IPSec對傳輸數據進行保護,加密算法除了MD5、SHA-1,還有加密塊鏈接(Cipher Block Chaining, CBC)模式加密算法等。

            二、IPSec的數據加密

            在數據加密上,IPSec使用的主要是DES(Data Encryption Standard)和3DES(Triple Data Encryption Standard)算法。

            三、IPSec的密鑰管理

            為了保證數據傳輸安全,IPSec使用由IKE(Internet Key Exchange)提供的動態密鑰更新機制,Diffie-Hellman算法提供密鑰生成策略,通信兩端需要維持一個安全關聯(Security Association),為兩端通信指定認證及加密所用算法和密鑰,并提供序列號和滑動窗口等。

            需要注意的是,IPSec并沒有提供數據產生到發送之前的保護機制。舉例來說,就是IPSec可以在最大程度上保證你輸入的帳號密碼在傳輸過程中的安全,但并不能防止釣魚軟件和其他木馬在你輸入這些信息時被截獲L,那應該是你要注意的。

            對IPSec有興趣的TX可以到http://www.ietf.org上下載相關的RFC文檔研究研究J

            //-----------------------------------------------------------------------------------------------------
            本以為手上工作完成,可以偷時間看看安全方面的東西,不曾想Joe又分下了新任務L……
            //-----------------------------------------------------------------------------------------------------

            posted @ 2008-02-28 20:54 Fox 閱讀(2095) | 評論 (3)編輯 收藏

            Author: Fox

            //-----------------------------------------------------------------------------------------------------
            此篇僅是對反脫機外掛的一點思考,其他安全問題如登錄驗證、消息驗證等更多的是涉及邏輯功能。
            //-----------------------------------------------------------------------------------------------------

            春節剛回來的時候,回公司去和Soft聊到了自己的畢業論文的問題,因為專業的關系,我必須給出一些安全方面的考慮,正是因為這一點,我當時開題時就立足對安全的無縫游戲世界進行思考。只是在游戲本身的安全性上,一直也沒有一個好的出發點,這兩周還是在考慮這個問題。

            這一點,有我入行時間不長,對于游戲本身、玩家與開發者(含游戲及外掛、木馬開發者)之間的關系并沒有一個很好的把握,更多的是由于我對游戲中的可用的安全技術不了解,尤其是對應用層安全協議不了解,對破解技術也不了解,導致無所適從。

            《游戲編程精粹1》中Andrew Kirmse在《在線游戲的網絡協議》一文中對常見的篡改報文、報文重放和逆向工程有講述。預防報文篡改的有效防御是哈希校驗,現在大多游戲是使用MD5算法,而且網上開源的MD5代碼也很多。對于報文重放,Andrew提到了使用線性疊加隨機數的狀態機,具體原理和實現方式因為沒有提到太詳細,還要針對實際應用繼續學習L。然而,由于客戶端既是報文的接收者也是發送者,因此,客戶端包括了完整的加解密算法。一旦客戶端被逆向,上述措施就變成了破解者背后的煙霧彈,完全失去意義。

            提到反外掛,Joe的看法也是說這個東西和具體某一個技術關系不大,還是要從機制上去看。加不加密對于普通玩家沒有意義,對于專業從事逆向的人更是也沒有意義,所有單純考慮加密是沒有效果的。對于免費游戲,外掛往往是打錢公司的工具,你封他的號,他再建就是了,代價幾乎為0,而一般付費游戲(像魔獸世界)一個帳號對應一個CDKey,一個CDKey就要幾十塊錢,這個封起來就有點咬牙了。

            說到這里,不妨換個思路:為免費游戲加入CDKey。我一款游戲從內測、封測到公測,讓玩家充分參與體驗,在被逆向且外掛橫行之前,按正常邏輯運營。進而假定我這一款游戲在公測之后,讓玩家感覺魅力十足。引導玩家并實施CDKey,一個CDKey大約會需要玩家付出些許Money以示誠意,在玩家游戲過程中,會階段性向玩家贈送部分增值道具。老玩家在進入新區時,需要申請繼續使用原CDKey。這樣一來,外掛就不會肆無忌憚了。

            BTW,這個思路沒有從技術角度解決問題,下面再來看一種略微關乎技術實現的解決方案:動態驗證。在游戲運行期間,會不定期的向玩家發送驗證碼,客戶端在收到消息后,必須在一定時間內響應,向服務器確認收到的驗證碼,否則將被強制下線,再次登錄后將更加頻繁的收到驗證碼,直到用其良好的回復次數累積消除其不良記錄為止。為了盡量減少因此給玩家造成的不友好體驗,在任務場景、重要PK場景或者高等級玩家活動場景,驗證碼的發送和確認可適當放寬

            當然,如果外掛中加入了圖形識別,這一招也未必奏效。

            不知是道高還是魔高,可以肯定的一點是:大家都是在利益的驅動下絞盡腦汁。

            //-----------------------------------------------------------------------------------------------------
            春節回來之后,一直比較忙(確切的說是比較懶),沒有更新,宜更加勤奮。
            最近工作涉及到數據庫編程,一點點對數據庫的讀寫居然耗掉我3天時間,汗!
            //-----------------------------------------------------------------------------------------------------

            posted @ 2008-02-26 16:04 Fox 閱讀(2621) | 評論 (10)編輯 收藏

            Author: Fox

            終于趕在周末之前調通了,現在來總結一下我這個項目中對于異步回調的應用背景。

            這個項目的內容就是在游戲中使用第三方庫為所有玩家提供更好的服務,當server啟動后,加載dll,初始化該模塊,當server退出時,結束模塊功能,卸載dll。

            當玩家提出請求后,server在main thread中通過lib轉發玩家請求,lib處理完畢,在其獨立thread中回調server為其實現的callback function。此時,server需要將返回的result轉到main thread中對result及其相關的玩家數據進行處理。

            第三方庫的需求是很明確的,在合適的地方發送請求,在合適的地方處理響應。

            Joe對我的要求也是很明確的,響應處理時采用server當前架構(這個架構在上一篇文中有提到),使我的編碼不涉及任何游戲功能邏輯處理,并使整個處理流程細節對后續應用開發透明。

            二者結合起來,就為這個項目融入整個server的架構提供了完美的需求,也為我的編碼提供了最小限度的選擇空間:(,好處是后續功能開發可以完全無視我的編碼,只需實現對回調響應后的功能,只有server底層知悉如何調用。

            給出序列圖:

            ?

            uml_asny_callback

            為了保持對上層開發透明,OnCallback需要封裝。

            //-------------------------------------------------------------------------------
            // 一年來,我主要參與了兩款游戲,確切的說是半年,前面半年并沒有真正涉及運營產品的開發,只是做工具。
            // 現在這個模塊是我做的最快,也是壓力最大的一個?,F在想來,原因在于此模塊涉及到游戲主邏輯底層和
            // 第三方動態鏈接庫的通信及處理。
            // 在短短幾天的時間內讓你的設計滿足第三方庫的應用需求并符合游戲自身底層邏輯的設計風格,的確有些痛苦,
            // 好在有Joe的指點,讓我在完成工作的同時又學到了一些方法:)。
            //-------------------------------------------------------------------------------

            posted @ 2008-01-25 11:27 Fox 閱讀(1568) | 評論 (4)編輯 收藏

            Author: Fox

            前段時間寫過一篇關于線程安全的文字,有TX覺得不深入。因為本來就沒想寫的太具體,只是隨便說說,今天就想說點具體的技術。

            //-------------------------------------------------------------------------------
            // 動態鏈接庫 (Dynamic Link Library)

            1) 動態鏈接;

            2) 跨語言;

            3) Win32平臺可用;

            ?1?// ?靜態鏈接庫.h文件中對函數的聲明:
            ?2?//?dllExam.h

            ?3?extern?"C"?void?/*__stdcall*/?Func(?int ?nParam?);
            ?4?

            ?5?// ?動態鏈接庫.h文件中對函數的聲明:
            ?6?//?dllExam.h

            ?7?extern?"C"?void?__declspec(?dllexport?)?/*__stdcall*/?Func(?int ?nParam?);
            ?8?

            ?9?//?動態鏈接庫的靜態調用:
            10?#pragma?comment(lib,"dllExam.lib" )?
            11?extern?"C"?__declspec(dllimport)?/*__stdcall*/?Func(?int
            ?nParam?);
            12?

            13?dllFun(0 );
            14?

            15?// ?動態鏈接庫的動態調用:
            16?//?useDllExam.cpp

            17?typedef?void(/*__stdcall*/?*CallFun?)(?int?);????//?宏定義,方便使用
            18?
            19?HINSTANCE?hDll;????????????????????????//?DLL句柄
            20?CallFun?dllFun;????????????????????????//?庫函數指針
            21?hDll?=?LoadLibrary(?"dllExam.dll" ?);
            22?if
            (?hDll?)
            23?
            {
            24?????dllFun?=?(CallFun)GetProcAddress(hDll,?"Func"
            );
            25?????if
            ?(?dllFun?)
            26?
            ????{
            27?????????dllFun(0
            );
            28?
            ????}
            29?
            ????FreeLibrary(hDll);
            30?}


            動態鏈接庫的一般應用都在這兒了,更加具體的就要去問google了:)。

            //-------------------------------------------------------------------------------
            // 異步回調 ( Asynchronism Callback )

            今天想說的主要內容是異步回調。大致結構是:

            //-------------------------------------------------------------------------------
            //??????????????? ?????????? IAsyncCaller? IAsyncCallback
            //???????????????????????????????????????? \??? /
            // CManager --> CSession --> CEvent
            //-------------------------------------------------------------------------------
            // class :??CManager
            // function :?Singleton實現,管理所有CSession對象

            // class :??CSession
            // function :?處理會話,關聯事務

            // class :??CEvent
            // function :?Session的關聯對象,處理異步回調
            // base class:?IAsyncCaller, IAsyncCallback

            在發起session的時候,new一個CSession對象,為其分配一個GUID,并加入管理session的CManager對象的map(支持多線程操作),new一個CEvent對象,將該CEvent對象設置為回調響應的host,該CEvent對象可進行其他同步處理。

            當回調條件滿足,由CManager通過相應CSession對象觸發,并交由其關聯的CEvent對象處理。

            如果CEvent應用規模較小,可由CManager的map直接管理,省掉CSession的中間處理。

            這種處理方式的優點是,將普通事務的回調處理機制抽象為通過Session Manager(CManager)進行統一管理,普通事務的處理放到main thread中,線程間通信則交給CManager和CSession,實現了良好封裝。

            //-------------------------------------------------------------------------------
            // 具體實現這里就不給出了,用到的TX根據上面的描述應該大概知道怎么做了。其他TX如果不清楚的話,
            // 清楚的話,可以先google其中的一些關鍵詞。動態鏈接庫的部分因為內容很少,因此也只提供基礎使用。
            //
            // PS: 因為GF學知識產權的,剛好了解到有這樣一個“創作共用”協議,而且最近很多人在討論
            // cppblog的原創精神問題,于是大家就看到我blog頂部的這個東西:)。
            // 注釋風格也改成自己平時用的了:)。
            //-------------------------------------------------------------------------------

            posted @ 2008-01-23 11:04 Fox 閱讀(2429) | 評論 (4)編輯 收藏

            Author: Fox

            一、多線程安全的引入:

            關于什么是多線程、為什么使用多線程的問題,大家可以看看Jim Beveridge & Robert Wiener的《Win32多線程程序設計》(侯捷 譯),或者其他隨便一本提到多線程的書或文章。這里只是提到Windows環境下多線程容易引發的問題和解決辦法。

            1、線程在時間片結束時退出做不到

            由于Windows屬于分時操作系統,系統會為每個線程分配響應的時間片使其工作,絕大多數線程不可能在時間片結束的時候完成其工作,而下一個時間片就有可能分配給其他線程。

            2、線程獨立做不到

            如果線程間不存在依賴關系,即線程A的執行不依賴于線程B的執行,此時即使線程B被打斷,由于線程獨立,所以二者也可以相安無事。

            然而,在多線程解決方案中,線程間的通信是頻繁而且必要的。線程通信主要有兩種情況:

            1) 多個線程共享相同資源;

            2) 一個線程的執行依賴于其他線程的結果或執行情況。

            這時,我們就需要實現共享資源及線程執行的同步。

            二、多線程安全的解決方案:

            因此,多線程安全的目標就是實現共享資源的互斥訪問和線程執行的同步通信。

            通過對操作系統的學習,我們知道線程同步主要有以下方法:

            1) 臨界段(Critical Section)

            a) 臨界資源的取舍,宜少不宜多,宜短不宜長,一個線程只能最多等待一個臨界段;

            b) 無法偵測一個臨界段是否已經被放棄;

            c) 臨界段屬于用戶對象。

            2) 互斥鎖(Mutex)

            同臨界段一樣,互斥鎖也主要用于保證資源的原子訪問,二者的不同之處在于:

            a) 互斥鎖屬于可具名內核對象;

            b) 互斥鎖可以跨進程使用,臨界段只能用于同一進程內;

            c) 互斥鎖可以指定等待時間,而且可以等待其他內核對象。

            3) 事件(Event)

            a) 事件重置具有人工重置和自動重置兩種方式,簡單說來,二者分別用于多讀和單寫;

            b) 事件主要用于線程間相互通知(喚醒);

            C) 事件屬于可具名內核對象。

            4) 信號量(Semaphore)

            a) 信號量屬于可具名內核對象;

            b) 信號量沒有擁有者,可被任一線程釋放;

            關于Win32中這四種對象的使用和要點,更詳細的介紹可以參照《Win32多線程程序設計》或《Windows核心編程》(Jeffrey Richter)等。

            三、多線程安全的實現:

            將對數據(對象、模型、消息、Socket)的I/O處理放在同一個I/O線程中,保證如隊列的push/pop操作、鏈表的insert/delete操作、文件的write操作、socket的recv/send操作、全局變量的write操作等的互斥訪問。

            新建獨立模塊,尤其是使用第三方庫的獨立模塊,大多會創建獨立的新線程。此時就需要對新線程中的數據操作加以注意,可以通過對操作數據的加鎖訪問解決同步問題,當然,更常見的處理方式是將新線程中的數據操作發送到專門的I/O線程中處理。

            總之,多線程安全是個常說常新的話題,現在有人提出Lock-Free數據結構的解決方案(Maged M. Michael),也有所謂的Wait-Free的解決方案(Maurice Herlihy),而國內網游界的大牛云風同學更是提出了單線程多進程的觀點和解決方案(因為不了解,按字面有可能存在斷章取義之嫌)。但不管怎么樣,從中至少可以看出,多線程,說來話長。

            零零散散、東拉西扯、不知所云的講了一些東西,未必正確,更不能當作知識。全當是對上次的承諾有個交代。

            /*****************************************************************************
            ?想把多線程的問題搞明白,不是說看看操作系統教材,寫點多線程讀寫的代碼就夠的。且不論孰是孰非,
            ?單就網上諸多高手新學對加鎖策略鋪天蓋地的爭執說辭甚至相互批判指責,足可見多線程開發并非只言
            ?片語即可挑明。
            ?為防止陷入細節爭論,這里先作聲明:小文僅就所學略抒拙見,無意引起爭端……
            *****************************************************************************/

            posted @ 2008-01-10 04:02 Fox 閱讀(2722) | 評論 (10)編輯 收藏

            Author: Fox

            元旦放假3天,本來想把前面寫的一個存在線程安全隱患的模塊推倒重來的,可是改著改著就覺得不對勁了。

            既然是返工,就想盡量把現在的理解完全加進去,讓后面的人看了不要罵??墒窍氚褞浊械拇a改得面目全非并且更加安全準確也并不是一件容易的事,雖然對于功能和邏輯的認識比以前要清晰的多。

            拿到一個新的模塊,上面一般會給個大致的deadline。除非你對這個模塊和整個項目的依賴關系(接口、邏輯、功能)有很好的把握,否則,你根本不知道到底有多少東西是已經實現的,有多少東西是可以復用的,有多少東西是需要修改的,有多少東西是要重寫的,有多少東西是要新加的,僅僅根據需求預估的進度是不可能恰到好處的。而脫離了整個項目實現的模塊是非??赡艹鰡栴}的,尤其是在使用多線程的項目中。

            當我的這個模塊完成并上馬之后,我沾沾自喜的跟上面說,應該是不會有問題了,上面跟我說了一句:如果不出問題就是奇跡了,我當時頗不以為然。在后面一兩周之內真的就是沒有什么問題,我真想告訴他是我創造了奇跡。

            “奇跡”在2007年的最后一周破滅了。在我從西嶺雪山回來的那天,為了增加新功能把代碼修改了一些,結果第二天更新之后,服務器就老是有問題,找了一下午,才發現在修改代碼的時候居然忘記對一個pointer做NULL判定!我心想,這種錯誤居然都出來了!死了算了!而且這個問題出在非主線程中。然后就和同事在考慮,這個東西如果線程同步出現問題,你就是每次使用前都做NULL判定也沒用,所以就決定把這個模塊重寫了。

            在這兒我就不想就線程安全問題多說了,以后想好了再專門去寫點多線程的東西吧,今天只是想說點瑣碎的東西。

            因為是放假,心思未必就全部放在上面了,代碼沒改多少,倒是玩了很長時間的游戲。后來想想,也不全是時間問題,幾千行的代碼改來改去,難保不出現更多的問題。必須把它當作一個新的模塊去寫,先要把邏輯結構完全理出來,能多細化就多細化,最好能夠精確到變量的使用,而且把文檔做細,這樣就可以在寫文檔的過程中把問題盡可能想全想清楚。改代碼先改文檔,這幾乎是所有學過軟件工程并寫過項目的同學都能認識并理解的常識,可是在實際工作中,上有任務催趕,下有閑心雜念,很難把文檔和注釋寫好。而做不到這一點的話,你就不敢保證你的模塊不出差錯。

            所以,對于一個一般的需求,如果deadline是2個月的話。讀需求、評估依賴關系、量進度要花掉1周,畫邏輯結構、寫文檔要花掉3周,相當于前面一半的時間沒有動手寫代碼,然后寫代碼大概只用1周,甚至更少,其他時間就留給測試和修改文檔、代碼了。從軟件工程的角度,這樣的分配是合理的,而且是應該的,但到了實際項目里面,又做不到!看來,不管是manager,還是coder,都不能急,軟件工程不能白學了。

            我發現,我的軟件工程就是白學了,以后得改改。

            /*****************************************************************************
            ?不想回頭去動以前的代碼,每次看以前寫過的東西,都有一種想把它徹底刪除的沖動。
            ?把需求看好、文檔寫好、時間安排好,這才是硬道理……

            ?畢竟是新年,還是祝大家:新年快樂!
            ?重要的是,新的一年,別荒廢了……
            *****************************************************************************/

            posted @ 2008-01-02 02:43 Fox 閱讀(786) | 評論 (6)編輯 收藏

            Author: Fox

            對于(1+2+...+N) 的求和,最早就是看高斯的故事,而且說實話,我是沒有這樣的智商的:

            ????????????????sum(1+2+...+N) = N*(N+1)/2

            剛看了一篇研究該級數求和的文章,雖為調侃,但實在感覺文中紕漏太多,不禁在此多言。

            文中的第一種方法自稱標準,而且還能使“全班2/3的同學都用俺的標準應付老師和試卷”,我大為驚詫:

            1?int?i,?sum?=?0 ;
            2?for(i?=?1;i?<?N;i?++)sum?+=
            ?i;
            3?printf("1-N的級數和是:?%i",sum);


            顯然,printf的結果是N-1個數的和,此處,我更愿意相信是文中的筆誤而已。

            第二種和第三種方法讓人覺得奇怪:

            1?float ?sum;
            2?sum?=?(N?^?2)?/?2?+?N?/?2
            ;
            3?printf("1-N的級數和是:?%i",(int
            )sum);
            4?

            5?float ?sum;
            6?sum?=?N?*?(N?/?2?+?0.5
            );
            7?printf("1-N的級數和是:?%i",(int)sum);


            前面的寫法純屬惡搞,^在C/C++中是異或位操作,相信接觸過位運算的人都知道這一點,而且當N為奇數時,sum的結果將比真實值少1。后面的寫法更是荒唐,當N為奇數時,sum的結果將比真實值相去更遠(有興趣的可以仔細看看)。

            對于后面兩種寫法,我想說的重點不是這些明顯的錯誤,因為這樣的錯誤只可博眾君一笑。但文中定義sum使用float的做法,讓我百思不得其解。對于計算機的運算,浮點運算的耗時和整型運算的耗時,那不是一個數量級的。對于該級數運算,我們完全可以避免浮點運算,而且方法在文章一開始,就已經給出了:

            1?int ?sum;
            2?sum?=?N*(N+1)/2
            ;
            3?printf("1-N的級數和是:?%i",?sum);


            無論N為奇數還是偶數,N*(N+1)一定是偶數,因此,上述方法不存在浮點運算,而且系統會自動將/2的操作優化為右移1位。

            不知怎么,忽然就想到了遞歸,想到了Fibonacci數列。講遞歸的教材都會拿上面的級數求和和Fibonacci數列做例子。其實,我個人感覺這是不恰當的,但想想為了讓學生掌握遞歸算法,也只能舉類似的簡單的例子。我們也知道,遞歸計算對于堆棧調用是非常頻繁而耗時的,對于求Hanoi塔這樣的復雜問題,我不知道不用遞歸有沒有更好的方法,但如果計算Fibonacci數列還是使用遞歸,在初學遞歸時是可以原諒的。簡單點的方法可以是這樣:

            ?1?int?fib_odd?=?0,?fib_even?=?1 ?;
            ?2?int?n?=?(N+1)/2
            ;
            ?3?for(int?i=0;?i<n;?i++
            ?)
            ?4?
            {
            ?5???fib_odd?+=
            ??fib_even;
            ?6???fib_even?+=
            ??fib_odd;
            ?7?
            }
            ?8?int?nFib?=?0
            ;
            ?9?if(?N?%?2
            ?)
            10???nFib?=
            ?fib_odd;
            11?else

            12???nFib?= ?fib_even;
            13?printf("Fibonacci數列前N項和是:?%i",nFib);?


            上面的兩段代碼中sum和nFib的值不能太大:)。

            常言道,言過必失。但自私一點講,把自己的錯誤暴露給別人,可以讓自己更好的進步:),因此,我寫下來,提醒自己也提醒大家,更歡迎大家多批評指正。

            posted @ 2007-12-21 10:19 Fox 閱讀(3365) | 評論 (10)編輯 收藏

            Author: Fox

            俗話說,道高一尺,魔高一丈。

            今天在一個群里,有人提到某某算法(3DES)可以杜絕外掛。我當時心里苦笑一聲:哥們兒,太逗了。這年頭,中國人已經被忽悠怕了。我信鬼信魔,就是不信佛……

            不過想想,如果能在一定程度上打擊外掛,也不錯,可是討論了半天,愣是沒有給出具體的方案,最后還是不了了之。

            不過,有時間把思路整理整理,提一個稍微好一點的方法也好。

            王城里面,一排排的外掛小號像閱兵一樣,囂張成馬了,完全不把我們放在眼里。

            話說回來,連個脫機外掛都防不住,別人還確實沒必要把你放在眼里。

            這邊Login Server搞了兩三個月的驗證碼,感覺不錯,因為不使用外掛的玩家每次都要折騰半天,我們自己人員輸入驗證碼輸的都煩,結果沒出半個月外掛又開始橫行了,感覺比以前還囂張。

            我是外掛,我得意的笑,我得意的笑……

            敢情是防賊沒防住,把賊扔屋里,自己被鎖在外面了!

            /*****************************************************************************
            ? 晚上本來想自己寫個內掛,可以偷偷懶,可惜對這東西實在是從來沒有過研究。
            ??折騰了一晚上,郁郁而終。
            ? 技不如人啊!想來都覺得可笑……
            *****************************************************************************/

            posted @ 2007-12-20 02:08 Fox 閱讀(2194) | 評論 (21)編輯 收藏

            僅列出標題
            共7頁: 1 2 3 4 5 6 7 
            深夜久久AAAAA级毛片免费看| 久久久国产精华液| 国产综合免费精品久久久| 国产AⅤ精品一区二区三区久久| 久久久91人妻无码精品蜜桃HD| 久久激情五月丁香伊人| 久久精品国产亚洲av麻豆图片| 亚洲精品国产字幕久久不卡| 丰满少妇高潮惨叫久久久| 国内精品久久久久久久影视麻豆| 国产91久久综合| 久久人人爽人人爽人人片AV高清| 国产午夜精品久久久久免费视 | 69SEX久久精品国产麻豆| 一97日本道伊人久久综合影院| 久久久国产乱子伦精品作者| 国产香蕉97碰碰久久人人| 久久人人爽人人爽人人av东京热| 久久97精品久久久久久久不卡| 午夜精品久久久久久毛片| 久久国产精品国语对白| 国产亚洲美女精品久久久久狼| 麻豆久久久9性大片| 精品久久久久久中文字幕大豆网| 66精品综合久久久久久久| 亚洲国产精品久久久久网站| 色8久久人人97超碰香蕉987| 亚洲AV成人无码久久精品老人| 国内精品久久久久国产盗摄| 久久综合中文字幕| 国产精品女同一区二区久久| 狠狠色丁香久久婷婷综合五月 | 亚洲AV无码久久精品成人| 四虎久久影院| 久久久久亚洲爆乳少妇无| 91麻豆国产精品91久久久| 一本色综合网久久| 精品国产91久久久久久久| 久久久久久久97| 97久久久精品综合88久久| 青青草原1769久久免费播放|