Angular – Page 4 – Stephen Adams

Weeknotes #1

I’ve seen a few web developers starting to write up a weekly blog post on what they have been up to throughout the week. As I was enjoying reading these types of posts I thought I’d start writing a weekly update on what’s going on at CGCSoftware.

What Went Well

Work

Still working on a new Ionic 4 application, which hasn’t been released yet, but is getting close to a beta release. The Ionic v4 is really good, we’ve been using it since the beta release and had no issues with it.

Book Writing

Also still working on writing a book on Angular. Writing a book is a big task, and for my first book you really don’t realise how much work there is to creating a book, but it is a great way to dig deep into a subject.
I’m halfway through the first draft of the book, aiming for releasing it soon.

What didn’t go well

Freelance business growth

With working full-time on the Ionic application and writing the Angular book, there hasn’t been anytime to focus on running CGCSoftware.
As a freelancer I need to keep promoting my work in order for getting the next project after this Ionic project ends. This is a constant task you have for running a business.

Following GTD

I’m trying to follow the GTD methodology for both work and personal tasks. I do keep slipping in doing my weekly reviews, which I didn’t do last week.

Articles I’ve Read

Turning Design into Angular Components

Recently I had to take a design and create the Angular components for this design, while working through this problem it made me think about the thought process of how as Angular developers we turn designs into working applications.

When I first looked at the design, it’s a very simple layout of a page, which has a simple form, and a few controls at the bottom of the page. The first thing I thought of was how I would divide up the sections of the page into separate components. I’d create one component for the main page, one for the form, one for the controls at the bottom of the form, then off I went creating components using the CLI.

What I really should have done is looked at the page as a whole, how it works within the application and asked myself some questions before diving into building components.

The types of questions to ask before include:

What is the purpose of the page, what does it do?
What are the inputs and outputs of the page?
How will the possible components of the page pass data to other components?
Is there already a component I can reuse for this design?
What is the teams conventions on how pages should be built? Do they have a preferred way that components should share data?
Is this design actually finalised? If it changes is my approach flexible enough to cope, so if the design does change is there a large amount of work to change the page?

These questions are important, because we need to plan how we are going to build out the pages/views of the applications we build.

There can be times when we as developers are given a design to implement and it at first glance looks so complex that we are not sure where to start, but I think there are a few points we should remember in order to get started.

Iteration – the first attempt doesn’t have to be perfect, you can always iterate on the implementation
Feedback from others – getting feedback from others is important to get their perspective, but you still have to use you original ideas as starting point
There is no perfect way – there are many different ways to create a layout from a design, there are best practices (for efficiency and performance) but trying to hit that perfect approach first time is impossible

Angular is great, it gives us so much out of the box, but it is too easy to just start throwing out components using the Angular CLI, that this few minutes planning of how to turn a design into a set of components can be missed, which may lead to problems later.

2018 Review

Writing a yearly review is not something I normally do, but after speaking to some other independent developers, it seems like it is a good idea, just for yourself to see what you’ve accomplished throughout the year.

What went well in 2018

Well, had another year of solid work, with no long-term breaks between contracts.
I worked on 3 major projects, one Angular project and two Ionic mobile apps.
I actually had my best year financially, bringing in the most I have since I started working for myself, which is very satisfying.

I’ve also managed to work remotely for over half the year, which was one of the goals I had for 2018. I do enjoy working remotely, mainly because I don’t like commuting into London every day, the trains in the UK are rubbish. Unfortunately, I do think I’ll have to go back to London for my next contract, as they will probably want me to work onsite in their offices.

One of my other goals for 2018 was to get work directly, which I managed to do. I found my latest contract through a connection on Twitter, who knew someone looking for an Ionic developer. I contacted them and we arranged a telephone interview and that was that. It turned into a really fun 3-month contract, which is soon to end, but it’s great to see that getting work directly does work.

One of the other ideas I’ve had for 2018 was to start writing a book. I was thinking of ideas and planning to go down the self-publish route, using something like LeanPub, but through a couple of blog post I’ve written on Angular and Ionic I was contacted by Packt Publishing to write a book for them. I started this in October and still have plenty to do. This is one of my main goals for 2019 to get this book completed.

Throughout 2018 I’ve worked with in some great teams, learnt a lot for them all. Each new team I work with I learn new things, new ways of working, new approaches to how people develop.

A lot of these yearly reviews mention how many books they’ve read or how healthy they have been for 2018, but for me, these are just ongoing things. It’s interesting to see some of the books that people have been reading, but I’m not that concerned about how many I may or may not have read.

What didn’t go so well in 2018

I definitely got too caught up in spending too much on content marketing. In 2018 it seemed everyone was releasing a new course or a new book, which is great. I do believe that content marketing is a great way to promote yourself and the work you do. It is something that I plan to do more of myself in 2019, but I did find that I bought a few too many freelancing books or online courses. Many of them I still haven’t read or watched. So I’m planning on not doing that so much, instead just taking what I’ve learnt from the ones I have read or bought and applying that to my business.

I have also found that I did fall back into just contracting instead of running my own business a few times. What I mean by this is, I have been working on a few projects as a development resource, where I get paid to work daily, 9-5 as an extra developer on a project. This is fine, it can pay well and has kept me working for the last few years. But my aim is to change how I work so I can get work directly as a consultant instead of a development resource. Instead, clients will come to me because I can solve a problem they have. This will take time to set up, as I need to be able to show potential clients what problems I can solve for them, prove that I can do this and also have the business skills in place to win these new types of clients. This is a goal of mine for 2019.

So all in all 2018 was a good year for me and my business. Writing out these yearly reviews do help you take stock of what you have achieved, now I need to start planning out my goals for 2019.

Upgrading Your Approach to Angular from AngularJS

When upgrading an AngularJS app to Angular, there are a couple of routes you can take. There’s ngUpgrade, which is the official migration path set out in the Angular docs. There is also ngMigration, a fantastic tool that reviews your existing AngularJS codebase and lists the actions you need to take in order to migrate to Angular. Both ways show you what to do with your codebase in order to get from AngularJS to Angular, but the trickiest part is for developers new to Angular, who may have been working on one large AngularJS application for the last few years and have had no exposure to Angular. Is for them to understand the new approach Angular is taking.

In AngularJS you had scope, controllers, directives and services/factories. In v1.6 components were brought in (though they are really just directives with controllers built on). Now in Angular, you have components, modules, providers, pipes, classes, interfaces (though both features of TypeScript). You have type safety on top of all this.

So for the legacy AngularJS developer, there is a whole mindset shift that needs to happen besides just upgrading the codebase.

They need to know what effect having everything as a component has on the structure of an application. What is the relationship between parent/child components, how is data transferred between parent/child components? How does the module system need to be used? A legacy developer may just add all their components to the single module, creating one large monolithic module. Instead of taking advantage of the module system to break down the application by having feature modules. They need to know about the by feature approach to the folder structure of an application. They need to know about where the common features will go, is there a core folder that contains all the components/providers that aren’t part of a feature?

Another area that legacy AngularJS developers can slip up on is using TypeScript and embracing the type system. It could be far to easy to just set everything with a type of any and not using the benefits that the type system gives you. Like better tooling, picking up spelling errors before running the app, more efficient code that the TypeScript compiler can optimise to make the application run faster.

The advice I’d give if upgrading to Angular

Read the ngUpgrade guide
Read the Angular style guide in order to understand the approach to writing an Angular app
Understand the module system, how to use it to divide up your app
Understand the relationship between parent/child components
Learn at least the basics of TypeScript and creating Types

You can’t go from AngularJS to Angular and expect to use the same approach you had. Angular is so different from AngularJS, that it is not just a case of changing a few JavaScript files to TypeScript. It’s a complete shift in approach to not only writing Angular but developing front-end applications altogether.

This week in Angular

Photo by Mr Cup / Fabien Barral on Unsplash

Here is a list of news stories I’ve found interesting from around the world for the Angular platform.

Apps That Work Natively on the Web and Mobile

From the Angular official blog, we have a post about NativeScript and how you can now, thanks to Schematics in the Angular Cli, share code between desktop and mobile apps.

One codebase for both desktop and mobile, something that is very powerful. Max Lynch from the Ionic team did Tweet at the time that Ionic has been allowing developers to share code between desktop and mobile for a long time.

2 New Tools to help with AngularJS to Angular Migrations

Another story from the official Angular Blog, on two tools that will help to make upgrading from AngularJS to Angular. One tool is a CLI tool called ngMigration. This tool will analyse your application and gives a list of recommended changes you need to make in order to prepare for migration to Angular. This is extremely clever and gives anyone a great starting point when you want to migrate to Angular.

The second tool, is a forum where tips and tricks can be shared on how to migrate to Angular, and a place to ask for help during a migration.

Nrwl Nx 6.3: Faster Testing with Jest

The Nrwl team has just released a new update to NX, now at version 6.3. This release now has support for Jest, the test runner from Facebook. Now with this latest release Jest can be used as the test runner instead of Karma. According to their blog post, the main reason for using Jest over Karma is performance. Jest is fast, but not only that Jest has better reporting, uses Node so no need to link to the browser and Jest has excellent Mocking.

I’ve not used NX as yet, but I can see there is a really need for large scale Angular applications to have fast running tests. With this new release of NX, Nrwl are building an excellent tool for enterprise Angular teams.

RxJs Observables versus Subject

Continuing his brilliant articles on RxJs, Cory Ryan compares the different types of Observables that RxJs provides. Cory has written a number of great articles on RxJs, as well as articles on Tree Shaking in Angular, classes in TypeScript. His blog is a great resource for any Angular developer.

Angular Patterns 3: flexible and scaleable design of complex page

In this article, Adriano di Lauro goes through a set of patterns he has developed over his time developing Angular applications. There are many articles about how to use the latest features of a framework, or how to use a certain library. So it’s good to read, for a change, an article about how someone approaches a problem within Angular. Adriano also has articles on how he organises modules and what considerations to have when writing reusable components.

There is a lot happening within the Angular eco-system, but these posts I found really interesting.

The Business Case for Unit Tests

Recently I read this great article on the DZone website called The Business Case for Unit Testing by Erik Dietrich In this article, he sets out six reasons why Unit Tests should be considered as a serious business need and what benefits they bring to a business.

Two of the points Erik makes I feel are extremely important as to why Unit Tests are so a crucial part of an application. One, The Test Suite Reduces Deployment Risks, by having a good set of tests that can be run when the application is about to be deployed. There is less risk that issues will occur during this deployment phase, making the application deployment smoother and getting the application to your users quicker.

How do Unit Tests Reduce Deployment Risks?

As an application is being developed, your development team will continue to write test, this leads to greater test coverage of the application.
When it comes to making a deployment to your users, having this large set of tests, which can be run before each deployment, there is more chance that any bugs that have crept into the application will be found before the application is deployed to the end-user.
Within your release process, you can have all the unit tests be run automatically. If any tests fail, the deployment of the application will be stopped. Then the team can look at what caused the test to fail, and fix this issue.
Having these issues caught before the application is deployed to the end-user, means that they will have confidence in using the application. You also as a business owner can have confidence that your application is being released to your paying customers, with the application being thoroughly tested.

The second great point that Erik made was Tighter Feedback Loop for Time Savings. In this section, Erik makes the point that having Unit Tests improves the feedback loop that developers use to see if errors are appearing in their code.

What is this Feedback Loop?

This feedback loop that Erik mentions is where the developer is given feedback straight away if there is a problem in their code, it’s not doing what it should be doing, the code is not fulfilling the requirements that have been set out in the user story.
For example, if you have an Angular based business application, that has the requirement that when the user clicks on the Login button, the application should open a login panel.
So the developer builds the Login section and adds a Login button that loads the Login section. As part of this, they need to check that the user is not already logged in. Now in their code, they could have a function which clears any current login sessions. This code could have a bug in it where it fails to clear all the logged in sessions. So being a good Angular developer, they write a Unit Test that checks for the list of login sessions, and confirms that this list is 0 when the Login button has been clicked (this confirms that when the user clicks Login, any previous logins have been cleared so they never see someone else account details).
Now 6 months later a new requirement has come in that the Login process needs to write to a database when the login was made so a report can be produced to show user logins. As part of adding this new functionality the clear logins code gets amended and a bug is introduced. It looks like its still working, but the login sessions aren’t being cleared.
Without a Unit Test to check that the functionality of the code still works as expected, this bug could get through to the paying customer, causing major problems.
With the developer using Unit Tests, they would get feedback straight away that the changes they are making to this Login process have caused this new bug. They will fix the issue even before it goes any further.
As Erik says, A unit test suite makes you much more likely to catch errors sooner than later. It does this by tightening the feedback loop. so with a good test suite in place, you’re far less likely to spend disproportionate amounts of time tracking down, reproducing, and fixing issues and the code you’ve built on top of them.
Reducing this time tracking, reproducing and fixing issues, saves money and gets the application out to the customer sooner than later.

Unit Tests are important to a project, especially a long-term business critical application. They have a real benefit to the business and are not something a developer is just ‘wasting’ time with.

The full article by Erik has some really good points and is well worth reading, whether you are a developer or a project manager of a business owner.

Why you should allow developers to write tests for existing code

Is it possible to add Unit Tests to an existing application and if you do decide to add tests to a project, what benefit will this have to an existing application?

I’ve worked on a few projects where the application has been started, the first few features of the app come to life and before the developers realise the application is nearly delivered to the end user, without any Unit Test coverage.
One of the main reasons for this is when an application is started there is usually a tight deadline, or a push to get something out to the end user within the first sprint and there isn’t time considered for the writing of tests. The unit test theory is that a test should be written before any code is written, but with time pressures writing tests is always something ‘we can do later’.

But can unit tests be added to existing code? And what benefit will this bring?

It is possible to write tests for existing code, it is, in fact, a good practice to go through this process for a number of reasons.

It provides confidence that new changes do not break what is already there

First, it stabilises the codebase of the application, providing confidence that any further changes are not going to break the existing code. Once tests have been written for the existing code, developers know that there is a quick way to check if the new feature they are adding is not breaking what is there already. As they go through developing this new feature having the test runner going in the background running all the tests the developer will see straight away if the change they are making is stopping existing code from working as it did before. They will get a red warning, telling them exactly what is no longer work and why.

It highlights areas to developers where code can be improved

The second reason is when writing tests for existing code developers will notice areas where the code can be improved, optimised. When writing a test you need to know exactly what the code you are testing is doing and how it works. Through this investigation, developers will see ways it can be refactored to make improvements. Once this code has been refactored and improved the test will ensure that any further changes don’t break this improved codebase.

Its a great way to onboard new developers to a team

Another reason that allowing your developers to write tests on existing code is it is an excellent way for new developers to a project really understand how an application works. If for example, you have a large enterprise business application, that has many business rules. It can take a new developer to the team to both understand the business rules, but also understand how the application currently supports these rules. If for their first few weeks on a project they are given the task to write the tests for a certain section of the application, maybe an API the application provides or a set of services that the application uses to process user orders. Through writing tests, the new team member will learn, in depth, how the current application works. They will also be involved in how the application is built, deployed, how the processes the team has for committing code, what rules there are in place for writing code. All this they can do through writing tests without affecting the code of the application.

How can tests be added to your existing project?

If you are a project manager or the business owner of an application and your team have said that the Unit Test coverage for the application needs to be improved. There are some things you can do to help this.

Writing tests should be defined as Sprint stories

You don’t need to stop development on new features just to have your team write all the unit tests for the application. This can still continue, but you need to add time to each sprint (if that’s the method you use) to allow the developers time to write tests for part of the application. When it comes to sprint planning have a few stories for writing tests. Prioritise areas of the application where test coverage is low, maybe focus on areas that are more stable, an existing API for example or the data model which isn’t going to change for a while. Assign these write tests user stories to the newer members of the team, so all they can go through all the development processes the team uses.

Improving test coverage can be a gradual process

The existing application doesn’t need to have 100% code coverage straight away. It’s better to add tests gradually as the project progresses, tests can be bought in for existing code. This does mean there is a risk that changes could break another piece of existing code, but if the tests are being written this risk will get less and less the more coverage your application has.

Allow your developers to write tests

When you are planning some work with the team, a new feature to be added. Allow time in estimates for the developers to write tests. If this time is not in the estimates developers will find that they don’t have enough time to not only write the new feature and write the tests. So the tests will start to be left, this will cause the test coverage to reduce over time and you’ll be back to where you were before, with an application that has a lot of functionality and existing code, that isn’t covered by tests.

Your QA team and clients will thank you

Finally, an application that has a higher test coverage, will have fewer bugs. New features won’t cause new bugs to appear in the existing application.
This makes the QA team happy, for them it means that they can be confident that what is already in the application still works as before. They don’t need to thoroughly test the entire application every time there is a release. They can quickly test the existing application and then focus on testing the new features. Any bugs that crop up should be caught by the developers during the development phase when they have their test runner quietly running along as they write code and then warning them as soon as any issues come up. Instead of the QA team raising a new bug.
Having the QA team raise these minor bugs which could have been caught by unit tests, takes time. It adds delays to the latest release of the code being allowed out to the end user.
So if your end users are waiting for a new feature that will greatly improve their experience of an application and this new feature is delayed due to the release not getting past QA because they have to raise a bug for something that has broken in an existing part of the application. The end user will be disappointed, and a happy end user is what we all want.

Unit test coverage is important, it vastly improves the quality of an application, but if due to time constraints an application has been delivered without a high level of test coverage, it’s not the end of the world. By allowing developers to write tests for the existing code, the coverage will grow over time and the quality of the application can be guaranteed when a new feature is released to your happy users.

Principles of Writing Testable code

I’ve recently been spending time researching into how to write unit tests for an existing codebase. One thing that keeps coming up in the research I’m doing is how important it is to write testable code from the start, but what is testable code?

Well from the research I’ve been doing I found that to write testable code a good approach is following the SOLID principles.

S – Single Responsibility Principle
O – Open/Close Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

So what do these principles mean and how do they apply to Angular?

Single Responsibility Principle is where an Object should do one thing and one thing only. For example in a controller or component you might have a function that loads some data, updates a local array then loads some more data from another source and finally displays this data in the UI. Well, that is four different things this one function is doing. To make this more testable it would be better to have one function that loads and returns data. One function that binds data passed into it to a local array, then another function which loads data from the second source and then finally allowing Angulars data binding to bind the data to the UI.

This means that you have only three separate functions, which can all be tested separately. One test to check the first function loads data correctly, a second test to check that the second function binds any data passed into it to the local array and finally the third test to check that the third function loads the data from the second source as expected.

Open/Close Principle is where a class is Open to extension, but Closed to changed. An example could be a function loads and returns some data. Then as the project continues the requirement for that data is changed as it is now ordered alphabetically. So you go back and amend the function to order the returned data after it has loaded. By doing this you’ve broken this principle. What you should really do it add a new function that calls the first function, then takes the returned data and then the second function performs the ordering of the returned data. This way you have two separate functions, both performing smaller tasks and the first function, which is already tested, has not been changed.

To write a function with this principle in mind, it needs to (in this loading data example) be able to return the loaded data and not just simply bind the returned data to a local variable or array. If the load data function returns the data as it loads it, then this allows other functions to take this returned data and extend what can be done with it.

Liskov Substitution Principle is where a class that uses another class, should be able to accept using another class without it knowing the difference. Within Angular, this means a controller or component may be using a service to load data, but the controller/component knows so little about the service that another service could replace the original one, without any changes needed to the controller/component.

This is an extremely important principle for writing testable code because adhering to this means that external services can be mocked in tests in order to write tests for just the function that uses this service. Through the use of mocking we can write tests that test different scenarios to see how our original function handles various responses from the mocked service.

Interface Segregation Principle this is important because it forces you to write smaller interfaces/classes which are easier to mock in tests. For example having a service that does loading data, aggregating data and ordering data, means that you will need to mock all three different functions in order to test something that is just using the loading data function. Separating it into three separate services means it is easy to mock just the one you need in order to test your code.

Dependency Inversion Principle is where your concretions (the act or process of concreting or becoming substantial; coalescence; solidification) or classes that are set out. Should only depend on classes that are abstractions of functionality. This means if you have a class that does something, like filtering an array. Then anything other classes it needs in order to perform this filtering should be an abstraction of the implementation. For example, with your class/function that filters an array, you may use something like Underscore or Lodash to help with the filtering. When you use Underscore or Lodash’s function you aren’t using the inner workings of the library, but an exposed function that abstracts away the inner workings of the library. So if in a new version of the library the helper function you are using is re-written to make it faster, as far as you are concerned you are still calling the helper function in the same way.

So by writing your code using this principle, you are writing more loosely coupled code, which is easier to test, because you test the individual parts. Parts that know nothing or need to know nothing about the inner workings of each other. This makes mocking for tests easier to do.

Following these principles will help make your code more modular, separated and therefore easier to mock for the tests you are going to write. From the research I’ve been doing the main concept to get in order to write more testable code is, in isolation, meaning writing code that can run in isolation is easier to test. It is easier to mock any dependencies (which there shouldn’t be many) it’s easier to write tests just for that single piece of code. Therefore writing more and more tests leads to an application which has more test coverage going forward.

Here are some links to articles, blog posts I’ve found during my research:

Theory of Uniting Testing in Angular

I recently finished reading through an article on Unit Testing in Angular. The article was from the Infragistics website and in 3 parts it tried to demystify Unit Tests in Angular:

In this article, the author, Jared Fineman, really goes into how to setup your tests, how to structure tests and some of the great new features of Angular, that help with testing. One great point Jared makes is *In the world of development, unit tests have long been viewed as second-class citizens. * This is very true, it is something I have been guilty of too, forgetting that Unit Tests are an extremely important part of the development process. As part of my drive this year to improve the quality of my work, I’m focusing on both Unit Testing and readability, so I need to make writing test a core part of my development process.

In the first part of the article, Jared shows how to set up tests for your project. Though at the time of writing this version 6 of Angular was not released yet. So there is a section about updating the .angular-cli.json file, which has now been replaced by the angular.json file. Then in the other two parts of the article, Jared goes through structuring unit tests and some of the great features that Angular has that allow you to really explore the inner workings of your components. So you can write tests that examine all parts of the component.

The one that struck me in the second part of this article was the approach he mentions for structuring your unit tests. He mentions this AAA approach, which stands for Arrange, Act and Assert. The idea is that you first setup everything needed to run the component that is going to be tested, you basically arrange all the parts needed for the component. This could be modules that need to initialised, other parent components or mock data.
Next is the Act section, this is where you call the method or the component to be tested and from that call, the result can be examined. Finally, there is the Assert phase, where our assertions or expectations are tested.

This AAA methodology is great for learning how to set up tests, it is definitely something that isn’t documented enough in the official Angular docs. If a developer is new to Angular and they want to start writing tests for their app, the Angular docs do give a detailed overview of how to write a test for different scenarios. The new Angular docs really give a lot of examples, how to test components, how to test the DOM, how to test services and providers, but the theory of unit testing is not discussed enough in the documentation (but the Angular docs is open source, so maybe that can be changed).

There is, of course, articles about AAA outside of Angular, here are a few I found, though they are C# based the theory still applies:

There are a lot of articles about the Theory of Unit Testing, just not all Angular specific. It is worth searching around for them. This article from Jared Fineman is a great start.

When enough is enough,

There is a time when writing code that you need to say to yourself, enough is enough. I’m not talking about giving up coding, what I’m talking about is when you’ve been adding so many features to a section, that the code is unmanageable. There is a point where cramming in another feature to a section, means that the code behind will need to be re-written in order to make it easier to read, easier to manage and easier to test.

One of the big problems with AnglarJS, when it first became popular was developers didn’t know the best practices for how to write good clean AngularJS applications. The main problem was with the controller. The controller is a great concept, having a JavaScript file that sits behind your HTML template, which has access to all the elements in the template was amazing, but soon developers started to go crazy writing everything in one controller, at the time there wasn’t a ‘style guide’ that showed us a better way. Slowly over time, better practices were shared in the community, there were more examples of how to structure our AngularJS apps.

Recently I’ve had to work with an AngularJS project that has a controller where the structure of the controller has become unmanageable. Currently, the file has over 1200 lines of code, it is full of functions all doing different things, nothing grouped together in a logical structure, the use of both $scope and VM models is throughout the file instead of using one approach consistently. It is hard to work with this controller, and it is important of the functionality of the application.

Now I can see how this controller has gotten into this situation. It’s clear that at the beginning of the development this core piece of functionality that the controller manages was not fully planned. So the developer probably thought, this section doesn’t have a great deal of functionality I can keep it all within one controller.
Soon the features for this section grew and became more and more complex, the demand to get them delivered also grew, so the time for refactoring was not available. Now we are in a situation when we have a 1200 line controller that is hard to work with, nearly impossible to add new features too and is still buggy.

In order to stop this type of situation, developers need to be able to say to the PMs and stakeholders of a project, that they need to spend some time, refactoring the existing code in order to make it so new features can be added easily.

When a team successfully uses Scrum there is this time to raise issues like this, to let the PMs know that a bit of time is needed in order to tidy up the code before tackling a new feature. As part of the standard sprint planning, this can be raised. Without it the team just keep ploughing on building onto of existing code, adding feature after feature until everything is nearly unmanageable.

So what can developers and teams do in order to stop this happening:

Have regular sprint planning meetings to discuss the work coming up and not keep ploughing along without reviewing
Set out from the beginning a style guide, how the team will approach the development of the application
In PR reviews, don’t just have a quick look over the code and accept it, discuss with the developer if there are problems or code smells and how they can restructure their code to avoid these types issues later
Teach the more junior developers good practices on structuring code
Tell the managers and stakeholders why having good code quality is important to their project, why cutting corners, will only come back to haunt a project later on