-
1 # 老九的說說
-
2 # 湫音社
改別人程式碼吃力,這是很正常的一件事情,畢竟程式碼是別人寫的,我們要想改他的bug首先要做的就是要找到他的bug,為了找到他的bug我們又不得不去搞懂他的邏輯知道它到底是如何寫的寫了什麼,所以會比較吃力
別說改別人的bug了,在工作中別人的程式碼我都懶得拿過來用,因為別人的程式碼並不是為你的專案寫的所以或多或少要去修改,要修改就要去讀懂,因為我比較懶,能自己寫的儘量自己去寫這樣反而比修改別人的程式碼要快得多
如果你覺得修改別人的bug比較吃力並且有明顯的異常報錯,我們就可以完全面向谷歌程式設計啊,因為很多問題不止你一個人會遇到,多數情況下網上會有現成的解決方案
同時可以採取斷點除錯的方法,逐步地去排查,這也是很不錯的方法
如果實在不行就去請教別人,很多久經沙場的大牛可能一眼就看出來問題出在哪裡
-
3 # 猿攀網籃
技術經驗都是積累出來的,沒有菜不菜,多練就是了。總結下我的排查bug經驗,互相學習。
1、出現bug,分業務級別還是系統級別。
解決業務bug:首先理清各個業務邏輯線,然後打斷點調式程式碼,很快會定位原因,改起來也就簡單了。
系統級別bug(例如系統卡,記憶體溢位等):這時候要利用監控工具,檢視JVM或者各個中介軟體的使用情況,根據各日誌去定位問題
2、平時多研究監控工具使用,在排查問題是挺有幫助的
3、提高自己的程式碼閱讀量。閱讀量上去了,那你看別人的程式碼才會迅速看懂理解
-
4 # 自學JAVA
改別人寫的程式碼覺得吃力,這個完全體現不了一個人的技術菜不菜。為什麼?原因答主根據自己的經驗從以下幾個點給分析分析:
外在因素工具的使用習慣不同
大家應該有遇到過這種情況,我們可能在看到其他人使用和你一樣的開發工具的,但是你發現他把開發工具的窗體上的模組都調的和你的使用習慣完全不一樣的,比如:你的資源管理器在左邊,但是他把資源管理器調到了右下角。那這個適合你來給他找bug剛開始真的會覺得很麻煩,總感覺不舒服,並且你還不能調。這樣會嚴重的影響你的找bug效率。
當工具使用習慣不一樣的時候也會有所影響程式碼的風格不同
所謂的程式碼風格不一樣,打個比喻:你敲的程式碼每個變數名的命名都是按照規定的需求文件來,絕對沒有一點差錯,但是你看到對方的變數名總是一些奇奇怪怪的單詞的組合。在或者你習慣把成員變數放在類的最上面,但是別人習慣把成員變數放在當前要使用的方法上面,等等等等。雖然這個對於找bug沒有實質性的影響,但是相信很多小夥伴有這種感覺,總感覺不舒服,每次看到這裡和自己的風格不一樣,心裡總是會咯噔一下。這應該叫做影響心情吧!!!業務邏輯的理解思路不同
對於同一個模組的業務功能,大家會根據自己的業務邏輯的理解,找到解決方案,或者說同一個業務模組,你理解的業務邏輯和他的會不一樣,那麼你的解決方案也就不一樣。所以在給他找bug的時候你會經常遇到看不懂的程式碼,這個看不懂也不是說你比較菜,是你不理解他現在的想法,所以你如果要繼續往下面找的話,必須要問他來理解他敲出來的程式碼的他的想法,這樣就會很麻煩很麻煩,如果他能正確的表達他的思路還好,如果表達不清楚那就會花費很多的時間了。所以二手程式碼對於所有程式設計師來說真的是噩夢,你會在看程式碼的時候內心瘋狂的吐槽前開發者。
每個人的業務邏輯理解可能不一樣,所以溝通成本會比較大自身因素對當前遇到的技術不夠熟悉
自身對於技術的不熟練才是找bug吃力的最主要原因,但是不是絕對因素。如果對於當前使用的技術不夠熟練,會導致遇到的bug你也在內心是摸稜兩可的,也不確實,之後你會在各種調式中去試,如果運氣好,你可能試個幾次找到原因,如果運氣不好,可能把你覺得有問題的都試完都找不到。那這個時候你在對別人說不好意思你也找不到,那你這完全是在浪費時間,有可能還會招到別人的吐槽。但是你的對現在用到的這個技術瞭如指掌,那你每個模組檢查完畢,基本跑一跑你就能縮小範圍然後除錯之後就能確定問題所在了。
技術才是核心對業務邏輯理解的不夠透徹
也有一種可能你不是負責這個模組的,然後別人給你講了講現在他的模組業務功能,然後對於業務功能的不熟練也會導致你在找bug的時候一邊找一邊去想業務邏輯,效率會很低,你找的肯定會很吃力。總結:別人出現bug能拜託你去幫忙的話,已經證明了你在他內心技術是足夠好的,找bug吃力的原因有很多,但是對於技術的熟練也還是最主要的原因,但也不是絕對原因。
-
5 # 小貝愛跳舞
很多朋友都對學習路線問題感到迷茫,特別是還在上學的朋友們。在這裡就詳細的為大家介紹一下。1.Java基礎很多朋友一上手就開始學習Android,似乎太著急了一些。Android應用程式開發是以Java語言為基礎的,所以沒有紮實的Java基礎知識,只是機械的照抄別人的程式碼,是沒有任何意義的。那麼Java學到什麼程度才算是過關呢?我個人認為至少要掌握以下兩個方面的內容:a) Java基礎語法:具體的知識點列表可以在這裡下載:《Java知識點列表》V1.0。這部分內容沒有討價還價的餘地,必須爛熟於胸。至於具體的學習方法,可以看書或者是看影片,但是關鍵是要多加練習,無論是書上的練習還是影片裡面的練習,都需要仔仔細細的完成;b)設計模式:由於在Android系統的框架層當中,使用了大量的設計模式,如果沒有這個方面的知識,對於Android的理解就會大打折扣。設計模式的種類非常之多,一個一個的全部掌握,是不現實的,必須首先掌握面向物件的基礎設計原則,有了這些基礎原則的支援,就可以舉一反三。這部分內容可以在《Effective Java》和《Agile.Software.Development:Principles,Patterns.and.Practices》這兩本書中找到。2.Linux基礎知識大家都知道,Android系統的基礎是Linux作業系統。在開發過程當中,我們也需要使用到一些Linux命令。所以說一些Linux的基礎知識是必須的(話說現在的程式設計師,不懂Linux都不好意思跟人家打招呼),推薦大家看看《鳥哥的私房菜》這本書,寫的相當不錯;3.資料庫基礎知識這個比較簡單,就是一個增刪改查的資料庫操作,可以看一下這本書:《SQL程式設計練習與解答》4.網路協議至少需要學習兩種基礎的協議,HTTP協議與Socket協議;5.Android基礎知識有了以上的鋪墊,再來看Android,是不是覺得輕鬆了很多呢?至於基礎知識的學習順序,最好的方法就是按照Android SDK幫助文件當中的Dev Guide裡面的順序,我的《Android影片教程》也基本上是按照這個順序錄制的;6.伺服器端開發知識由於很多Android應用程式都需要伺服器端的支援,所以掌握一些伺服器端開發知識還是非常有必要的。至於選擇哪一種伺服器端知識進行學習,就比較麻煩了,因為技術的種類實在是太多了:a)Java EE:就是上面郵件當中所提到的SSH—Struts+Spring+Hibernate。這種技術的優點的功能完整、強大,已經使用了很多年,而且既然大家已經非常熟悉Java了,那麼學習SSH看起來也順理成章。但是使用這種技術開發伺服器端程式,非常麻煩。即使是一些簡單的功能,也可能需要大量的程式碼和配置檔案來實現;b)PHP:簡單易學,開發快速。但是我們需要多學一種語言,是否得不償失,就要大家自己判斷了;c).NET:這項技術的特點和Java EE差不多,但是要想掌握.NET,則需要掌握c#,也是個麻煩的事情;d)ruby on rails:這是我個人最喜歡的伺服器端技術,簡潔,優雅,寥寥幾行程式碼,就可以實現很複雜的功能,但是這需要Ruby語言知識作為基礎;至於選擇哪一種技術,就看大家自己的判斷了。夢想:要成為一個專業的Android開發者,以上的這些知識都必不可少。看起來好像很多,多的可怕。所以還是那句話--“耐心,耐心很重要”。學習一門專業要很長時間啊,耐心很重要,很多朋友也來問我C4D,能感覺到大家都想急著學會,其實要有長時間的積累才能有長遠進步,Android開發,最近公司要做程式,也涉及到,如果UI設計師的我學會了Android,是不是可以獨立做開發了。
-
6 # IT人劉俊明
除錯程式的能力確實是評價程式設計師整體技術水平的一個重要方面,但是由於不同程式設計師往往會面對不同的開發場景,所以程式的bug也會有很多種不同的呈現形式,所以如果除錯一些複雜度比較高的程式,即使是經驗豐富的程式設計師,也不會感覺特別輕鬆。
程式設計師除錯程式的能力,往往由三方面因素決定的,其一是自身的從業經驗;其二是自身對於業務的理解;其三是演算法設計能力。
程式碼量對於程式設計師除錯能力的影響是最為直接的,通常程式碼量越大的程式設計師,往往也會有越強的除錯能力,這一點在除錯一些常見bug時會表現得特別明顯,很多初級程式設計師在程式出現bug時,往往需要很長時間來進行除錯,但是老程式設計師幾乎是“一眼”就能發現問題,關鍵還是程式設計經驗起到的作用。
程式設計師對於業務流程的理解情況對於除錯能力的影響也是比較直接的,因為程式設計往往需要與業務流程相契合,尤其是管理類軟體,很多複雜的邏輯都來源於具體的業務規則,所以如果不瞭解業務規則很難進行程式除錯。實際上,很多程式設計師在半路接手程式程式碼時,都需要對業務有一定的瞭解,而這個過程往往是比較耗費時間的。
演算法設計能力也會在很大程度上影響程式設計師的除錯能力,雖然目前很多應用級開發任務中並不會有太多關於演算法的內容,但是演算法設計能力對於程式設計師的邏輯思維能力也有非常大的影響,所以演算法設計能力強的程式設計師,在理解程式碼時往往也會更快。
-
7 # 既不是廚子也不是戲子
條條大路通羅馬,你要找到他(寫bug的那鍋)在路上丟的那個鑰匙。首先,要知道他走的是哪條道,你跟著他的腳印向羅馬走。然後,沿路找尋丟失的鑰匙。 如果,你要是沿著他腳印都走不到羅馬。那肯定是你的問題,說明你要進修下了。如果找不到鑰匙,那排除其他意外情況,那就和你沒啥太大關係,你需要的只是 耐心耐心還TM的是耐心。
回覆列表
其實,改程式碼的工作量不低於自己寫。難點不是方法,而是業務的理解,思路的梳理。不能按自己的想法來,你得先研究明白當時為啥那樣寫。理解透徹了,再上手改程式碼。