今日推荐开源项目：《魔法 magic》
今日推荐英文原文：《Why Rewriting Is Essential for Keeping Software Alive》
今日推荐开源项目：《魔法 magic》传送门：GitHub链接
推荐理由：使用 CSS3 实现的一些特效合集。如果你正好想要学习制作新的特效，或者是寻找为页面上添加特效的灵感的话，这个项目刚好可以满足你的需求。自己写特效不仅可以自给自足的装扮自己的页面，作为对自己学习成果的检验也是一个好选择，毕竟这是直接通过视觉表现出的，兴许也是曾经见过但是完全无法理解的东西，通过自己的学习来实现它能够获得相当的成就感。
今日推荐英文原文：《Why Rewriting Is Essential for Keeping Software Alive》作者：Yoav Kadosh
原文链接：https://medium.com/better-programming/why-code-rewriting-is-essential-for-keeping-software-alive-81c7307e7f6
推荐理由：如果需要，把旧代码彻底铲平而不是加以改造，因为有时改造后会变得更加混乱
Why Rewriting Is Essential for Keeping Software Alive
No matter what management says, you should take time now to save time later
The software industry has changed tremendously over the past decade. One of the things that’s changed the most is the software development process.
That change was triggered by an ongoing increase in the rate at which new user requirements have to be implemented, packaged, and shipped. Instead of waiting a year or more for the next software release, software manufacturers today have monthly, weekly, and even daily (or nightly) releases.
In the past, waterfall was the prevalent software development life cycle (SDLC) model. This process had only one cycle of design and development, after which the software entered a long maintenance stage until it died, making “death” an inherent stage in the process.
TLC understood the problem with that model early on
As the software industry matured, software companies moved towards the incremental/prototyping model, in which the software is designed and developed incrementally, adding more features each time.
This process evolved further with the practice of continuous integration and delivery (CI/CD), to the point where the line between development and maintenance has completely blurred. Software moved from being inanimate to being dynamic.
The software of today is like a living organism. It requires proper nurturing in order to sustain life, and for that, it must maintain a healthy diet. That diet, in my opinion, should be based on one important nutrient: rewrites.
Rewrite
Think of software development as drawing in pencil. If you need to change something you’ve previously drawn, you erase it and draw over it. However, doing so never completely removes the previous pencil marks. There are always some leftovers.In the art world, this phenomenon is referred to as hesitation marks. These marks are visual evidence of the artist’s thought process and are considered by some to be aesthetically pleasing. However, even the most eager proponents of this phenomenon would agree that there’s a limit to what the paper can suffer. There comes a point when you have to start over.
Code refactoring is like pencil erasing
While hesitation marks may be considered an aesthetic pro in the art world, the software development world strives for a more polished appearance.
The equivalent of hesitation marks in the software world is messy, unreadable code (aka spaghetti code), which is often the result of a change in the requirements, just like erasure marks are the result of the artist changing their mind.
The descent into spaghetti-code chaos begins when the customer decides that they want a new feature or a change to an existing one. The customer’s demands are translated into new requirements, and after going through review and design, the developers receive them and it’s time to dig into the code. This occurs very often, and just like in pencil drawing, soon enough the code stops being aesthetically pleasing and becomes one big mess.
Look familiar?
Why Rewrite?
Working with messy code is not much fun. You have to spend a lot of time trying to read and understand it, but you never really do. When you finally decide to touch the code and change something, things tend to break unexpectedly and terribly. The code is no longer maintainable. So where did we go wrong?When developers receive new requirements that diverge from the original set of requirements and cannot be easily supported by the current code, they have two options:
- Refactor the component. Force the code to work with the new requirements by applying a workaround. This is the “quick and dirty” solution.
- Rewrite the component. Write the code from the ground up based on the new requirements and the lessons learned from the old code. This is the “slow and clean” solution.
- Code is a reflection of its requirements. If the set of requirements is rewritten, the code must be rewritten to reflect that.
- Workarounds and partial solutions only delay the problem, they don’t solve it. Eventually, you’ll end up spending time and money on both the workaround and the rewrite.
- Delayed problems tend to grow the more they’re delayed. When you finally realize that you have to rewrite, the effort is much greater than it would have been had you done it before.
- Workarounds make the code harder to read and modify. Unreadable code leads to fragility and increases the chance of introducing new defects.
- Unreadable code also hurts the productivity and motivation of the developers who have to work with it. In extreme cases, it may cause developers to leave a project.
When to Rewrite
There’s a balance to maintain between refactors and rewrites due to their trade-offs in terms of duration and price. You should be prudent when choosing one over the other. The following traits are a good indication that your component is due for a rewrite:- When the code becomes unreadable. This happens after going through several refactors, or perhaps it was poorly written to begin with. Another refactor will only make things worse.
- When the new requirements are diverging too far. The code has been written based on certain assumptions, and now with the new requirements, these assumptions are no longer true. A refactor is not enough in this case.
- When new information opens the path to a better design. Sometimes new requirements give a clearer picture than was available before. This, combined with the lessons learned from the previous implementation, may bring forth an improved solution.
- When new technologies become available. It’s important to stay updated with the latest technologies. This includes using the latest features of your programming language, keeping your third-party packages up to date, and keeping up with the latest trends. It’s important to keep your code fresh, otherwise, it will slowly decay into an unusable state.
How to Rewrite
There are two types of rewrites: internal and external.An internal rewrite changes the internal structure of the component without affecting the component’s exposed API, leaving its dependents unaware of the change.
An external rewrite may or may not change the internal structure of the component, but it will change the component’s exposed API. Such a rewrite affects the component’s dependents, and there are two ways to handle it.
Deprecation and Adoption
This is the method of choice when you have no control over the dependents of your component, or if they are too many to update at once.In this approach, new component and old component coexist until all the dependents using the old component adopt the new component.
The old component receives a deprecation status that can be indicated by its name (i.e. MyComponent will be renamed to DeprecatedMyComponent or DEPRECATED_MyComponent, whatever your convention is) or in the documentation (for example, JSDoc supports the @deprecated keyword).
Dependency/Dependent Modification
This is the method of choice when you have full control over your component’s dependents and there aren’t too many of them to update at once.In this approach, the new component replaces the old component and all the dependents are refactored to use the new one without a deprecation process.
Conclusion
I tried to focus on the case for rewrites since, in my experience, they’re underrated and feared when compared to refactors. Even worse, rewriting is often viewed as an admission of failure by the development team, making them guilty for being unable to write flexible code and predict future requirements.But just as it is impossible for product owners/managers to predict every possible future requirement, it is impossible (and even damaging) for the developers to write their code that way.
That doesn’t mean that there’s no case for refactoring. But the delicate balance between refactoring and rewrites is better maintained when rewrites are equally considered.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
