閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?bitorge2020-11-04 00:33:34

一個json十幾二十層,還帶邏輯,要先解析某個值,才知道下一步怎麼解析

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?java架構設計2020-10-31 12:24:11

一個service類兩萬行程式碼、一個方法六七百行、if else巢狀如十八層地獄般深厚、方法傳參全是JSON,返回都HashMap,單是依賴注入的其他服務類程式碼就達400行,小200個注入!

接下來讓我們一起來體驗這個神奇的“垃圾原始碼”!

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

返回引數是HashMap,傳引數是JSON,然後反序列化為HashMap物件:

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

這就是牛逼的“面向過程程式設計”,你說你維護的時候,你怎麼知道他傳的啥?根據各種引數條件然後再返回啥?

硬著頭皮看程式碼吧,這時候你發現這個方法3341-2657=684行程式碼,再來看看他的if else巢狀:

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

按照sonarLint的方法複雜度計算,這段程式碼的複雜度是116,這還只是這個方法中的“一小段”程式碼。要知道sonarLint預設規則是隻要這個方法的複雜度超過15就提示需要優化了!

看這個類的Annotate,竟然前前後後有幾十人維護過,恨不得一個類搞定所有業務,idea提示器從頭到尾都是黃色警告,更不用說整合阿里規約掃描外掛甚至solarLint外掛來掃描程式碼了。。。

崩潰麼?程式設計師的崩潰就在這一瞬間~

你說這樣的程式碼讓你來維護是怎樣的一種體驗?

有時候不得不感慨,一個產品的成功與否,與程式碼質量無關~

寫好漂亮可維護的程式碼真就這麼難?

那麼問題來了,程式設計師寫出一手漂亮可維護的程式碼真的就這麼難?

我覺得寫程式碼本身不難,大多數都是在寫業務程式碼,難得是自己心中沒有好程式碼的標準,有的程式設計師知道自己寫的程式碼不好,但是不知道怎麼寫出好的程式碼,這是問題存在的本因,你同意嗎?

這裡我給出我個人覺得寫出可維護程式碼的一些方法論:

1、

不要用設計模式去實現業務程式碼

,越複雜越不可維護;

2、

多看書,讀書破萬卷,下筆如有神

。比如Java的可以看《阿里巴巴Java開發手冊》、《重構-改善既有程式碼的設計》等;

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

3、去sonarqube官網學習一下sonarqube,他的程式碼檢查rule等;

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

4、從今天起,在你的idea上裝上阿里巴巴Java規約掃描外掛,讓你寫的每一個Java類沒有一個警告(還有更嚴格的sonarLint外掛哦~);

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

短期依賴工具迅速提高自己的程式碼質量,長期持續學習閱讀相關技術書籍!

長此以往,你的程式碼一定是可閱讀和可維護的,還有一個更大的好處就是:“

你的程式碼寫完了,基本上可以一次性自測透過!

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?小殭屍Rua2020-11-03 12:04:32

有時候程式設計師也很無奈,比如剛新開發上線的功能可能過兩天後就要改版,然後發現要動很多地方,時間也很緊迫,需求就三個字:“明天要”,這種情況下你還考慮什麼整潔度、設計模式、程式碼抽離之類的,能在有限的時間內把業務程式碼堆完就不錯了,這種情況很無奈。等你回頭想最佳化程式碼時,發現根本沒時間而且程式碼越滾越大,已經無力修改了。

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?xrex2020-11-02 16:50:58

就發兩行讓大家開開眼吧

boolean flag=!(!(list==null) &&!(list。size()==0 ))

if(!flag){

}

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?瀟灑的尿2020-10-31 23:38:03

入職一家公司,剛接觸專案程式碼時候給我人都看傻了。一個activity 6000多行,各種邏輯都放在裡面處理,if else 嵌套了1500行,新加個欄位能折騰半天。後來一問是外包寫的。

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?老孫正經胡說2021-03-26 20:46:30

閱讀優秀的程式碼就像欣賞一件珍貴的藝術品一樣,閱讀垃圾程式碼恨不得掐死之前開發的那個人。雖然中國的程式設計師數量每年都在遞增,但是好的程式設計師仍然是稀有群體。雖然有很多的開發規範、程式碼Review來糾正錯誤,但是解決根本問題的還是要提高國內開發人員對開發這件事情本身的思維意識。

之前在外企和美國同事合作的時候,他們對於程式碼要求非常嚴格,對於大部分程式設計師來說,所謂的“程式碼完成”就是指功能實現和程式碼提交。從更嚴格的角度來定義:

程式碼完成 = 程式碼提交 + 單元測試 + 文件

但是很遺憾的一點,能夠有這樣的意識的程式設計師和這樣要求的研發團隊並不多,往往為了追求快不得不做出犧牲,這也造成了我們看到很多網際網路公司不停的推翻以前的架構,重複製造輪子。

所以我覺得作為從業者,應該從根上意識到這樣的問題,從自我做起,這樣無論你在任何團隊你留下的永遠是精品,而不是被人罵孃的垃圾程式碼!

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?Soler索萊爾HO2017-12-30 13:35:41

原始碼垃圾的時候,你肯定會想這個專案怎麼變成這樣子了!

當你去讀的時候,你肯定會有一萬個草泥馬從頭上飄過!有的時候會直接讀得你懷疑人生!

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?突突殺2020-11-05 16:01:02

第一,這跟大多數公司要求相關,公司沒有這些規定時,每個程式設計師都有每個人的寫作風格,所以你也不必喯。

第二,由於公司專案催得緊,在短時間內能夠實現功能都不錯了,你讓程式設計師怎麼給你規範寫程式碼呢?現在大多數公司最求的是短期利潤,所以很難有非常優質的程式碼的!

第三,這與個人習慣有很大關係,大多數程式設計師都是自以為自己寫的程式碼是很好閱讀的,但是對於別人來說閱讀起來並不友好!

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?在彩虹上2020-11-06 10:10:24

接手一個應用程式,是管理研發課題的。一個課題下面可以有若干項任務,每個任務有一個狀態status,狀態可以是待批,批准,進行中,完成,驗收合格等等。一個數據庫儲存過程非常慢,經常10分鐘以上才能得到結果,還經常半道死了。你結果對也行,還經常返回一些任務狀態不一致的課題,有bug。裡面用了十幾個query,沒有註釋,讀了兩小時愣是沒看懂它要幹什麼。結果課題經理說,如果一個課題下的所有任務的狀態相同,比如都是完成,那麼該課題就應該被返回,就是找出所有其全部任務都處於相同狀態的課題。我靠,這麼簡單的事?給他全改了,一個query,group by課題編號,having max(status) = min (status),執行速度快得飛起,就沒有超過一秒鐘的時候。老闆嘴都笑歪了。我心想,你僱的都是什麼程式設計師吶,這程式碼寫的,好比解皮帶,蹲坑,起來,再把皮帶繫上,如此反覆多次,最後沒拉便便,放了一個pi,還是蔫兒臭的那種,沒法看。糟心大了。

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?遊走在程式碼裡的魚2020-11-17 09:17:47

經常遇到過!

1,資料呼叫,只看有資料,從不核對資料!

2,圖示統計,資料寫死,沒有動態呼叫!

3,sql語句已經有現成的預編譯框架,安全有效,卻硬生生的把預編譯整成原生的

4,資料庫表呼叫錯誤!

5,安全過濾直接跳過,用原生獲取!

……

相對於垃圾程式碼,以上情況,又會是什麼體驗呢?“欲罷不能”,想瘋的心都有的

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?程式設計師光光2020-11-20 06:37:21

接手別人的辣雞程式碼工作很難避免,作為一個奮鬥一線的程式設計師說說感受吧。

剛開始接觸程式碼,先是緊張,萬一翻車了咋整?

面對一坨坨辣雞程式碼,心裡壓力肯定不小。

心裡默問,這哥們留的有沒有坑呢?如果上線出了bug我該如何處理呢?…,所有的一切都是未知,所以會緊張,萬一出了問題,一時半會搞不定多沒面子。會不會暴露自己水平很菜?

畢竟之前很長時間內做的都是自己熟悉的東西,萬一這個玩不轉,領導、同事怎麼看我?崇拜我技術牛逼的測試妹子又會怎麼想?

所以,問題會有很多。不過不管怎樣都得硬著頭皮去一塊一塊的去啃。

後來深入了,學習了,理解了

然後開始罵開,

這寫的什麼玩意程式碼?

這個實現方式這麼low?這哥們啥技術呀,會不會寫程式碼?

哎,真是一堆辣雞程式碼!還好遇到了我,有起死回生的技術,有時間給他重構吧!

嗯,也多虧是我接手這辣雞程式碼,換了其他人肯定得好幾個月也不一定搞的定。此時又信心爆崩…

最後,我感覺那哥們水平真不咋地

哎,我還傻傻的曾經認為他是大神!就這程式碼效果簡直和小學生差不多呀。

算了,不吐槽了,就這樣吧。隨便改改湊合能用就好了!

嗯大致就這樣,你說神奇不伸手?

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?八戒你瘦了看著疲憊啊2020-11-03 18:22:55

我入職三天了,專案之前全是畢業生寫的,聽說之前的都被開了,現在重構,沒註釋沒文件,不規範,程式碼髒亂差,我都想離職了

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?程式猿充電站2021-04-21 12:47:26

一個詞兒——崩潰

程式設計師本就是個高風險行業,閱讀風格不太整潔的程式碼著實

是對內心一種修行

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?

隨著專案進入維護階段,大批老員工紛紛離職,目前剩下的老員工寥寥無幾。平時工作中難免要修改一些老需求,當聽到老需求時,大腦就開始忐忑了,因為上次這個需求就是某同事開發了一年才寫了來的東西。

如今給到了你,3天內上線,能不讓人頭疼啊。

最讓人崩潰的有以下幾點:

1、沒有註釋

全篇密密麻麻的一個註釋都沒有,那感覺就像是用火星文書寫的博士論文,越是難的地方,程式碼塊兒越大。

2、沒有日誌

對於維護期的專案,最重要的就保障老功能的正常執行。當出現生產bug時,如果沒有列印日誌,該功能又比較不容易復現,造資料就需要 好幾天。這時候唯有望洋興嘆了

3、程式碼深度大

一個功能模組,方法調方法,一層一層,當你找到第10層時,跳樓的心都有了。還有那種想將整個功能重寫的衝動。

4、命名不規範

不知道有沒有看到過類名小寫,方法名不同模組中好幾個都相同的,在梳理程式碼邏輯時完全不知道從哪兒下手。

5、程式碼冗餘多

一個Service中10介面,競然有8個介面中的某一部分功能區別很小,卻被重寫了8次,程式碼極大冗餘,看到你發慌。

還有很多很多,這種現像的原因很有可能是在寫時,自己都沒有想清楚都開始幹了。

解決方案:

1、學習下設計模式

2、站在全域性考慮問題,不重複造輪子

3、學會歸類、分組

各位程式設計師們,同意不

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?s嶺上多白雲2021-01-20 23:26:03

蘭德里的折磨

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?第四等公民2020-11-06 08:29:40

一個儲存過程幾千行。裡面巢狀合眾儲存過程和函式,n個臨時表,註釋少得可憐,沒有任何資料庫欄位說明,爽不爽(`Δ´)!還有一個幾乎沒有任何註釋的cs程式碼,我一步一步除錯下來等到執行結束足足用了40多分鐘。

閱讀離職程式設計師遺留下來的垃圾原始碼是怎樣一種體驗?改個大家都沒有的名字2020-11-06 15:43:40

不是垃圾程式碼,是多少個通宵打上去的補丁,雖然亂,但是解決了實際問題。實現過程也是需求穩定的過程,如果需求穩定後再開發,就不會這麼難看,這個鍋程式設計師不背