Recently I joined a team working on several Angular projects (products of the same company) and my first task was to review the code on the development branch. I’m not yet sure if I’m allowed to share details, or even the name of the client (with NDA’s and all that, you know how it goes), but maybe at a later date. Until then, I’ll stick to the subject of this post, the Angular code review checklist.
This is not the first time I was given this task at the start of a new job. Maybe it’s their way of assessing my actual on-the-field technical experience and my attention to details, or maybe they just needed to keep me busy and out of their way until the upcoming release :)).
Nevertheless, I took it very seriously and did the review and while I was doing it, I remembered this is not the first time I’ve been tasked with this when joining a new project, therefor I’m definitely not be the only one receiving this task, so I wrote up a three part list and posted it on Git Gist and I’ve embedded it below.
I keep having the feeling that I forgot some checks. Don’t you? Let me know what you think is missing from the list.
The code review results?
As expected. We’re talking about brilliant, very experienced engineers. So, naturally, I didn’t find anything major during the review. It’s properly implemented and well documented.
Ah, actually I saw one thing, that I can’t say it’s a flaw. They don’t use lazy loading for modules. In fact there are no secondary modules, only the main one – app.module.ts. That can also be because it’s a small, single purpose project.
Is that a problem if the project is small and loads fast? it’s not like it needs lazy loading.
Other than that, I could only find some minor coding style differences from what I’m used to, but just because I’m not used to this style it doesn’t mean it’s a flaw. Maybe my way is flawed.