建站
咨詢
售后
建站咨詢
新聞中心
1：寫不易出錯(cuò)的代碼
岳麓ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！
第一次聽說“寫明顯沒有什么錯(cuò)誤的代碼”時(shí)，我覺得這個(gè)說法很新鮮，讓我記憶深刻。其他的很多觀點(diǎn)聽得我耳朵生繭，基本都是左耳進(jìn)右耳出。明顯沒有什么錯(cuò)了的代碼肯定是思路清晰、很容易理解的。而要做到這點(diǎn)很難，牛人才能寫出牛叉的代碼，要做到這一點(diǎn)要有足夠的閱歷和實(shí)戰(zhàn)，只能當(dāng)做目標(biāo)啦，哪天也和云風(fēng)一樣：今天完成了XX功能，代碼明顯沒有什么錯(cuò)誤?，F(xiàn)在還不知道明顯沒有什么錯(cuò)誤的代碼是怎么樣的，但我知道很多代碼讓我半天不知所云。如從類名和方法名看不出其職能；變量命名讓人蛋疼；不對參數(shù)做任何驗(yàn)證；參數(shù)到處都是都是基本類型；方法參數(shù)十幾個(gè)；一個(gè)方法幾屏；不能適應(yīng)半點(diǎn)變化的方法；要么沒有注釋，要么一堆廢話；排版稀爛。這些都是不好理解，半天找不到問題的代碼，也是容易出錯(cuò)的代碼。
2：寫容易查錯(cuò)的代碼
一直想寫很干凈的代碼，代碼除了功能沒有多余的代碼，但是代碼必須有日志，如果代碼沒有日志，要是出錯(cuò)了，查錯(cuò)肯定很麻煩，有時(shí)候真的是無從下手，一個(gè)功能涉及到一堆的模塊，要想很快的定位錯(cuò)誤，就必須記好日志。越清楚越好，程序執(zhí)行到哪一步，當(dāng)前的狀態(tài)最好都要記下來，日志不在多，清楚記錄有效的日志非常重要，過多無效的日志不方便查看，而且對于快速定位錯(cuò)誤的位置沒有任何幫助。如果日志都記錄在文本文件中，最好能寫一個(gè)分析日志的工具?？赡苁俏覍懙暮途S護(hù)的代碼太容易出錯(cuò)了，個(gè)人覺得記好日志真他媽重要。一看到日志就能知道出了什么問題那不是一般的爽，當(dāng)然聽說又出問題了讓人郁悶。我以前所在的一家公司記錄日志的方式是在很多類中都定義一個(gè)int類型的成員變量，每隔幾行讓它自增1，將這個(gè)值記錄起來，當(dāng)出錯(cuò)了就能大致估計(jì)是哪幾行出錯(cuò)了。這種方法雖然有點(diǎn)蹩腳，代碼中到處是這個(gè)變量，但的確能幫助我們快速定位錯(cuò)誤的位置，日志的作用就是保存案發(fā)現(xiàn)場，只有記錄犯罪分子作案的過程才能更好的抓住它。
3：寫擴(kuò)展性好的代碼
“今天說要這樣，明天說要那樣，在上線的前一天說：還是覺得開始的做法是最好的”。而我們程序員總是為這種人2B的想法買單。寫擴(kuò)展性好的代碼真的就是不僅要滿足需求還要超越需求。我們到處可以聽到這樣的口號，當(dāng)然很多情況下是這樣的人自己都不知道需求是什么。最讓人無語的是菜鳥提需求，我來實(shí)現(xiàn)。殺了我吧。但現(xiàn)實(shí)是殺了我之前我先要滿足他的需求。當(dāng)這種需求像滔滔江水綿延不絕的襲來時(shí)，我想到了四個(gè)字：生不如死。既然死不了，生活還得繼續(xù)。代碼還是要做到超越需求（你說這世界對程序員要求怎么就這么高呢），要做到這點(diǎn)難啊，我們是幫別人實(shí)現(xiàn)夢想的開拓者。前途是光明的，道路是坎坷的，現(xiàn)實(shí)是殘酷的，代碼必須是擴(kuò)展性好的。當(dāng)然這里所說都是人為因素。
還有就是項(xiàng)目的需求本來就是變化的，或者說你現(xiàn)在完成的是一期，還有二期，三期......，你在做的時(shí)候就必須考慮這些情況，不要把代碼寫死。我以前總是想：這個(gè)可能以后不會(huì)變化，可以寫死，少一個(gè)參數(shù)，少一個(gè)變量性能會(huì)更好寫。其實(shí)性能的提升相當(dāng)于一個(gè)千萬富翁突然多了幾毛錢。但是要是以后需求變了，你就得改寫代碼，還得擔(dān)心是否會(huì)出問題。有時(shí)候我就有點(diǎn)怕重構(gòu)，就怕一個(gè)好的功能，被重構(gòu)壞了，當(dāng)然也和時(shí)間緊，測試不專業(yè)有關(guān)。寫擴(kuò)展性好的代碼別在乎所謂的那點(diǎn)性能，那真的就是九牛一毛不值一提。一個(gè)項(xiàng)目維護(hù)時(shí)間久了，發(fā)現(xiàn)那些本來看是不變的很多都變了，而代碼也被改了很多次，每一次修改就要做一堆本來沒有必要的事情（修改代碼，寫測試說明，送測，協(xié)調(diào)上線，而這些溝通時(shí)間也不少，真叫一個(gè)低效浪費(fèi)時(shí)間），如果能考慮到可能發(fā)生的變化，寫好代碼，效率會(huì)高很多，這一點(diǎn)就能體現(xiàn)高手和菜鳥的區(qū)別。
4：寫高性能的代碼
這是我一直渴望的（我當(dāng)然也會(huì)說是我還沒有做到的）。我覺得要寫出高效的代碼首先要非常明白你要實(shí)現(xiàn)的功能，將功能分析得很透徹，你找到了解決方案，回想你的實(shí)現(xiàn)，如果你的思路非常清晰，你就大致知道每一步是否夠好，大致知道你的代碼是否高效，或者更進(jìn)一步說，你確定這就是最優(yōu)解；如果功能實(shí)現(xiàn)了，但是你對自己實(shí)現(xiàn)的功能不是很了解，記憶模糊，那肯定不是最優(yōu)解，你肯定會(huì)對自己不是很清楚的代碼不放心（我經(jīng)常是這樣），就別談性能，是否正確都待定。很多高效的代碼都很簡潔，容易理解，而有些代碼總讓人看起來很郁悶，如一堆看起來類似的代碼實(shí)現(xiàn)一個(gè)很簡單的功能。用數(shù)組和一個(gè)循環(huán)經(jīng)常能將這樣的代碼簡化，讓你輕松實(shí)現(xiàn)簡潔容易理解的代碼，或許它不是最高效的。82法則告訴我們，我們應(yīng)該對影響系統(tǒng)性能的20%的代碼進(jìn)行優(yōu)化，而不應(yīng)對其他的80%的代碼耿耿于懷。20%影響性能的代碼應(yīng)注重性能進(jìn)行優(yōu)化，而其他80%則更多應(yīng)該考慮理解性，擴(kuò)展性等。
文章名稱：陳太漢：軟件隨想之編寫出色的代碼
文章地址：http://www.5511xx.com/article/dpihpec.html
