開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，堅持閱讀《開源日報》，保持每日學習的好習慣。
今日推薦開源項目：《網格 cssgridgenerator》
今日推薦英文原文：《5 Powerful Habits of Successful Developers》
今日推薦開源項目：《網格 cssgridgenerator》傳送門：GitHub鏈接
推薦理由：興許你正在開始著手使用網格的方式布置你的頁面，但是一個個的為你的元素寫上網格規格實在是有些重複勞動……那麼這個項目就能幫助你。它能夠讓你簡單的生成網格所需的 CSS，你只需要把你的布局畫上去，然後調整配置就能得到你需要的代碼了。儘管它沒辦法讓你很全面的使用網格，只能幫你寫個最開始的布局而已，剩下的事情你還是要自己動手，但是不可否認的是在最初的一步上你會節省很多時間。
今日推薦英文原文：《5 Powerful Habits of Successful Developers》作者：Ada Cohen
原文鏈接：https://medium.com/better-programming/5-powerful-habits-of-successful-developers-10fa9f5eee77?source=topic_page---------23------------------1
推薦理由：一些良好的習慣，包括保持不斷的學習，這會讓未來的你不需要為了之前浪費的時間而穿越時空回來好好的敲你的腦袋

5 Powerful Habits of Successful Developers

Here are five incredible propensities that can supercharge your prosperity as a developer:

Be Professional

  • 「The correct activity and the hard activity are typically the same. What』s more, both require professionalism.」
Professionalism resembles the sword of Damocles. On one hand, it is a symbol of respect and pride. On the other hand, it is a marker of duty and responsibility. The two are inseparable. You can』t invest heavily in something that you aren』t responsible for.

Imagine that you thought of some code and then created it, but that you caused the generation framework to be disturbed for one day. Obviously, the client isn』t happy. You return the code, yet whatever harm happened couldn』t be fixed.

The nonprofessional would shrug his shoulders, say 「stuff happens,」 and then begin composing the next module. The expert would sweat and fuss over the slippage and would ensure that the same mistake doesn』t happen again.

Professionalism is about responsibility. You can』t be correct all the time, so you must own your mistakes.

Try Not to Repeat the Same Error

  • 「When a statement of regret is followed by an excuse, it implies a similar mix-up will happen again.」
Obviously, we need our product to work. Surely, a large portion of us are software engineers today because we got something to work once, and we need that feeling of rapture once again. In any case, we aren』t the main ones who need the product to work. Our clients and managers need it to work as well. Without a doubt, they are paying us to make programming that works in the manner they need it to.

But software isn』t immaculate. Every product will have bugs.

The key here isn』t seeking to compose impeccable code. That is an idealistic dream that will never happen. The message here is taking responsibility for the blemishes in your product. Make new bugs. Commit new errors. However, don』t commit the same oversights again and again.

As you develop in your calling, your blunder rate ought to quickly diminish toward zero. Though it won』t ever reach zero, it is your duty to get as close to it as you can.

Don』t Leave Anything to Luck. It Never Works.

  • 「The harshness of low quality lasts longer than the sweetness of gathering the timetable.」
The standard guideline is that if something is destined to turn out badly, it will turn out badly and no measure of karma can keep it from happening.

That is the reason testing is so significant. How can you figure out if your code functions? That is simple. Test it. Test it once more. Test it up. Test it down. Test it every one of the seven days to Sunday!

Regardless of whether due dates are hardened and there is pressure on you to compromise, don』t. Mechanize experiments, get into pair programming mode, or even take a gander at reusing existing experiments. In any case, don』t diminish the holiness of this progression.

Your entire notoriety relies upon how well you have tried the code before conveying underway. Each and every bit of code you compose ought to be tried. Enough said.

Consider the possibility that the code is 「untestable.」 The code is written so that makes it hard to test.

The short answer is making the code simple to test. Furthermore, the most ideal approach is composing your tests before you compose the code that passes them.

Remember, the motivation behind your code is to get it to solve a business issue. On the off chance that goal flops, no number of lines of code or code beautification are of any use.

You as a software engineer should know whether your code works. Nothing else is more important.

Continuously Create Flexible Code

  • 「Innovation has dependably relied upon transparency and adaptability, so keep seeking both.」
The genuine expert realizes that conveying capacity to the detriment of structure is a waste of time. It is the structure of your code that enables it to be adaptable. On the off chance that you bargain the structure, you bargain what』s to come.

The essential presumption behind all product ventures is that the product is easy to change. On the off chance that this is not the case, then something is truly off-base.

Many activities get caught in the mess of unyielding code. When engineers travel every which way, they further add to the slough of unyielding code and end up making a beast that cannot be revamped nor maintained effectively.

The key here is recognizing the parts of the code that make it unyielding. When we discover those segments, we can fix them instead of further adding to the chaos. This matters more than due dates. Get the up front investment and make the best decision.

Continuously pursue the guideline of 「Unfeeling Refactoring.」 Leave the code cleaner when you drop it, and if that implies accomplishing something 「additional」 from what you have been advised to do, do it.

Always Be a Learner

  • 「Build up an energy for learning. In the event that you do, you will never stop developing.」
「I need to do a S/4HANA course, but the business isn』t supporting it.」

「I need to learn Web Dynpro frames, but I am not ready to take time from my busy calendar.」

「I need to go to that Codeathon, but it is a busy weekend.」

All these are excuses not to learn. Your profession is your obligation. It isn』t your boss』s duty to ensure you are attractive. It isn』t your boss』s obligation to prepare you, or to send you to meetings, or to buy you books. These things are your responsibility.

As a standard guideline, pursue the 40–20-hour rule each week. Use 40 hours for business. Then use 20 hours for your own learning. Use at least 60 hours of the week to develop a ceaseless learning society inside you.

What』s more, 20 hours of the week isn』t troublesome. If you use your time carefully, you will discover that you have a lot of additional time just for yourself.

Always remember that the product field is constantly showing signs of change, and it』s easy to turn into a dinosaur. That』s why you need to stay on top of it by putting resources into yourself and your continuous learning.
「Self-instruction is available to everyone, but it is taken seriously by those who want a purposeful life.」
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/