The Unwritten Laws of Code Reviews: Lessons Learned the Hard Way

When I first got into the habit of reviewing code, I thought I had it figured out. After all, code reviews are just about making sure things work, right?

How little did I know how wrong I was.

My attitude to code reviews wasn't just inefficient, it was damaging: it irritated colleagues, fomented resentment, and delayed feature launches, all for failing to stick to some really simple yet powerful unwritten rules of code reviews.

Here are the 4 rules I learned the hard way:

1. Block a PR Only If It Requires Your Approval

We've all been there: you click "Request Changes" because something seems off, or you don't like some implementation detail. It sounds harmless-after all, it's just a request, right?

Wrong.

Where you "request changes," that action often halts the entire process. And let's be real: there's a reason it's written in red.

So unless the change being requested is literally the only thing preventing you from advance with a bug or security vulnerability or something imperative, don't block the pull request. 

Suggestions are well and good, but over-zealously blocking PRs gets in the way of frustrating your peers and slowing them down.

2. Show Don't Tell

I have no idea how much time I wasted typing away explaining changes with long paragraphs when a code snippet would do.

Instead of writing "You should refactor this section to be more DRY," you can simply write the refactored code and paste it in the comments. It's quicker and easier, and helps the developer understand your point straight away. Code is the common language we all understand, so use it to your advantage.

3. Give Critical Feedback In Person (or Via a Slack Huddle)

There is nothing worse than getting back a five-paragraph essay tearing your code apart. Code review platforms are great for comments, but can often strip out much of the nuance that a conversation provides.

If you need to provide critical or serious feedback, it's best to talk about it in person or through a quick Slack huddle. That way, it's much easier to convey your tone and avoid misunderstanding. Moreover, with a direct yet respectful conversation, you are less likely to bruise an ego. 

4. Review the Big Picture First

It's tempting to dive into the details-after all, nitpicking code is what we love doing! But before you get into the small stuff, take a step back. Look at the high-level changes:

• Are there any API changes?
• Is the database schema being modified?
• Do the changes impact overall architecture?

Focusing on the big-picture stuff first helps to identify the potential blockers earlier on. As for the small stuff - those minor refactors, naming conventions, or unit tests ,they often can be cleaned up later.

As a matter of fact, those little details could well change based on larger discussions about the big picture anyway.

The Most Important Rule: Everyone Has a "Nit Limit"

Everyone has a limit in terms of how much nitpicking they are willing to tolerate. We all want to improve our code, but we all reach a stage where too much feedback turns into resentment. People won't always be open about their feelings of frustration, and they might not even be aware that it's happening in their brain, but the more nitpicks you do, the less they'll care about your feedback.

So, pick your battles. Don't die on a hill for that one extra line of spacing or whether to use a const instead of a let.

When you approach code review, bring curiosity and empathy. Try to understand why the author decided on one thing over another. Most of all, this holds true if you will be the maintainer of this code later. Instead of "this is wrong," start off by "why." Understanding of trade-offs is key in software development.

Conclusion: Give Helpful, Respectful Feedback and Everyone Wins

Code reviews are about so much more than finding mistakes at the end of the day. It's about collaboration, improvement, and making sure we're all building something maintainable. If done right, code reviews can build trust, solidify team cohesion, and ultimately drive better results for us all.

And don’t forget - always squash your commits.

The Basics of RESTful API Security: A Beginner's Guide

A major portion of the applications in today's digital, networked world has been developed based on the backbone of a RESTful API to pass information between different software systems. As a software developer, security becomes an important thing to take care of. The following beginner's guide will take one through the key concepts of RESTful API security: authentication, authorization, encryption, and data validation.

Understanding RESTful API Security

Since the RESTful APIs are designed to be stateless, the request made by any client to the server must contain complete information to allow the execution of an operation. Designing for API RESTfulness is very convenient, but it also results in some potential risks in terms of security: unauthorized access, breach of data, and manipulation of sensitive information.

1. Authentication: identity of user

Authentication involves verifying the identity of a user or system trying to gain access to an API. An authentication layer is a measure that presents the first line of defence for APIs and strives to lock out ill-intentioned users from making requests against the API.

    Common Authentication Methods:

• API Keys: This is a very simple solution where the client gets a key in particular that he includes in the header of the request. However, not secure at all—in fact, it is very weak—because if unencrypted, this key could easily be intercepted.

• OAuth 2.0: Likely the most implemented protocol, allowing a third-party application to obtain API access for an end-user without supplying credentials. OAuth 2.0 is token-based, so it's way more secure and flexible in how authentication can be done.

• Basic Auth: This is the base64 encoding of a username and password that gets sent with every single request to an API. It should, thus, only be used over HTTPS, as the encoding will easily be decoded if intercepted.

2. Authentication: Access Control

Authorization is the act performed after authentication, which decides what the user who has been authenticated may do. Said differently, once authentication confirms the identity of the user, authorization looks at whether he is authorized to carry out a certain action or access particular data.

    Implementing Authorization:

• Role-Based Access Control: Users are assigned different roles, and the role would include specific permission. A very common example is an admin being able to access all the API endpoints, while a regular user can only have a limited set of actions.

• OAuth 2.0 Scopes: The allowed actions of an Access Token are defined by its scopes. A scope is a constraining of the set of actions that can be performed using an access token. Example: A read-only token to user data.

3. Encryption: Data Protection

 Encryption is an essential tool in data protection, both when it is at rest and when in transit. It surely makes data, which falls into the wrong hands, unreadable.

    Encryption Methods:

• TLS: Data travelling in between the client and server is encrypted. Theoretically, this could prevent an attacker from reading the data by catching it in transit. Always use HTTPS-HTTP over TLS when communicating with APIs.

• End-to-end encryption: data is encrypted on the client side and decrypted only on the server side, hence making it impossible to steal data when intercepted in transit.

4. Data Validation: Ensuring Data Integrity

Validation: The data is checked at the server to ensure that it comes from the client without malicious data and is complete in the right way. This is an important step for validating user inputs against SQL injection and cross-site scripting, among other manipulations.

    Best Practices for Data Validation

• Input validation: Ensure data that is received at the server is validated properly. Validate the type, format, and length of input data. 

• Output Encoding: Encode the output data to prevent injection attacks. This is specifically important if the output data is being pumped back into a web page or in the database query. 

• Schema Validation: Another way they provide validation is in the structure of incoming data with JSON Schema, which ensures conformance to the expected schema. 

Security considerations when using RESTful APIs touch many layers: they start at the beginning with authentication and authorization, go on to encryption, and end with data validation. These basic security practices will allow a person to build strong APIs that protect sensitive data and ensure access to services only for people meant to be using them. As you go deeper into developing and scaling your APIs, consider adding additional advanced security features, such as rate limiting, whitelisting IPs, and regularly running security audits. A proactive approach to security means you will set the bar high in terms of users' trust in your applications.