开源日报 每天推荐一个 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/