TL;DR style notes from articles I read today.
Refactoring is about features
- Always refactor in the service of a feature.
- Find code that is frequently being worked on. Try to refactor that code.
- It seems faster to write a new feature in a complex system than to refactor the old system first and then add the new feature. But the overall time that you would spend debugging, rolling back releases, sending out bug fixes, writing tests for complex systems will be lesser of you refactor first.
- Pick a feature that you want to implement, and figure out what you could refactor that would make it easier to implement it.
- Set boundaries around your code. Eg: “I’m not going to refactor anything outside of my project to get this feature done.”
- “There is no perfect design, there is only a better design.” So, avoid over-engineering or spending too much time on figuring out how to refactor something.
Full post here, 10 mins read
Five habits that help code quality
- Write unit tests to save you from regression bugs. Unit tests also force you to write code that is less tightly coupled and more logically factored.
- Keep coupling to a minimum.
- Apply the Principle of Least Astonishment - design components of your system in a way that they behave how people using your system expect them to behave.
- Minimise cyclomatic complexity - number of independent paths through a given piece of code.
- Write clear, unambiguous, self-explanatory names to minimise confusion.
Full post here, 6 mins read
Happy customers, quality code: the new trends in software development
Results from Atlassian’s research with 500 software developers & IT professionals, conducted at the beginning of 2019.
- It takes an average of 3.3 different tools to know the real status of the project and teams use an average of 4.3 tools to move code from development to production.
- 71% of software & IT teams who use a microservices structure believe it’s easier to test or deploy features.
- 57% developers reported fewer bugs or outages by adopting CI/CD solutions.
- Feature flagging reduces risks while rolling out features to customers. 63% developers who use feature flagging reported better testing of features or higher quality software.
- Outcome-driven development is shifting the focus away from feature delivery speed to the customer value features creates.
Full post here, 4 mins read
Top comments (3)
This is incredibly true. I've only been going at this for a short time, but in my short time as a developer I've already experienced having to refactor something after the fact and it took me nearly twice as long. Not only did I have to refactor whatever code the new feature depended on, I also had to refactor the actual feature. Had I done the refactor first, I could have simply build on top of that work and I wouldn't have to be in that mess.
I've tried to refactor first ever since.
Yeah, it's always best to refactor first (if possible). In my experience, refactoring really helps clarify how to approach a new feature -- quite often, the approach just kind of 'falls out' during the refactoring process.
Absolute gold :) Thank you for the post