今日推荐开源项目：《时间减速 comcastifyjs》
今日推荐英文原文：《Refactor Your Project, One Step at a Time》
今日推荐开源项目：《时间减速 comcastifyjs》传送门：GitHub链接
推荐理由：现在网速是越来越快了，基本上就很少见到需要等读条加载的情况……然后就有了这个项目，让你的图片能够慢慢的加载出来——至于有多慢你可以自己决定。这个 JS 库允许你预读加载图片之后假装网速很慢的显示它们，甚至还能模拟一下网络延迟所造成的加载停顿，虽然在正式项目里基本起不到作用，但是娱乐效果和节目效果依然值得期待。
今日推荐英文原文：《Refactor Your Project, One Step at a Time》作者：Faith Chikwekwe
原文链接：https://medium.com/@faith.chikwekwe/refactor-your-project-one-step-at-a-time-21838df431ba
推荐理由：重构实际上是迟早的事情，这篇文章介绍的是如何从小步骤开始着手重构。
Refactor Your Project, One Step at a Time
So you have a project that wasn’t your best? Maybe you wrote it at a hackathon. Maybe you had a tight deadline. Or maybe you’ve gotten much better as a programmer since you wrote it.So what should you do?
You could bury it at the bottom of your Github profile and forget about it. Sometimes this isn’t a bad thing. There are some projects which are not worth going back to.
But if you’re reading this article, you care about this project.
You believe in it.
You want to make it something that you can be proud of.
Don’t worry! We’ll go step by step through the refactoring process and discuss best practices to help you through your coding makeover.
Before you Start, Make a Plan.
Photo by Med Badr Chemmaoui on Unsplash
Before you can embark on this type of programming journey, you need to make a plan. There are a few core decisions that will help provide you with a framework that you can follow throughout your refactor.
- Design the overall goal of the project: What is your product trying to accomplish? How does your project deliver upon that goal? Who is the user or the recipient of the product? How will they interact with it and what will they take away from it?
- Make a more refined goal for the outcome of this refactor: How will your improved code make your project better? Are you trying to improve things for the user by improving performance or making a better user experience? Are you trying to make things better for yourself and other engineers by adding comments to your code, pulling large chunks of code apart into separate functions or making your code DRY-er (DRY means Don’t Repeat Yourself).
- Make a framework for the goals of each class, route or major function: What is the particular thing that this class achieves? Why is this function necessary? What other systems does it interact with? What parameters does it take in and what objects does it return?
Start Small.
Refactoring is a step by step process. Photo by Lindsay Henwood on Unsplash
Okay! Now you’ve got a plan.
A general outline of where this refactor will take you.
You’ve renewed your understanding of the goals of your project. But how do you decide what part of the project to refactor first?
The steps for every section of your refactor are the same.
Pseudocode, write tests, show your code to others, and improve it until it pass tests and passes your plan.
It is important to remember to start small when you pick the first section that you will improve.
Refactoring is hard.
Make it easier on yourself by starting with some low hanging fruit.
- That POST route that works, but isn’t very pretty.
- That class method that you already kind of know how to detangle.
Anne, an instructor of mine, once told me that the secret to writing good tests (and good code in general) is to just get started.
Write Some Pseudocode.
Photo by Campaign Creators on Unsplash
You’ve got your soon-to-be-awesome function all picked out, and now it is time to write some pseudocode for it.
The secret to writing good pseudocode is to write something that you will understand as a programmer and that non-technical stakeholders will also get.
- Use indentation and whitespace effectively to mimic code spacing while keeping your pseudocode in plain English.
- Try using variable names. If you do, name them semantically (in plain English and with purpose) and use them consistently throughout your pseudocode.
- Use code-like terms to help explain what you might do at each step. Instead of writing for i in range(word_list), write loop over the word_list until you get to the end.
Write your pseudocode so that you can show it to him. It doesn’t have to be exactly down to his level, but make it somewhat accessible.
Even if you don’t have non-technical people involved, writing to this level will help keep the pseudocode friendly as a reference point for your conversations your future self and with other developers.
Write New Tests or Perfect your Existing Ones.
Photo by John Schnobrich on Unsplash
It is time to write some code!
This guide is following the principles of Test Driven Development or TDD. If you prefer to code first and test later, you can do this step last.
If you’re starting from scratch with your tests, you’ll want to start by writing some unit tests.
Testing varies from language to language, so look up the guide for your preferred testing framework and follow proper conventions.
Once you’ve gotten some basic tests written, or if you’ve already got tests written for this class or function, then review your tests for the following:
- Does my test cover every possible outcome? e.g. Every condition in a conditional statement; every button that the user can click, etc.
- Is my test readable? Understandable? Does it need comments that explain its aim?
Write Better Code.
Photo by Markus Spiske on Unsplash
You’ve got a plan, you’ve written pseudocode and you’ve got working tests that are descriptive and small in scope.
Now it is time to make your code more functional, readable and performant.
Some things to look out for as your improve your code:
- Reduce complexity. If you have highly nested and complex code, make sure that any nesting is truly necessary. You can often reduce cyclomatic complexity by drawing diagrams.
- Add comments to explain complex portions of your code. Use those comments to explain the goal of each line of code and the expected outcome, if applicable.
- Rename variables to be more semantic. Using variable names like i and x have their place, but generally they don’t help with code readability.
- Break up you code. Cheeky one-liners can be nice in a pinch, but they tend to reduce the readability of your code. Consider breaking multiple function calls apart and using more variables throughout your code.
Work With Others.
Two heads are better than one. Photo by Kobu Agency on Unsplash
Once you’ve got something that you think is passable, you’re not done!
It is time to share your code with other programmers. This can also be done alongside the other steps in this process.
One of the most powerful tools out there is pair programming. This is when you sit side by side with another coder: one of you tells the other what to do (the navigator) and the other (the driver) types into the IDE (Independent Development Environment). The idea is to pass these roles back and forth every 10 minutes or so to increase the flow of ideas.
Pair programming can increase efficiency and productivity and also reduce errors. If you’d like to know a little bit more about pair programming, click here.
If don’t have the option of pair programming or cannot because of scheduling and time constraints, ask for code review from a colleague, a programmer friend or a classmate.
Any input from another person who understands your code will help to improve it. Getting feedback is a vitally important step.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
