優(yōu)效學(xué)院，名師執(zhí)教，學(xué)習(xí)更優(yōu)效，IT在線教育領(lǐng)導(dǎo)者。三人行必有我?guī)煟松切枰粩鄬W(xué)習(xí)的，在這里我們相遇就是緣分，歡迎大家加群----四六零五七零八二四----讓我們共同進步！希望各位可以看完這篇文章，也歡迎大家在下面留言討論，天冷了，也動動手指轉(zhuǎn)發(fā)收藏一下，謝謝大家！
缺少必要的注釋
大段的if-else缺少注釋，讓維護者無法快速分辨分支邏輯。特定地方存在hack或復(fù)雜邏輯的代碼，缺少注釋會讓后來者不明所以。為了你好，也為了后來者好，請務(wù)必加上代碼。說不準(zhǔn)以后還是由你來維護這段代碼。
不變和變化的部分拆分
程序員中流傳著一句話，此處不要寫死，將來必改。有經(jīng)驗的程序員會將一些業(yè)務(wù)層的邏輯抽象出來，寫成配置文件，好處就是若后續(xù)需求有改變，只需改配置文件即可，肯定不會引入bug。
忽視測試部分
程序員中又流傳著一句話，沒有測試的代碼等于沒寫。雖不敢全部贊同，卻也有幾分道理。從測試用例驅(qū)動開發(fā)，持續(xù)集成，每次編譯自動跑測試用例，能夠保證系統(tǒng)的穩(wěn)定同時也減輕測試成本。自己改的的部分做好自測，理解需求，做一個有責(zé)任心的工程師。
直接操作數(shù)據(jù)
你應(yīng)該通過方法去操作數(shù)據(jù)，而不是直接操作數(shù)據(jù),這樣能夠保證你總能操作數(shù)據(jù)正確。例如一個類中定義的屬性發(fā)生變化了，代碼中所有涉及到直接操作該屬性的代碼都需要修改。如果通過方法操作該屬性，則僅需修改操作方法，對于外部調(diào)用者，類屬性變化被屏蔽了，遵循了解耦的原則，代碼穩(wěn)定性大大提高。
缺乏文檔或文檔質(zhì)量低下
前期文檔很重要，不論是框架的API使用手冊，還是需求或設(shè)計文檔，以及各種既定流程的規(guī)范，不同種類的模板及核對表，等等這些文檔，對于項目來說都是非常重要的資源。而往往有些項目，這類文檔就是交由非軟件行業(yè)的人員來編寫，或者前期根本不打算在文檔上浪費時間。
無盡的需求變更，永遠追不上的進度
這是最常見也是最可怕的，因為無論怎樣，我們都無法完成它。客戶可能認為改個程序，就像改個Excel一樣簡單省事，甚至?xí)褂每蓜佑玫囊磺袡?quán)利和資源來推行變更。好吧，我承認這樣的客戶我遇到過很多。當(dāng)我向客戶解釋過變更的代價并提供備選方案后，也就只能等待客戶的選擇了，這多少有些運數(shù)的成分，但也是無奈之舉。
僅僅靠加班應(yīng)對進度落后
進度落后并不可怕，可怕的是僅靠加班來追趕進度。這是問題的關(guān)鍵，長時間的趕工仍然無法趕上進度，這只意味著項目有某種更深層次的問題，已經(jīng)不是單開趕工可以解決的了。留意那些長時間加班的項目，他們往往在管理上存在很大問題，發(fā)現(xiàn)這些問題，在你成為PM時，不要犯類似錯誤。
最后，如果想有一群“臭味相投”的朋友來一起交流學(xué)習(xí)的話，歡迎大家搜索群460570824，讓我們共同進步！
