H4H

Cypress Testing

I was brought into to H4H to lead the end to end UI tests on the frontend using cypress. Their QA team was busy with business as usual and where not able to take on the work. They also had more expertise in selenium than in more modern test frameworks and drivers such as Cypress.

I worked on this for a couple of weeks. Auditing their code base setting up a basic test structure and writing up a specification on how we where going to run it on Github Actions.

It however became quickly clear that the tests where not going to be possible with the current code base. For the following reasons

• Complex web of dependency injections making it hard to mock anything out.

• Slow page speed. topping out at 8 seconds to load a view for the more complex pages.

• Each feature team was writing code in a different way.

This resulted in tests failing all the time unless we wanted to up the timeout on the tests, which would be a super bad pattern and cost loads in GitHub credits.

It became clear that the code needed to be refactored.

Tech Debt & Team Autonomy

Once we had identified this, I then joined the Agenda feature team to help out with development and start planning out the refactor with that team as a proof of concept.

I conducted a series of informal conversations with the existing frontend team. Being introduced across the teams as i went. To identify the main thing that was effecting them in terms of react.

It was as is usually the case. No time to handle tech debt. As Feature development was always Prioritized. At this point i started a conversation with the product and business team to find a way we can balance out the need for active development with tech debt.

The main blocker was trying to add the tech debt to the sprint. As it was more technical, it was hard to justify to the wider team. As such we agreed to have two days of gap between sprints to allow the dev team to handle the tech debt.

We also decided to handled outside product ops. We instead used GitHub issues and discussions to raise concerns and provide a space where people could discuss patterns, improvements or questions. This gave the tech team the autonomy they needed to reduce the amount of tech debt step by step.

Mapping the Refactor

Once we had that in place it was a case of mapping out what needed to be refactored, where & what needed to be done.

After many many conversations I made a visual map to guide all stakeholders in where we needed to put the effort. You can see this below.

Simplifying the Frontend Architecture

The Refactor primarily involved changing the patterns we where using on the frontend, reworking the mental model and removing a lot of spaghetti dependency injections.

We also had very little in the way of presentation logic outside of the store. Leading to the sluggish performance as every reactive property on the page was pushed through the very bloated store.

There was also a lot we could do to improve the model structure. we had multiple classes and constants across multiple directories.

• Move constants & classes into a single Model schema. Pulled from source API swagger docs generated by the backend team

• Replace Vuex with Pinia

• Move a large portion of the presentation login into the component. Its fine to have some logic in the template, provided its related to that views presentation.

• Refactor the multiple nested views into a pages directory that follows the URL structure of the site. Users can also navigate directly to the save form via URL which they could not before.

• The page views are where the store data is hooked up. Not in the components that must remain as only functional never fetching data.

• Pull tables & forms up into a new higher order function that allows them to call the store directly; benefiting largely DevX as the same form could be used across the application.

🔥 I demonstrated this new architecture by refactoring one of the existing views. Then deploying it on a preview branch. The performance was clear and all stakeholders agreed to move forward.

Original Page Speed: ~8 seconds
After the refactor: ~800ms 💪

Frontend Developer Docs

After having the above signed off on, we moved to turn all the discussions regarding tech debt from GitHub. A workflow we had already set up prior to the refactor. Turning these into meetings and workshops to flesh out our frontend developer guide.

This gave Developers an equal say in how the code was written and finally aligned the feature teams on one set of patterns and guides.

Balancing Feature Development & the Refactor

With all the above in hand I worked across the rest of the two year contract managing the roadmap for the refactor. Inline with the new feature development needed for the customer base. Along side repeating audit reviews of our tech debt and error reports from our AMP tool. This was rotating giving each frontend developer the wheel and the space to drive change.

Vladimir Velkovski
Lead Frontend Engineer @ H4h

Max is an exceptional senior frontend developer who has made a significant impact on our team. In his role, he took on the responsibility of refactoring specific parts of our codebase and introducing new patterns to improve the performance and user experience of our application.
Max's technical expertise and attention to detail were evident in his work. He brought fresh ideas and innovative solutions to the table, and was always willing to go above and beyond to ensure our application was of the highest quality.

He has excellent communication skills and is always willing to share his knowledge and provide valuable insights to help the team make informed decisions.

I highly recommend Max for any frontend development role. His passion for excellence, technical proficiency, and ability to work collaboratively makes him a valuable asset to any team.

Julia Makhmoudova MBA
COO @ H4H
I'm pleased to provide my sincere recommendation for Max as a highly positive and knowledgeable Front End Developer. Max possesses a clear vision for how projects should be developed and has a remarkable ability to comprehend the complexity of challenging tasks, providing well-supported proposals to address them.

What stands out about Max is his proficiency in understanding and applying front-end patterns. He stays up-to-date on the latest trends and technologies, and utilizes his knowledge to enhance the functionality and aesthetics of projects. Additionally, Max is capable of explaining complex topics in an understandable manner, a skill that is invaluable to the team and shareholders.