开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《表情无处不在 gitmoji》
今日推荐英文原文：《The most important skill a programmer can learn》
今日推荐开源项目：《表情无处不在 gitmoji》传送门：GitHub链接
推荐理由：有的时候一个表情可以有很多含义，所以用起来很管用。这个项目能为 Git 中的提交信息添加表情符号，看多了文字突然冒出来一个表情自然会相当显眼，在团队中为一些通用的操作统一添加表情符号也能更好的辨别提交信息，在这层意义上它能够最大限度的发挥将人们的目光聚集在自己身上的功能。
今日推荐英文原文：《The most important skill a programmer can learn》作者：Huseyin Polat Yuruk
原文链接：https://medium.com/free-code-camp/the-most-important-skill-a-programmer-can-learn-9d410c786baf
推荐理由：不要只管写什么而不管该写什么啊kora！

The most important skill a programmer can learn

No, no, no, no, and no. And no.

A big NO. Clear as that.

All you have to do is to bring those two letters together and say the word.

Now, let’s say it together. NOOOOOOO!

Good start.

But wait a minute. Say NO to what and when?

Well, this is the important point where most of the programmers (even seniors) get easily confused.

As a programmer, writing code is the biggest part of your job. In your programming lifetime, you will have to deal with different kinds of code requests. Each request will force you to make difficult decisions. That all is OKAY. Nothing wrong with that. This is what everyone expects from you, as a programmer: Writing code. However, here is a question: Should you write all the code that is requested from you?

This question brings us to the most important skill a programmer can learn:
Knowing when not to code is possibly the most important skill a programmer can learn. — The Art Of Readable Code
I couldn’t agree more. Why is that?

Programming is the art of solving a problem. So naturally, programmers are problem solvers. As programmers, when we have a new problem in front of us ready to be solved or any other reason that needs from us to write code lines, we get excited.

And that is okay because we are programmers. We love writing code.

However, getting too excited about writing code makes us blind. It causes us to ignore some important facts that can cause bigger problems we will have to deal with in the future.

So, what are those important facts that we tend to ignore?

Every line of code you write is:
  • code that has to be read and understood by other programmers
  • code that has to be tested and debugged
  • code that will increase defects in your software
  • code that probably will introduce new bugs in the future
As Rich Skrenta wrote, code is our enemy:

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean the old code has to be adapted.

The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

Furthermore, more code often means less flexibility and functionality. This is counter-intuitive, but a lot of times a simple, elegant solution is faster and more general than the plodding mess of code produced by a programmer of lesser talent.

Code is produced by engineers. To make more code requires more engineers. Engineers have n² communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.

It’s so true, isn’t it? The programmers who inspire you with their productivity and coding mentality are those who know when to say no and when not to code. The software that is easy to maintain, that lasts long and keeps helping their users is the one that doesn’t contain any unnecessary code lines.
The best code is no code at all, and the most effective programmer is the one who knows when not to code.

How can you know when not to code?

It’s natural to get excited when you’re working on a project and think about all the cool features you’d love to implement. But programmers tend to overestimate how many features their project needs. Many features go unfinished or unused or simply make the application overcomplicated. You should know what is essential for your project to avoid making this mistake.
Understanding the purpose of your software and its core definition is the first step to know when not to code.
Let me give you an example. Let’s say you have software that has only one purpose: managing emails. And for that purpose, sending and receiving emails are two essential features to your project. You can’t expect that software to manage your to-do list as well, can you?

So you should say NO to any possible feature requests that are irrelevant to this definition. This is the moment you can be exactly sure that you know when not to write code.
Never expand your software’s purpose.
Once you know what is essential for your project, you will be conscious next time when you evaluate possible code requests. You will exactly know your requirements to write code. Which feature should be implemented? Which code is worth to write? You will question everything because you will know exactly how unnecessary code can kill your project.
Knowing when not to code keeps your codebase small.

The Art Of Readable Code

There are only two or three source files when you start your project. All looks so simple. It takes just a few seconds to compile and run the code. You know where to find exactly what you’re looking for.

Then, as the project grows, more and more source files fill your directory. Each code file contains hundreds of code lines. To organize them all, you will need multiple directories soon. Remembering which functions call other functions is more difficult, and tracking bugs requires a bit more work. Managing your project becomes difficult, and you need more programmers to help. Communication overheads increase as the number of programmers increases. You get slower and slower.

In the end, the project becomes huge. Adding new features is painful. Even making small changes takes hours. Fixing present bugs always introduces new bugs. You start missing deadlines.

Now, life is a struggle for you. Why?

Because you didn’t know when not to code, you said YES to every possible feature request. You were blind. Coding something new caused you to ignore essential facts.

It’s like a horror movie, right?

This is what will happen if you keep saying YES to everything. Know exactly when not to code. Eliminate all unnecessary code from your project. This will make your life easier and make your software last longer.
One of my most productive days was throwing away 1000 lines of code. — Ken Thompson
I know that knowing when not to code is so hard. Even for senior programmers. Perhaps what I wrote in this article is hard to understand for junior programmers, and that is okay and understandable.

I know you have just started your programming journey and you want to write code. You are so excited about that. This is good. Never lose this excitement but also never ignore the important facts. We learned them by making our own mistakes. You will make mistakes as well, and you will learn from them as well. But at least you can be more conscious if you can learn from our experience.
Keep coding but know when to say no to coding.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/