今日推荐开源项目：《网格 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.”
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.”
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.”
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 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 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/
