开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《跑步 Energym》
今日推荐英文原文：《How I Start the Day as a Senior Software Engineer》
今日推荐开源项目：《跑步 Energym》传送门：项目链接
推荐理由：微信里的计步程序是通过记录并储存手机上的各种传感器的数据得出步数的，该项目的原理类似，是一款基于手机加速度传感器的跑步记录小程序，拥有历史记录，BMI计算，目标设置等功能，由 JavaScript 编写。
今日推荐英文原文：《How I Start the Day as a Senior Software Engineer》作者：Agon Qorolli
原文链接：https://medium.com/better-programming/how-i-start-the-day-as-a-senior-software-engineer-ebba07c18c5c
推荐理由：软件工程师的日常。

How I Start the Day as a Senior Software Engineer

From the perspective of a longtime JavaScript developer

Some context: My day-to-day activities are related to the JavaScript environment. My work involves researching/designing/implementing new features, improving existing ones, or solving particular bugs.

My software engineering thinking starts every day at 8:09 in the morning — just when I hop on the train for a 50-minute ride to Ghent, where I work as a software engineer for content marketing workspace StoryChief.io.

During that time, I repeatedly do only one of the three following things:

1. Read Medium articles about JavaScript, good coding patterns, or updates for specific tools. I tend to not go broader than these three main topics because being focused on a small, concrete, and cherry-picked set of topics allows me to achieve a sense of control. 2. Jump-start the day by already writing a couple of lines for the corresponding feature/bug that I was previously working on. This way, by the time I open my laptop at the office, I’m already in the right mindset and test environment. I see this as a warm-up before the game, just as athletes do. 3. Last but not least, occasionally I sleep with one eye open! I’m a father of one, and once in a while, the nights are not so smooth.
“I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.” — Bruce Lee
Alright, let’s go further into detail about the first activity since the other two are self-explanatory.

JavaScript Content

I follow these two forms of JavaScript content:

  1. New releases.
  2. Efficiency comparisons between the same functionalities but with different blocks of code. A simple example would be:


const users = [...];
const { length } = users;
let i;
for (i = 0; i > length; i++ ) {
  // some statement here
}
vs. 

const users = [...];
users.forEach((user) => {
  // some statement here
});
Research says that the former is faster, but not significantly enough to overcome the readability bonus that we get from the latter.

Bonus tip: continue; and break; statements are not available in forEach, while they are in for statements.

It’s your call!

Coding Patterns

I’ve recently been digging into is OOP vs. functional programming, and the more I read, the more I’m starting to lean toward the latter. To give some context, I initially learned coding through lectures about OOP and I believe I have a good foundation to come to reasonable comparisons.

What I prefer about FP is having a heavy mathematics background while, on the other hand, we have very abstract concepts to begin with. Why complicate the life of a student who is already acquainted with mathematical concepts?

I won’t discuss the performance differences between them, even though I’m highly tempted! Maybe that’s for a standalone article.

Other patterns that I like to read about are how a community organises their file structure, the advantages/disadvantages between them, and the best approaches to managing an application’s state.

Specific Tools

Examples of tools that I use are React, Apollo, and AWS services. But how do I decide which tools to use? By defining my goals first. I start by answering the following questions:

1. Do I see myself as a full-stack, front-end, or back-end engineer? 2. If I choose front end, then I compare some tools and decide which ones fit my style best. For me, it was React and Apollo. 3. If I choose back end, then I compare some tools and decide which ones fit my style best. For me, it was AWS services. Some considerations are the market share of the tools (because that defines your chances of being employed) and whether you find it interesting to code in such an environment (because you don’t want your second month to be boring).

However, it’s important to give it some time to get comfortable with your choices before deciding to switch environments. That can lead to confusion and dissatisfaction from having not completed a project.

Final Words

To conclude, I would like to present what I do when I open my laptop in the morning.

I always write a short and concrete to-do list for the day — usually three bullet points. This way, I can have a sense of productivity at the end of the day, and after a few years, you develop the correct sense for measuring your estimated time to finish specific tasks as well.

An example of a to-do list would be:

1. Implement comments sidebar. 2. Research user-friendly places to add comments CTA. 3. Implement 2. Thanks for reading! I hope you enjoyed this article.

下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/