DEV Community: Gavin Cettolo

The Strategy Pattern in JavaScript: Replace Messy If-Else Logic With Clean Code

Gavin Cettolo — Tue, 14 Apr 2026 07:30:00 +0000

A while ago, I opened a file and immediately knew something was off.

Not because it was broken.
Not because it was complex.

But because it had that shape.

You know the one:

if (...) {
  // something
} else if (...) {
  // something else
} else if (...) {
  // another thing
} else {
  // fallback
}

It worked.

But every time we needed to add a new case, we had to go back into that block and make it just a bit worse.

And that’s when I realized:

This isn’t just messy code. This is a scaling problem.

Let’s fix it.

TL;DR

Long if-else chains are a signal that your logic doesn’t scale well.
The Strategy Pattern helps you encapsulate behaviors and swap them easily.
In JavaScript, you don’t need heavy OOP: functions are often enough.

The Problem: The If-Else Monster
A Real Example: Payment Methods
Why This Doesn’t Scale
Introducing the Strategy Pattern
Step-by-Step Refactoring
Final Result: Clean and Extensible
Using TypeScript for Safer Strategies
Optional: Class-Based Strategy
When to Use (and Not Use) Strategy
Final Thoughts

The Problem: The If-Else Monster

At first, if-else feels fine.

It’s simple.
It’s readable.
It gets the job done.

Until it doesn’t.

The moment your logic starts growing based on types, modes, or variants, things start getting messy.

And more importantly:

every new feature requires modifying existing logic

That’s the real problem.

A Real Example: Payment Methods

Let’s say you’re building a checkout system.

You need to handle multiple payment methods:

credit card
PayPal
bank transfer

A typical implementation might look like this:

function processPayment(method, amount) {
  if (method === "credit-card") {
    console.log("Processing credit card payment:", amount)
    // card logic
  } else if (method === "paypal") {
    console.log("Processing PayPal payment:", amount)
    // paypal logic
  } else if (method === "bank-transfer") {
    console.log("Processing bank transfer:", amount)
    // bank logic
  } else {
    throw new Error("Unsupported payment method")
  }
}

It works, but you can already feel the tension.

Why This Doesn’t Scale

The issue isn’t the code itself.

It’s how it evolves.

Every time you add a new payment method:

you modify this function
you increase its complexity
you risk breaking existing logic

After a few iterations, you end up with:

long functions
duplicated patterns
fragile logic

This is exactly where the Strategy Pattern shines.

Introducing the Strategy Pattern

The idea is simple:

Instead of having one function decide how to do everything,
delegate each behavior to a separate “strategy”.

Each strategy handles one case.

The main function just selects which one to use.

In practice:

replace conditionals with a lookup-based approach

Step-by-Step Refactoring

Let’s improve the previous example step by step.

Step 1: Extract behaviors

function payWithCreditCard(amount) {
  console.log("Processing credit card payment:", amount)
}

function payWithPaypal(amount) {
  console.log("Processing PayPal payment:", amount)
}

function payWithBankTransfer(amount) {
  console.log("Processing bank transfer:", amount)
}

Each function now has a clear responsibility.

Step 2: Create a strategy map

const paymentStrategies = {
  "credit-card": payWithCreditCard,
  "paypal": payWithPaypal,
  "bank-transfer": payWithBankTransfer,
}

This replaces the if-else chain with a simple lookup.

Step 3: Simplify the main function

function processPayment(method, amount) {
  const strategy = paymentStrategies[method]

  if (!strategy) {
    throw new Error("Unsupported payment method")
  }

  strategy(amount)
}

No branching logic.

Just delegation.

Final Result: Clean and Extensible

Now adding a new payment method is straightforward:

function payWithCrypto(amount) {
  console.log("Processing crypto payment:", amount)
}

paymentStrategies["crypto"] = payWithCrypto

No need to modify existing logic.

No risk of breaking unrelated behavior.

👉 This is the real benefit: open for extension, closed for modification

Using TypeScript for Safer Strategies

So far, everything works perfectly in JavaScript.

And thanks to this guard:

if (!strategy) {
  throw new Error("Unsupported payment method")
}

invalid inputs are handled safely.

However, the error is still detected at runtime.

With TypeScript, we can catch the same issue earlier, before the code even runs.

Step 1: Define allowed methods

type PaymentMethod = "credit-card" | "paypal" | "bank-transfer"

Now only valid methods are allowed.

Step 2: Type the strategies

type PaymentStrategy = (amount: number) => void

const paymentStrategies: Record<PaymentMethod, PaymentStrategy> = {
  "credit-card": payWithCreditCard,
  "paypal": payWithPaypal,
  "bank-transfer": payWithBankTransfer,
}

Now TypeScript guarantees:

every method has a strategy
every strategy has the correct signature

Step 3: Type the main function

function processPayment(method: PaymentMethod, amount: number) {
  const strategy = paymentStrategies[method]
  strategy(amount)
}

No need for runtime checks anymore.

Errors are caught at compile time.

Why this matters

With JavaScript, you make your code flexible.
With TypeScript, you make it reliable.

You’re not just cleaning your code.

You’re making invalid states impossible.

Optional: Class-Based Strategy

If you prefer a more OOP-style approach with JavaScript, you can model strategies as classes:

class CreditCardStrategy {
  execute(amount) {
    console.log("Processing credit card payment:", amount)
  }
}

class PayPalStrategy {
  execute(amount) {
    console.log("Processing PayPal payment:", amount)
  }
}

Then use them like this:

const strategies = {
  "credit-card": new CreditCardStrategy(),
  "paypal": new PayPalStrategy(),
}

function processPayment(method, amount) {
  const strategy = strategies[method]

  if (!strategy) {
    throw new Error("Unsupported payment method")
  }

  strategy.execute(amount)
}

It’s more structured, but also more verbose.

In JavaScript, the functional approach is usually enough.

When to Use (and Not Use) Strategy

Use it when:

you have multiple variants of the same behavior
new cases are added frequently
conditionals are growing

Avoid it when:

you only have a couple of simple cases
the logic is unlikely to change
it adds unnecessary complexity

The goal is not to apply patterns, but to solve real problems.

Final Thoughts

The Strategy Pattern isn’t about being clever, it’s about writing code that can grow without becoming fragile.

Most messy if-else chains don’t start messy, they become messy over time and by the time you notice, changing them feels risky.

The good news is:

You don’t need a rewrite, just a better way to organize behavior.

If this helped you:

Leave a ❤️ reaction
Drop a 🦄 unicorn
Share the worst if-else monster you’ve seen

And if you enjoy this kind of content, follow me here on DEV for more.

Code Reviews Without Drama: How Great Teams Give Feedback That Actually Helps

Gavin Cettolo — Tue, 07 Apr 2026 07:30:00 +0000

A few years ago, I left a code review feeling… weird.

The code worked.

Tests were passing.

But the comments?

“This is wrong”

“Bad approach”

“Rewrite this”

No explanation.

No context.

Just judgment.

Nothing was technically incorrect.

But something was off.

That’s when it clicked:

Code reviews aren’t just about code, they’re about communication.

And done poorly, they don’t improve the codebase, they just slowly damage the team.

TL;DR

Great code reviews focus on improving the code, not judging the developer.
The difference is in how feedback is framed, not just what is said.
Healthy teams optimize for clarity, context, and collaboration, not ego.

Why Code Reviews Go Wrong
What Great Code Reviews Actually Do
1. Focus on the Code, Not the Person
2. Explain the Why, Not Just the What
3. Turn Judgments Into Questions
4. Avoid Bike-Shedding
5. Balance Speed and Depth
Real Example: From Harsh to Helpful
How to Handle Receiving Feedback
Practical Team Agreements
Final Thoughts

Why Code Reviews Go Wrong

Most developers don’t want to give bad feedback, but code reviews often become tense anyway.

Why?

Because they sit at the intersection of:

ownership (“this is my code”)
identity (“this reflects my skills”)
time pressure (“we need to ship”)

Add a bit of unclear communication, and things escalate quickly.

What starts as feedback becomes criticism.
What should be collaboration becomes friction.

What Great Code Reviews Actually Do

A good code review doesn’t just catch bugs.

It does three things:

improves the code
shares knowledge
strengthens the team

If one of these is missing, something is off, especially the last one, because a team that avoids reviews or fears them will never move fast in the long run.

1. Focus on the Code, Not the Person

This sounds obvious, but small wording differences matter a lot.

Compare:

This is wrong

This logic might lead to edge cases when the input is empty

The first feels like judgment.
The second feels like collaboration.

A simple shift helps:

👉 describe the problem, not the person

Instead of:

“you did this wrong”

Try:

“this approach could cause issues because…”

It’s a small change, but it completely changes how feedback is received.

2. Explain the Why, Not Just the What

One of the most frustrating things in code reviews is vague feedback.

Refactor this

Why?

What’s the problem?

What’s the goal?

Without context, the comment becomes noise.

Good feedback always answers one question:

Why does this matter?

For example:

This works, but extracting this into a function could make it easier to test and reuse

Now the author understands:

the intent
the benefit
the trade-off

And can make a better decision.

3. Turn Judgments Into Questions

When in doubt, ask.

Questions are powerful because they:

invite discussion
reduce defensiveness
uncover context you might be missing

Instead of:

This is over-engineered

Try:

Do we need this level of abstraction here, or could a simpler approach work?

Same concern.

Completely different outcome.

Sometimes, you’ll even realize the original author had a valid reason.

4. Avoid Bike-Shedding

Not all feedback has the same weight, but many reviews treat everything equally.

You end up with long threads about:

variable names
formatting
personal preferences

While more important issues get less attention.

This is called bike-shedding and it kills productivity.

A simple rule helps:

👉 focus on what impacts:

correctness
readability
maintainability

Leave the rest to:

linters
formatters
team conventions

Your energy is limited, so use it where it matters.

5. Balance Speed and Depth

There’s a tension in every code review:

go deep → better quality
go fast → better velocity

Great teams don’t pick one, they balance both.

Some practical ways:

keep PRs small
review early, not just at the end
avoid “mega reviews” with 1000+ lines

Because the larger the change, the harder it is to review well.

And the easier it is for issues to slip through.

Real Example: From Harsh to Helpful

Let’s take a real-style example.

❌ Harsh

This is messy. Refactor it.

This creates:

confusion
frustration
back-and-forth

✅ Helpful

This works, but it’s a bit hard to follow due to the nested conditions.

What do you think about extracting this part into a separate function? It might make the flow easier to read and test.

Now we have:

context
suggestion
collaboration

Same intent, much better outcome.

How to Handle Receiving Feedback

Giving feedback is only half of the equation.

Receiving it matters just as much.

A few things that help:

assume positive intent
ask for clarification if something is unclear
don’t take comments personally
push back when needed, but with context

A good code review is not about agreeing on everything.

It’s about reaching a better solution together.

Practical Team Agreements

The best teams don’t leave this to chance.

They define how reviews should work.

A few simple agreements can make a big difference:

“Explain the why” is mandatory
Prefer questions over judgments
Focus on high-impact issues first
Keep PRs small and focused
No ego in discussions

These are small rules, but they create a much healthier environment.

Final Thoughts

Code reviews are one of the most powerful tools a team has, but only if they’re done right because bad reviews don’t just slow down development, they create friction, frustration, and eventually silence.

Great reviews do the opposite:

They improve the code.
They spread knowledge.
They build trust.

And in the long run, that’s what makes a team truly fast.

If this resonated with you:

Leave a ❤️ reaction
Drop a 🦄 unicorn
Share the best (or worst) code review you’ve experienced

And if you enjoy this kind of content, follow me here on DEV for more.

Bad Code Is a High-Interest Loan: How Technical Debt Slowly Kills Team Velocity

Gavin Cettolo — Tue, 31 Mar 2026 07:30:00 +0000

We were moving fast.

Features shipped every week.

Stakeholders were happy.

The backlog was finally under control.

Then, almost without noticing, everything slowed down. A feature that should have taken a day took three abd a small change broke something unrelated. Fixing bugs started taking longer than building new features.
And at some point, someone said:

“But this used to be faster, right?”

They weren’t wrong. At some point in the past, things were faster, but that speed came at a cost.

A cost that wasn’t visible at the time.
A cost that quietly accumulated.

This is something I’ve often wanted to explain to non-technical stakeholders:

we didn’t suddenly become slower, we’re just paying back what we borrowed.

TL;DR

Technical debt behaves like a high-interest loan: it feels cheap at first, but becomes expensive over time.
The real problem isn’t having technical debt, it’s letting it compound unmanaged.
Refactoring isn’t a cost, it’s an investment with measurable ROI in team velocity.

The Illusion of Speed
Technical Debt as a Financial Model
Where the Interest Shows Up
The Compounding Effect
When Teams Hit Default
The ROI of Refactoring
When NOT to Refactor
Practical Ways to Manage Technical Debt
Final Thoughts

The Illusion of Speed

Technical debt often starts as a conscious trade-off:

You skip a refactor.
You duplicate a bit of logic.
You hardcode something “just for now”.

And in the moment, it feels like the right decision because:

You move faster.
You deliver sooner.
You hit the deadline.

That’s why it’s so hard to avoid, because it works, but what you’re really doing is borrowing time from your future self and like any loan, that time comes back.

Technical Debt as a Financial Model

One of the most useful ways to think about technical debt is to treat it like an actual financial system.
Not just a metaphor, but a model.

Principal: the shortcut

The principal is the initial shortcut you take:

skipping a proper abstraction
duplicating logic instead of extracting it
shipping a workaround instead of fixing the root cause

Individually, these decisions are often reasonable.

Sometimes even necessary.

Interest: the friction

The interest is what you pay every time you touch that code again. It shows up as:

extra time to understand what’s happening
unexpected side effects
more effort to implement even simple changes

You don’t notice it immediately.

But it’s there, every time.

Compounding: the multiplier

And then comes the real problem: compounding.

Each new feature built on top of messy code increases the cost of the next one.

Not linearly.

Exponentially.

Where the Interest Shows Up

Interest doesn’t arrive as a big, visible cost, it shows up as friction.

Small things that make your work just a bit slower, every single day.

A feature takes longer than expected
A bug fix introduces another bug
You spend more time reading code than writing it
Onboarding a new developer becomes difficult

Or even something like this:

// "temporary" workaround from 6 months ago
if (user.role === "admin" && featureFlagX) {
  // special case inside special case
}

Nothing here breaks the system, but everything here slows you down.

That’s the interest you’re paying.

The Compounding Effect

This is where things become dangerous.

Technical debt doesn’t just add cost, it multiplies it. Every new feature built on top of unclear or fragile code becomes:

harder to implement
harder to test
harder to change

So the next feature takes longer.

And the next one.

At some point, the system isn’t just complex.

It’s actively resisting change.

And that’s when velocity starts dropping, even if your team hasn’t changed at all.

When Teams Hit Default

In finance, default happens when you can’t repay your debt anymore.

In software, it looks different, but the signal is clear.

You see it when:

refactoring is always postponed
certain parts of the codebase are avoided
every release feels risky
progress slows down despite increasing effort

At this stage, teams often react the wrong way.

They try to push harder.

More hours.

More pressure.

More “just ship it”.

But the problem isn’t effort.

It’s accumulated complexity.

And no amount of speed can compensate for that.

The ROI of Refactoring

Refactoring is often perceived as a cost, something that slows down delivery, something you “don’t have time for”, but that perspective ignores the return.

Refactoring is an investment.

And like any investment, it pays off over time.

Let’s make it concrete, imagine:

A feature currently takes 3 days to implement
After refactoring, similar features take 1.5 days

That’s a 50% improvement.
Over 10 features, you’ve saved 15 days.
That’s not just cleaner code, that’s recovered velocity.

And just like debt compounds negatively, good code compounds positively:

faster development
fewer bugs
easier onboarding
more confidence in changes

This is where engineering meets business, because velocity is not just a technical metric, it’s a business advantage.

When NOT to Refactor

Not all debt needs to be repaid immediately, and not all code needs to be perfect.

Refactoring everything blindly can be just as harmful.

Avoid refactoring when:

the code is rarely touched
the feature is about to be replaced
you’re still validating a product idea
the cost clearly outweighs the benefit

The goal is not to eliminate technical debt, but it’s to manage it intentionally.

Practical Ways to Manage Technical Debt

You don’t need a full rewrite to stay in control, you need consistency.

A few habits make a huge difference over time:

Refactor as you go: improve code while you’re already working on it
Make debt visible: track it instead of hiding it
Set a refactoring budget: even 10–20% of time is enough
Review for maintainability, not just correctness
Call out complexity early, before it spreads

These are small actions, but they prevent large problems.

Final Thoughts

Technical debt isn’t the enemy, it’s a tool.

Sometimes you take on debt to move faster and that’s a valid decision, but if you ignore it, it becomes a liability and, eventually, it starts slowing everything down.

The real problem isn’t having technical debt.

It’s pretending you don’t.

If this resonated with you:

Leave a ❤️ reaction
Drop a 🦄 unicorn
Share the most “expensive” piece of bad code you’ve seen

And if you enjoy this kind of content, follow me here on DEV for more.

React Components vs Spaghetti: 5 Signs Your UI Is Becoming Unmaintainable

Gavin Cettolo — Tue, 24 Mar 2026 08:30:00 +0000

Last week I opened a React component… and immediately closed it.

Not because it was complex.

But because it felt hostile.

You know that feeling: the file keeps scrolling, props are flying around, and every small change feels like it might break something completely unrelated.

That’s not complexity.

That’s entropy.

And if you’ve been building UIs for a while, you’ve probably seen it happen slowly, almost invisibly.

Let’s talk about the signals before things get out of hand.

TL;DR

If your React components start feeling hard to read, fragile, or unpredictable, your UI is likely becoming unmaintainable.

The most common signals are oversized components, props drilling, unclear responsibilities, duplication, and messy conditionals.

You don’t need a rewrite, just small, consistent refactoring habits.

The Problem with “It Still Works”
1. The God Component (Too Big to Understand)
2. Props Drilling Everywhere
3. Confusing Responsibilities
4. UI Logic Duplication
5. Conditional Rendering Hell
Bonus Signs You Shouldn’t Ignore
Mini Refactoring: From Spaghetti to Clean
Practical Refactoring Rituals
Final Thoughts

The Problem with “It Still Works”

Most messy UIs don’t start messy.

They start small, clear, even elegant.

Then a feature gets added.

Then another one.

Then a quick fix before a deadline.

Nothing dramatic, just small decisions that make sense in the moment.

Until one day you open a file and realize you don’t really understand it anymore.

That’s the moment where “it still works” becomes dangerous.

Because now every change carries risk.

And the cost of touching the code becomes higher than leaving it alone.

1. The God Component (Too Big to Understand)

There’s usually one file in every project that everyone avoids.

It’s big. Really big.

It handles data, UI, state, events, and probably a few side effects too.

Something like this:

export default function Dashboard({ user, posts }: Props) {
  // fetching logic
  // filtering logic
  // UI rendering
  // event handlers
  // conditionals everywhere

  return (
    <div>
      <h1>{user.name}</h1>
      {/* hundreds of lines */}
    </div>
  )
}

The issue isn’t just the size.

It’s the lack of boundaries.

When everything lives in the same place, nothing is clearly defined.

You don’t know what’s safe to change and what might break something else.

A useful rule I rely on is simple:

If you can’t describe a component in one sentence, it’s doing too much.

Breaking it down doesn’t mean over-engineering.

It means restoring clarity.

export function Dashboard() {
  return (
    <div>
      <UserHeader/>
      <PostList/>
    </div>
  )
}

Now each piece has a purpose.

And more importantly, a limit.

2. Props Drilling Everywhere

Props drilling usually starts innocently.

You pass user from a parent to a child, then to another child, then another.

Until you end up here:

<Dashboard user={user}>
  <Sidebar user={user}>
    <UserAvatar user={user}/>
  </Sidebar>
</Dashboard>

At this point, some components are just acting as pipelines.

They don’t use the data, they just pass it along.

That creates a subtle kind of friction.

Every layer becomes aware of something it doesn’t actually care about.

And any change to that data ripples through the entire tree.

The obvious solution is often:

“Let’s use Context.”

And that’s valid… but only to a point.

Context is not a silver bullet.

Overusing it can make your app harder to reason about:

data becomes less explicit
re-renders become harder to control
tracing where values come from gets tricky

A better approach is to use it intentionally, when it actually solves a real problem:

truly global data (auth, theme, user)
deeply shared state
repeated props drilling across many levels

Combined with a custom hook, it stays clean:

function useUser() {
  return useContext(UserContext)
}

function UserAvatar() {
  const user = useUser()
  return <img src={user.avatar} />
}

Now the dependency lives exactly where it’s needed.

3. Confusing Responsibilities

Sometimes the problem isn’t visible at a glance.

It’s not about how much code there is, but about what kind of work is happening in the same place.

A single component handling:

data fetching
state management
transformation
rendering

…is doing too many different jobs.

The result is cognitive overload.

You open the file and constantly switch context:

“Am I reading UI? Or logic? Or data?”

That friction slows everything down.

Separating responsibilities makes the code easier to navigate and easier to trust.

A simple split already helps a lot:

function usePosts() {
  // fetch + transform
}

function PostList() {
  const posts = usePosts()
  return (...)
}

Now the component reads like a story again, not a puzzle.

4. UI Logic Duplication

Duplication doesn’t always look like copy-paste.

Sometimes it shows up as repeated patterns:

if (isLoading) return <Spinner />
if (error) return <Error />

You write it once.

Then again.

At some point, changing that behavior means updating multiple places.

That’s when it becomes expensive.

Extracting shared logic is less about abstraction and more about centralizing decisions.

function DataState({ loading, error, children }: Props) {
  if (loading) return <Spinner />
  if (error) return <Error />
  return children
}

Now the behavior lives in one place.

And your UI becomes more consistent by default.

5. Conditional Rendering Hell

Conditional rendering is fine.

Until it isn’t.

We’ve all written something like this:

return isAdmin
  ? isActive
    ? <AdminPanel />
    : <InactiveAdmin />
  : <UserPanel />

It works.

But it’s not easy to read.

The problem isn’t React.

It’s that too much logic is living inside JSX.

A first step is to move that logic out:

function renderContent() {
  if (isAdmin && isActive) return <AdminPanel />
  if (isAdmin) return <InactiveAdmin />
  return <UserPanel />
}

return renderContent()

Already much better.

Using Guard Clauses

Guard clauses can make this even clearer, when used carefully.

if (!isAdmin) {
  return <UserPanel />
}

if (!isActive) {
  return <InactiveAdmin />
}

return <AdminPanel />

This removes nesting and keeps the flow linear.

The key is balance.

use guard clauses when they simplify the flow
avoid stacking too many negative conditions
keep the logic readable from top to bottom

The goal isn’t fewer lines.

It’s clarity.

Bonus Signs You Shouldn’t Ignore

Sometimes the signals are less technical and more instinctive.

You hesitate before opening a file
You’re afraid to change something
Fixing a bug feels risky
You’ve said “let’s not touch this” more than once

These are all valid warnings.

And they usually show up before bigger problems.

Mini Refactoring: From Spaghetti to Clean

A while ago I ran into a component like this.

It wasn’t broken.

It wasn’t even that complex.

But it had that feeling:

“There’s just a bit too much going on here.”

❌ Before

export default function Dashboard({ user, posts }: Props) {
  const [filter, setFilter] = useState("all")

  const filteredPosts = posts.filter(p =>
    filter === "all" ? true : p.type === filter
  )

  return (
    <div>
      <h1>{user.name}</h1>

      <select onChange={e => setFilter(e.target.value)}>
        <option value="all">All</option>
        <option value="tech">Tech</option>
      </select>

      {filteredPosts.length === 0 ? (
        <p>No posts</p>
      ) : (
        filteredPosts.map(p => <div key={p.id}>{p.title}</div>)
      )}
    </div>
  )
}

Nothing wrong, technically.

But everything is mixed together:

state
logic
UI

So I started small.

Step 1: isolate the logic

function useFilteredPosts(posts: Post[]) {
  const [filter, setFilter] = useState("all")

  const filtered = posts.filter(post =>
    filter === "all" ? true : post.type === filter
  )

  return { filter, setFilter, filtered }
}

Now the component doesn’t care how filtering works.

Step 2: extract reusable UI

function PostFilter({ value, onChange }: Props) {
  return (
    <select value={value} onChange={e => onChange(e.target.value)}>
      <option value="all">All</option>
      <option value="tech">Tech</option>
    </select>
  )
}

Step 3: compose everything

export default function Dashboard({ user, posts }: Props) {
  const { filter, setFilter, filtered } = useFilteredPosts(posts)

  return (
    <div>
      <h1>{user.name}</h1>

      <PostFilter value={filter} onChange={setFilter} />

      {filtered.length === 0 ? (
        <p>No posts</p>
      ) : (
        filtered.map(p => <div key={p.id}>{p.title}</div>)
      )}
    </div>
  )
}

Same feature.

Completely different feeling.

That’s the real goal of refactoring.

Practical Refactoring Rituals

You don’t need a full rewrite to fix spaghetti code.

You need habits.

Refactoring works best when it’s part of your workflow, not something you postpone.

A few simple ones:

extract things early, when they start feeling “off”
keep components focused on one responsibility
move growing logic into hooks
spend time naming things clearly

None of these are revolutionary.

But together, they make your codebase easier to work with.

Final Thoughts

Spaghetti UI isn’t a failure.

It’s what happens when real features meet real constraints.

But if you ignore it, it slowly turns your codebase into something you avoid instead of something you trust.

The good news is, you don’t need perfection.

Just small improvements, applied consistently.

If this article resonated with you:

Leave a ❤️ reaction
Drop a 🦄 unicorn
Share the worst component you’ve ever written (or seen) in the comments

And if you enjoy this kind of content, follow me here on DEV for more.

Next.js Folder Zen: Padroneggiare la Directory app/

Gavin Cettolo — Wed, 18 Mar 2026 08:30:00 +0000

Se hai iniziato da poco a usare Next.js 13+, probabilmente hai aperto un progetto e hai pensato:

“Perché questa struttura di cartelle sembra così... diversa?”

Con l’App Router, la directory app/ è diventata il cuore di ogni progetto Next.js moderno. Ma per molti sviluppatori—soprattutto quelli che arrivano dal vecchio pages/ router—la struttura delle cartelle può risultare inizialmente confusa.

Sistemiamo le cose.

TL;DR

La directory app/ di Next.js introduce un’architettura basata su file che controlla routing, layout e comportamento del rendering.

File speciali come page.tsx, layout.tsx, loading.tsx, error.tsx e not-found.tsx definiscono come si comportano le route.

Una struttura pulita con route groups e dynamic routes rende le app Next.js scalabili e manutenibili.

Perché la directory app/ è importante
Il concetto base: File-Based Routing
I file essenziali dentro app/
Layouts: l’arma segreta
Loading ed Error States
Error Boundaries: una limitazione importante
Gestire le 404 con not-found.tsx
Dynamic Routes
Route Groups
Una struttura reale
Errori comuni
Considerazioni finali

Perché la directory `app/` è importante

Quando Next.js ha introdotto l’App Router, non era solo una nuova cartella.

Era un cambio di paradigma.

Invece di spargere la logica in più livelli, la directory app/ organizza l’app attorno a route e segmenti UI.

Pensala così:

URL → Cartella → UI

Questo approccio rende le applicazioni grandi molto più facili da capire.

Invece di chiederti:

“Dov’è il componente per questa pagina?”

Vai direttamente nella cartella che corrisponde alla route.

Il concetto base: File-Based Routing

Nel app/ directory il routing è semplice.

Le cartelle definiscono le route.

Esempio:

app/
  page.tsx
  about/
    page.tsx
  dashboard/
    page.tsx

Questo genera:

/           → page.tsx
/about      → about/page.tsx
/dashboard  → dashboard/page.tsx

Una pagina base:

export default function Page() {
  return <h1>Hello Next.js</h1>
}

Zero configurazione di routing.

I file essenziali dentro `app/`

Next.js usa nomi di file speciali per definire il comportamento.

`page.tsx`

Definisce la UI della route.

export default function Page() {
  return <div>Dashboard</div>
}

Ogni route accessibile deve avere un page.tsx.

`layout.tsx`

I layout wrappano più pagine e persistono durante la navigazione.

app/
  layout.tsx
  dashboard/
    layout.tsx
    page.tsx

Esempio:

export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <main>
      <nav>Navigation</nav>
      {children}
    </main>
  )
}

I layout non vengono ri-renderizzati durante la navigazione, il che li rende perfetti per:

navbar
sidebar
UI condivisa

Layouts: l’arma segreta

Uno dei punti più forti dell’App Router sono i layout annidati.

app/
  layout.tsx
  dashboard/
    layout.tsx
    analytics/
      page.tsx

Rendering:

Root Layout
   ↓
Dashboard Layout
   ↓
Analytics Page

Questo permette UI complesse senza duplicare codice.

Loading ed Error States

Next.js supporta stati UI a livello di route.

`loading.tsx`

Mostrato durante il caricamento.

export default function Loading() {
  return <p>Loading...</p>
}

`error.tsx`

Gestisce errori nel segmento.

"use client" // Gli error boundaries devono essere componenti client

export default function Error({ error }: { error:Error }) {
  return <p>Something went wrong</p>
}

Error Boundaries: una limitazione importante

Il file error.tsx funziona come un gestore di errori React per un segmento di percorso.

Tuttavia, esiste un limite importante che molti sviluppatori trascurano.

I gestori di errori non intercettano gli errori all'interno dei gestori di eventi.

Cattura solo errori durante:

rendering
server components
data fetching

Esempio:

"use client"

export default function Error({
  error,
  reset,
}: {
  error:Error
  reset: () => void
}) {
  return (
    <div>
      <h2>C'è stato un errore.</h2>
      <button onClick={() => reset()}>
        Riprova
      </button>
    </div>
  )
}

Gli errori generati all'interno dei gestori di eventi devono comunque essere gestiti manualmente. Ad esempio:

"use client"

export default function Button() {
  const handleClick = () => {
    try {
      throw new Error("Boom");
    } catch (err) {
      console.error(err);
    }
  }
  return <button onClick={handleClick}>Click</button>
}

Considera error.tsx come una rete di sicurezza per l'interfaccia utente, non come un sistema completo di gestione degli errori.

Gestire le 404 con `not-found.tsx`

Next.js semplifica le 404.

export default function NotFound() {
  return (
    <h2>Pagina non trovata</h2>
  )
}

Trigger:

import {notFound} from "next/navigation"

if (!post) {
  notFound()
}

Supporta livelli multipli:

app/
  not-found.tsx
  dashboard/
    not-found.tsx

Viene usato quello più vicino.

Dynamic Routes

I dynamic routes usano le parentesi quadre.

Ad esempio:

app/
  blog/
    [slug]/
      page.tsx

URL generati:

/blog/my-first-post
/blog/nextjs-routing
/blog/react-performance

Esempio di implementazione:

export default function BlogPost({
  params
}: {
  params: { slug: string }
}) {
  return <h1>{params.slug}</h1>
}

È possibile combinarlo anche con la generazione statica.

Segmenti multipli

Esempio:

app/
  shop/
    [category]/
      [product]/
        page.tsx

Esempi di route generate:

/shop/laptops/macbook-pro
/shop/phones/iphone-15

Esempio di codice:

export default function ProductPage({
  params
}: {
  params: {
    category:string
    product:string
  }
}) {
  return (
    <div>
      <h1>{params.product}</h1>
      <p>Category: {params.category}</p>
    </div>
  )
}

Route Catch-all

A volte servono percorsi flessibili.

Next.js supporta i segmenti catch-all.

[...slug]

Esempio:

app/
  docs/
    [...slug]/
      page.tsx

URL supportati:

/docs
/docs/getting-started
/docs/guides/routing
/docs/api/config

Implementazione:

export default function DocsPage({
  params
}: {
  params: { slug: string[] }
}) {
  return <div>{params.slug?.join("/")}</div>
}

Optional route catch-all

È la versione opzionale:

[[...slug]]

Questo supporta entrambi:

/docs
/docs/routing
/docs/config/api

Tutto gestito dalla stessa pagina.

Comprendere i Route Groups

I Route Groups aiutano a organizzare il codice senza influire sugli URL.

Usano le parentesi tonde:

app/
  (marketing)/
    page.tsx
    about/
      page.tsx

  (dashboard)/
    dashboard/
      page.tsx

URL generati:

/
/about
/dashboard

Non appaiono nelle URL e sono perfetti per separare diverse sezioni dell'app così da avere:

layout differenti
provider differenti
strutture UI differenti

Un esempio pratico

app/
  layout.tsx
  page.tsx

  (marketing)/
    page.tsx
    about/
      page.tsx

  (dashboard)/
    dashboard/
      layout.tsx
      page.tsx
      analytics/
        page.tsx
      settings/
        page.tsx

  blog/
    page.tsx
    [slug]/
      page.tsx

In questo modo, le pagine di marketing, l'interfaccia utente dell'applicazione e i percorsi dei contenuti rimangono chiaramente separati.

Errori comuni

Quando affianco sviluppatori che utilizzano Next.js, questi sono i problemi che riscontro più frequentemente.

1. Mischiare `pages/` e `app/`

Sebbene tecnicamente possibile, crea confusione.

Se inizi con app/, mantieni solo app.

2. Cartelle annidate

Mantieni la struttura semplice.

Preferisci:

dashboard/analytics

Piuttosto che:

dashboard/features/analytics/pages

3. Ignorare i layout

I layout sono una delle funzionalità più potenti di App Router.

Usateli.

Semplificano notevolmente l'architettura.

Considerazioni finali

La directory app/ potrebbe inizialmente sembrare insolita.

Ma una volta che ci si prende la mano, diventa uno dei modi più puliti per strutturare le applicazioni React.

Invece di dover lottare con la configurazione del routing, i wrapper globali e la duplicazione dei layout, si ottiene un'architettura chiara e prevedibile.

Le cartelle rappresentano i percorsi
File speciali controllano il comportamento
I layout gestiscono l'interfaccia utente condivisa

E improvvisamente il tuo progetto sembra molto più... zen.

Se questo articolo ti è stato utile:

lascia un ❤️
aggiungi un 🦄
raccontami nei commenti come organizzi i tuoi progetti

E se apprezzate contenuti di questo tipo, non esitate a seguirmi qui su DEV per altri post su Next.js, architettura e produttività degli sviluppatori.

EDIT: Questa è una versione riadattata in italiano di questo mio precedente articolo: Next.js Folder Zen: Mastering the app/ Directory

Next.js Folder Zen: Mastering the app/ Directory

Gavin Cettolo — Tue, 17 Mar 2026 08:30:00 +0000

If you’ve recently started using Next.js 13+, you’ve probably opened a project and thought:

“Why does this folder structure feel so… different?”

With the App Router, the app/ directory became the heart of every modern Next.js project. But for many developers, especially those coming from the old pages/ router, the folder structure can feel confusing at first.

Let’s fix that.

TL;DR

The app/ directory in Next.js introduces a file-system-based architecture that controls routing, layouts, and rendering behavior.

Special files like page.tsx, layout.tsx, loading.tsx, error.tsx, and not-found.tsx define how routes behave.

A clean folder strategy with route groups and dynamic routes makes large Next.js apps scalable and maintainable.

Why the app/ Directory Matters
The Core Concept: File-Based Routing
The Essential Files Inside app/
Layouts: The Secret Weapon
Loading and Error States
Error Boundaries: One Important Limitation
Handling 404 Pages with not-found.tsx
Dynamic Routes
Understanding Route Groups
A Real-World Folder Structure
Common Mistakes Developers Make
Final Thoughts

Why the `app/` Directory Matters

When Next.js introduced the App Router, it wasn’t just a new folder.

It was a shift in how we design React applications.

Instead of scattering logic across multiple layers, the app/ directory organizes your app around routes and UI segments.

Think of it like this:

URL → Folder → UI

This approach makes large applications easier to reason about.

Instead of asking:

"Where is the component for this page?"

You simply look at the folder that matches the route.

The Core Concept: File-Based Routing

Routing in the app/ directory is simple.

Folders define routes.

Example:

app/
  page.tsx
  about/
    page.tsx
  dashboard/
    page.tsx

This produces:

/           → page.tsx
/about      → about/page.tsx
/dashboard  → dashboard/page.tsx

A basic page file looks like this:

export default function Page() {
  return <h1>Hello Next.js</h1>
}

That’s it.

No router configuration required.

The Essential Files Inside `app/`

Next.js uses special filenames to control behavior.

Here are the ones you'll use most.

`page.tsx`

Defines a route UI.

export default function Page() {
  return <div>Dashboard</div>
}

Every accessible route must contain a page.tsx.

`layout.tsx`

Layouts wrap multiple pages and persist during navigation.
Example:

app/
  layout.tsx
  dashboard/
    layout.tsx
    page.tsx

Example layout:

export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <main>
      <nav>Navigation</nav>
      {children}
    </main>
  )
}

Layouts do not re-render during navigation, making them perfect for:

Navigation bars
Sidebars
Shared UI

Layouts: The Secret Weapon

One of the biggest advantages of the App Router is nested layouts.

Example structure:

app/
  layout.tsx
  dashboard/
    layout.tsx
    analytics/
      page.tsx

Rendering flow:

Root Layout
   ↓
Dashboard Layout
   ↓
Analytics Page

This allows you to build complex UI structures without prop-drilling or layout duplication.

Loading and Error States

Next.js lets you define route-level UI states.

`loading.tsx`

Displayed while a route loads.

export default function Loading() {
  return <p>Loading...</p>
}

Useful for:

skeleton screens
streaming UI

`error.tsx`

Handles errors inside a route segment.

"use client" // Error boundaries must be Client Components

export default function Error({ error }: { error:Error }) {
  return <p>Something went wrong</p>
}

This prevents the entire app from crashing.

Error Boundaries: One Important Limitation

The error.tsx file works as a React Error Boundary for a route segment.

But there's an important limitation many developers miss.

Error boundaries do not catch errors inside event handlers.

They only catch errors that happen during:

rendering
server component execution
data fetching

Example error boundary:

"use client"

export default function Error({
  error,
  reset,
}: {
  error:Error
  reset: () => void
}) {
  return (
    <div>
      <h2>Something went wrong.</h2>
      <button onClick={() => reset()}>
        Try again
      </button>
    </div>
  )
}

Errors thrown inside event handlers must still be handled manually.

Example:

"use client"

export default function Button() {
  const handleClick = () => {
    try {
      throw new Error("Boom");
    } catch (err) {
      console.error(err);
    }
  }
  return <button onClick={handleClick}>Click me</button>
}

Think of error.tsx as a UI safety net, not a full error handling system.

Handling 404 Pages with `not-found.tsx`

Every production app needs a good 404 experience.

Next.js handles this with not-found.tsx.

Example:

export default function NotFound() {
  return (
    <div>
      <h2>Page not found</h2>
      <p>The content you're looking for doesn't exist.</p>
    </div>
  )
}

To trigger it, use the notFound() function.

import {notFound} from "next/navigation"

if (!post) {
  notFound()
}

You can define multiple not-found.tsx files at different levels.

Example:

app/
  not-found.tsx
  dashboard/
    not-found.tsx

The closest one in the route tree wins.

Dynamic Routes

Dynamic routes use square brackets.

Example:

app/
  blog/
    [slug]/
      page.tsx

URLs generated:

/blog/my-first-post
/blog/nextjs-routing
/blog/react-performance

Example implementation:

export default function BlogPost({
  params
}: {
  params: { slug: string }
}) {
  return <h1>{params.slug}</h1>
}

You can also combine it with static generation.

Multiple Dynamic Segments

Example:

app/
  shop/
    [category]/
      [product]/
        page.tsx

Routes:

/shop/laptops/macbook-pro
/shop/phones/iphone-15

Example code:

export default function ProductPage({
  params
}: {
  params: {
    category:string
    product:string
  }
}) {
  return (
    <div>
      <h1>{params.product}</h1>
      <p>Category: {params.category}</p>
    </div>
  )
}

Catch-All Routes

Sometimes you need flexible routes.

Next.js supports catch-all segments.

[...slug]

Example:

app/
  docs/
    [...slug]/
      page.tsx

Supported URLs:

/docs
/docs/getting-started
/docs/guides/routing
/docs/api/config

Implementation:

export default function DocsPage({
  params
}: {
  params: { slug: string[] }
}) {
  return <div>{params.slug?.join("/")}</div>
}

Optional Catch-All Routes

Optional version:

[[...slug]]

This supports both:

/docs
/docs/routing
/docs/config/api

All handled by the same page.

Understanding Route Groups

Route Groups help organize code without affecting URLs.

They use parentheses.

Example:

app/
  (marketing)/
    page.tsx
    about/
      page.tsx

  (dashboard)/
    dashboard/
      page.tsx

Generated URLs:

/
/about
/dashboard

The group names never appear in the URL.

Why use them?

Because real applications often have multiple app sections.

Example:

app/
  (marketing)/
    layout.tsx
    page.tsx
    pricing/
      page.tsx

  (app)/
    layout.tsx
    dashboard/
      page.tsx
    settings/
      page.tsx

This allows:

different layouts
different providers
different UI structures

without polluting URLs.

A Real-World Folder Structure

Here’s a scalable structure used in production projects.

app/
  layout.tsx
  page.tsx

  (marketing)/
    page.tsx
    about/
      page.tsx

  (dashboard)/
    dashboard/
      layout.tsx
      page.tsx
      analytics/
        page.tsx
      settings/
        page.tsx

  blog/
    page.tsx
    [slug]/
      page.tsx

This keeps marketing pages, application UI, and content routes clearly separated.

Common Mistakes Developers Make

When I mentor developers using Next.js, these are the issues I see most often.

1. Mixing `pages/` and `app/`

While technically possible, it creates confusion.

If you start with app/, commit to it.

2. Over-nesting folders

Deep structures become hard to maintain.

Prefer:

dashboard/analytics

Instead of:

dashboard/features/analytics/pages

3. Ignoring layouts

Layouts are one of the most powerful features of the App Router.

Use them.

They dramatically simplify architecture.

Final Thoughts

The app/ directory might feel unfamiliar at first.

But once it clicks, it becomes one of the cleanest ways to structure React applications.

Instead of wrestling with routing configuration, global wrappers, and layout duplication, you get a clear, predictable architecture.

Folders represent routes
special files control behavior
layouts manage shared UI

And suddenly your project feels a lot more… Zen.

If this article helped you understand the Next.js app/ directory better:

Leave a ❤️ reaction
Drop a 🦄 unicorn if you love Next.js
Share in the comments how you structure your projects

And if you enjoy content like this, feel free to follow me here on DEV for more posts about Next.js, architecture, and developer productivity.

EDIT: A few people asked for an Italian version of this article.
You can read it here: Next.js Folder Zen: Padroneggiare la Directory app/

Il codice non si licenzia, ma le persone sì: Clean Code, Debito Tecnico e Bus Factor

Gavin Cettolo — Wed, 11 Mar 2026 08:30:00 +0000

TL;DR

Il debito tecnico non è solo un fastidio per gli sviluppatori: è un rischio aziendale con interessi composti. Quando gli sviluppatori lasciano l’azienda, spesso si portano via il “perché” dietro al codice.

Il Clean Code non riguarda la perfezione: riguarda mantenere la conoscenza nel sistema, invece che nella testa di qualcuno.

This article is also available in English.

Poco tempo fa ho terminato il mio MBA e, guardando il mio lavoro anche da una prospettiva più business, sono arrivato a una conclusione interessante: sviluppatori e stakeholder hanno in realtà paura della stessa identica cosa, ma la descrivono con parole diverse.

Benvenuti nel Bus Factor.

Una piccola realizzazione durante l’MBA

Ho recentemente concluso il mio MBA e, tra fogli di calcolo, strategie e discussioni sul posizionamento di mercato, ho avuto una piccola illuminazione.

Mi sono reso conto che sviluppatori e business stakeholder spesso parlano lingue completamente diverse.

Noi sviluppatori parliamo di:

Refactoring e pattern
Debito tecnico
Qualità del codice

Il lato business invece parla di:

Mitigazione del rischio
Turnover e ROI
Scalabilità e produttività

Slide diverse, riunioni diverse, caffè diversi. Ma il punto è questo: in realtà abbiamo paura della stessa identica cosa.

Il Bus Factor

Il Bus Factor risponde a una domanda un po’ inquietante:

Quante persone possono lasciare il progetto prima che diventi un problema serio?

Se la risposta è una, ho una brutta notizia per te. Il tuo progetto ha un Bus Factor di 1 e la tua azienda sta praticamente gestendo una situazione di ostaggio software.

Questo succede più spesso di quanto tendiamo ad ammettere.

Un solo sviluppatore sa:

Come funziona davvero il flusso di autenticazione
Perché la logica di fatturazione richiede tre tentativi e una preghiera silenziosa al server
Cosa ci fa ancora lì quell’"hack temporaneo" del 2019

E all'improvviso quello sviluppatore se ne va.

Nuovo lavoro.
Nuova città.
Magari un allevamento di pecore in Nuova Zelanda.

E così, all'improvviso...

l’azienda perde letteralmente una parte del suo cervello.

Amnesia aziendale

La Corporate Amnesia si verifica quando gli sviluppatori lasciano l’azienda portando con sé la conoscenza istituzionale:

Contesto: perché è stata scelta quella tecnologia o quell’architettura
Vincoli: trappole nascoste e aree fragili del codice
Trade-off: compromessi e decisioni prese nel tempo

Anche la migliore documentazione può diventare obsoleta se non viene aggiornata costantemente.

Se il codice assomiglia a un museo di spaghetti sperimentali, tutta quella conoscenza si diluisce o scompare. Il prodotto esiste ancora, ma nessuno capisce davvero come funzioni.

E questo non è solo un problema tecnico, è un rischio economico serio.

Il fantasma degli sviluppatori del passato

Ogni sviluppatore ha vissuto questo momento.

Apri un file.

Scorri.

E scorri ancora.

Poi lo trovi: un useEffect() da 500 righe, senza commenti, con variabili chiamate temp, data2 e finalFinalVersion.

Controlli la cronologia Git.

L’autore? Ha lasciato l’azienda due anni fa. Forse ora alleva pecore in Nuova Zelanda.

Stai guardando una casa infestata di codice: troppo rischiosa da cancellare, impossibile da modificare con sicurezza.

Questo è il Fantasma degli Sviluppatori del Passato, e costa all’azienda migliaia di euro in produttività persa ogni giorno.

Clean Code come trasferimento di conoscenza

È qui che Clean Code cambia prospettiva.

Il Clean Code non è estetica: è comunicazione strategica.

Quando il codice è pulito, la conoscenza rimane nel sistema anche quando le persone se ne vanno. Ogni sviluppatore futuro può capire:

Cosa fa il codice
Perché esiste
Come interagisce con il resto del sistema

senza fissare un incontro con esperti di archeologia.

Prendiamo questo esempio:

❌ Il modo criptico

function processData(d){
  let t = d.filter(x => x.a)
  let r = []
  for(let i=0; i<t.length; i++){
    if(t[i].b > 10){
      r.push(t[i])
    }
  }
  return r
}

✅ Il modo chiaro

function getActiveUsersWithHighScore(users) {
  const ACTIVE_THRESHOLD = 10;

  return users
    .filter(user => user.isActive)
    .filter(user => user.score > ACTIVE_THRESHOLD);
}

La logica è la stessa, ma la seconda versione comunica chiaramente l’intento. La conoscenza rimane nel codice, non solo nella testa di uno sviluppatore.

Il refactoring come assicurazione

Una delle frasi più comuni nelle aziende è:

"Non abbiamo tempo per fare refactoring"

Ma da una prospettiva aziendale, la vera domanda dovrebbe essere un'altra:

"Quanto ci costerà quando nessuno capirà più questo codice?"

Ogni ora spesa per trasformare una funzione Frankenstein in qualcosa di leggibile non è tempo sprecato.

È un investimento in:

Velocità di onboarding: i nuovi sviluppatori diventano produttivi in giorni, non mesi
Autonomia del team: chiunque può lavorare su qualsiasi parte del sistema
Resilienza: quando qualcuno lascia l’azienda, il progetto sopravvive

In altre parole: il refactoring è letteralmente un'assicurazione contro l'amnesia aziendale.

Il codice è documentazione

Quando è scritto bene, il codice è la miglior documentazione possibile. Nomi chiari, funzioni piccole e architetture comprensibili preservano la conoscenza.

A differenza della documentazione statica, il codice pulito non diventa obsoleto per abbandono: evolve insieme al sistema.

Clean Code nell'era dell'IA

Oggi stiamo entrando in una nuova fase dello sviluppo software.

Gli strumenti di IA, come gli assistenti al codice, possono generare funzioni, componenti e persino interi moduli in pochi secondi.

Questo cambia la produttività, ma aumenta anche la posta in gioco per la qualità del codice.

Se l'IA genera codice su un'architettura disordinata, semplicemente accelera il caos, ma quando la base di codice è pulita e ben strutturata, l'IA diventa incredibilmente potente:

comprende l'architettura più velocemente
genera suggerimenti migliori
riduce i tempi di sviluppo senza aumentare la complessità

In altre parole, il codice pulito diventa la base per un efficace sviluppo assistito dall'IA.

Un codice scadente rallenta gli esseri umani e un codice scadente rallenta anche l'IA.

Messaggio chiave

Se c’è una sola cosa da ricordare è questa:

Il Clean Code non riguarda l’eleganza: riguarda la memoria organizzativa.

Più a lungo vive un progetto, più questo diventa importante.

Pensiero finale

Dopo il mio MBA, una cosa è diventata molto chiara: il Clean Code è una strategia aziendale. Protegge dalla perdita di conoscenza, riduce l’attrito nell’onboarding e rende i team più resilienti ai cambiamenti.

Dato che gli sviluppatori cambiano lavoro molto più spesso di quanto il codice cambi repository, scrivere codice pulito è uno degli investimenti migliori che un’azienda possa fare.

Una domanda per te

Quanta parte del tuo sistema vive:

Nel codebase
Nella testa di qualcuno?

Condividi la tua esperienza nei commenti!

Code doesn’t quit, but people do: Clean Code, Technical Debt, and the Bus Factor

Gavin Cettolo — Tue, 10 Mar 2026 08:30:00 +0000

TL;DR

Technical debt isn’t just a developer inconvenience, it’s a business risk with compound interest. When developers leave, they often take the “why” behind the code with them.

Clean Code isn’t about perfection: it’s about preserving knowledge inside the system, instead of inside someone’s head.

Questo articolo è disponibile anche in Italiano.

Not long ago I finished my MBA and, looking at my work from a more business-oriented perspective, I came to an interesting realization: developers and stakeholders are actually afraid of the exact same thing, they just describe it using different words.

Welcome to the Bus Factor.

This article explores how Clean Code, technical debt, and knowledge transfer affect real business risks like developer turnover, onboarding speed, and team scalability.

A small MBA realization

I recently closed my MBA, and among all the talk of spreadsheets and market positioning, I had a "Eureka" moment.

I realized that developers and business stakeholders often speak completely different languages.

We (the devs) talk about:

Refactoring and patterns
Technical debt
Code quality

Meanwhile, the business side talks about:

Risk mitigation
Turnover and ROI
Scalability and productivity

Different slides, different meetings, different coffee. But the kicker: we are actually afraid of the exact same thing.

The Bus Factor

The Bus Factor answers a slightly dark question:

How many people can leave before the project becomes a serious risk?

If the answer is one, I have bad news for you. Your project has a Bus Factor of 1, and your company is basically running a software hostage situation.

This happens more often than we'd like to admit.

One developer knows:

How the authentication flow actually works
Why the billing logic requires three retries and a silent prayer
What that "temporary hack" from 2019 is still doing there

And suddenly that developer leaves.

New job.

New city.

Maybe a goat farm in New Zealand.

And just like that…

the company loses part of its brain.

Corporate Amnesia

Corporate Amnesia happens when developers leave, taking with them institutional knowledge:

Context: Why this technology or design was chosen
Constraints: Hidden pitfalls and fragile areas of the code
Trade-offs: Decisions and compromises made over time

Even the best documentation can become outdated if not constantly maintained.

If the codebase looks like a museum of experimental spaghetti, all that knowledge is diluted or lost. The product exists, but nobody fully understands how it works anymore.

That is not just a technical problem, that's a serious financial risk.

The Ghost of Developers Past

Every developer has experienced this:

You open a file.

You scroll.

And scroll again.

Then you find it: A 500-line useEffect(), with no comments and variables like temp, data2, and finalFinalVersion.

Git history? The author left the company two years ago. Possibly raising goats in New Zealand.

You’re staring at a haunted codehouse: too risky to delete, impossible to touch safely.

This is the Ghost of Developers Past, silently costing thousands in lost productivity every day.

Clean Code as Knowledge Transfer

This is where Clean Code changes perspective.

Clean Code is not aesthetic, it’s strategic communication.

When code is clean, knowledge stays in the system even when people leave. Every future developer understands:

What the code does
Why it exists
How it interacts with the system

without scheduling a meeting with archaeology experts.

Let's take this example:

❌ The Cryptic Way

function processData(d){
  let t = d.filter(x => x.a)
  let r = []
  for(let i=0; i<t.length; i++){
    if(t[i].b > 10){
      r.push(t[i])
    }
  }
  return r
}

✅ The Clean Way

function getActiveUsersWithHighScore(users) {
  const ACTIVE_THRESHOLD = 10;

  return users
    .filter(user => user.isActive)
    .filter(user => user.score > ACTIVE_THRESHOLD);
}

The logic is the same, but the second version communicates the intent. Knowledge is preserved inside the code, not just in a developer’s head.

Refactoring as Insurance

There's a common argument in many companies:

"We don't have time for refactoring"

But from a business perspective, the real question should be different:

"How expensive will it be when nobody understands this code anymore?"

Every hour spent turning a Frankenstein function into something readable is not wasted time.

It's an investment in:

Onboarding Speed: New hires become productive in days instead of months
Team Autonomy: Anyone can safely modify any part of the system
Resilience: When developers leave, the project survives

In other words: refactoring is literally an insurance against corporate amnesia.

Code is Documentation

Code is the best documentation when written well. Clear naming, small focused functions, and understandable architecture preserve knowledge.

Unlike static docs, clean code doesn’t get outdated by neglectit evolves with the system.

Clean Code in the age of AI

Today we are entering a new phase of software development.

AI tools, like code assistants, can generate functions, components, and even entire modules in seconds.

This changes productivity, but it also raises the stakes for code quality.

If AI generates code on top of a messy architecture, it simply accelerates chaos, but when the codebase is clean and well structured, AI becomes incredibly powerful:

it understands the architecture faster
it generates better suggestions
it reduces development time without increasing complexity

In other words, Clean Code becomes the foundation for effective AI-assisted development.

Bad code slows humans and bad code slows AI too.

Mini takeaway

If there's one takeaway:

Clean Code isn’t about elegance, it’s about organizational memory.

The longer your project exists, the more valuable this becomes.

Final thought

After my MBA, one thing became clear: Clean Code is a business strategy. It protects against knowledge loss, reduces onboarding friction, and makes teams resilient to change.

Since developers change jobs more often than code changes repositories, clean code is one of the best investments a company can make.

One question for you

How much of your system lives:

Inside the codebase
Inside someone's head

Share your thoughts in the comments!

EDIT: A few people asked for an Italian version of this article.
You can read it here:
https://dev.to/gavincettolo/il-codice-non-si-licenzia-ma-le-persone-si-perche-il-clean-code-protegge-la-tua-azienda-dal-14d

A quick thought experiment

Imagine that tomorrow one of your senior developers leaves the company.

How many parts of the system would suddenly become a black box?

authentication
billing
deployment pipelines
legacy integrations

If the answer is "too many", the problem is not the developer leaving.

The problem is that knowledge lives in people's heads instead of the codebase.

That’s exactly what Clean Code tries to prevent.

Hellooo devs 👋

Gavin Cettolo — Thu, 05 Mar 2026 17:55:22 +0000

TL;DR

I'm Gavin Cettolo, a developer since 2017, builder and problem solver. I mainly work with React and Next.js, have experience coordinating projects and dev teams, and recently completed an MBA with honors to better understand the business dynamics behind every line of code.

I’ve decided to start publishing on Dev.to to talk about React, Clean Code, AI in development, OOP patterns, system design interviews, and project organization. My goal is to share what I learn and, most importantly, to learn better by explaining things clearly. Ideally, you’ll read something here and think, “Ah, that’s interesting.”

Questo articolo è anche disponibile in Italiano

Who I Am

Hi everyone,

I’m Gavin, and this is my way of politely knocking on Dev.to’s door before diving into technical articles.

I consider myself a builder and a problem solver. I like creating solutions that are useful, well-structured, and maintainable. Coding officially became my job back in March 2017, but the curiosity started much earlier. As a kid, I used to take computers apart, copy code from random tutorials, and spend more time experimenting than actually playing games.

Over the years, I’ve worked with several technologies: Java, .NET, Angular, jQuery, and more. Each one taught me something valuable. Then I discovered React, and it won me over.

Its flexibility, mindset, and community made development feel cleaner and more modular. Next.js naturally followed: better project structure, easier SEO handling, elegant rendering strategies, and less friction between idea and production.

Today I move between frontend and backend with a strong focus on code quality. I’ve also coordinated projects and development teams over time. I genuinely enjoy working with people as much as I enjoy working with code: running constructive code reviews, improving communication, and helping projects stay structured as they scale.

The startup world taught me one simple thing: change is constant. New features, inevitable refactors, unexpected bugs. If you don’t enjoy continuous learning, this might not be the right field for you.

Clean Code as a Mindset

I don’t see Clean Code as an aesthetic preference. It’s a form of respect.

Respect for the person who will read your code after you.
Respect for your future self.
Respect for the project.

For me, it means writing code that can be understood without decoding cryptic comments. Functions with a clear responsibility. Names that explain instead of confuse. Structures that don’t create anxiety three months later.

I follow classic principles, but I don’t treat them as dogma. Context matters. The real goal is always the same: readable, testable, maintainable code that doesn’t cause unnecessary friction.

AI in Development

I use AI as a support tool, not as an autopilot.

It helps me generate simple snippets, perform small refactors, and unblock ideas when I get stuck. But the responsibility remains mine. AI accelerates the process, it doesn’t replace reasoning.

In the coming years, I believe the real difference won’t be between developers who use AI and those who don’t. It will be between those who use it consciously and those who use it passively.

An MBA to Understand What’s Beyond the Code

I recently completed a Master of Business Administration with top honors.

It wasn’t a change of direction, but an expansion of perspective. Budgeting, strategy, organization, goal setting, resource management. Every piece of software lives inside a business context. Understanding that context changes how you make technical decisions.

Writing a feature is one thing. Writing it while understanding why it exists and what business impact it has is another.

Why I’m Writing Here

I write to share, but also to learn better.

There’s a simple rule I’ve always found true: if you can explain something clearly, then you truly understand it. This blog is also a personal exercise in clarity.

My plan is to publish one article per week, alternating topics. Some weeks will focus on React and Next.js, others on Clean Code, AI in development, OOP patterns, system design interviews, and reflections on organization and professional growth.

I want to keep a consistent and sustainable rhythm. No content overload, just thoughtful, practical, and concrete articles.

Here you’ll find content about:

React and Next.js
Clean Code and best practices
OOP patterns
System design interviews
AI applied to development
Organization, growth, and project dynamics

No guru mindset and no absolute truths. Just experience, experiments, mistakes, and continuous improvement.

If you made it this far, thank you.

Feel free to introduce yourself in the comments or tell me what kind of content you’d like to read.

See you soon.

Gavin 🚀

Buuuongiorno devs 👋

Gavin Cettolo — Thu, 05 Mar 2026 17:55:09 +0000

TL;DR

Sono Gavin Cettolo, sviluppatore dal 2017, builder e problem solver. Lavoro principalmente con React e Next.js, ho esperienza nel coordinamento di progetti e ho appena concluso un MBA con il massimo dei voti per comprendere meglio le dinamiche aziendali dietro ogni riga di codice.

Ho deciso di iniziare a pubblicare su Dev.To per parlare di React, Clean Code, AI nello sviluppo, OOP patterns, system design interview e organizzazione del lavoro. Il mio obiettivo è condividere e, soprattutto, imparare meglio spiegando agli altri, magari strappandovi un "ah, interessante!"

This article is also available in English

Chi sono

Ciao a tutti!
sono Gavin, e questo è il mio modo per bussare educatamente alla porta di Dev.to prima di iniziare a parlare seriamente di codice.

Mi definisco un builder e un problem solver: mi piace costruire soluzioni utili, ragionate e manutenibili. Scrivere codice è diventato un lavoro nel lontano marzo 2017, ma la passione e la curiosità sono nate molto prima: da ragazzino smontavo computer, copiavo codice da HTML.it cercando di capire perché funzionasse e passavo più tempo a fare esperimenti che a giocare.

Negli anni ho lavorato con diverse tecnologie: Java, .NET, Angular, jQuery e altre ancora. Ognuna mi ha lasciato qualcosa. Poi è arrivato React, e mi ha conquistato.

Per flessibilità, mentalità e community. Mi ha dato la sensazione di poter costruire in modo più pulito e modulare. Next.js è diventato il naturale compagno di viaggio: struttura migliore, SEO più gestibile, rendering elegante e meno frizione tra idea e produzione.

Oggi mi muovo tra frontend e backend con una forte attenzione alla qualità del codice. Nel tempo ho coordinato progetti e team di sviluppo. Mi piace lavorare con le persone tanto quanto con l’editor: fare code review costruttive, migliorare la comunicazione e aiutare un progetto a restare ordinato anche quando cresce velocemente.

Il mondo startup mi ha insegnato una cosa semplice: il cambiamento è continuo. Nuove feature, refactor inevitabili, bug che compaiono quando meno te lo aspetti. Se non ti piace imparare costantemente, sei nel posto sbagliato.

Clean Code come mentalità

Non considero il Clean Code un vezzo estetico. È una forma di rispetto.

Rispetto per chi leggerà quel codice dopo di te.
Rispetto per il tuo io futuro.
Rispetto per il progetto.

Per me significa scrivere codice che si capisca senza dover decifrare commenti criptici. Funzioni con una responsabilità chiara. Nomi che raccontano cosa fanno. Strutture che non generano ansia dopo tre mesi.

Seguo i principi classici, ma senza trasformarli in religione. Il contesto conta. L’obiettivo è sempre lo stesso: codice leggibile, testabile e modificabile senza drammi.

AI nello sviluppo

Uso l’AI come strumento di supporto, non come pilota automatico.

Mi aiuta a generare snippet semplici, a fare piccoli refactor e a sbloccare idee quando mi incastro mentalmente. Ma la responsabilità resta mia. L’AI accelera il processo, non sostituisce il ragionamento.

Credo che nei prossimi anni la vera differenza non sarà tra chi usa o non usa l’AI, ma tra chi la usa in modo consapevole e chi la usa in modo passivo.

Un MBA per capire cosa c’è oltre il codice

Ho appena concluso un Master universitario in Business Administration (MBA) con il massimo dei voti.

Non è stato un cambio di rotta, ma un ampliamento di prospettiva. Budget, strategia, organizzazione, obiettivi, gestione delle risorse. Ogni software vive dentro un contesto aziendale. Capire quel contesto cambia il modo in cui prendi decisioni tecniche.

Scrivere una feature è una cosa. Scriverla sapendo perché esiste e quale impatto ha sul business è un’altra.

Perché scrivo qui

Scrivo per condividere, ma anche per imparare meglio.

C’è una regola semplice che ho sempre trovato vera: se sai spiegare qualcosa in modo chiaro, allora l’hai capita davvero. Questo blog è anche un esercizio personale di chiarezza.

L’idea è pubblicare un articolo alla settimana, alternando gli argomenti. Un po’ di React e Next.js, un po’ di Clean Code, poi AI applicata allo sviluppo, OOP patterns, system design interview e qualche riflessione su organizzazione e crescita professionale.

Voglio mantenere una cadenza costante e sostenibile. Niente pubblicazioni compulsive, ma contenuti pensati, concreti e utili.

Qui troverai quindi contenuti su:

React e Next.js
Clean Code e best practice
OOP patterns
System design interview
AI applicata allo sviluppo
Organizzazione, crescita e dinamiche di progetto

Niente guru e niente verità assolute. Solo esperienza, esperimenti, errori e miglioramenti continui.

Se sei arrivato fin qui, grazie davvero.

Se vuoi, presentati nei commenti o dimmi che tipo di contenuti ti piacerebbe leggere.

A prestissimo!

Gavin 🚀

DEV Community: Gavin Cettolo

The Strategy Pattern in JavaScript: Replace Messy If-Else Logic With Clean Code

TL;DR

Table of Contents

The Problem: The If-Else Monster

A Real Example: Payment Methods

Why This Doesn’t Scale

Introducing the Strategy Pattern

Step-by-Step Refactoring

Step 1: Extract behaviors

Step 2: Create a strategy map

Step 3: Simplify the main function

Final Result: Clean and Extensible

Using TypeScript for Safer Strategies

Step 1: Define allowed methods

Step 2: Type the strategies

Step 3: Type the main function

Why this matters

Optional: Class-Based Strategy

When to Use (and Not Use) Strategy

Final Thoughts

Code Reviews Without Drama: How Great Teams Give Feedback That Actually Helps

TL;DR

Table of Contents

Why Code Reviews Go Wrong

What Great Code Reviews Actually Do

1. Focus on the Code, Not the Person

2. Explain the Why, Not Just the What

3. Turn Judgments Into Questions

4. Avoid Bike-Shedding

5. Balance Speed and Depth

Real Example: From Harsh to Helpful

❌ Harsh

✅ Helpful

How to Handle Receiving Feedback

Practical Team Agreements

Final Thoughts

Bad Code Is a High-Interest Loan: How Technical Debt Slowly Kills Team Velocity

TL;DR

Table of Contents

The Illusion of Speed

Technical Debt as a Financial Model

Principal: the shortcut

Interest: the friction

Compounding: the multiplier

Where the Interest Shows Up

The Compounding Effect

When Teams Hit Default

The ROI of Refactoring

When NOT to Refactor

Practical Ways to Manage Technical Debt

Final Thoughts

React Components vs Spaghetti: 5 Signs Your UI Is Becoming Unmaintainable

TL;DR

Table of Contents

The Problem with “It Still Works”

1. The God Component (Too Big to Understand)

2. Props Drilling Everywhere

3. Confusing Responsibilities

4. UI Logic Duplication

5. Conditional Rendering Hell

Using Guard Clauses

Bonus Signs You Shouldn’t Ignore

Mini Refactoring: From Spaghetti to Clean

❌ Before

Step 1: isolate the logic

Step 2: extract reusable UI

Step 3: compose everything

Practical Refactoring Rituals

Final Thoughts

Next.js Folder Zen: Padroneggiare la Directory app/

TL;DR

Table of Contents

Perché la directory app/ è importante

Il concetto base: File-Based Routing

I file essenziali dentro app/

page.tsx

layout.tsx

Layouts: l’arma segreta

Loading ed Error States

Perché la directory `app/` è importante

I file essenziali dentro `app/`

`page.tsx`

`layout.tsx`

`loading.tsx`

`error.tsx`

Gestire le 404 con `not-found.tsx`

1. Mischiare `pages/` e `app/`

Why the `app/` Directory Matters

The Essential Files Inside `app/`

`page.tsx`

`layout.tsx`

`loading.tsx`

`error.tsx`

Handling 404 Pages with `not-found.tsx`

1. Mixing `pages/` and `app/`