A smell of code has to do with being a superficial indicator which in most cases has corresponded to a much bigger and deeper problem in the system. This term was first coined by Kent Beck. This character became famous even after the appearance he had with Martin Fowler’s book. Code winds are very subjective winds and which differ only on the basis of language, developers but also methodology that have other factors.

What are the some frequently seen smells?

Bloaters: In its entirety this includes code, but also classes and methods. This smell has become great over time, making the accumulation of functionality but also the creep of features it has.

For example: it is about long methods, for classes of gods but also for long lists of parameters.

Dispensable: This smell refers to code that is otherwise known as dead code, which can not be called or executed. These are unnecessary blocks of code, as these codes do not offer benefits, but make it possible to increase technical debt.

Psrsh: It is a duplicate code, it deals with the refactoring of objects, as well as makes the generalization premature.

Connections: This smell means the moment when a code must be independent and end up bound together due to lack of access control, as well as excessive delegation.

Ex: We have code tracking, as well as the use of private and internal members.

*Developers in most cases are trained to see what are the logical errors that have been accidentally inserted into their code. Errors of this type will range from the most forgotten cases of different edges, which are not treated to the point where there are logical errors which make possible the crash that can have systems from most. Code winds are some signals that our code needs to be refactored in order to improve the alignment, support but also readability.

The presence of code scents is a very serious topic, despite the names being perhaps a bit ridiculous. Anyone who has little experience in software development is aware that code winds also have the property of seriously slowing down software release.

With the use of code wind detection tools, but also making it possible to submit codes in short as well as controlled refactoring sessions, we have the opportunity to go beyond the initial impact of code winds. In this way we have the right to discover the deepest problem that lies within the software. Code winds can in many cases be vital to make it possible to discover when to refactor and what refactoring techniques to use.

There is a part that is very essential in the way the software is developed as well as to find the flavors of the code. Another role is to dig into the root causes but also to fix them through what is called refactoring.

Most common codes are:

• Bloaters
• Object-Orientation Abusers

• Change Preventers

• Dispensables

• Couplers

The ones that are found the most by details are :

Long method
Duplicate Code
Inheritance method
Data Clumps
Middle Man
Primitive types
Divergent Code
Shotgun Surgery
Feature EnvyPrimitive Obsession
Lazy Class
Type Embedded in Name
Uncommunicative Name
Dead Code

References:

https://levelup.gitconnected.com/10-programming-code-smells-that-affect-your-codebase-e66104e0341d

https://www.infoq.com/news/2016/09/refactoring-code-smells/

https://8thlight.com/blog/georgina-mcfadyen/2017/01/19/common-code-smells.html

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

• Creational
• Structural
• Behavioral

In what is called software engineering, a design model describes a solution that is determined by the problems found in the design of the software. It makes it possible to represent practices that are best and which evolve over a longer period of time through gaming but also testing that is done by software experienced developers.

1)Creational Design Patterns are patterns that explain how an object can be created. These models make it possible to reduce the complexity but also the instability that they have by making the creation of objects in a more controlled way.

In most cases, the new operator is often considered harmful as it distributes objects throughout the application. This can become even more challenging over time, in order to change the implementation, for the sole reason that the classes have a very close relationship with each other.

Creative design models address this issue here by making the client disconnect from the initialization process that is currently underway.

1. Singleton – Makes it possible to provide a single instance of an object that exists during an application.

2. Factory Method – It is possible to create different objects of different classes that are related, but without making specifications in the exact object that can be created.

3. Abstract Factory – Makes possible the creation of families that are dependent but also connected together.

4. Builder – Has the ability to build complex objects using one approach after another, or in other words step by step.

2) Structural design patterns– These are models that have to do with what is called the organization of objects and classes that are different, but also that change the formation of structures from the largest, but at the same time to make it possible to provide the functionality of ri.

Explain how the structural design model is used-

At the moment when we have two interfaces that have an incompatibility with each other but also that want to have a relationship between them by having adaptation with each other, it is also called as the adapter design model. This model, also known as the adapter model, converts an interface of a class to an interface or another class that the client expects. In other words, what is called adaptability somehow allows the classes to work together, which at another point due to incompatibility could not have happened otherwise.

3)Behavioral design patterns represent the responsibility but also the interaction of different objects.

By generalizing these design models, the interaction that takes place through objects should be in such a way that they too can talk smoothly to each other.

Translated into simpler words, in order to avoid dependencies but also difficult coding, the application and the client at the same time should be connected as loosely as possible.

Behavioral design models have 12 types usable for this model:

1. Enterprise chain model

2.Command model

3.Performer model

4.Iterator Models

5.Broker model

6.The model of memories

7.Observer model

8.The state model

9.Strategy Model

10.Template model

11.Visitor model

12.Object Null

References:

https://www.gofpatterns.com/design-patterns/module2/three-types-design-patterns.php

https://howtodoinjava.com/design-patterns/creational/

https://howtodoinjava.com/design-patterns/structural/

https://www.ifourtechnolab.com/blog/a-complete-guide-on-behavioral-design-pattern-and-chain-of-responsibility-pattern-in-java

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

“Find what changes and encapsulate it.”-  This is a different approach from the redesign approach. In simpler words, we are able to consider what we want to change without redesigning, rather than thinking about who might force a change in design.

This principle of encapsulating makes it possible for nothing to affect the rest of your code.

Encapsulation can be found everywhere!

When we turn the steering wheel and the car wheels rotate, we see that there is a variety of moving parts that work together to transform our action into the final effect that the car wheels have, but all these details are encapsulated by us. But this example can never be confused with abstraction. Because they are simply similar and can be true. Just like in the real world but also in the world of Software we have various examples of encapsulation but also of Abstraction that interact together. These are two concepts that are different but that are also related to each other, and that in most cases work together.

The moment we include anything that has the potential for change, we are dealing with time savings. In general, encapsulation has to do with objects which in a way make possible the merging of attributes but also of the methods they have, for the sole reason that they do not have an impact on other objects they have. But it works differently in cases when we are dealing with the design of a program which is mostly object-oriented. This is because the requirements that may most likely change in the future, need to be more concise for one reason only: that the change is likely to occur at the time it is requested. The volume of the code is changed by the summary which minimizes the volume of the code, and which may need to be changed in the future.

When we see that this principle is particularly relevant to the code which changes very often, we are dealing with the benefit of encapsulating the code, regardless of the frequency of the code change. Like what:

The code that is encapsulated has the possibility of reasoning to be separate from the code

• To prevent conjugation summarized with the implementation of the code which is encapsulated, such as when summarizing when the interaction of a downstream system. At this point this replacement is even easier.
• -Other developers can understand from the encapsulation constants, that they are sufficiently connected and have control security in case they have changed or even the way it has changed.

References:

https://genderi.org/encapsulate-what-varies.html

https://alexkondov.com/encapsulate-what-varies/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

YAGNI has two different meanings: You Ain’t Gonna Need It or in other words, You Aren’t Gonna Need It. YAGNI has appeared differently as the main principle that has been used in the extreme program. This principle stated in a different interpretation is:

“Always implement things when you really need them, never when you just anticipate that you might need them.”

The reasons why this principle exists are various. As a start, it makes it possible to maximize the amount of unnecessary work that remains unfinished. This is a very good way to improve the productivity of the developer, but also the simplicity of the product. One thing to keep in mind, these features are very expensive, both for development and maintenance. It is also important for users, so that they have the opportunity to learn, but also to navigate around. But those features seemingly are not necessary, in fact, they are a very large source of waste.

 Yagni Advantages

Here are some reasons why YAGNI should be used:

-Save time in the same amount of money (saving time and money is equal), and this is the main factor but also the most important

-gives you the opportunity to use a much easier code, good but most importantly “thoughtless”

-makes available the deadlines

-ensures that the client is happy with the very frequent but also obvious changes that are in line with the specifications

-code has better quality, notice this from the fact that many developers focus on just one even smaller task they may be doing (tasks which are more important at the moment)

last but not least, that code has the property to be more extensible.

Yagni design principle

We will not need this program much. Extreme Programming (XP) says that a programmer should not add the functionality he has until it is considered necessary. So YAGNI translates differently – You will not need it. Extreme software is generally used in the Agile software development process. According to this principle, we should not add any functionality until the moment when it is deemed necessary, in other words, to write the code which we need in the current situation.

YAGNI in Agile/XP

Many people may remember that this principle is called “stupid” and that the requirements it has should be prepared even better. But those people who work in the slightly more advanced methodology or, as they say, “agile” should take into account the possible changes that the client’s requirements may have. For this reason, the subsequent tasks in most cases depend on the results of the current status of this project, but that over time this result may change.

If at the same time we develop many features that “maybe needed” as a start, we lose not only the time but also the effort that has been needed to complete it. There are also cases when we waste the time we spend refactoring or fixing them as these interventions may be redundant.

In general, developers should never rely on different assumptions because they are likely to prove that they are not worthy and capable of the effort and time a programmer needs.

Refereces:

https://www.plutora.com/blog/you-aint-gonna-need-it-yagni

https://jasonmccreary.me/articles/practicing-yagni/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Do not repeat yourself

This term was coined in 1999 by Dave Thomas and Andy Hunt in the book they created The Programmatic Programmer. The definition they made was like “Every piece of knowledge or logic must have a single, clear representation within a system.” DRY in the use of software engineering, is the principle that has to do with reducing duplication in code, having as main source or “fragment” – that has reusable code in the moments when we need it.

If we are writing a module or even a code, we need to keep in mind the design principles of today and use them wisely. We have to make them our habit, so that we do not have to remember them every time. This will save development time, but also make our software software strong, and in this way we will have it even easier to maintain and expand this software.

DRY Violations- “We enjoy pressing” (or in other words, “Losing everyone ‘s time.”). This phrase means that we can write the same code or logic over and over again.

How to get dry- Less code is good: This saves effort and time for it, it is much easier to maintain, but above all, it reduces the chances of any defect.

Kiss: Keep It Simple, Stupid-KISS Principle is an indicator that shows you how to keep the code clear and simple, to make it as easy to understand as possible. However in general programming languages should be as understandable as possible by humans, because computers the only way they can understand is only with 0 and 1. Therefore we must keep the coding as simple as possible but also direct. We should keep our methods no matter how small, but these methods should not always contain more than 40-50 lines.

KISS Violations – It is very likely that we have all experienced a situation where we need to work on a project and have found a code written incorrectly. This makes us wonder why we wrote these unnecessary lines.

How to reach KISS- To avoid violations of the KISS principle, we should try to write a code as simple as possible and transform it into our code.

The benefit of KISS- If we have some functionalities written by a developer if it is written in irregular code, and at the same time we want another developer to make the modification in the same code, then first they have to understand the code.

If we have not yet discovered a productivity system, most of these may sound familiar.  The only difference here is that we have a process approach with a laser focus that is in unnecessary duplication.

Some of the tasks that rarely come up are:

-Increase tasks that are similar but unplanned, such as handling a customer complaint.

-Let’s not forget the annual tasks (or even the monthly ones, in cases when they are followed for a single week): such as billing, inspections, audits, greater maintenance.

– Ask others about their routine tasks. This helps us to fill the gaps.

References

https://henriquesd.medium.com/dry-kiss-yagni-principles-1ce09d9c601f

https://ardalis.com/don%E2%80%99t-repeat-yourself/

https://blog.softhints.com/programming-principles-and-best-practices-dry-kiss/#kisskeepitshortandsimple

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Solid principles are divided into five different parts of programming and a design that addresses objects. Robert Cecil Martin or also known as “Uncle Bob”, was the one who introduced this type of anchoring or principle also called SOLID. This is one of the principles, where each letter represents a method which is represented by three letters, and which basically has a principle. When we work with software, which has a poorly managed management mode, we are dealing with a code that can become rigid, a fragile mode, and this makes this software difficult to use. When the code is rigid we are dealing with a code that is difficult to modify, it is difficult to change the way it currently works, or even more difficult to add any other features.

·  Single Responsibility Principle (SRP)

·  Open-Closed Principle (OCP)

·  Liskov Substitution Principle (LSP)

·  Interface Segregation Principle (ISP)

·  Dependency Inversion Principle (DIP)

Single Responsibility Prinnciple

The Principle of Sole Responsibility (SRP) at its core for a class not to change, there should be no more than one reason. And this results in every different class having to work with one method. However, each member in the class is related has a direct connection to what is called the primary function of the class. Unlike the example where a class has multiple responsibilities within it, in this method the possibility that it needs to be changed increases even more. And from all of this, we have an increased risk of presenting flaws whenever a class starts to modify. But by focusing only on one responsibility, this risk is even more limited.

Open-Closed Principle (OCP)

The Open / Closed Principle (OCP) means that classes for extension should generally be open, but for modification they should be closed. “Open for extension” aims to open the creation of our classrooms in order to add new functionality, while new requirements are generated. “Closed for modification” means not modifying a class after we have developed it, as it should never be modified, except to correct defects. These two parts of the principle seem to be contradictory to each other. However, if we structure our classes and their dependencies well, we can add functionality without having to reduce the existing source code.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) can be formed in a variety of ways. LSP is applicable to inheritance hierarchies. He emphasizes that we need to create as many of our classes as possible, so that client dependencies are replaced with subclasses without the client being aware of this change. For this reason, all subclasses are based on functioning in the same way as the basic classes they have. Subclasses do not have to apply only the methods and properties that the class bases have so that they are the true type of behavior. But they must also be consistent with her behavior. And this requires compliance with some basic rules.

Interface Segregation Principle (ISP)

There are some classes that have public interfaces and that are not cohesive. The principle of interface sharing (ISP) explains that clients are not tasked with dependent on interfaces that are not usable by them.

– The first rule is the existence of contradictions between the parameters of the methods that the base class has and that of the compliance in the subclasses.

– The other rule is for preconditions and unconditional. The other LSP considers invariant.

-The other rule is to limit history.

– The last rule of LSP states that a subclass should not throw exceptions that are not thrown from the other base class.

Dependency Inversion Principle (DIP)

(DIP) indicates that high-level modules should not be dependent on low-level modules. Both should be dependent on abstraction. These abstractions should not depend on the details, but these should depend on the abstractions. The idea is that high and low-level modules have, categorizes classes hierarchically. High-level classes or modules are those that deal with much larger groups of their functionality.

References

https://www.jrebel.com/blog/solid-principles-in-java

https://www.geeksforgeeks.org/solid-principle-in-programming-understand-with-real-life-examples/

https://www.educative.io/edpresso/what-are-the-solid-principles-in-java

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.