Due to the integration with popular versioning tools, code reviews had become very popular. They are absolutely a MUST and should integrate with a team’s existing processes. It not only improves your code quality and helps escape major defects but it also helps developers be more familiar with all aspects of the application. Here is the list of DO’s and DONT’s in the code reviewing process:
|Have at least two reviewers||Do not leave the destiny of the code to just one person. In case that person misses something there is a good chance another person will catch it|
|Take your time to do a code review (and of course be aware that the team is waiting for you to finish it)||Do not rush, finding security and functional bugs is important and your team is relying on you to catch those|
|Make sure that code follows the right design and architectural standards||Do not be afraid or lazy to mention that the code is designed poorly and not according to standards. This is where the mess begins!|
|Make sure you express yourself clearly and correctly when communicating||Do not use slang or abbreviations, some people will not be able to understand it|
|Try to judge the code from the point of view of non-functional requirements. It is better to have a check list of things to check||Do not think that it is not your responsibility to think about other aspects of the code, except functionality|
|If you are new to the team and do not have the domain knowledge about the code, you should ask someone to help you review/explain the code||Make a thorough review every time you review the code. Do not mark it as approved if you do not fully understand it|
|Do long design reviews in person, so your team members can ask questions and get clarifications right away in the same interaction||Commenting a huge piece of code can be messy and inefficient|
|Do your own code review as well||Do not waste other people’s time. By reviewing your code yourself you can get rid of half the defects on your own|
|Keep your comments short and to the point||Do not start writing an article about a better approach that you had done a year ago while cruising over the Atlantic Ocean|
|Try to take breaks between reviewing code||Do not review code for too long in one sitting. You can lose your concentration and miss defects|
|Imagine how the code will work in production. Consider key user workflows and how that code will facilitate/block them||Do not just blindly click Approve button; think wider|
|Pay as much attention to the follow up review as to the original one||Do not think that all your comments will be addressed. Make sure to check fixes thoroughly|
No one can write perfect bug-free code. Issues may slip past you and introduce broken functionality, performance degradation, security bridges, etc. That is why code reviews are crucial and in the end, four eyes are always better than two.
JWT is used for creating access tokens and passing claims between two parties. You should use it whenever you want to pass information from the server to the client in a secure manner. However, JWT is not 100% secure. Everyone still can see the information which is available as part of the token. JWT should be cryptographically signed to ensure that token has not been tampered with (JWS -RFC7515). It can be encrypted to keep sensitive information hidden from the client or third parties (JWE - RFC7516). Or it can be both signed and encrypted.
JWT is mainly used in web applications. JWT can be used to authorize users to services. An authenticated user may receive a JWT that can be passed to downstream services to both identify that user and provide that user’s authorization credentials.
JWT contains three parts (all are base64 encoded), which are separated with dots:
Header is a JSON object which usually contains two parts:
Payload –contains all the necessary data which needs to be sent from the server to the client or vice versa. Information is JSON representation of claims (“key”:”value”). Default keys include the following:
You are not limited to these keys and you add your own custom keys.
Remember! All information in payload is not encrypted and visible to everyone; however client or other third parties cannot modify any information in payload since it will invalidate the entire token.
Signature is a hash of header and payload using a secret. Looks like this and it’s very hard to decrypt in general:
var t = base64Encode(header) + “ . ” + base64Encode(payload);
var signature = base64Encode(t, secret);
More info about JWT can be found here: IETF Trust