DEV Community: Hamit SEYREK

8- What is Git? Why should I use it? What is Github, Gitlab, Bitbucket used for?

Hamit SEYREK — Mon, 28 Mar 2022 12:25:50 +0000

We have finally come to the **Git **version control system, which allows you to keep your codes more organized, which we talked about throughout the Advanced Software Development article series. If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.

Everyone gets errors while writing code. While trying to fix that error, we sometimes try more than one solution that we found on the internet. And, there are times when we crash other parties. In such a case, we may want to restore our project to the state after than applying those trials/solutions. While dealing with all this, it can sometimes be too late when we realize that we are making our project worse.

Of course, these are all memories of when we were unaware of the Git version control system. Fortunately, these problems are now a thing of the past, thanks to Git. Git is very useful for anyone who writes code or who sometimes wants to revert to previous versions.

Of course, this is not the only benefit.

Projects rotting on hard drives are now gone from our lives. We can find the pure version of a module we have written among the versions and use it in our new projects. In this way, we are now able to develop projects faster. Each version of each project we do is kept in the Git system on a regular basis.

While there are version control systems such as Git, Mercurial, BitKeeper, CVS and SVN, Git is the most used version control system. Nearly 43% of professional software developers prefer Git.

Git's contributions to teams are another feature. In cases where more than one person works on the same project, a record is kept of who made what changes and what they did. The desired change can be undone instantly.

In short, using Git for all your projects that you develop alone or with your team will make you a more organized and more practical developer. Because the changes made by any of the team members can be seen by the other members. You can pull the changes made by other developers to your own computer with a single command.

Git is software that works locally. After Git is installed, it is easier to follow the versions thanks to such a Client interface program. Thanks to GitHub Desktop, Sourcetree, Fork etc. desktop applications, you can follow the version controls of the projects you have developed on your own local computer.

Why should I use it?

There are more advantages to using Git online. In this way, you can access your projects from anywhere, as well as share them with other members of the team very easily. While all members of the team are working on the same project, Git helps you a lot in merging all commits. Online storage systems such as Github, Gitlab and Bitbucket use the Git version control system. On these platforms, you can keep your projects either public or private.

All the systems we mentioned in other articles (Devops, Agile, SOLID, etc.) actually require the use of git. Or we can say that Git makes it possible for such systems to work. Because growing projects as a single module does not comply with any software development principle. Git both encourages modularization and makes it more feasible. Projects developed by large teams are shared among team members in modules. Thanks to Git, multiple modules of the project (interface, registration form, api, basket part, payment modules, etc.) can be developed by different people in parallel.

When changes made in teams where Git version control is not used are added to the main project, things do not always go as desired. For example, when your customer says they don't want module X anymore, it will be very difficult to find all the other modules that that module affects. Thanks to the Git branching system, modules can be removed from the system much more easily.

One of my favorite features of Git is that it gives me the chance to experiment without limit.

I can do all the ideas that come to my mind with the comfort of knowing that I will not break the project. Even though I don't use most of my ideas afterwards, I can sometimes come across something creative. We can say that this comfort has increased my creativity. This comfort can accelerate the development of newcomers, less experienced fellows, as it gives them the opportunity to try things out without breaking them. Because you can undo your mistakes whenever you want. And without a single line damaging the project :)

With Git version control, you can write the commits you have made in an explanatory way. Which change why was made can be easily seen by all team members. When you commit, the Git system not only takes a snapshot of the current state of your project, but also shows you comparatively what has been done down to the smallest detail. Not only does it keep file changes or lines added/removed, it even saves a single space character that has changed in the file. In this way, your progress will be much stronger. The important point here is that when you commit, you should pay attention to a single subject if possible. When you undo multi-subject commits, you may be deprived of more than one change. But a commit with a single feature is more useful for undoing transactions related to only that feature.

Many companies work offline for security reasons. But in the offline working model, which can be realized thanks to Git, even when a problem occurs on the main server, since each developer has a sub-version, the work can continue without stopping.

Conclusion

Without a doubt, what a developer fears most is data loss. Sometimes we think that we have taken a backup, but we had not get it completely. Sometimes, the backup files we receive can be infected with viruses and corrupt our backups. Data loss is actually the worst thing that can happen to a project. But luckily Git got us out of this trouble as well. In fact, it saved the companies. Because versions of a project are kept on each developer's computer. A user who uses Git has a full-fledged copy on his computer as well as a record of all changes made to the project.

There is a difference between someone who has actively written code or a project that can be referenced in their CV and someone who does not have any work :)

In the article, I touched on why we should use Git. I'll leave it up to you to research how to use it. Don't wait, start now. There is no doubt that using Git will make you a better developer.

In the Advanced Software Development series:

Previous article: "7- What makes SOLID principles special? Are there any other software development principles? What are they?".

Don't forget to like if you think it's useful :)

Always get better...

7- What makes SOLID principles special? Are there any other software development principles? What are they?

Hamit SEYREK — Mon, 21 Mar 2022 15:26:47 +0000

Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

It's time to talk about SOLID, perhaps the highlight subject of our Advanced Software Development article series. If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.

You all know that SOLID is the indispensable question of recruitment interviews today. SOLID is an acronym for the top five object-oriented design (OOD) principles first introduced by American software engineer and educator Robert C. Martin in his 2000 article Design Principles and Design Patterns.

If you're familiar with Object Oriented Programming, you've probably heard of SOLID principles already. Before explaining what SOLID is, I would like to touch on why it is needed.

The software industry is getting popular day by day. The time shows that it will become more and more popular. As the popularity increases, there is a serious increase in the number of people entering the sector. This is why the Codemvia Community was established. Because while the interest in the sector is constantly increasing, software experts who write high quality code do not increase with the same momentum.

Today, companies are growing and the world is becoming a global village. Naturally, software projects that serve all this wheel can become gigantic. It is getting harder to ensure sustainability in these growing projects. The number of people working on a project is increasing and terms such as Agile and DevOps are entering our lives. It is difficult for newcomers to adapt quickly to large projects written by large teams or to add new features to these projects.

Loosely Coupled, a software development principle put forward as a solution to this problem, provides a high level of benefit. Loosely Coupled a software development principle that allows modules of a system to be used or expanded separately from each other. This principle, which argues that a project should not be tightly bound to an object in order to work, has a very important place for the software development system. Although the Loosely Coupled principle is not included in the SOLID principles, it is an important underlying issue.

SOLID is an acronym consisting of the initials of 5 principles. Let's talk about these principles:

S — Single Responsibility Principle (SRP)

This principle says that a class, module or function should be only one area of responsibility. What we call Loosely Coupled should show itself here. Classes should be clearly separated from each other. Each class should be responsible for only one function of the program it is in and should cover this part. Robert C. Martin tell “A class must have only one reason to change”.

O — OCP (Open/Closed Principle)

Every class, module, or function should be open to development but closed to change. A module prepared according to this principle should be impervious to change of source code but should allow extension of its behavior.

L — LSP (Liskov's Substitution Principle)

This principle says that the subclasses of the classes can be used for the same function.

I — ISP (Interface Segregation Principle)

This principle, which means the separation of interfaces, tells that interfaces should not be too large, divided into smaller interfaces. In this way, each interface will only have the functions it will need and will not run unnecessary codes. Every job that can be separated from each other should be designed with different interfaces. While other principles are more about classes, this principle is more about interfaces.

D — DIP (Dependency Inversion Principle)

The dependency reversal principle recommends using abstract classes instead of concrete classes. Because if high-level classes become dependent on low-level classes, improvements to be made may require changes in more than one class, as it will affect the main class. If instead they are linked to abstract classes, the principle of Loose Dependency will be more adhered to.

I have tried to briefly explain the principles that the initials SOLID represent. Of course, SOLID is not such a simple thing. A series of articles should be written on each principle; has already been written. However, it should not be overlooked that all of the SOLID principles are related to Loosely Coupled.

Although the use of SOLID principles is not mandatory, it is clear that the use of it will increase the quality and prevent a serious loss of time in the expansion stages of large projects. Projects developed without complying with SOLID principles have a shorter lifespan. Because it will not be able to handle expansions that will be needed in the future. You can all guess that software is like a living living organism. It is not stationary. They need to be constantly improved. I think we agree that 10 years ago, if the best software is not developed, it will still not be the best software. That's why it will make our job easier to comply with SOLID principles in order to carry out a continuous renewal, development and expansion work more flexibly.

Of course, there are many principles when it comes to software development. Apart from the SOLID principles, I would like to talk about these three principles in one sentence too:

YAGNI (You Ain't Gonna Need It): The YAGNI principle recommends adding no extra functionality until you really need it.

DRY (Don't Repeat Yourself): The DRY principle, which says "Don't repeat yourself", recommends that functions that perform the same function in more than one class should not be written over and over again.

KISS (Keep It Simple Stupid): The KISS principle asks us to keep things as simple as possible. Like that everyone who sees can understand. Contrary to the view that complex works are professional, he argues that simple designs are thought of more intelligently.

We must pay attention to the principles of software development so that we can provide the features that large projects should have, which we can describe with simple, extensible, flexible, developable, updateable, readable, plain and many other similar terms.

In this article, I touched on why principles should be, rather than what they are. But don't stop here. Be sure to keep researching what they are and how they are applied. I'm thinking of writing a separate article about how these principles are applied in Swift. Regardless of the language or framework you use, you will definitely find sample applications on the internet.

Be sure to try and even make it a principle to abide by these principles. There is no doubt that you will see the benefits. They will make you a better developer.

In the Advanced Software Development series:

Previous article: "6- What is Agile Scrum methodology? What are the benefits to software development teams?".

Next article: "8- What is Git? Why should I use it? What is Github, Gitlab, Bitbucket used for?".

Don't forget to like if you think it's useful :)

Always get better...

6- What is Agile Scrum methodology? What are the benefits to software development teams?

Hamit SEYREK — Mon, 14 Mar 2022 14:54:36 +0000

Will the project reach this date? Urgent!! Agile is the method not applied in companies where the completion time of such projects is valued more than the quality.

Organizations that can be shaped according to market conditions and are open to change are Agile organizations. In traditional companies, personnel do not have time to think, they have no authority to interpret, their own initiative is minimal. Because the chain of command is very strict. And the company has a manager who knows everything. Ideas of employees that can add value to the project or company are not considered. This leads to a decrease in motivation over time and eventually the loss of personnel.

Of course, it is not right to expect innovative and high value-added projects to emerge in environments where mistakes are not welcomed, covered up, and is paid for with overtime, low promotions or low salary increases. Projects like this are always patched or stuffed with irrelevant modules or classes that don't fit, making them cluttered and underperforming. However, in agile companies, mistakes are seen as tutorials to take one step further. With the experience gained, mistakes that can make the project worse later are prevented.

Agile companies are not a company where personnel performances is measured by what is written in weekly reports. Instead, they are structures where the employee is valued, the impact of the work done is prioritized rather than the size. Agile companies are places where leaders who personally take part in projects, guide, help and motivate work, rather than managers who know everything and just say do it.

This time, I started by praising Agile culture, which is another very important topic of the Advanced Software Development article series, and criticizing the traditional method (If I made a mistake, support me with your comments. Let's correct it together.). If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.

Now back to our topic, what really is Agile?

Agile is a process that allows a team to manage a project more efficiently by dividing it into several phases.

Although Agile has been partially implemented in many sectors, especially the software industry, since the 1970s, it was fully defined with the Agile Manifesto published in 2000 by a group of developers looking for a new software development method, with the effect of the Scrum methodology that emerged towards the end of the 1900s.

12 principles for Agile are identified in the Agile Manifesto:

Customer satisfaction
Early and continuous delivery
Being open to change
Frequent delivery
Business and developer collaboration
Motivated individuals
Face to face meeting
Clearly defined transactions
Technical competence
Simplicity
Self-organized teams
Editing, mirroring and adjusting

You may have heard the term Agile mostly with scrum methodology. So let's explain the term scrum. Scrum is one of many types of agile methodology known for breaking down projects into large chunks called "sprints". It is an Agile method that contains meetings, roles, and tools to help teams working on complex projects collaborate and better structure and manage workloads. Although it is known for its frequent use in the software industry, it can actually be used by any team. You can apply the scrum methodology even within the family. After all, every family counts as a small team serving a common purpose :)

Scrum is used to manage complex projects or by companies that are results-oriented, efficient, and focused on innovation. Scrum is a very good project management system for customer-oriented companies as it is more adaptable to customer preferences thanks to its flexibility.

Agile Scrum Methodology

The combination of the Agile philosophy and the scrum framework creates the “Agile Scrum” methodology. Agile scrum methodology can be used for companies of all sizes. Actually, agile and scrum are two different methods and can be used separately; however, the benefits of using them together make this compound structure the most popular of the agile methods.

While other project management methods often emphasize building an entire product in a single operation from start to finish, agile scrum methodology focuses on delivering several iterations of a product to stakeholders to deliver the highest business value in the least amount of time.

Agile scrum methodology is a project management system based on incremental development. Each iteration consists of two to four weekly sprints. The goal of each sprint is to establish its specified characteristics and produce a potentially deliverable product. Subsequent sprints are adjusted based on stakeholder and customer feedback as more features are added to the product.

What benefits does the Agile scrum methodology provide?

Agile scrum methodology has many benefits. The biggest benefit is that it is flexible and adaptable. In this sprint-based method, feedback is received from the team and stakeholders after each sprint. If there is any problem or change suggestion, the scrum team adapts it to reach its target more easily and quickly to the new sprints to be planned. This way all stakeholders of the project are happy because they are involved in every stage of project management. This increases employee and customer satisfaction as well as increases organizational synergy.

Compare this situation with situations where you had to make customer annoyance and voiced change requests after most, or worse, the entire project, where stakeholders were not involved. Either you compromise the performance and algorithm by making big changes in the project, or you start the project from the beginning and cause more costs. This situation, which is frequently encountered in traditional methods, reveals how important the agile scrum methodology is. Based on these, we can conclude that the agile scrum methodology also reduces costs.

The benefits it provides to the project in terms of creativity, innovation and quality can be counted among the other benefits of agile scrum, as ideas are taken from all stakeholders in each sprint.

There are three basic roles in Agile scrum methodology: scrum master, product owner and scrum team. Everyone is equally dedicated to the project. A team working for a single purpose. Let's talk briefly about these roles:

Scrum master: The scrum master is the facilitator of the scrum development process. It ensures that the scrum rules are implemented as intended, as well as holding daily meetings with the scrum team. The Scrum master is a leader, not a manager. Coaches and motivates the team. It seeks to remove obstacles to sprints and ensure that the team has the best possible conditions to achieve its goals.

Product owner: The Product Owner is the person who tries to maximize the value of the product. This is no easy task. It should ensure that the expectations of all stakeholders who use or will use the product are met. Accordingly, his main task is to set the expectations of the product and manage a scrum backlog, which is a detailed and constantly updated to-do list for the scrum project. He checks that each sprint has achieved its goals, and expresses his ideas to the scrum master or the scrum team at sprint meetings where necessary.

Scrum team: A Scrum team is a self-organized group of three to nine people who do the work themselves, with the business, design, analytical, and development skills to solve problems and produce deliverables. This team is responsible for achieving of each sprint.

To ensure that the scrum principles are properly applied in the Agile scrum methodology, there must be a scrum expert in the company or an outside scrum expert consultant.

For now we have come to the end of another article. I also published the 7th article of the series. Now you know how important Agile Scrum methodology is for large-scale companies or quality projects that I have mentioned in every article, or how much it will contribute to the project. I'm ending this article here, but don't stop here, keep researching. Moreover You can check the scrum.org platform for scrum master trainings and certification.

In the Advanced Software Development series:

Previous article: "5- What is Continuous Integration and Continuous Delivery? Why should it be used?".

Next article: "7- What makes SOLID principles special? Are there any other software development principles? What are they?".

Don't forget to like if you think it's useful :)

Always get better...

5- What is Continuous Integration and Continuous Delivery? Why should it be used?

Hamit SEYREK — Mon, 07 Mar 2022 13:40:57 +0000

“In software, when something is painful, the way to reduce the pain is to do it more frequently, not less.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

I am here with another very important topic of the Advanced Software Development article series. In this article, I will talk about CI/CD, which is an indispensable part of DevOps. If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.

You are likely to have heard of the term CI/CD, both in the business world and in your own research. It is an integral part of DevOps, which was the subject of the previous article.

CI (Continous Integration) is a continuous control mechanism without integration after the code is developed. All developers send their changes periodically (usually daily) to the main server. It is very important that these changes do not affect each other or cause a new problem. Developers should review old commits before merging any changes they make. Although it does not pose a problem at first, it is both costly and difficult to manually check whether a change made in growing projects causes another problem in the system. Because there may be hundreds or even thousands of merges that have been made before. For this case, the term Integration Hell is used.

Automated tests are used to solve this problem. While running tests on a CI server requires passing tests to ensure integration, such servers also facilitate analysis, performance measurement, and QA of the source code.

Thanks to this continuous quality control (QA), both the software quality is improved and the job is delivered faster as no separate time is required for integration.

CD stands for continuous delivery and continuous deployment. Continuous integration starting with CI is continuously deployment on CD. The tests are run in the CI phase and the new version of the application is distributed in the CD phase.

The CI feedback loop provides automatic feedback to the developer by automatically performing tests for the entire given project in a short time.

You may have witnessed that the CI/CD pipeline is viewed as unnecessary by some circles or is passed on as an overhead. But this is completely wrong. Because there are some steps that must be followed before a new version of a software product can be released.

Performing the steps you see in the picture above manually without the CI/CD pipeline will take much more time, causing the team to work with lower performance. This naturally increases the cost of a software.

A good Pipeline consists of these main parts:

Compiling and testing the code (Continuous Integration)
Creating a ready-to-deploy build from code (Continuous Delivery)
Automatically deploy the application to a server (Continuous Deployment)

The first step in a CI/CD pipeline for a good Pipeline is to have an automatic triggering system. The easiest way is to configure the CI/CD tool to check for changes in a Git repository. If you set up the pipeline bot to be run manually, this increases the cost and is sometimes forgettable. In an auto-triggered system, you have the peace of mind knowing that your code will be tested for every change.

CI tool triggered after auto-trigger checks the code in use Github, Bitbucket etc repository. The pipeline followed by compiling the code can do this very easily with Docker. Language-appropriate compilation is made in new environments to be created with container structures to be installed on Docker.

After the compilation phase, the testing phase is started. The CI/CD tool must be configured correctly for the tests to run correctly. It is also very important that being sustainable , as well as the tests are implemented and passed successfully . If you continue to develop the application and add new modules, but do not develop the tests in the same direction, this will endanger the sustainability of the application.

The majority of your tests should be unit tests. Unit tests give you value for money. It is easy to write, inexpensive to run, and least costly to maintain. Martin Fowler

After all tests are passed successfully, you can move on to packaging the code. How you package it depends on the programming language you use or your target environment. If you are using Docker, which is common use in DevOps, you can create a "Docker Image".

Now that we've done the packaging, we can start the acceptance tests. Acceptance testing is a way to make sure your software does what it's supposed to and meets the original requirements. For automatic acceptance tests, you can use the Selenium tool, which can simulate user behavior such as opening websites and clicking certain places.

Our software, which has successfully passed the acceptance tests, can now move on to "Delivery and Distribution" that is the final stage. You can now distribute your software, which has reached the Continous Delivery stage, thanks to a tool that enables distribution such as Kubernetes (Continous Deployment).

From now on, every code change you make in the software will start with the trigger phase and go through the same phases. For CI/CD Pipeline to be successful, great attention must be paid to testing, ease of use, and security.

Thus, deployment ceases to be big scary job done once after the whole project is finished, and becomes an easy process that is done regularly.

The earlier you catch defects, the cheaper they are to fix.
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

CI/CD is one of the most influential changes in the software development industry. Here are a few advantages of adopting CI/CD in your software development process:

CI/CD has allowed companies to update and deliver their software faster.
It made possible the possibility of controlled remote working.
It provided more solid progress with the tests applied continuously.
It saves time, as it provides instant feedback to the developers and solves the errors before they grow.
It made the delivery step easier.

Most used CI/CD tools: Jenkins, CircleCI, Bamboo, TeamCity, GitLab, Travis CI, Buddy …

You can find more resources by researching the CI/CD actions of these tools. Regardless of the language you use, let me end this article by saying that you should definitely try to apply a few of the CI / CD tools :)

In the Advanced Software Development series:

Previous article: "4- What is DevOps? What are the benefits? What tools does it use?".

Next article: "6- What is Agile Scrum methodology? What are the benefits to software development teams?".

Don't forget to like if you think it's useful :)

Always get better...

4- What is DevOps? What are the benefits? What tools does it use?

Hamit SEYREK — Mon, 28 Feb 2022 12:10:00 +0000

A compound of development (Dev) and operations (Ops), DevOps is the union of people, processes and technology to continually provide value to customers. Microsoft

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. Amazon

Here I am again with the 3rd article of the Advanced Software Development article series. I wanted to start by giving the definition of the term DevOps by two big companies. If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.

Microsoft and Amazon's DevOps definitions actually summarize DevOps very well. We can say that DevOps is not a tool, a set of tools. I would say that DevOps is not a subset of CI/CD, as most blog posts imply, but rather consists of continuous planning, continuous integration, continuous delivery, continuous testing, continuous monitoring, implicit feedback, and traceability. DevOps is as much about the culture as it is about the tools it uses.

State DevOps is not easy to adopt. Information flow, shared responsibilities, learning from failures and adopting new ideas are very important for the formation of this culture. With the adoption of DevOps, the biggest advantage that comes with team building and each member having responsibility is to provide more control while developing the application without slowing down. Because everyone will pay more attention to their steps with a sense of responsibility.

The formation of this culture is a significant challenge and requires professional attention. The 2015 State of DevOps Report listed the top 7 metrics with the strongest correlation to corporate culture as follows:

1- Institutional investment
2- Experience and effectiveness of team leaders
3- Continuous delivery
4- Communication of different disciplines (development, operations and information security)
5- Organizational performance
6- Development issues
7- Lean management practices

In order for the culture to be adopted and DevOps to be realized;

Architecturally important requirements
To effectively implement DevOps, software applications must meet a number of architecturally important requirements, such as deployability, interchangeability, testability, and monitoring capability.

Micro Services
While in principle it is possible to implement DevOps with any architectural style, the micro services architectural style is most commonly used for building continuously distributed systems.

DevOps Automation
It also supports consistency, reliability, and efficiency within the organization and is often enabled by a shared code repository or version control.

Through DevOps, there is an assumption that all functions can be executed, controlled and managed in a central place using simple code. Ravi Teja Yarlagadda

Version Control
Many organizations use version control to support DevOps automation technologies such as virtual machines, containerization (or OS-level virtualization), and CI/CD. All developers need to make changes to the same codebase, and sometimes even edit the same files. For efficient work and to avoid conflicts, Git version control system (Github, Gitlab, Bitbucket etc.) should be used.

We talked about DevOps tools throughout the article. To give an example of a few of the most preferred:

Communication: Many companies working around the world use Slack for team communication. It is very successful in communication related to the workflow.

Continuous Integration (CI): Many of the tasks involved in the software development lifecycle (SDLC) can be automated with Jenkins. In this system, where all tests can be carried out automatically, if a certain sprint causes a broken structure, the system will inform you thanks to quick feedback.

Containerization: Docker is the most popular tool that allows applications independently of the running environment to be packaged, deployed, and run. This technology, which allows more than one container to be created on a single operating system, reduces costs. Most of the enterprise companies have preferr Docker for containerization.

Security: A safer development can be achieved in all phases of SDLC with the Phantom tool, which provides DevOps engineers with options such as device or file quarantine and reduces the risks that may occur. If we bring together the fact that security is the most important component for DevOps and the fact that Phantom has many features for this, it will be understood why this is the most preferred one.

Management: By allowing to create or manage developer virtual machines in a single workflow, the Vagrant tool eliminates the "works only on my machine" excuse, allowing the project to remain the same on all developers' machines. Another management tool, Ansible, is an editing and configuration management tool that provides simple usage opportunities as well as effective. It is not very affected by the resources used in the background of the device. It is used to make new changes within the existing system or to configure newly installed servers. Reducing infrastructure costs is among the reasons for preference.

Version Control: Undoubtedly, the most used version control system is the Git system, as you all know. Thanks to its easy and widespread use, Github is the most preferred tool. The commit system, it is possible to revert to the desired version instantly. Changes to the code are instantly communicated to team members with notifications. Developers can also choose Gitlab or Bitbucket tools to meet the paid features of Github with less cost. Bitbucket's easy integration with Jira and Trello can provide an advantage.

Development Issues: Ruby, Swift, JavaScript, PHP etc. Sentry tool, which has customizable SDKs to support many languages or frameworks such as Microsoft, PayPal, Pinterest, is one of the most used DevOps tools for bug detection. For example, with the integration that can be done quickly in frameworks such as Laravel and SwiftUI, you can easily catch every possible error with Sentry.

Now, a question may have in mind!

What does DevOps have to do with advanced software development or code quality?

DevOps aims to better connect development and operations teams with each other. In other words, there are two teams in the middle and it facilitates communication. If you are working alone or with 2-3 people today, you do not need to use the DevOps model. You can use some of its tools, such as Git, but you don't need to fully adopt it. If your goal is to work in large corporate companies, it is useful to have a general knowledge of DevOps. Because most of the large-scale companies today have either adopted or are considering the DevOps model. To be a part of such a team, you should not be unfamiliar with the technologies that such teams use and the cultures they adopt.

We are in a fast developing industry. We need to be in constant research and study. If you search, you can find more detailed documentation about the tools DevOps uses.

In the Advanced Software Development series:

Previous article: "3- Why Should I Write Tests While Developing Software?".

Next article: "5- What is Continuous Integration and Continuous Delivery? Why should it be used?".

Don't forget to like if you think it's useful :)

Always get better...

3- Why Should I Write Tests While Developing Software?

Hamit SEYREK — Mon, 21 Feb 2022 13:01:36 +0000

Hi everyone. Here I am again with the 4th article of the Advanced Software Development series. If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.

Now on to the subject of testing, "Why is testing so important when developing software?" I think we can start by looking for an answer to the question.

It is impossible not to make mistakes while writing code. We all make mistakes. While some of them are insignificant, some of them can be vital for the software. In such a situation, we may not always to be tolerated by our team leader, boss or customer.

After writing our code and revealing our product, we cannot catch the blind spots in the manual tests we do individually. Because we test our product from the perspective we have when writing. In such a case, we are likely to miss the same blind spots again.

When we look from a professional point of view, we see that the majority of corporate companies now use advanced project management systems. All of these project management systems, which pay attention to the software development life cycle, use software tests. The Software Testing Lifecycle (STLC) is an integral part of the Software Development Lifecycle (SDLC). While this is the case, it has become mandatory for us to write test codes. Otherwise, it will be very difficult for us to find a job in a large corporate company. Our advanced software development process will end at the beginning of the road.

Tested software enables you to provide customers with quality software that requires less maintenance, making you more reliable and professional.

A continuous verification and validation process is required to deliver a great product. Tests measure the performance and efficiency of the system/application, helping to ensure that the software is compatible with all technical and business parameters.

There are many different testing methods you can use to make sure changes to your code are working as expected. We can divide these into two main groups as manual and automatic tests.

Manual Test: It is done using the software personally. This is very costly as it requires someone to devote time to it. At the same time, since the tester is a human, there is a high probability of making mistakes.

Automatic Test: It is done by running pre-written test codes. Here, the tester is the machine itself. It is ensured that all conditions written in the test function are met.

Automated testing is important component of Continuous Integration (CI) and Continuous Delivery (CD) of DevOps tools . It is also an important part of the QA (Quality Control) process.

Test Types

Unit Tests

They are low-level tests used to test the functionality of classes, methods, or functions we create in software. Unit tests can be easily automated by CI (Continuous Integration) servers.

Integration Tests

It is the type of test where we test how well different modules or services used by our application work together. Since this test type requires interacting with more than one module of the software to be successful, it is more costly to run than unit testing. For example, integration tests can tests whether the interaction of some modules with the database works correctly or whether some microservices that are separate from each other in a software work as expected.

Functional Tests

Sometimes Functional Tests and Integration Tests are confused because both work with different modules. Functional Tests focus on the business needs of the application. It focuses only on the output of event. Unlike Integration Tests, it does not question the relationship of modules with each other. It is enough that the output is correct for this test to be successful.

End-to-End Tests

This test imitates user behavior. It is used to verify whether various user flows are working as expected. They are more costly to implement. They are more complex in structure. It is generally recommended to be used at a few different points of vital importance in a software. For the rest of the software it makes more sense to use the less costly Unit Tests and Integration Tests.

Acceptance Tests

User behaviors such as End-to-End Tests are emulated. Acceptance Tests are used to verify whether the application meets all desired business requirements. If not all requirements are met, the test will fail.

Performance Tests

As the name suggests, it is used to measure performance. They are often used to measure the response time of the system when executing a large number of requests or the behavior of the system under a heavy load. These tests are costly as serious server power is required. However, it is very important to implement it after major changes to be made in future software.

Smoke Test

Smoke tests are used to test the main features of the application. They are therefore faster. They do not need to be written for each module. It is enough to focus only on the main features.

Whatever programming language you use, there are definitely many different test options for it. For example, there are Appium, XCTest, Calablash, Detox, OCMock and EarlGrey test frameworks for iOS, while PHPUnit, Mocha and RSpec frameworks are used for PHP and JavaScript. You can find the best by doing research in the developer communities.

Tests can be run with the help of a compiler or directly from the command line, or they can be automated with CI from DevOps tools. (CI pipeline consists of Build-Test-Deploy steps. If the test phase, which is the 2nd step, is not passed, the application will never be deployed.)

Test Processes in Software

We have mentioned code quality in every article of the Advanced Software Development series. Now let's add one more to the code quality's properties. Quality code is also error-free code. To ensure this, we need to test the software. While software tests are written TDD, BDD, DDD, RDD, FDD, ATDD etc there are many approaches. I will briefly touch on the most commonly used TDD and BDD approaches. But my advice to you is to read at least 1-2 articles about other approaches. Even if you are going to use TDD, it is useful to at least know why you should choose it and why it differs from others.

TDD - Test Driven Development

This approach, released in 2003, is the most-used testing approach. The TDD approach is not a test type. It is more of a way of doing software testing, a software development tactic. The TDD approach requires that test codes be written before software codes are written. TDD helps the software to come out in a simpler and simpler structure as it requires the expectations to be determined beforehand so that the tests can be written in advance. This makes the quality of the software better.

In the TDD approach:

1- [Write Test] Write a test for a situation.
2- [Fail] The test is run. The test fails because there is no function/method that does this yet in the software.
3- [Refactor] The necessary codes are written/edited to pass the test. The test is passed successfully.

[Write Test] - [Fail] - [Refactor] steps continue in the loop. The application is subjected to a continuous refactoring process until the software is able to meet all the demands of the customer.

BDD - Behaviour Driven Development

In this approach, which was put forward in 2009, the TDD approach was tried to be facilitated. In line with TDD, tests are written in advance in the BDD approach too. Behavior Driven Development (BDD), as the name suggests, is a behavior-based software development method. Business analysts and developers determine the required behavior of the software with meetings.

In the BDD approach, three scenarios are establishing: "Given", "When", "Then". These scenarios are writting in colloquial language. Writing tests in spoken language are the advantages of BDD. Members who will join the team later can understand these tests much more easily.

Conclusion

After giving a brief overview of the testing approaches, you now know exactly what the "Test" folders were created for in the framework you are using. Just knowing is not enough, it is also necessary to use. If you want to find a job in corporate companies that manage their projects with Agile, the code you will write should be testable code. The easiest way to achieve this is to use one of the testing approaches.

While the importance of writing test code is sometimes difficult to understand, it should be measured not just by the cost and time spent, but by the great value it brings.

In the Advanced Software Development series:

Previous article: "2- Why/How to Write a Comment? What is Clean Code?".

Next article: "4- What is DevOps? What are the benefits? What tools does it use?".

Don't forget to like if you think it's useful :)

Always get better...

2- Why/How to write "Comment"? What is Clean Code?

Hamit SEYREK — Mon, 14 Feb 2022 12:56:47 +0000

CleanCode

Have you ever been significantly impeded by bad code? If you are a programmer of any experience then you’ve felt this impediment many times. Indeed, we have a name for it. We call it wading. We wade through bad code. We slog through a morass of tangled brambles and hidden pitfalls. We struggle to find our way, hoping for some hint, some clue, of what is going on; but all we see is more and more senseless code.

Of course you have been impeded by bad code. So then—why did you write it?

Were you trying to go fast? Were you in a rush? Probably so. Perhaps you felt that you didn’t have time to do a good job; that your boss would be angry with you if you took the time to clean up your code. Perhaps you were just tired of working on this program and wanted it to be over. Or maybe you looked at the backlog of other stuff that you had promised to get done and realized that you needed to slam this module together so you could move on to the next.

We’ve all done it.

We’ve all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing. We’ve all said we’d go back and clean it up later. Of course, in those days we didn’t know LeBlanc’s law: Later equals never.

Here I am again with the 3rd article of the 0- Advanced Software Development article series. I wanted to start with a short excerpt from the chapter of Clean Code titled Bad Code. With the hope that you will develop software that you do not say "later"...

A good software developer writes quality code. The quality code is written with attention to many important issues such as architectures, tests, ci/cd, solid etc. Sometimes, no matter how careful we are, after a while, the work we receive from our managers, especially with the "URGENT" code, can turn into a mess, which we call spaghetti code. The "URGENT" code not only makes us panic and lowers the quality of our code, it is also losed us more time at the end of the day. Because it will always be more difficult to edit these codes later or add new features to this software.

Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. Robert C. Martin Clean Code

Of course, within the scope of this article, I will not translate the Clean Code book. In this series of articles, I talk about the issues that a person who wants to develop Advanced Software should pay attention to, focus on and research. If you want to develop advanced software, I can definitely say that it is a book you should read. It is certain that you will make much more profit than the time you spend reading the book. I'll leave the link here for those who want to read it. Clean Code

What are the features of clean code? To answer the question in items:

1- It should be readable, changeable, expandable and easy to maintain.

2- It should be written in accordance with SRP principle. To give an example of the Single Responsibility Principle, we can say that each method should serve only one purpose.

3- Architecture should be created appropriately. The purpose of all files should be clear. It will be easier to find what you are looking for. It saves time.

4- There should be no commented code blocks called zombie code. This will only confuse team members. Why was this written? Will it be needed in the future? It is losed time with questions like this.

5- All tests must be written and passed. In this way, it can be easily determined that future developments will not affect the old sections.

6- Each file in the project must contain codes only in the language specified in its extension. For example, instead of writing JavaScript/CSS in a file that ends with .php, creating a .js/.css file will provide a more organized structure.

7- It shouldn't be necessary to study all the code to understand any function. A simple action, such as an meaningful name , saves team members time.

8- Code duplication should be avoided. A method/function that does the same job should not be written over and over again.

As a result of my experience and research, I can say that you can write better quality code if these items are followed. That supported these, there are the following sections in the Clean Code book:

Meaningful Names, Functions, Classes, Exception Handling, Appendix, Formatting, Comments, Systems, Emergence, Concurrency, JUnit Internals, Smells and Heuristics, Refactoring, Successive Refinement, Unit Tests, Boundaries, Objects and Data Structures.

It is not possible to explain them in a single article. One or more articles should be written for each title. Here in the article I wrote only the section names. I'm thinking of writing articles on application examples that I will use Swift language for these section titles in the future.

Comments

As I mentioned before, the best comment is the one that is not needed. Code that is self-explanatory is best. The comments we try to explain our code are an indication that our code is not good. The best project is the one for which the README file is sufficient and does not need comments.

So why and how to write a comment?

We can use comments as a communication tool between team members. We can use it to indicate how much work has been done, or to tell another team member what to do next. When assigning a new task to a team member, after the file is opened, which functions should be written in this file can be written in the form of a comment block at first. Of course, comments written in this way should be deleted after their functions are finished.

We should use it to explain why a function is written, not to explain how it is written. Although there are many resources on how to write code, there are not enought resources on how to write comments.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler

Some sources say that comment lines should be at least as many as lines of code. I think that this point of view does not reflect the truth completely. Because measuring the number of comment lines in a program is easy. But measuring comment quality is not easy. An unwritten comment is better than a bad/unnecessary comment.

Writing good comments is harder than writing good code. Your compiler doesn’t check your comments so there is no way to determine that comments are correct. Peter Vogel

How to write a Clean Comment?

1- Comments should not duplicate the code
2- Good comments do not excuse unclear code.
3- If you can’t write a clear comment, there may be a problem with the code.
4- Comments should dispel confusion, not cause it.
5- Provide links to the original source of copied code.
[Source: https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/]

As Stack Overflow co-founder Jeff Atwood has written, “Code Tells You How, Comments Tell You Why.

A comment with release notes for the language or framework used in the first part of the files might be helpful. At the same time, the name, surname and e-mail address of the person who created the file can be used to indicate who should be contacted in case of potential problems in the future. The comments that you explain why you wrote the functions you wrote in a short and concise way will be a source for the person who will continue to work on the same project after you.

When we first start learning a language or framework, we feel the need to take little notes to ourselves. It's okay if we keep these notes as comments on our personal projects. We can then use this information over and over again as a documentation we prepare for ourselves.

The most important reason why comments are not liked by most developers is that they are not updated. Comments are usually left as they were originally written. A change made in the code is not reflected in the comment. The code becomes irrelevant to the comment made after a while. If you are not going to update your comments, it would be best not to write comments. Because your teammate is losed time trying to understand the misspelled comment line.

Unused code that convert to a comment is another biggest mistake.. Such a situation is likewise "Why was it written? Will it be used?" It causes you to steal the time of your teammates with questions such as. When writing comments, try to write comments that can save time for your teammates, not stealing their time.

Don't try to write comments for every code block. Take care to write comments at the function/method level. Use comments to tell why you're writing, not to explain your code. Try to keep the comments as up-to-date as possible. Feel free to delete it if no longer needed. If you pay attention to what is written here, there is no doubt that you will be a better team member.

According to the Clean Code book, the majority of comment lines are used to explain/hide badly written code. If you're commenting for this purpose, I suggest you go back and fix your code. I am aware too. Using comments has a bad reputation. But let's face the fact that it can be a great tool if you use it right. When working on a project, transfer your thought process to convey why you did it to people who will work on that project in the future.

Again, I tried to fit a lot into a single article. These are important issues that need to be read, researched and applied. We are in a fast developing industry. We need to be in constant research and study. If you search, you can find detailed documents about these topics that I mentioned at a simple level.

In the Advanced Software Development series:

Previous article: "1- Software Architectures".

Next article: "3- Why Should I Write Tests While Developing Software?".

Don't forget to like if you think it's useful :)

Always get better…

1- Software Architectures

Hamit SEYREK — Mon, 07 Feb 2022 11:01:46 +0000

When starting to write code for the first time, random code is written. Without any schema. Only the person who wrote it can continue a project written like this. Sometimes when we look at the projects we have done for the first time, it takes a long time to find where and what we have done. We can't even understand the codes we wrote ourselves :)

When we start work in a company or when we are involved in a large-scale project, we understand that there must be certain rules so that the written code structures can be easily understood by all team members. At this point, architectures come to our rescue. Because instead of creating a structure that only our own team can understand, using these structures that are already accepted in the software world will make our work more professional.

This is how the adventure of software architectures begins. So what exactly is this thing called architecture?

Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. (wikipedia)

When we think of the word architecture in its literal sense, we arrive at the same conclusion. It is actually a design for the software that is intended to be made. Software architecture is the plan of how and in what way the software will be built. Choosing the right architecture is vital before starting a software. Because later on, architectural change will be very difficult and costly. This is like trying to adapt a building built with a wrong plan to a different plan later on. In such a case, it will be easier if the building is demolished and rebuilt.

"How do You Know if Your Software Architecture is Good?

Following are indications that you have a good software architecture:

1- The software should be easy to maintain
2- No code duplication
3- Team members should be able to easily understand the written codes-classes.
4- Existing modules must be changeable and expandable
5- It should be scalable
6- Team members should be able to easily add new features. And the software shouldn't be too affected by these new features.
7- It should be less affected by possible database changes.
8- The system should be easily reconfigurable.

The conditions here can be increased or decreased. But in general, our architecture should be able to afford them.

So what are these Software Architecture Patterns?

Although there are many software architecture patterns, we will talk about the 5 most commonly used architectural patterns, according to Mark Richards, author of the "Software Architecture Patterns" book:

1. Layered Architecture Pattern

Layered architecture is the most widely used architectural pattern. You may also have heard of it as the n-Tier. It is very popular among software experts because many software projects in the industry are made with this architecture or because it is more used in programming languages trainings that you can find on the internet.

It is suitable for projects that need to be build quickly. It can also be said to be suitable for more inexperienced developers with relatively limited knowledge of architectural patterns. Because that is richer in terms of tutorials or resources. The fact that it contains sustainability and testability standards is one of the reasons why it is more preferred.

The fact that the changes that need to be made in the basics may require a complete re-planning of the application can be counted among its negative aspects. Java EE, Express, Laravel and many more frameworks are built with this architecture. Naturally, applications created with these frameworks emerge in this architecture.

It basically consists of four layers. There are Presentation-Application-Business(Logic) and Data Access layers. Sometimes three layers are used too. A 3-tier architectural Client-Server Architecture pattern using Presentation-Busines-Data Access can also be counted.

For example, MVC, MVVM, VIPER use this architectural pattern.

2. Event-Driven Architecture

Many software that interact directly with humans spend most of their time doing nothing. Such software is always in standby mode. Event-driven architecture can be preferred in such software. This system, which accepts all data and is idle, becomes active when a transaction arrives. This process is then assigned to the appropriate modules by a central unit. These qualify as an Event and only when the event occurs the software does the necessary work.

With this architecture, it is possible to write modules that perform operations such as mouse clicks and fingerprint reading. Programming a keystroke-activated keyboard is a very suitable example of event-driven architecture.

Like layered architecture, not every data has to pass through all layers. The software can be easily extended when new event types are wanted to be added to the software. The fact that the written modules do not affect each other facilitates the testability of the software. In software using Event-Driven architecture, defining a default process for the failure of modules makes the software more stable.

Notification systems are usually built on the basis of this architecture. Otherwise, continually checking notifications can cause high resource consumption. I think it would't be wrong to say that the most suitable architecture for systems with user interfaces or asynchronous data flow is event-driven architecture.

3. Microkernel Architecture

When we consider internet browsers, we know that many add-ons can be added and used in a very functional way. There are different plugins for different processes. Each process is considered as a different core. These cores can be used repeatedly in different models, and a model can use more than one core at the same time.

IDEs like VSCode or Eclipse that can be added plugins are actually the best examples. They have minimal features to run the code when they are first installed. We can add the features with the help of plugins that we want our code to work while compiling . In these IDEs, we open files, write code, and meanwhile, a lot of microprocesses are running in the background.

It can be a good choice if you want more flexibility and modularity than layered architecture. But it has worse consequences in terms of performance. If you're developing an application that has a fixed set of core routines and a dynamic set of rules that need to be updated frequently this is probably the best architecture to choose.

4. Microservices Architecture

Small projects are always sweet. Because they are always easier to understand, modify or test. But in growing software projects, things get difficult when complex functions, processes and modules are involved. Sweet little softwares don't get so cute when they grow up :) Because they don't accept changes easily anymore. Modifications would be difficult and complex.

The purpose of the Microservice architecture is to create many small programs and then bring together for one large program. In such a case, it will be easier to add new small programs or perform operations on an existing one.

These microservices, which are separated according to their responsibilities, can work alone. Not to be confused with the microkernel approach. Here, different services performing different tasks can be easily separated. For example, e-commerce sites are very busy on Black Friday discount days. Services can be special written for those days. Only services that require that much server power are run when needed. On other days, services that require less expense are returned. Another difference from the micro core architecture is that all the small parts need to come together and serve a single purpose.

Communication costs may increase in this architecture, which requires easy separation of all tasks. If a service written for taking the images of a website works very slowly compared to the loading of the site, the visuality may be distorted until the images are loaded on the site. It is the architecture most preferred by international companies that generally work remotely. It is the best choice of companies like Netflix.

5. Space-Based Architecture

There are two primary components within this architecture pattern: a processing unit and virtualized middleware. Mark Richars

Processing unit: Includes backend processes, web-based components, and application components. While a single processing unit is sufficient for small-scale projects, processing units may increase with growing projects. Processing units resemble microservice architecture in terms of their self-contained structure.
Virtualized middleware: Controls data synchronization and requests. The most important component of the software is always databases.

Any problem with databases can cause the entire application to crash. This problem has been tried to be solved by performing distributed database operations in space-based architecture. In the distributed database part, the term "cloud architecture" is also used for this architecture, as jobs can be assigned to multiple servers.

It makes use of RAM so that user logs do not tire the database too much. A lot of work stored in RAM allows software made with this architecture to run faster. However, the difficult nature of transaction support in RAM databases makes it difficult to use.

While the ability to test independent modules independently is among the advantages of the architecture, it may not be suitable for software that includes operations that require some types of analysis. For example, for an operation that requires averaging, it will be necessary to access all the distributed data. Such transactions are divided into sub-processes and propagated to nodes. When all operations are completed, the average should be calculated. This causes performance issues. Apart from that, it is very suitable for softwares where functions that require individual processing are concentrated. Since these processes can be handled in RAM without reaching the database, the process is very fast. It is highly preferred in projects such as social networks.

Conclusion

Someone who has just started software may be faced with questions such as "Which architecture should I choose?", "How do I choose?". If you are a new starter or still at the junior level, you can start with MVC, one of the layered architecture patterns. At later times, you can learn about other options and choose the right one for your next project.

Architecture knowledge alone will not be enough for the modules we mentioned here to be independent from each other or to offer options such as adding new modules. Because a class written without applying the Single Responsibility principle, one of the SOLID principles, cannot be separated from the whole structure.

Most of the items mentioned in the 0-Advanced Software Development article, which is the first of this series of articles, is interdependent. Applying only one item can increase your code quality, but applying a single item will not improve high level your software.

In this article, I mentioned 5 of the most used architectural patterns. Of course, software architectures are not limited to these. With there are many more architectures, it is not possible to master an architecture with such short explanations. I will try to write more about these architectural patterns after this series of articles is finished. I'm thinking of making a few simple iOS apps with Swift using some of them and sharing them here. Let's leave it here for now. Thank you for reading.

In the Advanced Software Development series:

Next article: "2- Why/How to Write a Comment? What is Clean Code?".

Don't forget to like if you think it's useful :)

Always get better…

0- Advanced Software Development

Hamit SEYREK — Mon, 31 Jan 2022 12:48:08 +0000

The reason I say "Advanced" and not "Senior" is because I believe that being a Senior Developer is not just based on knowledge, it needs time. It is true that some of our knowledge increases over time, but the experience that comes with time is necessary to become a Senior. In this article, I will talk about the tools necessary to develop advanced software.

I'll start by addressing an issue that is likely to happen to almost anyone who deals with software.

The steps to the software, which usually start with working in a programming language, turn into a dead end after a while.

After learning the basics of functions, variables, abstract classes and many more and starting to create applications, what should I do now? questions like this start to get confusing.

What should be the next step?
Will I always use the same codes and develop similar applications?

While you are confused by such questions, you see a lot of terms you hear for the first time in job postings. In this process, you will notice a lot of methods and terms that are not mentioned in the trainings because they focus on the programming language, but are frequently used in business life.

In such a situation, the person begins to feel inadequate. Or he thinks the job postings are exaggerated. We start making excuses like “Nobody knows that much!” . (By the way, I believe some of the jobs advertisement are really exaggerated. But only some of them :)))

At this point, I felt the need to write something. Hope it will be useful for everyone :)

Now let's get back to the main issue.
What an advanced programmer should know. Tools he should at least have an idea for or use when writing code:

1- Software architectures
What are the architectures that should be used when developing software with the programming language or framework you use? How to use?
Example: MVVM, MVP, MVC, VIPER etc…

2- Why/How to write "Comment"? What is CleanCode?

3- Why Should I Write Tests While Developing Software?
What are the benefits of writing test codes while developing software? Why should I write test codes? What are the test methods?
TDD, BDD, DDD etc…

4- What is DevOps? What are the benefits? What tools does it use?
Phantom, Slack, Vargant, Ansible etc…

5- What is Continuous Integration and Continuous Delivery? Why should it be used?
Jenkins, Codemagic etc…

6- What is Agile Scrum methodology? What are the benefits to software development teams?

7- What makes SOLID principles special? Are there any other software development principles? What are they?

8- What is Git? Why should I use it? What is Github, Gitlab, Bitbucket used for?"

9- What is Docker? What is containerisation and why is it important? What are the methods?

I intend to publish these as a series, each as a separate article. The 10th article will come with the title of “Advice to students and those who are at the beginning of the road in software”.

Always get better…