DEV Community: Andrzej Karaś

Don't create dedicated solutions create patterns

Andrzej Karaś — Thu, 23 Mar 2023 00:00:00 +0000

Context

I am sure that you are faced with a situation where you found a couple of classes that solve the same problem but in a different way. Also, when you implement or maintain similar modules you could find that entire code or specific classes look analogous. Here is how you could use it as leverage for your productivity.

Identify

Identifying such cases is key. Of course, without that, we can't do the next steps for the improvements. Sometimes we have to refactor given code because is implemented in way different way, but after "normalization" we get the same code. I faced such cases many times, especially when working on legacy code.

Improve

We could do the improvement described in the previous sentence - refactor the code, so it could look very similar in every module. But this is only part of the improvement we could do.

Implement a pattern

Once we isolate a common class (a subset of methods in other words), then we could: check whether it's doing a single thing and doing it right. Then we could divide the given class into smaller independent parts.

When we will be in this place we could introduce interfaces for all important classes. The complement step is to make those interfaces and concrete classes generic - a lot of languages are using "templates" or some corresponding method.

Replace old solution with generic one step by step

If you identified such classes in a couple of modules you should avoid replacing them at once. Does it step by step, so you could test everything properly and react to some problems if any would occur? This way you will discover them faster.

Summary

Thanks to the steps described above you will be able to implement something only once and use it anywhere else you need. Polymorphism is a game-changer here, it's an increasing number of places that we could use our code later on.

There are a couple of benefits that we get from described approach:

we have less code to maintain in the long term
we need to spend less time doing it
we need to remember less about our codebase
we have only one file when we want to improve feature X
what's more important we have one file to take a look at when searching for a bug culprit (we will be able to easily map file/class to a feature)
we could unit test our code way easier and faster
we decrease the complexity of the solution
we decrease the time needed to introduce a new person to our project
when having interfaces in place (that hides all other details under the hood), we could prepare very tiny documentation that will show connections between modules and interfaces :)
your team would be spending less time on code review and debugging bugs

You need to remember about couple more things:

it's a process, and you should not try to do the last step in the first place, you need to take time to decouple code correctly (do it only when you know the system is your pocket)
remember to inform your teammates about changes - they should reuse your code to not waste time and don't spend time on re-inventing the wheel

I know everybody loves spending time coding things. But by saving time you will be having it on doing another great thing with your app like preparing a design, discovering customer needs, helping your teammates, or just implementing another feature/fix way faster than planned.

Probably there are way more benefits from using the approach I described. You can share them with me of course!

How to break down your app? A short guide.

Andrzej Karaś — Tue, 21 Mar 2023 00:00:00 +0000

Let's take some imaginary enterprise or SaaS application which helps to solve many use cases. In this article, we will think, about how a lack of testing and couple other behaviours could impact such applications.

I. Writing code without implementing unit tests along

If you want your app to be crashing after every release, don't implement unit tests! For sure, you saw some cases where your system was failing on production because of a bug that could be discovered on the unit tests level.

Also, keep doing it for a couple of months or years. That will lead you to the situation where you are scared of changing anything in your app because it could break aby other modules :)

Objections on implementing unit tests

Let's be clear that we are considering a production ready app here. The biggest objections about writing tests are:

It consumes time
Development team needs to maintain it along with changes
It's hard to implement them when dealing with legacy code
"It can't be unit tested"

Answers

Let's break down all the objections.

1. Not implementing unit tests also costs time

Not implementing unit tests cost even more in the long term, and we want to maintain our applications as long as possible, no (when we're having revenue of course)? Solving bugs in an app without tests costs us: developer time (money), customer frustration (money), and support teamwork (money), sometimes bugs could e.g. increase infrastructure usage - which also generates costs. When fighting with bugs we can't work on new features at the same time, so it takes also our time.

2. You could do it way easier to maintain

Referring to the previous point, from my perspective maintaining well-written unit tests is easy to maintain and costs less than buggy applications.

3. Implementing unit tests will help you fix bugs and understand your application more

When you are in that place, and you are dealing with e.g. buggy feature you have two options:

try to fix without implementing unit tests
gather functional requirements, understand them, plan solutions from a technical perspective, implement unit tests for an API that solves it, implement code

The second solution allows you to understand the root of problems, prepare a correct solution for it and cover it with tests that would be working as a guard for the future. Such an approach is paying a lot in the future. I was doing that many times when working on legacy code.

Also, correctly written unit tests would work as documentation that is maintainable and resides very close to the source code.

4. "You can't unit test it properly"

Yes, this is the hard truth. Every piece of code could be unit tested in a proper way. But first, you need to learn how to:

decouple technical parts from business logic, because in most cases we want to cover the latter one-by-unit tests
separating things on many levels: single method, class, package, module, application, and infrastructure. Thanks to that you could focus on one problem at a time. This is very helpful when fighting some serious bugs - you are making them easier to spot! And at the end of the day that saves you a lot of time.

II. Pushing changes to the dev or master branch without manual (or any other tests)

I was seeing such situations many times. Developer X is finishing his code, committing everything, and pushing to production. After some time (we need to wait for CI/CD and instances rollout) we have a "fire on production" and no one knows what's happening.

The worst thing in those situations is when you need to solve that problem instead of so-called Developer X because they did not spot it or they did not want to.

Solution

I don't understand why developers act like that. I don't care. It's a very bad habit.

So my approach is simple. Try to separate from such developers or at least take away push permissions from them :)

III. Don't think about how your changes would impact anything or anyone

Unfortunately, the team I worked on was in that situation many times.

When you work in a big company, you could have multiple developer teams even though you all work on the same app

This leads to a couple of problems, (especially when working on the legacy app):

changes in app A could impact app B e.g. on performance, functional or security level
when the code is not correctly maintained you could waste much more time on solving merge conflicts
when you are using mono repo and your code is not correctly separated then teams could code dependencies that shouldn't be possible
when access to the projects is not restricted, anyone could change anything in your core module...

Also, every team could have:

a different approach to solving problems
a different opinion on testing things
a different process of delivering things to production
a different velocity for delivering changes
different skill levels

Everything adds up to one conclusion.

Divide & Conquer

When you apply that simple rule on code, infrastructure, and teams/company level you will get to the one important point. Developer teams won't be influencing each other.

Giving teams extreme ownership of the app they develop will pay off, you can try that. Developers are not stupid, they won't be doing things that would break an app they develop - or this is only my opinion?

IV. Don't care who is leading your development teams

I know, that I wrote above that teams should have ownership and freedom in developing the app they maintain. But you need to strictly check who leads your teams.

One simple hint

I heard somewhere one saying. 'When you have bad workers in a management place, then good workers will start leaving the company.'

I saw a couple of times e.g. when working on consulting company how someone who doesn't know how to lead the project could crash it in a second.

I am not telling that I know everything about project management. But I just want to show what you should avoid in your work.

Observation

When you have a skilled team of people, who do care about code quality, apps they develop, and are IT enthusiasts (and don't get up to work as punishment). Then you don't have anyone above them - especially the manager that would be assigned tasks. Such people would organize the team internally, you just need to show them the long-term goal(s) you want to achieve.

V. Don't try to release your changes as soon as possible

Of course, who needs that?! You can play with your code on the feature branch till the end of the world :) For sure your code would be optimized and polished as much as possible.

The problems

Such an approach leads to a couple of problems:

you won't get feedback from the end-users and people that make decisions (so-called business)
technology would go forward
your teammates would add a lot of changes to the code

When you're not trying to release it ASAP, then you're just wasting your time and company money. I need to clarify one thing. I am writing about things that could be precisely designed. But 99% of enterprise or SaaS applications fit into that.

VI. Don't care what're your colleagues asking for

If you are working in a company that has multiple teams - don't try to understand your colleague's needs. Who needs that? You exactly know what to do. Don't you?

Such a situation could end up in one way... You will implement or prepare a solution that nobody would be using. That's the hard truth, but even as a developer, you should be able to talk with your teammates and prepare a solution that they accept. Again, don't waste your time!

VII. Who needs code reviews? No one.

This topic is a little related to pushing changes to production without tests. But even though you are performing code reviews, you could still do it incorrectly.

I know this is a very broad topic, but short checks on what has been done without pointing out technical and business problems are a very bad approach. Also, when you do a code review, you should expect that all changes would be done or at least someone will discuss with you why something was done in that way.

VII. Documentation? My code is self-documented.

As I wrote before e.g. properly written unit tests are good at documenting our project. We need to understand all benefits that we could have from actual documentation. Especially, our new colleagues would be happy when passing the introductory stage. I know that thousands of pages are not the approach that anyone wants to take. But there is one more thing that you could use!

ADR - Architecture Design Record

There is a lot of templates for such document. In short:

you could store them in the same place as you store code
should be updated along with the code
explains what, how, and why would be solved
help us keep track history of changes and decisions that were made in the project
help us discover problems on a design level, which is the cheapest level ever possible

You could find examples on the internet. Maybe I will prepare a dedicated post in the future.

Summary

If you want to spoil the application you work on, please follow these steps :)

But, if you want to improve your skills and the app you work on, try to pick one thing I mentioned and deal with it in your organization.

For sure, you have some other ideas about what negatively impacts an application. You could share your thoughts on my dev.to profile. All comments are welcome.

Stay tuned!

How did making coffee help me find a bug in my code?

Andrzej Karaś — Fri, 17 Mar 2023 00:00:00 +0000

I know what you're thinking. Did that really happened? My answer is yes, it happened.

Context

It happened a couple of months after I started working in a team that developed browser extension. I got some bug to investigate related with one key feature of its extension.

When I found a code that was the potential culprit of a bug, I just set breakpoints in the browser and started trying to incrementally move through the code to examine it.

But I had no luck. I spent a big chunk of my time trying to trigger it in different ways… but still the corner case I wanted to find was hidden.

Coffee

After a couple of minutes I needed a quick break to make a cup of coffee and to think about other approaches that I could follow to find the culprit. But when I got back to my browser and IDE I spotted that the breakpoint was active! Something had triggered the correct code.

Solution

It turned out that feature I was testing, was using idle browser API. As a name says that API was allowing the user to track a device idle state. Inside a code I found an event handler responsible for doing the rest of the work. Solving a bug was super easy in the end.

That history is still funny after couple years… I still can’t believe that I solved a bug by preparing a coffee :)

Improve your work by usage of custom TODO labels

Andrzej Karaś — Tue, 14 Mar 2023 00:00:00 +0000

For sure, you have thousands of TODOs left in your project. Today I will show you how to sort them out a little.

TODOs and why we need them?

Every popular IDE as e.g. IntelliJ or Eclipse allows us to create comments containing magic TODO or FIXME labels. All comments marked like this could be found in a special section in our IDE.

Of course, they are used for marking some parts of code for the future when we want to: add some features, do some improvements, or fix some small bug that could wait for now.

This small feature helps us save time when working on something important - we don't have to open our task management tools to note it :)

Custom labels

I know those two labels could be enough, but as always we could distinguish a couple more of them. But ...

How we could create a custom label?

To prepare an example I will use IntelliJ IDE but, you could apply the same patterns to other IDEs.

You need to visit Setting -> Editor -> TODO and just add a custom pattern e.g. \bimprove\b.*. After that, your IDE would be highlighting your custom labels as default ones.

Why should I create a custom TODO label?

I will give you a couple of ideas on how to use custom labels:

IMPROVE - To distinguish things that must be fixed or just should be done later.By using a such label we could mark some nice-to-have changes
QUESTION - We could use them to give some open questions about the code before pushing it to code review. I know we could use e.g. Gitlab UI to do it. But doing it in the code will help us save time and will leave some notes way closer to the code - for sure not all team members will look at the issue you create.
OPTIMIZE - Special label for those who love doing performance optimizations in the code
SECURITY - Found some security flaw, but don't know how to fix it properly? You could mark that part of the code and share it with team members.

Let me know what other labels you will create in your project!

Why separating services could let your app fail gradually

Andrzej Karaś — Sun, 05 Mar 2023 00:00:00 +0000

Context

Some time ago my team in a company that I work on had really serious issue. I fixed one feature that started working as expected, but it also started sending a lot more notification emails to our clients - nearly 150k / a day.

As you probably guess we ran out of quota. What's worse it happened for all applications we develop.

How could we prevent it?

My advice probably is not ideal and won't save you in similar case, but it will:

help you survive longer
give more time to prepare a fix
won't crash all applications or modules that are sending emails, fail gradually in other words

Solution

Solution is very simple. When developing such thing as sending emails that are very important from business perspective. You should divide quota per every application or module that would be using it.

Thanks to that:

only one app or module would be affected or ran out of quota (the rest would be working as intended)
it will give you a space to shift quota a little if needed
it will give you more time to prepare a fix, because not all parts of your app would be affected

Additional steps

Of course this is not only thing you could do. You could:

implement sending emails or notifications in bulk as my very smart colleague did :)
implement metrics and alerting in order to spot your problem before your app would be crashed

Summary

So as you see following very simple rule of applications and modules separation on application or infrastructure level let's say gives you one very important thing. Your system is more resilient and your customers won't be affected by bugs so often.

How to use blocking web request API with Manifest v3

Andrzej Karaś — Fri, 03 Mar 2023 00:00:00 +0000

If you are on this page, you are probably extension developer that is in trouble. In this post I will try to help you introduce workaround that works.

Context

As you know a lot of APIs was removed or deprecated by introducing Manifest V3. It was advertised as change for good direction. As increased user privacy, better performance etc. Unfortunately by looking at how changes works in the runtime, what workarounds were created for a couple of problems and what changes were done since the announcing MV3, im not quite sure that this was change for good.

Declarative net request api as a cure

We could reimplement our code in order to use declarativeNetRequest, but this API won't allow us to do everything we need - in the code we could implement action that is needed in a way that we want to.

Workaround

Are you developing enterprise and self-hosted browser extension? You are saved!

According to the Google Chrome documentation (should work on Edge too) you are able to still use blocking version of webRequest API.

You just need to add webRequestBlocking into the manifest permissions.

Are there any drawbacks of that approach?

Unfortunately, they are...

Because of some bug in Chromium project we could not run that code locally (when using unpacked version of your extension). Extension must be deployed to your enterprise domain via policy.

So testing your code could be quite tricky. I advise you to do it on internal version that is hidden from production environment and your customers. Apart from that everything works as before. Hope this API would be still available after sunsetting MV2 extensions.

Other good news, Firefox claimed that they would be still maintaining this API.

How to pick proper name of classes?

Andrzej Karaś — Sat, 25 Feb 2023 00:00:00 +0000

Did you ever ask yourself how you could save time on development stage? It would be very nice when you could implement some part of code way faster than now. Especially when you develop a lot of new features or extending existing ones. In this post I will show you very simple trick to achieve it!

Don't you try to find name before you implement a class

The trick applies to structural programming too, but we are mostly using OOP on our daily basis. So I will use class as an example.

Imagine that we want to implement a class that would be doing some complex operations for us. Let's say we gathered some requirements at the first step (I will give couple examples):

we want to take a photo from a webcam by using our browser extension
we want to process data in a way that output would be ready to show to our client
we want to validate URL based on rule configured by our client

In all those cases we will be able to divide code into a couple of classes. If we don't want to use meaningless names like: controller, manager, service - then we could use that simple trick

Use some temp name

Yes, that is so simple. Use 'Foo' or 'Bar' for your class, implement whole logic encapsulated by this class. Of course, you need to remember that single class should do single thing, without any side effects. Also, remember about implementing unit-tests. Implementing both of them and sticking with very small class that have single purpose of use will let you create a name very quickly - once you finish implementing it or even in the middle of the process.

Remember: change the temp name to the correct one, before merging your code into the main branch.

Hope that you found it useful!

Using conditional breakpoints

Andrzej Karaś — Sat, 21 Jan 2023 00:00:00 +0000

This post would cover another tip that could make debugging process way easier. Imagine that we have registered a listener for some browser API, and we want to test how it works. Sometimes our normal break point won’t stop the code execution. That’s why we could use conditional breakpoints.

What’s conditional breakpoint?

It’s just line of code marked as normal breakpoint, but with additional condition applied. Thanks to that approach our code will stop there only if condition would be fulfilled. Take a look at example shown below.

Also in multithreaded languages e.g. like Java we could decide whether stop all threads or only one that is executing code for given class.

When we should use it?

We could use conditional breakpoints when:

we want to filter out breakpoints we don’t want to observe that time
we want to stop the code only in some specific cases
to make sure that breakpoint for event listener would stop the code execution

Debugging browser extension based on manifest version 3

Andrzej Karaś — Thu, 19 Jan 2023 00:00:00 +0000

Developers are facing with debugging code on a daily basis. When developing browser extension that is using service worker inside it could be a little hard sometimes to debug it properly. In this article I will explain how make it in easier way.

Catching actions that are done after starting a service worker

I wanted to discover a specific case when our extension is doing some task or requests right after calling a service worker. In order to catch actions done there we could use a simple trick.

In the script marked as dedicated to service worker (that applies to both JS and TS versions):

{
  "background": {
    "service_worker": "src/serviceWorker.ts"
  }
}

Instead of calling methods we want directly:

// src/serviceWorker.ts

const x = 10;
const y = 20;
const sum = x + y;
console.log("Result: " + sum);

We could do:

// src/serviceWorker.ts

// Delay in miliseconds
const delay = 15000;

setTimeout(() => {
    const x = 10;
    const y = 20;
    const sum = x + y;
    console.log("Result: " + sum);
}, delay);

That approach will give us time on opening background page after injecting local version of our extension in the browser. Thanks to that we will be able to: check all logs, network requests, breakpoints from the start.

Hope you would find this post useful!

Understanding common software development errors

Andrzej Karaś — Wed, 18 Jan 2023 00:00:00 +0000

A programmer's primary task is to automate the business processes of a given enterprise so that it ends up with a profit for the entity. Simple, right?

It is worth considering the amount of time spent fixing errors in code during daily work. Business owners invest in new functionality or modules, thus spending a significant amount of time correcting the same issues repeatedly, which may not align with the intended tasks or schedule.

Each programmer will probably answer that he would build new systems, modules, and functionalities rather than maintain the old system (which is not quite sure how it works and why).

Following this line of thought, the question we should answer is why bugs are introduced into software that is working on the production? What measures can we take to minimize such situations?

Ignorance of business and functional requirements

It's fair to say that working on a project at a consulting company or a SaaS application should differ significantly. In addition to differences in working style. Identifying business requirements from conversations with the ordering party, end customers, or application owners is very similar in both cases.

It's generally known that catching errors in assumptions at the requirements-gathering stage allows for the fastest and cheapest corrections. Hence the importance of properly taking the time to talk to customers/businesses to identify as many assumptions as possible.

A common mistake is starting development work without gathering requirements or before completing this stage. Another mistake is to rush through development, resulting in an ill-conceived code structure. Those causes could impact development velocity in the future. In other words, single feature development time for the same application would be longer and longer. Also, the number of errors introduced could increase because of it.

Misunderstanding of business and functional requirements

To avoid the above problem, work as closely as possible with the business to develop a common language and build a mutual understanding of what the application is supposed to do.

It is also good practice to indicate what the application will not do. That approach will help potential customers fully understand how the application would work.

At the stage of gathering and specifying requirements, the development team should cooperate with the business. The more mediators in communication, the worse (unfortunately).

Ignoring non-functional requirements

Premature optimization is a well-established antipattern. We use that term as an excuse for not preparing the technical requirements. Of course, emphasis on these requirements depends on the scale of the project.

For example, we could cause a negative evaluation of the project by not defining adequate response time for a module critical to the customer.

Insufficient shared knowledge of application modules

Nowadays, separate teams are working on a single application or system. In such a situation, teams must focus on sharing knowledge about every detail related to the developed app.

The matter worsens when working on a legacy project. Working in multiple teams that do not have the same knowledge about the product and the wrong dependencies between modules can only lead to one thing.

Misunderstanding of technology

It is common in legacy projects to encounter the use of a particular tool that contradicts the assumptions described in the documentation.

Introducing a new tool into our project connected with inadequate knowledge about that tool could lead to creating mistaken assumptions based on a couple of sentences from tool docs.

Unfortunately, both cases could end badly for our project.

YDD - Yolo-Driven Development

YDD is the opposite of the approach where we test changes before deploying them into production. "Let's release to production, and then we'll see". Unconsidered changes can cause a lot of damage (not only to the code):

customers may quite often encounter an inadequately working application
changes made on the spur of the moment increase the likelihood of increasing links between modules of the application
such an approach to development is also very irresponsible (and so, at the end of the day, it is WE who will maintain the code)

Working without a plan

When there are hundreds of tasks in the backlog, and we don't quite know which task is the most important from a business or technical perspective. The manufacturing team may have trouble planning their work. Not to mention identifying major changes that can solve several problems at once.

Work without metrics

Working with legacy code without a proper approach to testing changes. Combined with rushing changes into production. Without proper discussion of how a solution should work. Does this tell you anything? I hope that as few people as possible have encountered this approach to software development.

When the manufacturing team doesn't have the time or doesn't want to spend time on requirements identification and testing. There is nothing to dream about metrics that de facto save each developer's time.

Properly built metrics allow for faster detection of bugs introduced into the software. In addition, we should create metrics that would describe our application (number of requests, latencies, etc.) and the business that we have (number of customers, number of errors reports, number of feature X usages).

Lack of sense of responsibility

In my opinion, the worst thing that can happen to a team is the approach we somehow instead of quality.

Making changes without thinking about architecture and infrastructure

When modules of the application are not well encapsulated then any changes in the code may cause a lot of problems. Performance problems or introduce a bug in a module we didn't expect.

I can see from my observation that people start thinking about such things when their application is "burning".

Human error

Of course, everybody could make some mistakes. But at least introduce the techniques described above: collection of requirements and introduction of tests or metrics. It will significantly reduce the effects of human error.

Summary

Hope that list will help you spot such things in your project. That would be a good start to improving it!