4 Development Resolutions to Kick Off the New Year

2018 is here. It’s time we set our sights on some goals for the New Year.

Everyone has personal resolutions to aim for (or recycle from last year). Whether that includes going to the gym more often or finding a way to give back to the community, resolutions are a way to reset in the New Year and improve as individuals.

For software developers, the New Year is about getting back to basics. These resolutions won’t change any developers’ lives overnight, but they are important reminders of what it takes to make the best software possible in fast-charging environments.

1. Keep code simple and clean

It can be so easy to pick up bad habits. You fall into a rhythm, maybe get a bit complacent and then, seemingly out of nowhere, your code becomes practically illegible. Of course, the problem didn’t come out of nowhere; it was a steady build.

Most code should be self-explanatory and not need documentation that won’t get updated as the code changes. Naming conventions are an essential step in keeping code clean. Naming is easy to do, but hard to do right. Conventions should be consistent, easily understandable, and should avoid abbreviations. Language is important throughout code, not just when it comes to naming conventions. Code should be expressive, using constructs like interfaces and traits. Standards are the key to keeping code simple and clean. Follow the standards your team has set – code becomes easy to understand when everyone follows the same guidelines.

Write simple and clean code … your teammates will thank you for it.

2. Stick to SOLID

Talk about keeping code simple and clean: the five best practices that make up SOLID keep code understandable and easy to maintain. Follow the SOLID guidelines to ensure you’re keeping up with industry best practices.

Single Responsibility Principle: A class should have one and only one reason to change, meaning that a class should have only one job.
Open-Closed Principle: Objects or entities should be open for extension, but closed for modification.
Liskov Substitution Principle: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Interface Segregation Principle: Many client-specific interfaces are better than one general-purpose interface.
Dependency Inversion Principle: Entities must depend on abstractions not on concretions.

3. Don’t repeat yourself

This is a helpful hint for software developers looking to adhere to the “S” in the SOLID principles. The DRY principle dictates that repetition in logic should be replaced by abstraction, and duplication in process should be eliminated via automation. It’s important to remember the dangers of repetition because duplicate code adds to technical debt – decreasing the quality of code.

4. Rethink how you’re testing

It’s an all too familiar feeling for software developers when they’re pulled away from development work to focus on testing. Oftentimes, the software they are testing is code they built themselves. Using developers to test software (especially when they helped build it) wastes development resources and leads to missed bug reporting. It’s an inefficient system, but it’s an unfortunate necessity for many businesses that simply don’t have the testing resources needed to test in agile environments.