今日推荐开源项目：《编译器 the-super-tiny-compiler》
今日推荐英文原文：《Is Your Code a Bit Flabby?》
今日推荐开源项目：《编译器 the-super-tiny-compiler》传送门：GitHub链接
推荐理由：编译器，在技术学习中或多或少的都会听说过，但是除非特别情况，很少需要我们真的需要撬开一个编译器去看看它的内部，这也造成了一个假象——编译器似乎难以理解。这个项目用 JS 解释了编译器是如何工作的，它看起来并没有想象中那么困难……
今日推荐英文原文：《Is Your Code a Bit Flabby?》作者：Aphinya Dechalert
原文链接：https://medium.com/better-programming/is-your-code-a-bit-flabby-6ded04a21a84
推荐理由：由于这些可能存在的小问题，定期回头清理代码是必要的
Is Your Code a Bit Flabby?
Dealing with code bloat
Flabby code doesn’t bode well for anyone. In the short term, everything seems fine. We tell ourselves tiny little white lies that we’ll sort it all out later — but we never do.We get sidetracked, sidelined, or switched over to a new project completely. Then we come back to our code and wonder about our life choices at the time.
But what, exactly is, flabby code?
Flabby code is the bloat that we code into our work through patterns and architectural decisions. Sometimes we take shortcuts. Sometimes we ignore our bad habits and tendencies until they compound enough to be a major problem. Sometimes we just do things we shouldn’t be doing because we don’t know any better.
So how do you fix flabby code? How do you train away the flabby pooch that bumps up your final kilobyte size, and turn your app from a heavy and cumbersome thing to a lightweight, superspeedy beauty?
Going on a Code Diet
Flabbiness often occurs when you’ve let yourself go in certain areas of your code. There’s more to it than just cleaning your code up. Sure, you can lint your code to make it shorter and better formatted, but there are some things that linting can’t help you with.Here are some things you can do to help reduce the flab.
Create logical names
Naming things is not exactly rocket science, but many of us still get it wrong. We write long-winded names that end up either being too generic or too specific. Either that or we write things that are so cryptic that three months down the line, we’re convinced that we’re staring at some Egyptian hieroglyphics.Code is the bridge between humans and machines. It is the language we use to communicate and do things with the hardware and intermediary compilers and engines. This means that we need to understand it as well.
Write your function and class names for humans, not as a bunch of acronyms. It only takes one developer and missing documentation to lose all the information associated with it.
Reduce, reuse, recycle
Compact components, functions, and classes generally follow the single-functionality rule. The more functionality and features you have, the harder it is to turn your code into a Lego set.Because as developers, that’s what we do — we create modular code in order for it to be reused again in the future, for whatever purpose. We reduce our bloat by reducing the components down to the bare necessities and recycling the bigger ones down to a better-suited size.
Be flexible like bamboo
Oftentimes, we get too zealous and over-engineer our code. This often creates the issue of long-term rigidity, locking you into a structure that may not suit the trajectory you’re actually on.Sometimes, we try to be so over-flexible that our code turns into a floppy gloop that can’t hold its own weight over time.
Whatever is happening, finding the right balance is akin to scaffolding your app’s architecture with bamboo — a cheap material that can hold immense weight and pressure — over steel frames, which can be harder to modify if plans suddenly change.
To do this, you need to only scope for the current sprint and refactor the architecture as needed in the next iteration. If the foreseeable future is trustworthy and will certainly happen, you can extend the scope of the scaffold and architecture as needed.
It’s better to have a working app than one that’s built to withstand hurricanes and tornadoes. Code will change over time, and the revelations and understanding that come with it will help you create better code in the long run.
Code to the project vibe
There are conventions and suggestions galore on the internet. Everyone has their own opinions on how projects should be structured, named, and coded.Don’t follow them blindly.
Use your judgment wisely and create against the project vibe. You know the trajectory of your project better than someone on the internet telling you what you should be doing.
There are some things that you should take into consideration — like what to do to write clean code, plugins to use, and how to structure things — but you and your team need to balance them with what the actual project needs.
So code to the project’s vibe, not what the internet tells you to do.
Final Thoughts
Code pooch is something that can be slimmed down over time, but it takes good processes and long-term commitment to take effect.Some people call it a technical debt, except technical debt is more symptomatic of a bigger problem. Code bloat is a feature of technical debt, but it’s not the only one.
Code bloat happens when we overthink what our code is. We might be aware of clean, lean, and mean ways to code, but sometimes we get over-excited and end up trying to implement everything all at once.
Save it for your next project.
Figure out what you need and code to the conditions. Don’t over-code your project. Slim your number of lines down by limiting your features and functionality inside a particular block or set of code.
Once you get into the habit of doing that, you’re on your way to having code that’s truly lightweight for its conditions.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
