專業(yè)程序員的7個素質(zhì)： 承擔(dān)責(zé)任，高質(zhì)量代碼，代碼上的時間，對自己領(lǐng)域的精通，思維模式，溝通，合作。

1 。 寫邏輯代碼寫完后一定要對著自己的邏輯全部走通一遍。不要寫完立即開始運行調(diào)試。這樣的調(diào)試會浪費大量的時間。因為有些錯誤僅僅是因為你代碼寫錯，筆誤，或者邏輯的一個漏洞而導(dǎo)致。而這些問題都是非常簡單的。所以我們在寫完邏輯的時候一定要對著代碼理一遍思路，看看有沒有一些弱智錯誤，再三確認無誤再去運行調(diào)試。

2 更改代碼邏輯的時候，記住一定要去增加代碼，而不要去刪除或者更改代碼。增加代碼是最好的方式。

3 在更改一些代碼的情況，比如修改了一個變量的名字或者邏輯。一定要多思考這個地方更改的這個變量有沒有在其他的地方使用到過。邏輯的修改會不會影響其他代碼的調(diào)用?。?！ 有的時候不小心改了一個地方，但是沒有去思考，其他原本正確的邏輯也錯了，會給自己帶來相當(dāng)大的困擾??！ 也需要不斷的打印日志去查找。 其實就是一個非常弱智的錯誤?。?！

4.在調(diào)用別人的接口獲取數(shù)據(jù)的時候一定要給自己留一手！特別是在自己寫一個獨立的功能需要用到一些其他模塊的數(shù)據(jù)！ 取到數(shù)據(jù)一定要判斷一下有沒有！ 最好直接斷言。 防止你自己模塊出問題其實是別人那的數(shù)據(jù)問題??！

5 自己的接口函數(shù)盡量要想辦法不去依賴全局變量或者其他獲取數(shù)據(jù)的接口！ 要什么數(shù)據(jù)全部以參數(shù)的方式傳進來?。?參數(shù)的方式傳進來。 自己傳參數(shù)可以保證數(shù)據(jù)是正確的。另一種情況，這個接口要移植就會非常的方便，只需要自己用不同的方式創(chuàng)建參數(shù)數(shù)據(jù)。

6 在一些問題使用當(dāng)前的方法無法解決的時候，一定有新的方法可以驗證你的錯與對。你可以輸出幾種情況進行比較。

做項目一定要抽時間看看別人的代碼，先從跟你有關(guān)聯(lián)的地方開始看，再看跟你沒有關(guān)聯(lián)的地方。第一可以學(xué)習(xí)別人設(shè)計好的地方和良好的代碼。第二在添加功能和修改bug的時候可能需要跟他們的代碼進行聯(lián)系，之前讀過他們的邏輯這樣就很方便。

8 再添加一個游戲功能的時候一定要多考慮一些東西，在一些特殊的情況一定要多考慮，比如游戲的斷線重連，考察需要還原的數(shù)據(jù)是否有你需要的。比如添加一個if條件， if myserver == 3. 你一定要去假象有沒有myserver不定于3卻又滿足你邏輯的情況！ 一定要多思考，不然會給別人帶來很多的麻煩。

9.全局變量或者單利類 真的是有利有弊，今天算是體會到了。 exp.一個全局分配事件管理器g_eventManager，自己在一個類里面注冊了事件A，但是在釋放類的時候忘記刪除了事件A，在下一個環(huán)境創(chuàng)建這個類的時候有一次注冊了事件A！ 所有在分配事件的時候你會發(fā)現(xiàn)A事件執(zhí)行了兩次??！ 如此循環(huán)，程序直接卡死。

10 盡量不要出現(xiàn)這樣的代碼：

for （i = 0 ;i《20;i ）

{

if （a == getSelfData （））

}

關(guān)注這個getSelfData（）函數(shù)，被調(diào)用了20次，其實這個值是固定的，其實你直接可以在外層寫一個臨時變量來保存這個數(shù)據(jù)，這樣getSelfData 只會被調(diào)用一次！

11.在修改代碼邏輯的時候需要加入新的邏輯變量，一定要注意在這個函數(shù)當(dāng)中是否已經(jīng)有了這個變量名稱，否則會帶來不可預(yù)料的后果。

12.寫邏輯之前一定要先理清楚，在開始寫代碼，最好先畫一個流程圖來整理自己的思路！添加新的邏輯一定不要動原來的代碼，如果你動了一個函數(shù)，那么已經(jīng)定要檢查是否多個邏輯都在調(diào)用這個函數(shù)，所謂接口的復(fù)用性還是有一定的弊端的，改了這個函數(shù)的邏輯，那么所有調(diào)用函數(shù)的功能邏輯都會發(fā)生改變。

13.服務(wù)器發(fā)送過來的消息邏輯一定要記錄下來，游戲邏輯復(fù)雜必須要經(jīng)過多次梳理！】

14 計算機運行的邏輯永遠是正確的（雖然也有意外，）調(diào)bug的時候一定要多懷疑，不要排查每個函數(shù)點到為止，偶現(xiàn)bug 沒有運行你預(yù)期的動作絕對就是有問題！鎖定一個區(qū)域一定要仔細往下查??！

15 經(jīng)常偶現(xiàn)bug在第一次的時候無法查出其中的原因，而我們應(yīng)該做的事情是在懷疑的地方加上日志，這樣在下次出現(xiàn)的時候就可以方便解決，當(dāng)然，最簡單的辦法就是寫代碼的時候一定要考慮需要加入日志的地方，這很重要！