Posted on

Code review notes

learning the ropes

As always there is a TLDR section highlighted in bold.
These are just my personal notes and some tips and tricks I have picked up from my peers in my current job and naturally very open to any feedback on my topics I post.

Code Reviews


Now, I would normally use the prettier formatter to organize my code, but at my job I was advised not to do that due to some of the code being in a layout that is easier to read and work with. My auto formatter happens to mess it up, so I started to check my code format by eye, which is far from efficient and takes a bit of time ..sometimes. I just felt I had to share why I cannot just use a auto formatter.

Check list

TLDR

  • Use your editor search for console logs and remove ’em
  • Also removed unused code/imports to your project
  • use ESLint and make sure it passes (this is my next post trying to set it up now)
  • Run your unit tests, I’ve had my review approved and be denied by unit tests failing
  • Important make sure your naming conventions make sense so other developers can follow
  • Personally I think it is perfectly fine to leave commented notes on certain methods that are helpful! Such as // This section cleans up the goods and returns so and so
  • Create the PR ( Peer Review/ Merge Request..etc) and go through the comparison. The layout shows exactly where changes have been made and I tend to catch a lot of my syntactical errors at this point.

That’s all I have for now, these tips came from my colleagues and also through my own experiences. Checking is good but checking only once is even better.
Good luck and I hope to hear some comments on this one.

Posted on

[newbie]Dev notes: Basic checklist when starting a feature

As always there is a TLDR. Its been a while and yes everyday i’m still learning so much about myself and yadda yadda lets get on with it.

Thankfully i am blessed to work at a company where ‘Process is King’ (although this can be a good and bad thing…but that’s another story). As part of said process when it comes to stories/features we have a definition of “Ready”, this is a super important concept. This means that all questions have answers and you know as much as you can about the task/feature and there is no blockers or dependencies (i won’t go into detail but that could be anything from does the project actually run locally to do you need an API up for said feature to have you spoke to Big Phil yet?)

Each story/feature normally has its challenges and there are always unknowns and weird surprises…normally they just eat away at your time. These are the things you and the team will need to be concerned about and the developer that will carry this feature will need to make a decision if they are ready or not.

Now for the list , this is in no particular order.
*checklist listed here is credited to my current mentor fyi.

TLDR

  1. Do you have the requirements/BRS/documentation and have you read over the functional specs for the story?
  2. Are there any dependencies?
  3. Does the project I’m working on for this story run on my machine?
  4. Do you have a high level understanding of the story?
  5. Have you thought loosely about an implementation strategy?
  6. Do you have the designs necessary
  7. Is there a chance that you may have left the fridge open?

Overall there is always a lot of things to be aware of. The above list will help in most cases perhaps your project requires more particular checks before you can be “Ready to Dev”.

Of course if you feel that you do not understand the story or feel its too much for you or something on your checklist is not met, you must speak up to your Business Analyst or Project manager. This is super important to not set yourself up for failure.*

I am not saying that this list will take care of all the checks you need, but make a list that makes sense to you. This post is just expressing my opinion based on my experience so i’m happy to adjust my posts if they are not fair or correct….or if i have to add anything else
Have a great day.

Readers contributions

If you want to use the photo it would also be good to check with the artist beforehand in case it is subject to copyright.

Aaren Reggis Sela