專(zhuān)業(yè)程序員的7個(gè)素質(zhì): 承擔(dān)責(zé)任,高質(zhì)量代碼,代碼上的時(shí)間,對(duì)自己領(lǐng)域的精通,思維模式,溝通,合作。
1 。 寫(xiě)邏輯代碼寫(xiě)完后一定要對(duì)著自己的邏輯全部走通一遍。不要寫(xiě)完立即開(kāi)始運(yùn)行調(diào)試。這樣的調(diào)試會(huì)浪費(fèi)大量的時(shí)間。因?yàn)橛行╁e(cuò)誤僅僅是因?yàn)槟愦a寫(xiě)錯(cuò),筆誤,或者邏輯的一個(gè)漏洞而導(dǎo)致。而這些問(wèn)題都是非常簡(jiǎn)單的。所以我們?cè)趯?xiě)完邏輯的時(shí)候一定要對(duì)著代碼理一遍思路,看看有沒(méi)有一些弱智錯(cuò)誤,再三確認(rèn)無(wú)誤再去運(yùn)行調(diào)試。
2 更改代碼邏輯的時(shí)候,記住一定要去增加代碼,而不要去刪除或者更改代碼。增加代碼是最好的方式。
3 在更改一些代碼的情況,比如修改了一個(gè)變量的名字或者邏輯。一定要多思考這個(gè)地方更改的這個(gè)變量有沒(méi)有在其他的地方使用到過(guò)。邏輯的修改會(huì)不會(huì)影響其他代碼的調(diào)用!!! 有的時(shí)候不小心改了一個(gè)地方,但是沒(méi)有去思考,其他原本正確的邏輯也錯(cuò)了,會(huì)給自己帶來(lái)相當(dāng)大的困擾!! 也需要不斷的打印日志去查找。 其實(shí)就是一個(gè)非常弱智的錯(cuò)誤?。?!
4.在調(diào)用別人的接口獲取數(shù)據(jù)的時(shí)候一定要給自己留一手!特別是在自己寫(xiě)一個(gè)獨(dú)立的功能需要用到一些其他模塊的數(shù)據(jù)! 取到數(shù)據(jù)一定要判斷一下有沒(méi)有! 最好直接斷言。 防止你自己模塊出問(wèn)題其實(shí)是別人那的數(shù)據(jù)問(wèn)題?。?/p>
5 自己的接口函數(shù)盡量要想辦法不去依賴(lài)全局變量或者其他獲取數(shù)據(jù)的接口! 要什么數(shù)據(jù)全部以參數(shù)的方式傳進(jìn)來(lái)??! 參數(shù)的方式傳進(jìn)來(lái)。 自己傳參數(shù)可以保證數(shù)據(jù)是正確的。另一種情況,這個(gè)接口要移植就會(huì)非常的方便,只需要自己用不同的方式創(chuàng)建參數(shù)數(shù)據(jù)。
6 在一些問(wèn)題使用當(dāng)前的方法無(wú)法解決的時(shí)候,一定有新的方法可以驗(yàn)證你的錯(cuò)與對(duì)。你可以輸出幾種情況進(jìn)行比較。
做項(xiàng)目一定要抽時(shí)間看看別人的代碼,先從跟你有關(guān)聯(lián)的地方開(kāi)始看,再看跟你沒(méi)有關(guān)聯(lián)的地方。第一可以學(xué)習(xí)別人設(shè)計(jì)好的地方和良好的代碼。第二在添加功能和修改bug的時(shí)候可能需要跟他們的代碼進(jìn)行聯(lián)系,之前讀過(guò)他們的邏輯這樣就很方便。
8 再添加一個(gè)游戲功能的時(shí)候一定要多考慮一些東西,在一些特殊的情況一定要多考慮,比如游戲的斷線重連,考察需要還原的數(shù)據(jù)是否有你需要的。比如添加一個(gè)if條件, if myserver == 3. 你一定要去假象有沒(méi)有myserver不定于3卻又滿足你邏輯的情況! 一定要多思考,不然會(huì)給別人帶來(lái)很多的麻煩。
9.全局變量或者單利類(lèi) 真的是有利有弊,今天算是體會(huì)到了。 exp.一個(gè)全局分配事件管理器g_eventManager,自己在一個(gè)類(lèi)里面注冊(cè)了事件A,但是在釋放類(lèi)的時(shí)候忘記刪除了事件A,在下一個(gè)環(huán)境創(chuàng)建這個(gè)類(lèi)的時(shí)候有一次注冊(cè)了事件A! 所有在分配事件的時(shí)候你會(huì)發(fā)現(xiàn)A事件執(zhí)行了兩次??! 如此循環(huán),程序直接卡死。
10 盡量不要出現(xiàn)這樣的代碼:
for (i = 0 ;i《20;i )
{
if (a == getSelfData ())
}
關(guān)注這個(gè)getSelfData()函數(shù),被調(diào)用了20次,其實(shí)這個(gè)值是固定的,其實(shí)你直接可以在外層寫(xiě)一個(gè)臨時(shí)變量來(lái)保存這個(gè)數(shù)據(jù),這樣getSelfData 只會(huì)被調(diào)用一次!
11.在修改代碼邏輯的時(shí)候需要加入新的邏輯變量,一定要注意在這個(gè)函數(shù)當(dāng)中是否已經(jīng)有了這個(gè)變量名稱(chēng),否則會(huì)帶來(lái)不可預(yù)料的后果。
12.寫(xiě)邏輯之前一定要先理清楚,在開(kāi)始寫(xiě)代碼,最好先畫(huà)一個(gè)流程圖來(lái)整理自己的思路!添加新的邏輯一定不要?jiǎng)釉瓉?lái)的代碼,如果你動(dòng)了一個(gè)函數(shù),那么已經(jīng)定要檢查是否多個(gè)邏輯都在調(diào)用這個(gè)函數(shù),所謂接口的復(fù)用性還是有一定的弊端的,改了這個(gè)函數(shù)的邏輯,那么所有調(diào)用函數(shù)的功能邏輯都會(huì)發(fā)生改變。
13.服務(wù)器發(fā)送過(guò)來(lái)的消息邏輯一定要記錄下來(lái),游戲邏輯復(fù)雜必須要經(jīng)過(guò)多次梳理!】
14 計(jì)算機(jī)運(yùn)行的邏輯永遠(yuǎn)是正確的(雖然也有意外,)調(diào)bug的時(shí)候一定要多懷疑,不要排查每個(gè)函數(shù)點(diǎn)到為止,偶現(xiàn)bug 沒(méi)有運(yùn)行你預(yù)期的動(dòng)作絕對(duì)就是有問(wèn)題!鎖定一個(gè)區(qū)域一定要仔細(xì)往下查??!
15 經(jīng)常偶現(xiàn)bug在第一次的時(shí)候無(wú)法查出其中的原因,而我們應(yīng)該做的事情是在懷疑的地方加上日志,這樣在下次出現(xiàn)的時(shí)候就可以方便解決,當(dāng)然,最簡(jiǎn)單的辦法就是寫(xiě)代碼的時(shí)候一定要考慮需要加入日志的地方,這很重要!
-
程序員
+關(guān)注
關(guān)注
4文章
946瀏覽量
29732
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論