The code represents the detail of the requirements and the details cannot be ignored or abstracted. We may create languages that are closer to the requirements. We can create tools that help us parse and assemble those requirements into formal structures. But we will never eliminate necessary precision.
Code reviews are a critical part of ensuring code quality, maintainability, and adherence to best practices. The goal of this guide is to provide a structured approach to reviewing code effectively.
These tips are not strict rules but rather a helpful framework to focus your review efforts. They aim to ensure that the code is functional, scalable, and easy to understand, while also aligning with the team’s architectural standards and project requirements.
Tip
A key goal of these reviews is to establish a consistent coding culture where all team members write and review code in line with shared expectations. By defining these standards, we can:
In most of our codebases we should use a library to log. When we do, it is useful to adhere to a standardised logging practice when using this library to make it easier to understand, query and analyse logs. This standardisation involves using two main parameters: message and data. The message parameter is structured to include the class name, method, and an optional error description, while the data parameter contains valuable information that aids in troubleshooting and analysis.
To implement a logging library that fits within our standard practices, we need it to support multiple log levels (such as INFO, WARN, and ERROR) and accept two key arguments: a message and a data object. Here's a breakdown of these requirements:
- Log Levels: The library should allow us to easily categorize log entries based on their severity (e.g.,
INFO,WARN,ERROR), helping us prioritize which logs need immediate attention and which are s
Book by Mark Seemann and Steven van Deursen
This document serves as a distilled summary of the book, tailored for a Node.js and TypeScript context.
Note
At the end of this summary, you will find section How We Do DI at Tactile which outlines our approach to Dependency Injection together with Clean Code and Unit Testing.
The book explores the core concepts of dependency injection, emphasising its role in promoting loose coupling, testability, and adherence to SOLID principles. It covers foundational DI patterns, anti-patterns, and advanced practices like Pure DI, lifetime management and Cross-Cutting Concerns with Aspect Oriented Programming.
Is it correct to say that interfaces have ownership? Not really, instead, we should think of interfaces as contracts, expectations of behaviors or how data structures should look/be used. Interfaces are a way to ensure consistency across different implementations.
What are the main benefits that we are looking for when using Interfaces?
- Abstraction: Hide the implementation details from the consumer.
- Low Coupling: Reduce dependencies between classes.
- Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Single Responsibility Principle (SRP): Interfaces allow different parts of the application to be modularized and responsible for a single purpose.