3.1. Flexibility - the most important property of code

Project Lifecycle

Why do I describe creation and development separately?

If you quickly created a system that then requires days of refactoring to add a new feature NOT meeting the original requirements, then your system is low quality (inflexible).

But how can we achieve flexibility?

"Artificial complexity" can be eliminated if we abandon abstractions, groupings, and non-obvious behavior.

How to practically "abandon abstractions, groupings, and non-obvious behavior"

• Don't try to abstract away from infrastructure without rock-solid reasons. If you're using a specific library/DB/MQ/etc., don't try to create additional interfaces on top of them; use them in the code where you need them.

// # Instead of creating abstract repositories
const changeUserEmail = async (userRepostoty: UserRepository, req: { email: string }) => {
	const user = await userRepository.getByEmail(req.email)
	// ...
}

// # Use the adapter call directly in the code
// or the query language itself (e.g., SQL)
const registerUser = async (pg: PgConnection, req: { email: string }) => {
	const user = await pg.table(UserTableName).where({ email: req.email })
	// ...
}

• Models should look exactly as they are stored in the DB. If a model doesn't contain another model (e.g., as a PostgreSQL jsonb field or MongoDB nested document), don't nest them in the structure description (just add the exact fields present in the DB), as is common in many ORMs.Describe all entities exactly as they appear in the DB.

// # If you have PostgreSQL, for example, instead of:
type Profile = {
	id: string
	user: User
}

// # write it exactly as in the DB
type Profile = {
	id: string
	user_id: string // Because it's not a whole user as jsonb, but just a reference to the table
}

• Don't use additional dependency management mechanics. To pass dependencies in code, you have function arguments/class constructor; use them without additional magic like IoC.

• Minimize side-effects and non-obvious behavior. For example, there are features like preSave, postInsert, preUpdate hooks - everything that happens inside them is completely non-obvious to a developer who hasn't read their contents.This will 100% sooner or later lead to very difficult-to-track bugs and problems in setting up new developers. It would be enough to simply create functions that handle creating/changing the model and call them, which would allow you to clearly see what happens when this function is called.

• Separate everything completely. This is a complex thought, but consider: if you divide your code into UserController and ProfileController, and then a method appears that relates to both, where will you put it?All subsequent logic will depend heavily on this decision.It's worse when this happens with three entities at once. Therefore, instead of trying to divide methods into groupings, write each method separately from each other, like: UpdateUserData, SetEmailOnProfile, DeleteUserAndProfile, and so on.

// # Instead of
const ProfileController = {
	setEmail: (req: Request) => {},
	deleteUserAndProfile: (req: Request) => {},
}

// # Separate into individual handlers
const SetProfileEmail = (req: Request) => {}

const DeleteUserAndProfile = (req: Request) => {}

"Where am I creating abstractions with my code, grouping logic, or executing code without explicitly declaring it?" - find these places and get rid of them.

What's next?