iT邦幫忙

2021 iThome 鐵人賽

DAY 29
0
自我挑戰組

菜鳥工程師的奇幻旅程系列 第 29

Day 29 - 這一年多來的開發問題解析心得分享

今天討論的主題是關於開發的過程中,問題要怎麼去思考和解決的小技巧,這些內容對於剛開始學習程式或者是新鮮人,可以有一些啟發和建議。

備註 : 下述的內容不預設程式語言

為什麼問題會發生?

這時候如果有個資深的同事可以詢問,並且參照他們的經驗法則就知道怎麼排除這個問題,那如果沒有人可以問的話該怎麼辦呢,下述的內容會從問題點如何察覺、下完關鍵字後怎麼判斷不同類型的答案對我有沒有用。

網路上有哪幾類的答案?

開發過程中總是會遇到程式錯誤的狀況,而當下會看到錯誤的提示訊息,第一件事情會先看是哪一行出錯了,接著到指定的行數檢視。在現今網路發達的發展下,想要要做什麼事情就可以透過關鍵字搜尋,所以當知道程式的錯誤訊息之後,就是把這一些訊息看看搜尋之後的結果,依照搜尋之後的結果我大概可以分為幾個觀點,來了解找到的資訊要怎麼要解決問題。

複製貼上型答案

對於開發者而言Stack Overflow算是一個職場上的好夥伴,常常搜尋完的結果有許多的資源都是來自這個平台,網友除了會回答問題的解決方式外,也會提供sample code給詢問者參考和測試。通常這個情境比較是在處理基礎的功能(例如數值怎麼轉換、怎麼傳值之類的),突然想不到這個語言的基礎用法時,就可以透過這樣的方式解決問題。

但雖然有一些答案複製貼上就可以執行,但也是需要了解為什麼程式碼會這樣寫,以及這些代碼有引用到哪一些觀念,或者是這個答案有沒有更好的寫法,以此讓自己在下一次再遇到類似的問題時,有更多的想法去尋找解法。

概念式的答案

上點提到的比較是大眾式的問題,所以通常都會有程式碼可以參考,但如果今天開發錯誤訊息找出來的結果都沒有具體的程式碼該怎麼辦,有幾點的搜尋方法可以給各位參考一下。

拆解錯誤的訊息

在一長串的錯誤訊息也代表這在描述一件事情,因此可以把不同的名詞或者是動詞搭配開發的程式碼查詢,看看基本的用法和意思是什麼。以過去的經驗這時候如果整個框架或者是功能是自己寫的話,通常看完名詞的一些解釋後,也會有一點思緒去推測是不是其他的地方功能寫錯的關係,導致連鎖錯誤發生的情況。

如果上述提到的方法還是沒有思緒的話,同樣也是保留關鍵字和開發程式碼,接著再加上你要做這件事情的敘述,例如要做xxx判斷加上使用這個錯誤訊息名詞,顯示的結果可以看看有網友問的問題,在他描述的情況是否就是你開發時遇到的情況。

影片教學式答案

除了程式碼的參考答案之外,越來越多的開發者會上傳一些技術的教學影片,然後下面的梗圖會看到影片教學有許多的印度人教你寫程式(誤)。這些資源如果是做類似的功能可以參考他們開發的過程,然而影片的好處就是知道一個功能從無到有的過程,但同樣的還是要留意內容的程式碼是否有其他的寫法,只有手把手做過很快就又會忘記了。

至於要去哪裡看教學影片,願意付費的話可以去udemy選擇相關的課程,但如果只是單純想看其他人怎麼開發,那可以去Youtube下關鍵字也是有蠻多的結果可以查看,不過我會另外留意影片的留言,如果有人留言影片內容有許多的錯誤,基本上就不太會繼續看下去(因為自己也還沒搞懂功能xD)。

Imgur

自己問問題

上述的資源搜尋了一輪還是沒有答案怎麼辦,最後的手段就是自己去社群提問,詢問的管道除了Stack Overflow之外,也可以看開發的語言或者是框架有沒有自己的論壇,或者是透過IT邦幫忙的技術問答也可以。

Google-Fu

剛剛說明了不同種類的答案之外,要如何快速找到想要的資源也是一門學問,以下的資源提供搜尋時的實用功能,以及當問題時需要怎麼拆解問題點的根源,逐步的找到最適合的答案。至於要下什麼關鍵字的技巧,進步最快的方法就是自己輸入關鍵字,這個意思是說先通過自己腦中的想法去找答案,真的找不到的時候再請教同事,透過這樣的方式可以更加知道下一次再遇到這個問題的時候,更快速的找到想要的結果。

備註 : 如果今天遇到的是現有的系統流程或者是資料流的問題,建議可以直接詢問同事是否有規格書或者是相關的附件參考。

參考資源

凡走過必留下痕跡

除了知道怎麼下關鍵字搜尋資源外,除錯我覺得是非常重要的一件事情,因為好的除錯技巧可以增加開發的效率,減少因為Debug卡太久拖延開發時程的狀況發生。個人剛開始開發程式的時候,很多時間看到錯誤的問題如果網路搜尋一輪找不到適合的問題時,會偏向是透過自己的想法去測去改寫程式碼,但很多時候測試的次數一多的時候就會花不少的時間。

把結果印出來

除錯起手式就是把輸出的結果顯示在畫面上,以Javascitpt為例使用console.log('訊息',變數)就可以檢查輸出的結果,另外今天是用C#開發的話可以使用Console.WriteLine()把結果印出來,透過這樣的方式可以減少自己猜測和通靈的時間,掌握輸出的結果去延伸思考問題解決的方法。

console.log參考來源
Console.WriteLine參考來源

斷點下起來!

如同上述的標題提到的凡走過必留下痕跡,因此除了看到錯誤訊息之外,使用開發工具的偵錯模式透過下斷點的方式,檢視錯誤的那行引用的類別或者是宣告的變數,顯示的結果跟開發預期的結果是否有一樣。

然後逐步把執行的過程每一個用到的Function下斷點檢視,確保這個錯誤訊息是執行的流程發生問題,還是單純自己的疏忽發生的問題(大概有8成都是這個原因),以過去的除錯經驗多次下來建議先從最小單位確認(意思指的是先確認變數的型態、引用的方法是否正確),然後再拉大範圍檢查function間的執行情況。

Visial Studio Code Debugger
Visual Studio Debugger

額外補充

第十天有提到Why Learning to Code is So Damn Hard的文章,如果現在正在下圖的這兩個階段迷茫太久的話,在這次的系列文章從過去的實戰經驗內容,也許能夠給正在閱讀的你們,能夠知道什麼情況下用哪種工具或是框架比較適合。另外確定了開發的框架後,今天的內容算是引導透過搜尋引擎,找到符合的答案或者是要怎麼找的建議後,就會有更多的信心和動力完成設定的目標。

Imgur


上一篇
Day 28 - 新鮮人第一份工作的心得與重要性
下一篇
Day 30 - 下一段的旅途與系列文章總結
系列文
菜鳥工程師的奇幻旅程30

尚未有邦友留言

立即登入留言