開源日報 每天推薦一個 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/