开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《受苦 dark-souls-cheat-sheet》
今日推荐英文原文:《The Most Common Pitfalls for an Inexperienced Developer》
开源日报第553期:《受苦 dark-souls-cheat-sheet》
今日推荐开源项目:《受苦 dark-souls-cheat-sheet》传送门:GitHub链接
推荐理由:说到高难度的受苦游戏,黑暗之魂肯定榜上有名。要想挑战这类游戏,充足的时间,足够快的反应和好运气都是相当重要的——国庆节兴许就是个好机会。这个项目是黑暗之魂的记录表,上面记录了游戏的流程和你能捡到的道具等,从黑魂开始接触受苦游戏兴许是个不错的开端,但是别忘了假期有限,请勿头铁,量力而行。
今日推荐英文原文:《The Most Common Pitfalls for an Inexperienced Developer》作者:Daan
原文链接:https://medium.com/better-programming/the-most-common-pitfalls-for-an-inexperienced-developer-c3636a1b5656
推荐理由:初学者可能犯下的一些错误,最要命的估计就是最后一条——技术可不能解决一切问题

The Most Common Pitfalls for an Inexperienced Developer

Don’t fall into the same traps as most developers

Experience is the name we give to our mistakes, according to Oscar Wilde. So, as you can imagine, developers with little experience haven’t yet hit the most common pitfalls. In this article I will show you some of these most common pitfalls, so you don’t have to fall into the same traps.

Most developers have probably fallen into at least one of these traps. Look at this article as a piece of advice, written from my experience, which you can benefit from — especially when you’re a relatively inexperienced developer.

Reimplementing Code That’s Already Available in the API

Most developers use some sort of framework to make their life easier. For an inexperienced developer new to the framework, it can be hard to know everything that is available in the API of the framework.

This often results in some kind of reimplementation of code that is already available in the API. Inexperienced developers are more likely to do this for two reasons.

Due to a lack of experience, the inexperienced developer doesn’t know everything that is available out of the box in the API. This leads to time being wasted on producing code that already exists in the framework. Their lack of experience also leads to them not using the framework’s full potential.

The second reason inexperienced developers often reimplement code is that they do not know where to look for in the documentation. Or even worse, they don’t look at the documentation at all.

This is a pitfall for inexperienced developers because it seems so tempting to just recreate the same function. Some functions only take a few lines of code to recreate. Plus it doesn’t take much time to write those few lines of code. But rewriting the same code has downsides. Double (untested) code is being introduced in the codebase. And the code gets more complex since a new function got introduced. Other developers are unfamiliar with that function and won’t understand why that function is introduced. Overall the complexity increases, which is something that you don’t want to do without good reason.

Don’t Make Things Unnecessarily Complex

Sometimes developers get in over their heads. The problem with this is that only experienced developers know when to admit it. Where experienced developers try to keep things as simple as possible, inexperienced developers tend to overdo things.

One of the reasons for this is that inexperienced developers will try to prove themselves to the rest of the team. They do this with all kinds of fancy stuff like quirky one-liners and overly complex abstractions. Technical debt is being added unnecessarily.

This pitfall will make the code more complex. Try to keep things as simple as possible. Experienced developers follow the KISS principle: Keep it simple, stupid. By adding technical debt code gets less readable and gets harder to maintain.

Silently Swallowing Errors

Silently swallowing errors is a mistake I’ve seen plenty of times from inexperienced developers.

A relatively inexperienced developer was working on a fix for a bug: a query that got executed wasn’t valid. The query was expecting a numeric value to check if a product was still in stock. The bug occurred because a numeric value wasn’t passed to the query. Instead, it got passed a null value. So the query looked like this: This triggered an error, of course. The inexperienced developer “fixed” the bug by typecasting the variable that got passed to the query to an integer. This made the syntax of the query valid but didn’t solve the problem.

Instead of tracking down the source of the problem, the inexperienced developer chose to “fix” the bug at the deepest level that was possible — entirely without bad intentions.

The correct way to fix this bug was by tracking down why a null value got passed to the query and fix that. One cause for the problem could be that the API that gives information about the stock was not available. If that’s the case the query probably shouldn’t be executed. The actual problem could be something completely different than a query not working properly.

By silently swallowing the error the real cause of this bug would have never been found. The “bugfix” that was implemented by the inexperienced developer was fine from a syntax perspective but would have swallowed the real error.

Overconfidence

Ask an overconfident inexperienced developer how long a task or user story will take and he’ll tell you the shortest time possible. If you ask the overconfident developer if he’s written some tests, he will tell you that there is no need to. The code is bug-free and it is impossible that it will break.

If you think you know it all when working on your first job as a developer, you’re wrong. If you don’t know what you don’t know, you don’t know how much you’re missing. This is where most inexperienced developers struggle.

Be humble and open to constructive criticism. Take advice from the more experienced developers. This will help you grow as a developer. Having confidence is good, but overconfidence will work against you.

Only Testing the Happy Path Scenario

Inexperienced developers often focus on just delivering the functionality or user story. This is what is known as following the happy path. The delivery of the functionality or user story should come with tests. This another place we see a difference between inexperienced and experienced developers: inexperienced developers only test what users are supposed to do; more experienced developers will also write tests for edge cases.

Only testing the happy path scenario is naive. Users are unpredictable — you need to test more than just the happy path scenario.

Switching Tools

Having the right tools and knowing how to use them can save you a lot of time on a daily basis. You should really take some time to find the right tools. When you are looking for tools, you should pick tools that do what they promise.

If you have the right tools, you should stick with them. Don’t switch tools every week. It takes time to get to know the tools and master them.

You should also invest in a good IDE since this is where you will spend most of your time. Learn the keyboard shortcuts and learn how to use code snippets. Create your own code snippets to speed up routine tasks.

Furthermore, you should learn how to debug. Pick an IDE that has some sort of debugger so that you can see the values of all the variables that are being used. This will give you a much better grasp of what is going on and will save you a lot of time debugging.

Focussed on the Tech and Not the Business

Inexperienced developers have not mastered their tech stack yet. And most of these developers tend to be so focused on learning the tech stack that the business gets out of sight. On the journey to becoming a master of your tech stack, it’s important to keep the business in mind. Why are you building this?

Some developers are only interested in the technical aspects of their job. They don’t care about the business or the economic factors that justify their job’s existence.

Is what you’re working on creating value for the business or are you spending too much time on something that doesn’t really matter? It’s an important question to ask yourself.
下载开源日报APP:https://openingsource.org/2579/
加入我们:https://openingsource.org/about/join/
关注我们:https://openingsource.org/about/love/