5.編寫單元測試

可測試的代碼通常意味著在組織結(jié)構(gòu)上具有更合理、更簡潔的代碼質(zhì)量。因?yàn)樗鼤?huì)驅(qū)使您去事先管理好各個(gè)類之間的關(guān)系、各種方法的訪問級(jí)別、以及其他方面。我甚至發(fā)現(xiàn)：即使是小的單元測試也能夠促進(jìn)更快、更便捷的開發(fā)進(jìn)程，進(jìn)而能夠讓自己寫出更加短、平、快的Java代碼。

當(dāng)然在現(xiàn)實(shí)開發(fā)工作中，您總會(huì)聽到一些諸如“我根本沒有時(shí)間來編寫單元測試”或“項(xiàng)目時(shí)間節(jié)點(diǎn)將至，不要浪費(fèi)時(shí)間些單元測試了”之類的反對(duì)意見。這些聽起來貌似很合理，但是根據(jù)我的經(jīng)驗(yàn)，在多數(shù)情況下，事實(shí)并非如此。

如果您沒有時(shí)間去編寫單元測試，那您是否有更多的時(shí)間，去修復(fù)代碼中那些可見、或不可見的bug呢?如果跳過了單元測試，那些倉促完成的代碼將無法保證穩(wěn)定性。特別對(duì)于一些新的代碼變更而言，您完全無法通過及時(shí)的反饋途徑，知曉那些新產(chǎn)生的代碼是否存在著錯(cuò)誤隱患，是否會(huì)在將來運(yùn)行的某個(gè)特定場景中產(chǎn)生不可預(yù)知的異常問題。

一般而言，Junit和TestNG是兩款非常的Java應(yīng)用、及單元測試框架。而我個(gè)人則更喜歡使用TestNG。

6.重構(gòu)：常見，但也很慢

簡潔干練的Java程序代碼從來不是一蹴而就的，它往往需要您進(jìn)行反復(fù)地琢磨與改進(jìn)。通過逐行進(jìn)行代碼重構(gòu)、和運(yùn)行各種測試用例，您可以確保自己的更改不會(huì)破壞既有代碼的正確功能。同樣，IDEA極大地提供了對(duì)于代碼重構(gòu)的支持，其中包括提取方法(extract method，將某個(gè)大的函數(shù)拆分為多個(gè)小函數(shù))、重命名、內(nèi)聯(lián)(inline)等功能。

當(dāng)然，如果您對(duì)代碼重構(gòu)是什么，以及它的作用不太了解的話，Martin Fowler的經(jīng)典著作《重構(gòu)：改善既有代碼的設(shè)計(jì)(第2版)，Refactoring: Improving the Design of Existing Code (2nd Edition)》(請?jiān)斠?/span>)是一本您必備的參考書。

7.定期聯(lián)絡(luò)客戶，以獲取他們的反饋

后一點(diǎn)，可能也是重要的：客戶花錢讓您通過編寫代碼，來解決他們的問題、滿足他們的需求、并解決他們的痛點(diǎn)。然而，您可能在不知不覺中花費(fèi)了太多的時(shí)間，去實(shí)現(xiàn)自以為重要、卻對(duì)客戶無關(guān)緊要的特殊功能，進(jìn)而忽略了代碼整體的健壯性和可維護(hù)性。那么，我們怎么才能夠盡早地發(fā)現(xiàn)該問題呢?請保持與客戶經(jīng)常聯(lián)系，以盡早地獲取他們的反饋。

話說回來，知易行難，即使是富有經(jīng)驗(yàn)的產(chǎn)品經(jīng)理也不一定能在較短的時(shí)間內(nèi)領(lǐng)悟需求的真諦，何況是那些滿腦子只注重功能實(shí)現(xiàn)的“碼農(nóng)”們呢?

因此，一個(gè)實(shí)用的建議是：如果您不能直接聯(lián)絡(luò)到終用戶的話，請盡量與該系統(tǒng)的產(chǎn)品經(jīng)理、或運(yùn)維人員進(jìn)行禮貌、且頻繁的溝通。磨刀不誤砍柴工，這些時(shí)間的投入對(duì)于后期時(shí)間的節(jié)省是值得的。

總結(jié)

在過去的多年編程實(shí)踐和項(xiàng)目應(yīng)用中，我一直受益于上述七點(diǎn)心得。在此，我希望它們也同樣能給您的代碼工作帶來幫助。祝您編程愉快!