How we deliver high quality code?

00:00 → 00:034

Hi, I'm Tomek and I am senior backend engineer at Merixstudio.

00:04 → 00:07

In this video I'm going to show you how we take care of our

00:07 → 00:11

code at Merixstudio and make sure it's always the highest quality.

00:11 → 00:14

I will acquaint you with development standards and

00:14 → 00:16

the tools we use.

00:16 → 00:20

We will also jump into our code and I will walk you through it.

00:20 → 00:21

So let's start with the best practices.

00:21 → 00:25

We try to accommodate the commonly used best practice.

00:25 → 00:27

The first of them is DRY.

00:27 → 00:31

DRY is an acronym that stands for don't repeat yourself.

00:31 → 00:34

Anytime there is a duplication of code or you are copying and

00:34 → 00:37

pasting anything inside your code base,

00:37 → 00:40

you should think twice before doing so because you can

00:40 → 00:43

probably reuse the same code and make your code look

00:43 → 00:47

cleaner, be easier to maintain, and less error prone.

00:47 → 00:50

Another good practice is KISS.

00:50 → 00:53

KISS is another acronym that stands

00:53 → 00:55

for Keep it simple stupid.

00:55 → 00:58

A simpler solution is better than a complex one because

00:58 → 01:01

simple solutions are easier to maintain.

01:01 → 01:04

This includes increased readability, understandability

01:04 → 01:05

and changeability.

01:05 → 01:09

Furthermore, writing simple code is less error prone.

01:09 → 01:12

Another rule is more is more complex.

01:12 → 01:16

Having more lines of codes, methods, classes,

01:16 → 01:19

packages, executables, libraries, etc.

01:19 → 01:22

Means also to have more complexity.

01:22 → 01:23

There is also another rule,

01:23 → 01:27

which is an acronym and stands for You Ain't Gonna Need It.

01:27 → 01:29

In the context of optimization,

01:29 → 01:32

you are unlikely to know upfront whether an optimization

01:32 → 01:34

will be of any real benefit.

01:34 → 01:37

Just write the code in the simplest way.

01:37 → 01:40

If eventually after profiling you discover a bottleneck,

01:40 → 01:42

optimize that.

01:42 → 01:46

SOLID is another acronym which stands for multiple sets of rules.

01:46 → 01:49

We are using it with emphasis on single

01:49 → 01:54

responsibility principle as it is the fundament of clean and readable code.

01:54 → 01:57

We always try to keep in mind the bigger picture.

01:57 → 02:01

We try not to focus only on the current task and always try to

02:01 → 02:04

think ahead and predict what might be needed in the future.

02:04 → 02:06

On the top of the best practices,

02:06 → 02:09

we stick to our internal guidelines, which include:

02:09 → 02:11

following the PEP20.

02:11 → 02:14

PEP stands for Python Enhancement Proposals.

02:14 → 02:16

PEP20 is the Zen of Python,

02:16 → 02:20

and it gives a general guidance of writing good code.

02:20 → 02:24

Sticking to PEP eight, which is style guide for Python code,

02:24 → 02:27

which focuses on specific rules of code formatting like

02:27 → 02:31

indentation, blank lines, imports, etcetera.

02:31 → 02:34

We keep our code well documented with PEP two fifty seven.

02:34 → 02:37

When our code is not self explanatory,

02:37 → 02:41

we use DOC strings to describe what is the purpose of the

02:41 → 02:42

certain chunk of code.

02:42 → 02:45

We use type hinting whenever we can.

02:45 → 02:49

It enables us to detect a lot of mistakes before even running the code.

02:49 → 02:51

We write unit tests.

02:51 → 02:54

This helps us to avoid situations in which we say,

02:54 → 02:56

but that worked just an hour ago.

02:56 → 02:59

We use git for versioning our code.

02:59 → 03:03

There is also a set of rules that we apply to make sure that

03:03 → 03:05

our work is effective and clean.

03:05 → 03:08

One of the rules is to use explanatory commit messages.

03:08 → 03:11

For example, another fix is bad.

03:11 → 03:15

It says nothing about the code that was pushed to the repository.

03:15 → 03:19

A good example would be products listing API endpoint.

03:19 → 03:22

It briefly describes the contents of this commit.

03:22 → 03:25

Another rule would be consistent commits.

03:25 → 03:28

We try to avoid pushing unfinished features,

03:28 → 03:31

to do comments or fragments of codes that are for debugging

03:31 → 03:32

purposes only.

03:32 → 03:35

We use the Gitflow branching model,

03:35 → 03:38

which helps us to maintain and deliver consistently new

03:38 → 03:42

features to our QA department and also to our clients.

03:42 → 03:45

I will now briefly walk you through the environments that

03:45 → 03:47

we use on our daily basis.

03:47 → 03:50

For the local development, we use Docker and Docker

03:50 → 03:51

Compose.

03:51 → 03:55

It helps us to set up the project on any machine in no

03:55 → 03:58

time and decreases the effort to introduce, for example,

03:58 → 04:00

a new code developer to the team.

04:00 → 04:05

Kubernetes with Helm charts is used for the develop environment.

04:05 → 04:08

The deployment process is semi automatic,

04:08 → 04:12

which makes the cooperation between the engineering and QA

04:12 → 04:13

department seamless.

04:13 → 04:15

For staging and production environment,

04:15 → 04:19

we use Amazon Web Services, Google Cloud Platform,

04:19 → 04:20

or whatever you wish for.

04:20 → 04:25

Of course, we can advise you what would be the best fit for your idea in

04:25 → 04:28

terms of scalability, high availability, performance,

04:28 → 04:29

and of course pricing.

04:29 → 04:33

The development cycle starts with developing new feature.

04:33 → 04:37

If a developer considers the feature to be finished,

04:37 → 04:40

then at least one different engineer needs to approve the

04:40 → 04:44

code in order to be able to push the code to the repository.

04:45 → 04:48

Code review is also a good opportunity to share knowledge

04:48 → 04:52

between the members of the team and increase each other's

04:52 → 04:55

skills Each time a new chunk of code is being pushed to the

04:55 → 04:59

repository it triggers a set of automated tasks that are performed.

04:59 → 05:01

Automatic tests are being run.

05:01 → 05:06

Linting, which is running a program that analyzes the code in terms of

05:06 → 05:09

following the best practices I mentioned earlier.

05:09 → 05:13

Deployment, if the previous stages pass successfully,

05:13 → 05:16

then the application is being built and deployed to the

05:16 → 05:18

corresponding environment.

05:18 → 05:21

Okay, so now it's time to dive into the code.

05:21 → 05:22

Let's start with the view.

05:22 → 05:26

View handles requests and returns response or

05:26 → 05:27

throws an exception.

05:27 → 05:31

In this case, the docstring explains the purpose of this view.

05:31 → 05:34

What is worth noting is clean code structure.

05:34 → 05:37

Also, a generic exception is handled

05:37 → 05:41

and a custom exception is thrown instead.

05:41 → 05:45

Also, this view uses a generic API view,

05:45 → 05:49

which is a shortcut for building a new view.

05:49 → 05:53

It enables you to use the built in functionalities

05:53 → 05:57

into a Django framework and makes the code looks

05:57 → 05:59

cleaner and more readable.

05:59 → 06:02

Also, some configurable parameters are being used in

06:02 → 06:05

this code so that we are not hard

06:05 → 06:08

coding any values into the code.

06:08 → 06:12

You might notice what is missing in this particular view.

06:12 → 06:14

It is type hinting.

06:14 → 06:18

This is done on purpose because of backwards

06:18 → 06:21

compatibility with older Python versions.

06:21 → 06:25

Another part of code that we'll discuss is a service.

06:25 → 06:30

In this case, a service is a user's token generator example.

06:30 → 06:33

What is worth noticing is a self explanatory

06:33 → 06:35

name of the class.

06:35 → 06:40

Also, docstring explains the details and the purpose of this service.

06:40 → 06:45

Also, meaningful method names is something that is worth noting.

06:45 → 06:47

And implementation of an abstraction,

06:47 → 06:50

which enables us to interchange this

06:50 → 06:52

particular service with another one.

06:52 → 06:56

Also, we try to keep our code clean and as readable as possible.

06:56 → 06:59

Also, another chunk of code would be another service.

06:59 → 07:02

I think this one is quite different from the previous

07:02 → 07:04

one, and it's also worth discussing.

07:04 → 07:07

This is a notification handle example,

07:07 → 07:11

and also this is an abstract class,

07:11 → 07:12

which uses a generic type.

07:12 → 07:15

This class can be implemented in multiple

07:15 → 07:19

ways, and also can define its own return type.

07:19 → 07:23

Also, what is worth mentioning is a bulk create

07:23 → 07:27

for database insertion, instead of creating new

07:27 → 07:31

objects in for loop and inserting them one by one.

07:31 → 07:34

Another code part would be a model.

07:34 → 07:38

Model represents the data model or a business model.

07:38 → 07:43

In this it's a method of authentication,

07:43 → 07:47

and it consists of multiple fields.

07:47 → 07:50

All of them are quite self explanatory.

07:50 → 07:51

The code is very readable.

07:51 → 07:56

The docstring explains the details of the purpose of model.

07:56 → 07:59

Another example can be a serializer.

07:59 → 08:02

It validates input data and also serializes or

08:02 → 08:04

deserializes the data models.

08:04 → 08:07

What is worth mentioning here is again explanatory

08:07 → 08:10

name, docstring explains the details,

08:10 → 08:14

and also readable structure, data type validation,

08:14 → 08:17

and business logic validation.

08:17 → 08:19

This is an example of env file,

08:19 → 08:24

which enables us to configure the environment in the way that we need it.

08:24 → 08:29

It enables us to have the same code base reusable across all environments.

08:29 → 08:33

It consists of the configuration for all external

08:33 → 08:36

service and all the parameters that need to be passed to the

08:36 → 08:39

application regarding the environment that the

08:39 → 08:41

application will be run on.

08:41 → 08:45

This way, there is no need to change the code base for deployment to

08:45 → 08:46

each environment.

08:46 → 08:46

Okay.

08:46 → 08:48

So that's basically it.

08:48 → 08:50

Of course, this process can vary in each project

08:50 → 08:52

depending on the chosen tech stack.

08:52 → 08:54

If you are looking for experienced developers who

08:54 → 08:59

deliver high quality code, contact us and let's talk about your project.