開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《大菠蘿 diabloweb》
今日推薦英文原文:《How to Cut Through Code Fog》
開源日報第517期:《大菠蘿 diabloweb》
今日推薦開源項目:《大菠蘿 diabloweb》傳送門:GitHub鏈接
推薦理由:Diablo,即暗黑破壞神,相信就算是沒有玩過它的玩家也多多少少聽過大菠蘿這個名號。這個項目允許你可以開著你的瀏覽器跑個 Diablo1 玩,隨著網路的不斷發展,瀏覽器能起到的作用越來越大了,在瀏覽器上重溫名作已經不只是紙上談兵,而是不斷接近的現實。
今日推薦英文原文:《How to Cut Through Code Fog》作者:Aphinya Dechalert
原文鏈接:https://medium.com/better-programming/how-to-cut-through-the-code-fog-45bfddc3d9c7
推薦理由:換個角度換種思考什麼的興許能解決一個看起來無解的問題

How to Cut Through Code Fog

It』s like brain fog but worse

At some point while sitting at our desks, we』ve all experienced code fog. It』s like a mixed feeling of confusion, frustration, and exhaustion. Code fog happens when you』ve tried to compile your code and it』s just not working.

You』ve chopped, changed, and Googled your way through every possible link. You probably have even made it to the 12th page of your Google search.

Code fog is notorious for causing imaginary table-flips and no — you』ve checked — it』s certainly not caused by a missing semi-colon. It』s something deeper and you can』t quite figure out what.

Rather than force yourself through the painfully unproductive process of debugging, here are some things you can do to help cure your code fog and gain a sense of clarity once again.

Why Bugs Happen

Bugs happen because there』s a gap in our knowledge. It』s also the main reason we instantly turn to Google when we get stuck. But oftentimes, the answers that Google gives tend to be snippets of something bigger. Sometimes, the gap in your knowledge is so big that looking at snippets is simply not enough.

You need to take a step back and look at the bigger picture. What does this mean? First, you need to identify the type of issue you』re facing. Is your code overly complicated? Then it』s a programming pattern issue. Is your code not working the way it should? Then it』s a gap in your understanding of the framework or library. Is your code not compiling? It might be a dependency issue.

When you have a programming pattern issue, the quickest cure is to slow down and look into functional and OOP patterns for your chosen language. If you』ve got a framework or library issue, then you need to look into the wider topic surrounding your issue. If it』s a dependency issue, you』ll need to trace the relationships and versions to figure out where the blip is.

Don』t try to look for a solution, it』ll continue to give you tunnel vision. A big-picture approach can lead you down a very different road from what you』re currently experiencing.

Sometimes, You Just Need a Break

As developers, our brains can get stuck in a funky loop and cause tunnel vision towards our code if we』ve been working on it long enough. We start to see only what we want to see. When this happens, you need to give your brain a break from the issue and go work on something else. A 12 to 24-hour quarantine from the problematic code is usually enough for most of us to properly disconnect and come back to the issue with fresh eyes.

According to the Science of Learning Journal, when we become frustrated or fearful, the part of our brain known as the amygdala kicks in. Based on past conditioning, it only makes us aware of the immediate threat — which in our case is the problematic code. The more we focus on it, the more we become entrenched in our own created mental boundaries and fail to see any systematic connections that may be contributing to the bug.

So take a break — go and do something else, then come back to it with a different attitude and mindset towards your code.

Seek a Second Opinion

One of the perks of peer programming is that there is always a second opinion on your code. As a developer, we may think of our code as infallible, however, another pair of eyes with knowledge of different topics and past experiences have the ability to inject an alternative perspective.

Most of the time, we work on our code alone, but when bugs arise, and before your brain becomes overly fixated on them, ask a colleague for help. Just have them to come over and review what you』ve coded. Get them to ask you questions about the code.

They don』t have to solve it for you — but their questions can lead you down a different path towards your solution. Everyone has their own flow of thought when it comes to debugging and chances are that they』ll think differently from you.

Final Words

Code fog happens because you get stuck. To become unstuck, you need to do something that is different from what you』re currently doing. You can』t expect a different output if your input remains the same.

Code fog sucks but it always eventually clears. You just need to be patient with yourself and work on constantly expanding your domain of knowledge. This is because you never quite know when something seemingly random will come in handy. It』s also one of the best ways to prevent code fog in the future.

As Steve Jobs once said in his Stanford commence speech —
You can』t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.
Thank you for reading. ❤

Aphinya
下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/