Data Structure 101: Part 1

I’ve wanted to write about Data Structure for a few years.

Why?

To most people with computer science knowledge, Data Structure is something boring that we are taught in school because we have to learn it. To me, Data Structure is a tool — one that is essential for project success.

These are the topics I will cover in this series of posts:

• The importance of Data Structure
• What is Cyclomatic Complexity
• Simple Data Structures
• Complex Data Structures
• Sorting Algorithms, and when are they required
• Search Algorithms, and how it helps to learn how to search
• Why some algorithms are better than others
• How to refactor using Cyclomatic Complexity as a tool

I’ll cover one or two topics per post. It’s easier for me to write, and probably easiser to understand. So, let's begin.

What is the importance of Data Structure?

We as software developers deal with some sort of data every day. Whether it’s a list of list of users delivered from some back-end API, or some registration data from a web form. We have to choose what types we will be using for each individually case.

As an example, imagine the client requested the phone number with a mask.

If you had chosen to use a number type for this field, you would have some issues on formatting the value. So, the data type you used is important for this scenario, right?

This is a somewhat "zoomed in" example, but you can scale it up to Rest APIs, which send lists of data. It isn't something unusual to have this example:

You will often face this situation — the REST API have two endpoints, one for the events, and another for the users. To know which events belong to which user, you have to either query the events API with the user_id, or iterate in both array to link them.

I know this is a bad scenario, but for the scenarios' sake keep this in mind. We could send the events as a field in the users, but this would become expensive for the request parse eventually. Alternatively, we could create the /users/:id where just when we are getting one user, we get the event associated to the user. Again this will cause our app to make several requests for each user.

While none of the solutions are completely bad or completely good, each has their pros and cons.

Conclusion

In part 2, I talk about Cyclomatic Complexity, which is a crucial tool to understand why some codes are bad, and some are good.

I really hope you like this series idea and it helps you become a better engineer. I'm not the expert in this topic, but I am enthusiastic about it.

If you have something new to add, please use the comment section, I really want to hear some more opinions about these topics.

Here at ArcTouch we have a great team of software developers. If you’d like to join us, check out our career opportunities.