專業(yè)程序員的素質(zhì)有哪些

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

1 。 寫邏輯代碼寫完后一定要對(duì)著自己的邏輯全部走通一遍。不要寫完立即開始運(yùn)行調(diào)試。這樣的調(diào)試會(huì)浪費(fèi)大量的時(shí)間。因?yàn)橛行╁e(cuò)誤僅僅是因?yàn)槟愦a寫錯(cuò)，筆誤，或者邏輯的一個(gè)漏洞而導(dǎo)致。而這些問題都是非常簡(jiǎn)單的。所以我們?cè)趯懲赀壿嫷臅r(shí)候一定要對(duì)著代碼理一遍思路，看看有沒有一些弱智錯(cuò)誤，再三確認(rèn)無誤再去運(yùn)行調(diào)試。

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

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

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

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

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

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

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

9.全局變量或者單利類 真的是有利有弊，今天算是體會(huì)到了。 exp.一個(gè)全局分配事件管理器g_eventManager，自己在一個(gè)類里面注冊(cè)了事件A，但是在釋放類的時(shí)候忘記刪除了事件A，在下一個(gè)環(huán)境創(chuàng)建這個(gè)類的時(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í)你直接可以在外層寫一個(gè)臨時(shí)變量來保存這個(gè)數(shù)據(jù)，這樣getSelfData 只會(huì)被調(diào)用一次！

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

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

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

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

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