Tag: architecture

Configurable implementation hidden behind a contract

Some concrete implementations are better to be hidden behind contracts, in a specific package. A layer of abstraction can save you later, mostly on unstable projects that often change requirements, or maybe you just want to test an idea, maybe you don’t have the necessary time to finish a task in a way you’d like to.

A good contract will save you. You can “throw” your implementation behind it and come back later to refine it. Sometimes later means in a few years. But if you’re behind a well designed contract, most probably you’re going to alter only the concrete implementation, without touching large areas of the projects.

I had to filter some user input. Some strings had to be HTML escaped, some sanitized to prevent different attacks. I’ve wrapped everything into a package, behind a contract. For escaping I’ve used Go’s html.EscapeString function, while for sanitizing I’ve found the bluemonday package, which is inspired by an OWASP sanitizier for Java. Continue reading Configurable implementation hidden behind a contract

Re: Isolation

It’s easy to talk about SOLID principles, design patterns, testing, moral expectations, self responsibility, and any other guide lines for a better world. Sometimes it’s even easy to adhere to those ideas, to put them in practice, no matter how may times some people repeat “there wasn’t/isn’t time”.

Although, there are situations that really stand against all best practices, like big legacy products which are already on the market, used by many clients, developed by many people who are managed very strict, in order to maintain… order. Or you need to get fast on the market.

The minimum that can be done is isolation. The least you can do is to throw your code in its own corner and use it only from there, then go back to change it whenever you want, without fear, with minimum cost and risk.

Start now

If you have some technical debt, an architecture issue, an old bug, or just some poorly developed features, now is the right moment to start changing. And I’m all pragmatic about it. No motivational stuff.

I’m talking about real problems which hold you back, waste time and money. Not about small optimizations which don’t bring you value, not every problem needs a solution.

To start doesn’t necessarily mean to actually do or to rush, you can start analyzing the need and the effort, think of required steps (technical analysis, people analysis, business requirements and so on).

Then start refactoring that old class or make a new one, maybe extract that feature into a microservice, upgrade that server, change that old technology, rethink that architecture so you can change easier in the future.

You know your business, but get fresh ideas from other people, maybe you’re too stiffed after many years on the project.

Just start the process now, because later everything will require more and more resources.

 

Avoiding IF statements for business rules

One moment a project can get on an unwanted road is when new business rules pop in. Even more if this happens on a tight deadline. You just throw some innocent if statements, and that’s how hell can unleash…

Later, other rules will be requested by business. Each will have at least one if statement and maybe interactions with some services. Then one day you notice yourself tangled in the code you’d prefer to never see.

There are ways to implement these rules fast and efficient, avoiding most of those undesired if statements. This is my situation:

  • I have a Song resource and a User resource
  • A Song can be restricted to a User based on multiple conditions
  • If a Song is restricted to a User, we have to let them know why, and this can be for reasons like:
    • Song is not released yet
    • Song was retired by the record company
    • User is from a country where we don’t have rights to offer the Song
    • User has a plan which doesn’t allow him to play the Song
    • and so on

The “what” doesn’t matter, the “how” is the key. And business folks can change their mind any time. They want a new rule fast, or cancel one, or change it. Continue reading Avoiding IF statements for business rules

Fast on the market and software architecture

You want to be ASAP on the market. So you require developers to write code fast.

We should have a decent code at least, so we can overcome future situations.

Yeah, yeah, but not now, let’s release fast. Then we’ll come back, this is just a concept, we need our clients to see something/we need to fix the issue now (cause it’s burning now, we’ve been ignoring it for a while because it was never urgent).

Both are right. You need good code and fast written code. Can you have them both? I would say not really.

Instead, you can have a decent architecture. At least decent. Start your project, feature, class or function in a manner which will allow you to update code in the moment you realize things went wrong, or when you just need to extend.

You don’t understand, you’re not mature enough, we have to work fast.

Great, I look forward for you to ask me why development is taking so much, why we have bugs.

Use frameworks and/or patterns/advices that others are using and working on for years. If at some point you end up on an unpleasant road, it’s going to be easier to change. Don’t be afraid of things you’re not used to.

And try to work as isolate as possible. Build independent components/libraries/modules/packages that are easy to integrate and dispose when needed, do not throw code everywhere.

Do not try to guess the future, make sure the present allows you to adapt. Otherwise, time, effort, money will be invested in maintaining a monster which holds you back from being fast on the market.