新聞中心
1. 技術(shù)只是解決問(wèn)題的選擇,而不是解決問(wèn)題的根本

我們可以因?yàn)檎莆樟?**的 JavaScript 框架 ahem、Angular 的 IoC 容器技術(shù)或者某些編程語(yǔ)言甚至操作系統(tǒng)而歡欣雀躍,但是這些東西并不是作為程序員的我們用來(lái)解決問(wèn)題的根本——它們只是用于幫助我們解決問(wèn)題的簡(jiǎn)單工具。
我們必須非常謹(jǐn)慎,不要對(duì)某項(xiàng)正好喜歡或者正好很火的特定技術(shù)走火入魔。否則,我們將進(jìn)入這樣的思維怪圈:把掌握的那項(xiàng)技術(shù)比做是錘子,在思考問(wèn)題時(shí),會(huì)自然的把所有的問(wèn)題都想象成是錘子可以解決的釘子。
2. 聰明是代碼清晰的敵人
當(dāng)編寫代碼時(shí),我們應(yīng)當(dāng)努力做到代碼清晰易理解。
雖然這句話并不總是正確的,但在一般情況下,聰明確實(shí)是代碼清晰的敵人。
事實(shí)證明,當(dāng)我們寫一段自認(rèn)為非常了不起的代碼的時(shí)候,這些代碼在別人眼里可能會(huì)是一頭霧水。
所以當(dāng)你在編寫某段聰明高效的代碼的時(shí)候牢牢記住這個(gè)原則是很有必要的。
如果你對(duì)如何編寫整潔清晰的代碼很感興趣的話,我強(qiáng)烈推薦你看羅伯特·C·馬丁的書《The Clean Coder: A Code of Conduct for Professional Programmers》。
3. 寫盡可能少的代碼
這句話看起來(lái)有一些矛盾。程序員的工作不就是編寫代碼么?
嗯,是的但也不是。
我們的工作需要我們編寫代碼,但是我們?cè)趪L試解決問(wèn)題的時(shí)候應(yīng)當(dāng)做到盡量編寫更少的代碼。
這并不意味著我們需要盡量把代碼寫得更緊湊或者把所有的變量都使用單個(gè)字母。它的意思是我們應(yīng)當(dāng)嘗試用更精簡(jiǎn)的算法來(lái)實(shí)現(xiàn)所需要實(shí)現(xiàn)的功能。
通常情況下,我們?cè)诖a中所添加的各種很酷的特性是非常誘人的,這還能讓我們的代碼看起來(lái)更“健壯”和“靈活”,能夠處理各種不同類型的情況。但是,在更多的時(shí)候,我們嘗試更多可能有用的特性或者預(yù)防可能在未來(lái)存在的問(wèn)題的做法是錯(cuò)誤的。這些額外的代碼可能不具備任何的價(jià)值,但是卻可能造成更多的傷害。因?yàn)榇a越多,出現(xiàn)未知錯(cuò)誤的機(jī)會(huì)就越多,代碼的維護(hù)也更加的麻煩。
優(yōu)秀的軟件工程師寫盡可能少的代碼。
偉大的軟件工程師刪除盡可能多的代碼。
4. 注釋是代碼表述的***選擇
鮑勃·馬丁曾經(jīng)說(shuō)過(guò):“當(dāng)你在為一段代碼寫注釋的時(shí)候,你應(yīng)當(dāng)對(duì)自己糟糕的表達(dá)能力而反思?!?/p>
這并不意味著我們以后就不要寫注釋了。但在大多數(shù)情況下這種情況是可以避免的,你可以選擇用更好的命名方式來(lái)取代它。
只有在使用命名都無(wú)法表述清楚某個(gè)方法或者變量的目的時(shí),注釋才是***的選擇。事實(shí)上,表達(dá)無(wú)法輕易在代碼表達(dá)的東西才是注釋的真正作用。
舉個(gè)例子,注釋可以告訴你在代碼中的那些奇怪的操作命令并不是一個(gè)錯(cuò)誤,而是故意的,那是因?yàn)樵诘讓硬僮飨到y(tǒng)存在著某個(gè) bug。
雖然在一般情況下,許多注釋還是非常有用的,但是卻存在著誤導(dǎo)的風(fēng)險(xiǎn)。
在其它代碼更新后,與某些更新前代碼相關(guān)的注釋常常會(huì)得不到同樣的更新,這就導(dǎo)致了某些注釋會(huì)變得非常的危險(xiǎn),它們很可能會(huì)把你引導(dǎo)到一個(gè)錯(cuò)誤的方向。
你檢查過(guò)與代碼密切相關(guān)的每一段注釋么?是否確保代碼都是在按照注釋所說(shuō)的那樣做?如果你都照著這樣做了,那么注釋的意義又何在呢?如果你沒(méi)有這樣做,你又怎么知道注釋說(shuō)的都是真的?
所以,注釋的作用并不象所宣揚(yáng)的那么好,這種東西切勿濫用。
5. 在編寫代碼之前你應(yīng)當(dāng)清楚你的代碼要做什么
這看起來(lái)是理所當(dāng)然的,但實(shí)際情況卻不是。
現(xiàn)實(shí)工作中你有多少次是在沒(méi)有經(jīng)過(guò)充分了解到你的代碼要干些什么就開(kāi)始著手編程的?反正對(duì)于我來(lái)說(shuō),是不計(jì)其數(shù)了,所以我把這條記錄下來(lái)用來(lái)隨時(shí)提醒我。
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)(TDD)的實(shí)踐在這里可以幫助你,因?yàn)槟阈枰诰帉懘a之前了解這些代碼將要用于什么地方,雖然這仍然不能阻止你創(chuàng)建錯(cuò)誤的東西,但是它仍然非常重要。所以當(dāng)你完完全全了解需要構(gòu)建的需求和功能時(shí),再動(dòng)手編程。
#p#
6. 提交完成代碼之前先自行測(cè)試
不要在完成編程工作后,就把代碼扔給 QA,然后就坐等消息了。這樣會(huì)浪費(fèi)每一個(gè)參加處理不必要 Bug 和問(wèn)題的人的時(shí)間。你應(yīng)當(dāng)在報(bào)告編程工作完成之前,花費(fèi)幾分鐘時(shí)間運(yùn)行測(cè)試場(chǎng)景進(jìn)行自我檢測(cè)。當(dāng)然,在你把代碼提交給 QA 之前不一定會(huì)發(fā)現(xiàn)每一個(gè) Bug,但至少你可以杜絕一些我們每個(gè)人都可能犯下的愚蠢低級(jí)錯(cuò)誤。
很多的軟件開(kāi)發(fā)人員認(rèn)為測(cè)試代碼只是 QA 人員的工作。這是不對(duì)的。保持質(zhì)量是我們每個(gè)人的責(zé)任。
7. 每天都要學(xué)一些新東西
有句名言“刀不磨要生銹,人不學(xué)要落后?!边@句話是很有道理的,因?yàn)闊o(wú)論是否獲取到新的知識(shí),你每天都會(huì)遺忘掉一些以前的東西。
每天學(xué)些一些新東西并不會(huì)花費(fèi)掉你很多的時(shí)間。試著每天用 15 分鐘時(shí)間去讀書,然后你就會(huì)發(fā)現(xiàn)每天你都會(huì)有一點(diǎn)點(diǎn)的進(jìn)步,在未來(lái)的某個(gè)時(shí)候,你會(huì)發(fā)現(xiàn)這種進(jìn)步是巨大的。因此,為了在今后獲得豐厚回報(bào)你必須從現(xiàn)在開(kāi)始就進(jìn)行投資。另外,今天的技術(shù)發(fā)展日新月異,如果你不改善自己的技巧,學(xué)習(xí)新的東西,你很快就會(huì)被甩開(kāi)。
8. 寫代碼應(yīng)該成為一種樂(lè)趣
這是非常正確的?;蛟S,你進(jìn)入這個(gè)行業(yè)僅僅是因?yàn)樗男剿捎^。選擇一份報(bào)酬豐厚的工作這并沒(méi)有錯(cuò),但是還有更好的選擇,比如醫(yī)生或者律師。事實(shí)上很多人選擇做軟件開(kāi)發(fā)還有一個(gè)原因,那就是他們喜歡寫代碼。在你被工作壓力所累的時(shí)候,不要忘了你選擇這份職業(yè)的初衷。
編寫代碼可以帶來(lái)很大的樂(lè)趣。多年的時(shí)間里,很多人可能都已經(jīng)遺忘了這一點(diǎn),那么從現(xiàn)在起,重新喚回以前的那份熱情吧,從身邊的項(xiàng)目開(kāi)始,把你的觀念和意識(shí)轉(zhuǎn)換到以前你開(kāi)始學(xué)習(xí)編程的那個(gè)時(shí)刻。
9. 你不需要無(wú)所不知
在你學(xué)到了很多知識(shí)的時(shí)候,你仍然有很多東西不知道。
意識(shí)到這點(diǎn)很重要,因?yàn)樗梢则?qū)使你去了解更多更多的東西。
不知道問(wèn)題的所有答案沒(méi)有關(guān)系,不了解某個(gè)東西說(shuō)出來(lái)并尋求幫助也無(wú)關(guān)緊要。在很多情況下,你可以選擇現(xiàn)學(xué)現(xiàn)用——相信我,我就是這么走過(guò)來(lái)的。
我的觀點(diǎn)是,不要企圖去學(xué)習(xí)所有的知識(shí),因?yàn)檫@是一個(gè)不可能完成的任務(wù)。你需要關(guān)注和掌握的是能夠幫助你快速學(xué)習(xí)的技巧。
10. ***的實(shí)踐視環(huán)境而定
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)***的方法是先編寫測(cè)試代碼?
我們應(yīng)該保持結(jié)對(duì)編程的習(xí)慣?
如果不使用 IoC 容器是否會(huì)低人一等?
所有這些問(wèn)題的答案是“看情況?!边@取決于所處的實(shí)際環(huán)境。
人們?cè)噲D把***的實(shí)踐通過(guò)喉嚨等方式傳輸給你,他們會(huì)告訴你,他們平時(shí)都是這樣應(yīng)用的。所以,你也應(yīng)該這樣做——這其實(shí)并不正確。
在寫代碼的時(shí)候,我也借鑒過(guò)不少別人的成功經(jīng)驗(yàn)。但是,這些借鑒都是有條件的。
知識(shí)是死的,人是活的。***的實(shí)踐需要視環(huán)境而定。
11. 努力做到化繁為簡(jiǎn)
所有的的問(wèn)題都可以進(jìn)行分解。而***雅的解決方案通常都非常簡(jiǎn)單。但是,要變得簡(jiǎn)單并不容易,這需要許多的工作。
比如,這篇文章的目的是從復(fù)雜的軟件開(kāi)發(fā)工作和日常生活中提取經(jīng)驗(yàn),通過(guò)歸納,以較簡(jiǎn)潔的方式呈現(xiàn)給大家,而這并不是一件容易的事情。
在解決問(wèn)題時(shí),可以先找到一個(gè)較為復(fù)雜的笨方法。在此基礎(chǔ)上進(jìn)行努力改進(jìn)和提煉,使它在正確的基礎(chǔ)上變得簡(jiǎn)單。這需要花費(fèi)很多時(shí)間和努力,而人類不正是因?yàn)檫@個(gè)過(guò)程才慢慢變得聰明么?
網(wǎng)站名稱:優(yōu)秀的程序員都應(yīng)當(dāng)知道的11個(gè)警句
URL標(biāo)題:http://www.dlmjj.cn/article/djsicos.html


咨詢
建站咨詢
