今日推荐开源项目：《Netease-cloud-music-gtk》
今日推荐英文原文：《15 Mistakes Every Developer Has Made in Their Life》
今日推荐开源项目：《Netease-cloud-music-gtk》传送门：项目链接
推荐理由：该项目是专为 Linux 系统打造的网易云网易云音乐播放器，基于Rust + GTK开发，稳定，极速，且简洁。
今日推荐英文原文：《15 Mistakes Every Developer Has Made in Their Life》作者：Daan
原文链接：https://medium.com/better-programming/15-mistakes-every-developer-has-made-in-their-life-7b7ef03cc84c
推荐理由：一些开发人员容易犯的错误。比如说，为了修改 bug 将代码缝缝补补，最后计算机也许能读懂，但是自己读不懂了。
15 Mistakes Every Developer Has Made in Their Life
Making mistakes is human and is actually what makes us grow. You shouldn’t be afraid to make mistakes. Chances are that you’ve made a lot of mistakes that are on this list. If not, that’s great. Try to learn from the mistakes other developers have made so you don’t have to make them yourself. 1. Quick and dirty fixes in code with a long lifespan. The problem with quick and dirty solutions is that they kill the quality of the code base. Chances are that such a solution will add unnecessary technical debt. In the long run, quick and dirty fixes will come back and bite you. You’ll probably end up refactoring your quick and dirty solution at some point in the future. 2. Lack of practice. As we all know, practice makes perfect. So if you want to grow as a developer, you need to practice more. The biggest mistake you can make is to not learn any new things every once in a while. If you want to learn something new, like a programming language, you probably have to do it outside of your daily job. That’s an investment that you have to make in yourself in order to stay relevant. 3. Underestimating the workload. Estimating the workload is one of the hardest things in software development. How often have you heard “I could easily do this feature in one story point” in a Scrum refinement? Chances are that things aren’t quite that easy and your intended solution won’t work. When it comes to estimates, make sure you count in time for things like testing as well — not just for the developer. 4. Writing obvious comments. We’ve all seen comments like this before. They don’t explain anything but focus on what the code is doing (e.g. a comment like “looping over the products” when there is a foreach loop). Whenever you’re in that situation, don’t write a comment that focuses on what the code is doing. Focus on the why of this code instead. 5. Commenting out blocks of code. We’ve all seen entire blocks of code containing multiple functions being commented out. No one knows why this block of code is still there or if it’s still relevant. The reason no one deletes this block of code is that everyone assumes that someone else might need it. Just delete the commented out code block. If it turns out that the code is still necessary, it will be in version control. 6. Only testing the happy-path scenario. When writing tests, you should take into consideration more than just the happy path. Think about some scenarios where things don’t work out as intended. What’s the worst-case scenario? Make sure to test that scenario as well. 7. Messy formatting of code. This is a mistake that’s most often made by inexperienced developers. It makes code harder to read and frustrates other developers who have to read your code. Fixing messy code can be done by installing a linter that formats your code. 8. Not logging any relevant information. Useful logs provide great help to developers. Having log messages can give you a lot of insight into where things went wrong inside your code and will save you a lot of debugging time. Good log messages provide context about what the user was doing when a specific error occurred. 9. Reinventing the wheel as a lack of knowledge. This mistake happens when a developer doesn’t know what’s already available in the framework. As a result of this lack of knowledge, new methods get implemented by the developer that are almost identical to a method that’s already available in the framework. 10. Starting to code without knowing the solution. This might seem exciting at first, but it will come back and bite you. Planning and organizing your code is an essential part of coding. You shouldn’t start coding without a plan. Think about problems that you might find along the way and how can you tackle them. This makes you more aware of the fact that there’s a lot to think about before writing code. 11. The art of writing bad commit messages. We’ve probably all committed this one before. “Fixed a bug” or “WIP” are not great commit messages. Having good commit messages is important and you should take the time to write a good commit message. A good commit message provides useful information about what has changed and why. When things really go south, the revision history is a great resource to quickly find out where exactly things went wrong. 12. Having magic numbers in your code. Magic numbers are unique values with unexplained meaning or multiple occurrences that can and should be replaced with named constants. The thing with magic numbers is that they’re not readable and don’t provide any context for the developer. On top of that, magic numbers are often used multiple times in different places within a program, which makes it error-prone. 13. Too many things going on in one function. Try to let your functions do one thing and one thing only. Don’t let a function fetch, process, and output the data. Split all of these responsibilities up into different functions. One for fetching, one for processing, and another one to output the data. Keeping a function focused on a single concern is what makes it more robust. 14. Not writing automated tests. Initially, it will cost you a little bit more time than doing manual tests when you start writing automated tests. In the long run, you’ll be glad you took the time to write these automated tests. Having to test everything manually is boring, time-consuming, and the human factor makes it more prone to errors. 15. Making things unnecessarily complex (aka over-engineering). Implementing certain design patterns for the heck of it is something that most developers have done. Just because you see an opportunity to implement a design pattern doesn’t mean you should. All this accomplishes is adding more technical debt to the code base.下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
