Check24 is a comparison portal for a very wide range of products and services. The comparison tools are split in different teams for different markets. I was part of the Baufi team, which is the mortgage team.
The best part of working at Check24 was the people I got to interact with. Everyone was willing to help each other and to provide or accept suggestions when it came to solve some issues differently or think about how a feature would best be implemented. Sometimes we just were a rubber duck for a fellow stuck developer. It really is a team I would have enjoyed working with for much longer, the teamwork was real. 10/10 would work with them again.
Here is a very raw but fairly detailed presentation of what the front-end tasks were and what role I took in the team :
- Design, estimation and retrospective in collaboration with the PM / PO and backend dev in a 2-week sprint
- Improvement of various existing application modules:
- Home loan application path, customer area, CRM used by accredited bank agents, online consultation allowing agents to present offers to the customer through screen sharing with interaction, landing pages optimised according to the recommendations of the SEO team
- each new feature or major evolution is developed in VueJS and added to the component library if it is to be used in other projects
- Migration from angularJS to vueJS, new features and refactoring were done in vueJS only
- 1 day per sprint a dev is in charge of consulting the logs of the errors occurring in production and to fix what is our responsibility (the more we got rid of angularJS, the less bugs we had)
- Participation in 2 features teams:
- Search for real estate ads in connection with loan simulation
- search form pre-filled with information from the loan application when it exists
- display of the results returned by BE
- caching of these results so that there are no queries when viewing the detail page
- Property insurance application process in partnership with BNP Paribas (we called it MoPro for Mortgage Protection)
- just-in-time project, no real MVP defined when we started because some things had to be discussed and validated with the partners as we went along
- it is a path of about 9 successive stages, most of which are blocked until the previous ones are validated (with the possibility of returning to certain previous stages but having to redo the intermediate stages)
- some steps require validation by an accredited agent internal to Check24, others by a partner who manages the health aspect of the subscription conditions
- We had kept the rhythm of the 2 weeks sprint essentially to have retrospectives, but in reality we worked more in a just-in-time way which is close to the Kanban method
- Personal emphasis on accessibility:
- restoration of the hover effects which was deleted on all the links and barely visible on a lot of buttons
- development of a tab component adapted to keyboard navigation
- introduction of the topic in the discussions for new features
Life cycle of a ticket
- ticket written by a project manager
- Refinement :
- discussion with project manager and backend dev on feasibility and approach, splitting the ticket if necessary
- estimation in story points
- addition to a future sprint
- dev takes the ticket
- clarify with project manager if necessary
- maturation with another front-end dev (and a back-end dev if the ticket requires collaboration)
- validation of story points and implementation choices
- work work work work work work
- if it's a long ticket, updates with the team during dailies
- build on test server to check if everything is as expected and if bugs seem to occur on an environment closer to production
- pull request -> code review
- build on staging server to be tested by QA team
- if bugs are detected or if an acceptance criterion is not validated, return to dev
- when everything is validated -> deployment to production
Once per sprint there is a "Jour fixe" meeting between frontend devs to discuss things like possible improvements to certain processes.
If we notice a recurring task that can be simplified or automated, or a bug for which we have found a solution that we think is useful for everyone:
- discussion
- update or add to the doc if there is validation of a change
Technical organisation :
- packages library on internal npm server
- css components, view components such as custom input or buttons, more complex components such as tabs ready to host any content or the root component of a feature
- versioning and changelog for each update
- breaking change (major version) -> update of the package, wherever it is used, by the dev who releases the major version to fix bugs that may occur
- storybook of these components with mock data if they are components that expect data from an api
- unit tests with jest
- front consumes api rest done by the back
Technical environment :
VueJS, AngularJS, ES6+, HTML5, CSS3, CSS Modules, sass, Jest, Storybook, api rest, GIT, Gitlab, Jenkins