DEV Community: Alejandro Barba

How Changing Requirements Shape the Infrastructure of a Software Project

Alejandro Barba — Tue, 25 Feb 2025 05:14:02 +0000

🎬 Introduction

Since few weeks ago I'm learning about AWS SAM so I decided to create a small project to put in practice what I've been learning.

The project is a wallet app with features we all know:

Register incomes and outcomes.
Categorize the incomes and outcomes.
Label the incomes and outcomes

An important requirement of this dummy wallet app was to allow users to create and manage their own categories for tracking incomes and outcomes. But, these categories needed to be private to each user meaning that a category created by one user could not be shared with another.

💪 Hands To Work

So I started designing the DB using this cool tool. The project has 2 tables, users and categories . The user can create many categories as he wants so the first approach I took was creating a third table, a union table to store user_id and category_id.
With this solution the users are able to create x numbers of categories and we can see assign the category to the user.

Example:

⚠️The problem

Technically, this approach works but something smells weird here. While it correctly assigns categories and users, the current design allows to assign a category created by User A to User B.
For example if user Alejandro creates the "Health" category, this category can be assigned to user Edith by simply creating the record in user_categories table. But the requirement is clear: A user can create as many categories as they want, but these categories must not be shared. Categories created by a specific user should remain tied to that user only.

🤓 The Solution

Although we can enforce this rule both on the backend and frontend, it’s generally a good practice to align all components with the project’s core requirements to maintain clarity and consistency.

So at the end, I've changed the design to this:

This aligns with the given requirement and reduces the complexity of the database.

🧠 Conclusions

I know this is a very basic example but its clear and concise. While coding is a crucial (and funny) part of the job, a software engineer’s role is to think critically about the design choices, taking into account factors like maintainability, security, and scalability.

How the Strategy Pattern Can Simplify Complex Logic

Alejandro Barba — Thu, 13 Feb 2025 04:53:51 +0000

🧠 Introduction

The Strategy pattern is a behavioral design pattern that allows you to define multiple ways to perform an operation by encapsulating them in separate classes. This makes behaviors interchangeable, following the Open/Closed Principle: open for extension but closed for modification.

🙋 Why it’s useful and in what scenarios it’s applied.

This pattern is useful when an application needs to perform the same operation using different approaches. Instead of cluttering your code with long if-else or switch statements, you encapsulate each variation in its own class, making the code more maintainable and scalable.

😵‍💫 Common misconceptions or confusion around it.

Strategy vs. Factory Pattern
- ❗Misconception: "Strategy and Factory are the same."
- ✅ Reality: The Factory Pattern is about creating objects, while the Strategy Pattern is about choosing a behavior at runtime.
  - You can use a Factory to instantiate the correct Strategy, but they serve different purposes.
Thinking It's Only for Algorithms
- ❗Misconception: "Strategy is only for sorting or mathematical algorithms."
- ✅Reality: It applies to any scenario where behavior varies dynamically, such as:
  - Payment methods 💰
  - Logging mechanisms 👨‍💻
  - Compression formats (ZIP, GZIP, etc.) 🗜️
Overcomplicating Small Problems
- ❗Misconception: "Strategy should be used everywhere!"
- ✅Reality: If you only have two or three simple cases, a basic function or if-else might be enough.
  - Good Use: Multiple payment gateways with different API calls.
  - Bad Use: A function that just switches between two database queries.
Forgetting Dependency Injection
- ❗Misconception: "Each Strategy should be instantiated manually."
- ✅Reality: It’s better to use Dependency Injection or a Factory Pattern to select and provide the strategy dynamically.

📌 Problem Example

You launch an app in Mexico, and it quickly becomes a hit! 🎉 At first, you integrate Conekta, a popular Mexican payment gateway.

As time goes on, users start requesting PayPal, so you add support for it. Then, your app gains traction in the USA, and you integrate Stripe to accept USD payments.

Later, your app expands to Colombia, where you realize that using a local payment gateway reduces transaction fees compared to Stripe. To cut costs and keep users happy, you integrate yet another payment provider.

Your app is a commercial success... but your code is a nightmare. 😱 Maintaining multiple payment gateway integrations has become a tangled mess, full of if-else statements and duplicated logic.

💡 Solution: The Strategy Pattern

Instead of hardcoding payment logic, the Strategy Pattern offers a cleaner approach:

✅ Encapsulate payment algorithms in separate classes, called strategies. Each class represents a different payment gateway (e.g., ConektaStrategy, PayPalStrategy, StripeStrategy).

✅ Create a Context class that decides which strategy to use at runtime. The context doesn't need to know the details of each payment method—it simply delegates the work to the selected strategy.

✅ Define a common interface for all payment strategies. This ensures consistency in your code and makes it easy to add new payment gateways in the future

Here’s a TypeScript example demonstrating the Strategy Pattern for handling multiple payment gateways dynamically:

👨‍💻 Code Example

Step 1: Define a Common Interface

Each payment method should follow the same structure.

// PaymentStrategy.ts
export interface PaymentStrategy {
  pay(amount: number): void;
}

Step 2: Create Payment Strategies

Each payment gateway gets its own class implementing PaymentStrategy.

// ConektaStrategy.ts
import { PaymentStrategy } from "./PaymentStrategy";

export class ConektaStrategy implements PaymentStrategy {
  pay(amount: number): void {
    console.log(`Processing payment of $${amount} MXN via Conekta.`);
  }
}

// PayPalStrategy.ts
import { PaymentStrategy } from "./PaymentStrategy";

export class PayPalStrategy implements PaymentStrategy {
  pay(amount: number): void {
    console.log(`Processing payment of $${amount} USD via PayPal.`);
  }
}

// StripeStrategy.ts
import { PaymentStrategy } from "./PaymentStrategy";

export class StripeStrategy implements PaymentStrategy {
  pay(amount: number): void {
    console.log(`Processing payment of $${amount} USD via Stripe.`);
  }
}

// ColombianGatewayStrategy.ts
import { PaymentStrategy } from "./PaymentStrategy";

export class ColombianGatewayStrategy implements PaymentStrategy {
  pay(amount: number): void {
    console.log(`Processing payment of $${amount} COP via Colombian Gateway.`);
  }
}

Step 3: Implement the Context Class

This class selects the payment strategy at runtime.

// PaymentContext.ts
import { PaymentStrategy } from "./PaymentStrategy";

export class PaymentContext {
  private strategy: PaymentStrategy;

  constructor(strategy: PaymentStrategy) {
    this.strategy = strategy;
  }

  setStrategy(strategy: PaymentStrategy): void {
    this.strategy = strategy;
  }

  processPayment(amount: number): void {
    this.strategy.pay(amount);
  }
}

Step 4: Use the Strategy Pattern in Your App

Now, we can dynamically switch payment methods:

// main.ts
import { PaymentContext } from "./PaymentContext";
import { ConektaStrategy } from "./ConektaStrategy";
import { PayPalStrategy } from "./PayPalStrategy";
import { StripeStrategy } from "./StripeStrategy";
import { ColombianGatewayStrategy } from "./ColombianGatewayStrategy";

// Select initial payment method
const paymentContext = new PaymentContext(new ConektaStrategy());
paymentContext.processPayment(500); // Processing payment of $500 MXN via Conekta.

// Switch to PayPal
paymentContext.setStrategy(new PayPalStrategy());
paymentContext.processPayment(100); // Processing payment of $100 USD via PayPal.

// Switch to Stripe
paymentContext.setStrategy(new StripeStrategy());
paymentContext.processPayment(200); // Processing payment of $200 USD via Stripe.

// Switch to Colombian Gateway
paymentContext.setStrategy(new ColombianGatewayStrategy());
paymentContext.processPayment(300000); // Processing payment of $300000 COP via Colombian Gateway.

🚀 Benefits of This Approach

✅ Scalability: Easily add new payment gateways without modifying existing code.

✅ Clean Code: No more long if-else statements for payment processing.

✅ Flexibility: Switch payment methods dynamically at runtime.

Would you like me to add any refinements, such as using dependency injection or a factory to select the strategy automatically? 😃

🤔 Conclusion

The Strategy Pattern is a powerful tool for managing complex or varying behaviors in your application. In the context of payment gateways, it allows you to encapsulate different payment methods in separate classes, making your code more maintainable and scalable. By using the Context class to delegate the logic and Dependency Injection (DI) to manage your strategies, you ensure that your app is flexible enough to handle future changes or new payment methods seamlessly.

Remember, the Strategy Pattern helps avoid long chains of if-else or switch statements, making your code cleaner and easier to extend. Whether you’re building a payment processing system or dealing with other dynamic behaviors, this pattern can simplify your design and reduce code duplication.

😁 Let me know your thoughts

What do you think? Have you implemented the Strategy Pattern in your own projects? If so, how did it help simplify your code? Feel free to share your thoughts or any questions you might have about this pattern in the comments below!

Let’s keep the conversation going! 👇

From Zero to Developer: My Journey into the World of Code

Alejandro Barba — Tue, 04 Feb 2025 05:13:16 +0000

Introduction

Hi, I’m Alejandro, a 26-year-old software engineer, and this is my journey (so far).

Right now (new Date() JS joke here), I’m living a great life doing what I love (sometimes 😜). But it wasn’t always this way. Four years ago, I made the decision to leave college and start working as a programmer. Five years ago, I was considering leaving college altogether to pursue a career in gastronomy. And even further back, I dreamed of becoming a doctor. Life has a funny way of taking unexpected turns, doesn’t it?

In this post, I’ll share how I went from being unsure about my future to building a career I’m passionate about—and the lessons I learned along the way.

The beginning

How did I start?

My first “Oh boy, this is what I love!” moment came when I was 17, studying programming in high school. The topics of the class were Visual Basic, Excel, and C++. I loved the feeling of solving problems and seeing my code actually do something—exactly what I wanted it to do. But what I loved even more was that my friends paid me to do their projects for them. (Hey, it was my first taste of freelancing!)

After high school, I went to college to study computer science. Back then, my goal was to get a PhD (naive me, right?). But reality hit hard. Being a software engineer was much harder than I thought. Looking back, it makes sense—in high school, the most complex thing I had to build was a calculator. But in college, I was learning things like Dijkstra’s algorithm. My younger self thought I’d spend my life making calculators in C++. Little did I know, there was a whole world of complexity waiting for me.

Imposter Syndrome and the (First)Turning Point

At that time, I met one of my best friends—Imposter Syndrome. This little f*er made me (and sometimes still does) think that coding wasn’t my thing, that I wasn’t smart enough, and that I didn’t work hard enough to pass my classes. It got so bad that I started thinking about leaving college altogether and pursuing something else, like gastronomy. I began skipping classes, missing exams, and as a result, I failed some subjects—like data structures.

That period was awful. I cried a lot. I was scared of the future and felt like I was stuck in a never-ending loop of failure. But one day, something changed. I decided to take matters into my own hands. I went to the library, picked up a book on data structures and algorithms in C++, and started reading and practicing on my own. Slowly but surely, something clicked in my head. I began to understand the concepts that had once seemed impossible. My grades improved, I passed the subjects I had previously failed, and for the first time, I started to see the light at the end of the tunnel.

Second Turning Point

After that awful period, I went through another one—lol—but this time, it was lighter. The main problem was that I had no idea how to use my super strong, almighty, powerful programming skills in real life. All I knew was C++, so once again, the idea of becoming a chef started creeping back into my mind.

After a few (and by "a few," I mean a lot) of days researching, I came across a Facebook ad for a bootcamp called DevF. It focused on web development, and at first, it seemed amazing—until I saw the price. So, I took the subjects from their syllabus and started learning on my own.

At the beginning, it was all a mess. Concepts like Node.js, CSS, JS, HTML, MongoDB, MySQL, middleware, JWT, Express, deploy, branches—a whole lot of WTF to be honest. I was overwhelmed. I didn’t know where to start, which path to take, or how to put everything together.

One day, while searching for courses on Udemy, I found Juan Pablo De la Torre Valdez. This guy saved my life (not literally, but you get it). The courses I bought from him gave me much-needed clarity. I started building a simple page with HTML, CSS, and JS, and suddenly, frontend development started making sense. I began to understand the technologies, how they connected, and what role each played.

But there was still a missing piece—the backend. I knew absolutely nothing about it. So, I made a bold decision: I enrolled in the DevF bootcamp. To afford it, I sold my one-week-old PS4 (painful, but worth it).

The bootcamp gave me the final clarity I needed. I finally understood how frontend and backend worked together. And at that moment, I knew—software engineering was what I wanted to do for the rest of my life.

A few months (and a lot of learning) later, I made another big decision: I dropped out of college to focus on my first programming jobs. Spoiler alert: they were absolute trash. But that's a story for another post.

Advice for Others

I have some advice for anyone starting this amazing career. These tips come from my own experience—they worked for me and still do:

Repeat, repeat, repeat, repeat...

I can’t even count how many to-do lists I built. One with MongoDB, one with MySQL, one with Python, one with Node.js, one with Vue, one with React, one with PHP, one with Laravel… you get the idea. I made tons of login pages, CRUDs, and React/Vue/Angular components.

The key? Practice. A lot.
Don’t think that just because you did something once, you’re an expert. There’s always room to learn and improve.
Don’t be afraid to ask

Back in college, I was struggling with data structures, and one guy approached me and helped me with my homework. He showed me what I was doing wrong and saved me a ton of time.

People always have different perspectives—take advantage of that. Asking for help is not a weakness, it’s a shortcut to learning.
Have someone to talk to

I’ll never forget the people who supported me during my toughest moments. Thanks to them, I became the professional I am today. Having people who understand your struggles and can offer guidance makes a huge difference.
Have a Plan B

I dropped out of college, but only after I had a job lined up. If you’re going to take a big risk, make sure you have a backup plan.
Never stop learning

You don’t know what you don’t know. Keep exploring, keep building, and keep improving. The tech world moves fast—stay curious and stay hungry.
Have fun

Life is a balance.