Forem: Volodymyr

It's time to talk about DRY

Volodymyr — Sun, 17 Dec 2023 19:01:32 +0000

This is a pattern that is one of the main practices in programming and system design. Its essence lies in minimizing the repetition of information and code, which helps to increase readability, maintainability, and scalability of software.

The main aspects of this principle:

Don't repeat code: When you write programs, avoid having the same lines of code repeated in different parts of the program. This means you should not copy or write the same code over and over again. Instead, create this code once and use it wherever needed.

Group code: To make your code more organized and easier to manage, consider grouping similar operations and functions in one part of the code. For example, if you have several places where you need to do the same things, create a function that performs these actions and use it as many times as needed.

Use functions and libraries: If other programmers have created useful pieces of code or libraries, you can use them in your programs. Instead of reinventing the wheel, you can use ready-made solutions that already exist. This will save you time and make your work more efficient.

Reducing complexity: By adhering to the DRY principle, you create less code that needs maintenance and bug fixing. This makes your program less complex and less prone to errors.

Test-driven Development or TDD

Volodymyr — Sat, 16 Dec 2023 14:24:53 +0000

Let's talk about testing.

At which stage is it best to write tests?

Generally, there are three approaches:

Tests are written after the code
Tests are written alongside the code
Tests are written before the code

In some situations, there aren't many options. For example, in system testing, tests mimic user behavior and perform actions in a browser.

Such tests are written after the code.

For lower-level tests, integration tests, and unit tests, one of the above options is usually available. The "write tests after the code" approach is one of the least user-friendly methods.

Why?

The process of writing code itself implies constant running of the code and checking that it works. For the simplest tasks, like educational ones, this running happens quite quickly.

It's easy to execute and easy to verify the correctness of the results.

For example:

capitalize('hello'); // Hello

In real code, preparing data to test the code's functionality can take a lot of time, minutes, or even tens of minutes.

On the other hand, the result of the code being tested can be something complex, like a large number of records in a database or the output of a particular complex structure.

Then each code run for testing becomes an entire adventure.

It's difficult to prepare the data. It's difficult to check the work's result.

For example: Loading goods from 1C into a database.

loadGoodsFrom1c();

This is where the "write tests before code" option comes into play. For many beginner developers, this phrase confuses. How can you write tests before the code is written? It turns out, you can and it's even pleasant.

Suppose we want to write a function that can repeat a given string a specified number of times:

repeat('$', 3); // $$$

We know what it takes as input, we know what its output should be.

Can we write tests now?

Of course!

test('repeat', () => expect(repeat('$', 3)).toBe('$$$') )

How long does it take for an experienced developer to write such a test? I think about 15 seconds, which is exactly how long it took me to write the code above. But now, to check the functionality of this code, all you need to do is type the command jest in the console.

Testing before writing code has another powerful advantage. It forces the programmer to first think about the design of their solution, and how it will be used, rather than how beautifully they can implement it internally.

Well-designed interfaces are the key to success.

In the development world, the approach where tests are written before the code is called Test-Driven Development (TDD).

TDD
Nowadays, everyone continues to talk about this method. In it, tests are written for all parts of the code with maximum detail. This type of TDD, while emphasizing the importance of design, focuses on specific functions and classes of the application, instead of the whole picture.

But there is also another TDD, where tests on the internal parts are almost never written.

6 reasons why a project needs documentation

Volodymyr — Fri, 15 Dec 2023 10:58:15 +0000

Explanation and Clarification: Code comments help clarify complex code sections, ensuring a better understanding of the algorithms and logic used. This is especially important in the case of complex operations or non-obvious decisions.

Ease of Maintenance and Expansion: Quality documentation and comments make the code more accessible to other developers, facilitating easier maintenance and expansion of the codebase. This reduces the time needed for new team members to learn the code.

Reducing the Likelihood of Errors: A clear understanding of what each part of the code does can help avoid mistakes during modifications or adding new features.

Enhancing Collaboration Efficiency: In large teams, where many developers work on the same project, well-documented code helps prevent misunderstandings and ensures more efficient collaboration.

Standardization and Consistency: Documentation can include coding standards and practices that ensure consistency throughout the codebase, making it more readable and easier to understand.

Enhancing Quality for End-User Experience: Good documentation can include user instructions, FAQs, and troubleshooting recommendations, enhancing the overall user experience.

In conclusion, documentation and code commenting assist in the maintenance and development of software and provide a better understanding and efficiency in teamwork.

Why Naming in Development is Important

Volodymyr — Thu, 14 Dec 2023 10:52:01 +0000

Naming entities in web development is crucial for several reasons:

Code Readability and Understandability: Clear and descriptive names for variables, functions, classes, etc., make it easier for others and yourself to understand the code. For example:

// Bad naming
let x = 10;

// Good naming
let userAge = 10;

Maintenance and Refactoring: Well-organized code with meaningful names simplifies maintenance and refactoring. For instance:

// Bad naming
function doSomething(data) { /* ... */ }

// Good naming
function calculateTotalPrice(order) { /* ... */ }

Teamwork: Consistent naming is key for smooth collaboration in large projects. Example:

// Inconsistent
let user_data;
function getUser() { /* ... */ }

// Consistent (using camelCase)
let userData;
function getUser() { /* ... */ }

Project Scalability: Logical and organized names simplify adding new features. For example:

// Non-descriptive
function handleData() { /* ... */ }

// Descriptive
function processUserInput() { /* ... */ }

For effective naming in web development, follow these rules:

Descriptiveness: Names should reflect the entity's purpose. For instance, use fetchUserData() instead of just getData().

Consistency: Use a consistent naming style. In JavaScript, camelCase is commonly used.

Brevity but Clarity: Names should be short yet informative. Avoid long names that are hard to read.

Avoiding General Names: Avoid vague terms like data or info. Use specific names that indicate their purpose.

Using Standard Conventions: Follow the conventions of your programming language. JavaScript typically uses camelCase for variables and functions.

Avoiding Abbreviations and Acronyms: Except for well-known abbreviations, avoid obscure acronyms to prevent confusion.

Popular Style Guides for Web Development

Volodymyr — Wed, 13 Dec 2023 14:37:30 +0000

Using a style guide for coding can make you a better developer, as it fosters the development of several key skills:

Readability and Maintainability: You will learn to write code that is easy to read and maintain by other developers.

Attention to Detail: Following a style guide requires attention to detail, which is an important quality in programming.

Teamwork: You will be able to work more effectively in a team, as your code will be aligned with the standards accepted in the team.

Professionalism: A style guide reflects professional standards in coding, which improves the quality of your work and contributes to your professional growth.

List of popular style guides for web development:

Google Style Guides:
This resource includes style guides for various programming languages, including JavaScript, TypeScript, HTML/CSS. They are used for Google projects and can be useful for forming consistency in code. Google Style Guides.

Airbnb JavaScript Style Guide:
One of the most famous style guides for JavaScript. It contains detailed recommendations for writing readable and consistent JavaScript code. Airbnb JavaScript Style Guide.

StandardJS:
This is a style guide for JavaScript, which also includes configuration for automatic code formatting. It offers established rules that simplify the code-writing process, requiring no settings. StandardJS.

MDN Web Docs:
Although not a formal style guide, MDN Web Docs provides useful tips and best practices for HTML, CSS, and JavaScript. This is a great source for developers who want to adhere to best practices. MDN Web Docs.

TypeScript Style Guide and Coding Conventions:
As TypeScript is a superset of JavaScript, many JavaScript style guides can be applied to TypeScript. However, for specific features of TypeScript, this guide can be used. TypeScript Style Guide and Coding Conventions.

A library or your own code

Volodymyr — Tue, 12 Dec 2023 13:50:14 +0000

Have you ever connected lodash, or any other library, using a single function from it? Wouldn't it be easier to write that function myself, especially if I solved this problem on vanilla JS?

First of all, if you are looking for one, there is no definite answer to this question. In each case, you need to take into account many factors, starting with the nature of the code and ending with the launch conditions, i.e. where and how the program is launched. We will talk about this later.

On the one hand, the size of the code is almost irrelevant. Plus or minus a megabyte, or even ten megabytes, doesn't solve anything at all. Modern software has enormous resources, the weight of which is much larger than the size of any library. Even so, a library with simple functionality takes up a lot of space.

On the front end, everything is a bit more complicated, but now it all comes down to how the library is organized. If the export is properly configured, the final version (for example, built by a webpack) will contain only those functions that are used. And this is very little.

Dependencies:

Some developers minimize the number of dependencies (third-party libraries) in their code. Small functions are no longer enough here, complex projects can have their solutions with many ready-made tools.

There's not much to say here. Dependencies are good if they save developer time and allow you to spend more time on application logic than infrastructure tasks.

What are the advantages?

Not all libraries are equally useful. There are often several basic problems that are poorly implemented in the programming language itself. These include working with collections, working with dates and times. In addition, various more specific parts need to be extended. In these cases, the library must be added as a dependency even for a single function.

As a rule, where one function is needed, another soon becomes necessary. Without realizing it, one person will write one function, another will write it elsewhere, and there is no certainty that they are aware of each other's already written solutions.

This situation quickly turns from "too early" to "too late" when there are many functions in the code available in each library.

Moreover, when programmers move to other projects, the same thing happens there. As a result, standard functions scattered across different projects, written by different people, contain bugs, lack documentation, and are usually poorly or not tested at all.

Your code will not be as thoroughly tested and documented as in popular libraries. Try opening lodash and see how extensive the documentation is. This is another advantage of such libraries. Since the library is so widely used and standardized, most developers know how to work with it.

This means the project code will be more understandable for everyone who works with it.

There is another interesting but not obvious advantage of using such libraries.

Libraries contain many functions that are difficult to understand on their own. By using these libraries, developers can increase their level of knowledge and learn how to solve most standard problems with a minimum amount of code and correct abstractions.

Of course, these functions need to be reviewed periodically. Students regularly reinvent the wheel because they don't know about standard solutions. In addition, when we say that only one function is needed, it turns out that there are actually several, and the developer may simply not be aware of them.

For other rare libraries, the situation is more complicated and it's not always clear whether to pull with the library. The key to making such a decision is realism, not completeness.