Refactoring is an important concept in software development
that refers to the process of modifying and improving the internal structure of
existing code without changing its external behavior. This can be a useful
technique for improving the readability, maintainability, and performance of a
codebase, and it is often an essential part of the software development
process.

There are many reasons why a developer might choose to
refactor their code. One common reason is to improve the readability and
understandability of the code. Over time, as a codebase grows and evolves, it
can become difficult to understand and maintain. Refactoring can help to clean
up the code and make it more organized and easier to read. Another reason to
refactor code is to improve its maintainability. As a codebase grows and
changes, it can become more difficult to make updates and modifications without
introducing bugs or breaking existing functionality. Refactoring can help to
make the code more modular and flexible, which can make it easier to make
changes and updates without breaking the code. Refactoring can also be used to
improve the performance of a codebase. As code is written and optimized, it can
sometimes become inefficient or slow. Refactoring can help to identify and
remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a
crucial concept in the field of computer science. As I read through the post, I
found it to be very informative and well-written. The post clearly explained
what refactoring is and described the various benefits it offers, such as
improving readability, maintainability, and performance. I found the discussion
of different techniques for refactoring code particularly interesting.
Techniques like extracting methods or functions, renaming variables and
functions, and restructuring code can all be effective ways to make code more
modular, readable, and maintainable. I also appreciated the emphasis on maintaining
the external behavior of the code during refactoring. This is something I will
keep in mind as I continue to learn software development. Although refactoring
wasn’t required in this class, I plan to use what I learned on future projects
and when working with others on a team. I will refer to this resource as I
continue to improve my skills and knowledge in the field.

Source:

https://maddevs.io/blog/code-refactoring/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Refactoring is an important concept in software development
that refers to the process of modifying and improving the internal structure of
existing code without changing its external behavior. This can be a useful
technique for improving the readability, maintainability, and performance of a
codebase, and it is often an essential part of the software development
process.

There are many reasons why a developer might choose to
refactor their code. One common reason is to improve the readability and
understandability of the code. Over time, as a codebase grows and evolves, it
can become difficult to understand and maintain. Refactoring can help to clean
up the code and make it more organized and easier to read. Another reason to
refactor code is to improve its maintainability. As a codebase grows and
changes, it can become more difficult to make updates and modifications without
introducing bugs or breaking existing functionality. Refactoring can help to
make the code more modular and flexible, which can make it easier to make
changes and updates without breaking the code. Refactoring can also be used to
improve the performance of a codebase. As code is written and optimized, it can
sometimes become inefficient or slow. Refactoring can help to identify and
remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a
crucial concept in the field of computer science. As I read through the post, I
found it to be very informative and well-written. The post clearly explained
what refactoring is and described the various benefits it offers, such as
improving readability, maintainability, and performance. I found the discussion
of different techniques for refactoring code particularly interesting.
Techniques like extracting methods or functions, renaming variables and
functions, and restructuring code can all be effective ways to make code more
modular, readable, and maintainable. I also appreciated the emphasis on maintaining
the external behavior of the code during refactoring. This is something I will
keep in mind as I continue to learn software development. Although refactoring
wasn’t required in this class, I plan to use what I learned on future projects
and when working with others on a team. I will refer to this resource as I
continue to improve my skills and knowledge in the field.

Source:

https://maddevs.io/blog/code-refactoring/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Refactoring is an important concept in software development
that refers to the process of modifying and improving the internal structure of
existing code without changing its external behavior. This can be a useful
technique for improving the readability, maintainability, and performance of a
codebase, and it is often an essential part of the software development
process.

There are many reasons why a developer might choose to
refactor their code. One common reason is to improve the readability and
understandability of the code. Over time, as a codebase grows and evolves, it
can become difficult to understand and maintain. Refactoring can help to clean
up the code and make it more organized and easier to read. Another reason to
refactor code is to improve its maintainability. As a codebase grows and
changes, it can become more difficult to make updates and modifications without
introducing bugs or breaking existing functionality. Refactoring can help to
make the code more modular and flexible, which can make it easier to make
changes and updates without breaking the code. Refactoring can also be used to
improve the performance of a codebase. As code is written and optimized, it can
sometimes become inefficient or slow. Refactoring can help to identify and
remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a
crucial concept in the field of computer science. As I read through the post, I
found it to be very informative and well-written. The post clearly explained
what refactoring is and described the various benefits it offers, such as
improving readability, maintainability, and performance. I found the discussion
of different techniques for refactoring code particularly interesting.
Techniques like extracting methods or functions, renaming variables and
functions, and restructuring code can all be effective ways to make code more
modular, readable, and maintainable. I also appreciated the emphasis on maintaining
the external behavior of the code during refactoring. This is something I will
keep in mind as I continue to learn software development. Although refactoring
wasn’t required in this class, I plan to use what I learned on future projects
and when working with others on a team. I will refer to this resource as I
continue to improve my skills and knowledge in the field.

Source:

https://maddevs.io/blog/code-refactoring/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Refactoring is an important concept in software development
that refers to the process of modifying and improving the internal structure of
existing code without changing its external behavior. This can be a useful
technique for improving the readability, maintainability, and performance of a
codebase, and it is often an essential part of the software development
process.

There are many reasons why a developer might choose to
refactor their code. One common reason is to improve the readability and
understandability of the code. Over time, as a codebase grows and evolves, it
can become difficult to understand and maintain. Refactoring can help to clean
up the code and make it more organized and easier to read. Another reason to
refactor code is to improve its maintainability. As a codebase grows and
changes, it can become more difficult to make updates and modifications without
introducing bugs or breaking existing functionality. Refactoring can help to
make the code more modular and flexible, which can make it easier to make
changes and updates without breaking the code. Refactoring can also be used to
improve the performance of a codebase. As code is written and optimized, it can
sometimes become inefficient or slow. Refactoring can help to identify and
remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a
crucial concept in the field of computer science. As I read through the post, I
found it to be very informative and well-written. The post clearly explained
what refactoring is and described the various benefits it offers, such as
improving readability, maintainability, and performance. I found the discussion
of different techniques for refactoring code particularly interesting.
Techniques like extracting methods or functions, renaming variables and
functions, and restructuring code can all be effective ways to make code more
modular, readable, and maintainable. I also appreciated the emphasis on maintaining
the external behavior of the code during refactoring. This is something I will
keep in mind as I continue to learn software development. Although refactoring
wasn’t required in this class, I plan to use what I learned on future projects
and when working with others on a team. I will refer to this resource as I
continue to improve my skills and knowledge in the field.

Source:

https://maddevs.io/blog/code-refactoring/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

The Blog I read this week focusses on the the different Types of software architecture that we had discussed in previous classes as well as the different situations that these different patterns are useful and for what type of situation they would be ideal for. One of the important ones discussed and the most interesting ones that applies to my everyday life is the client server pattern.

In this pattern a central server offers one or more services are offered to one or more clients, allowing for all of the work to be done at the central server while all of the users can use the Data independently. This is very relevant for the world at large as many of the sites that we use on a day to day basis use this type of pattern such as twitter, where the Application provided the under interface for the user and the servers to interact. this type of pattern is used for many different applications we use today such as facebook and many other types of social media, where the user takes the information from the server and the selections made on the users side will then be sent to the server and update the information on that side of it. it is interesting how our small interaction impacts the overall system as a whole and how the entire process occurs for something so simple as updating your twitter bio.

Another pattern discussed in the blog is the layers pattern, which we discussed in both classes related to Cohesion as well as design patterns. it is described as the most widely used and promotes low coupling and high cohesion, much of what we discussed before hand in class is gone over such is how it is utilized for the most part smaller projects with different teams working on different parts of the project in parallel with other departments in order to keep the system active for users as well as allowing for updates to be spit out more often without shutting down the rest of the system. this was an important aspect of release principles as allowing for these releases to happen frequently in order to push updates to users as often as possible while other developments were also in progressed proved beneficial to the user but strained the developers, with the different teams it allows for less stress on devs to release patches or updates in select parts of the projects.

O, Williams. “Fundamental Software Architectural Patterns.” Medium, Medium, 14 June 2022, https://medium.com/@liams_o/fundamental-software-architectural-patterns-663440c5f9a5.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

Anti-patterns are on the opposite side of the design pattern and are undesirable according to the blog “Anti-Patterns in Software Development That You Should Avoid”. Another term to describe Anti-patterns are called Design Smells.

The blog goes over the concept of the Golden Hammer anti pattern which occurs when using a familiar solution to attack an unfamiliar problem. Sometime it might work out, but most of the time it’s an inefficient way to solve problems.

The Golden Hammer anti-pattern is a concept that can shared in every aspect of life. Like for example, as mentioned in the blog some people tend to have their solution ready before understanding the problem like a doctor prescribing while the patient is still telling about the symptoms.

In software development, each design pattern is basically suited for its targeted problem. But it’s really easy to use the same framework, the same programming language, and the same design pattern for almost every problem. Like similar to the doctors example, some doctors might prescribe Ibuprofen to help a certain health but it might not completely relieve or heal that issue completely.

And so the Golden hammer could lead to; Poorly performing code, Overly complicated code, Redundant code. To avoid this anti-pattern it is best to find all potential solutions for one problem and benchmark them. List down all PROS and CONS for each solution then choose the better one.

Another anti-pattern is the God Class which for the most part controls many other classes, takes many responsibilities as well as lots of dependencies. An application could be well designed at the beginning so that there aren’t God classes but eventually dominant, very well specified classes will turn into God classes at some point.

The big ball of mud is a very common anti-pattern that happens when the solutions/application lacks a perceivable, flexible, suitable architecture as defined in the blog. A ball of mud will have, haphazardly and sloppy structure without coding comments, contains many God classes with more than 6000 lines of code, static variables/functions everywhere, methods being overloaded several times, and code duplications.

This anti-pattern is dangerous because it could happen while writing the application. Once we can’t refactor the code anymore, then we have to rewrite the entire thing. There are many reason why this anti-pattern could be brought up. It could be due to the frequent changes and requirements that the application might need, the deadline is near and the project is rushed, new developer are being brought in, or being too narrow minded about the design architecture that was initially brought in.

There are many more anti-patterns when it comes to the software development process, these are just the most common ones to date.

Link to blog: https://medium.com/geekculture/anti-patterns-in-software-development-that-you-should-avoid-780841ce4f1d

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Unified Modeling Language is a standardized language to
visually represent software construction, design, and architecture. UML designs
are process independent, and often omit irrelevant, or insignificant
relationships and attributes in favor of simplicity. UML diagrams can be used
to represent a variety of things in several ways. UML diagram can be classified
into two main categories: Structure Diagram, and Behavioral Diagram.

Structure diagrams show the structure of objects and the
relationship/interaction between those objects. Structure diagrams are to be
considered descriptive and behave like a blueprint for the code, i.e., it can
be used to inform the design of written code. Class diagrams are one of the
most frequently used Structure diagrams in software development. It shows each
of the classes in a system with their attributes, class methods or operations,
the scope of every attribute and method within a class, and the relationship
between two or more classes. A class diagram has three parts: Class Name, Attributes,
and Methods. The name of the class is always at the top, while any attribute
like a variable is in the middle. A note can be added pointing to the attribute
to show any individual specification or requirement. The methods are listed at
the bottom and can similarly have notes pointing to the method to show any
individual specification or requirement. Arrows are used to describe the
relationship between two or more classes. Depending on the arrow the specific
relationships can be identified. The various relationships are Association, Dependency,
Implementation, and Inheritance.

Behavioral diagrams show the intended function of the system
and any objects it contains. They describe how those objects should interact
with each other to make the system functional. Behavioral diagrams are
considered prescriptive, i.e., they show how the written code should work in
the system.

As a CS student, I found this
blog post on UML diagrams to be highly relevant and useful. Homework 1 and
Homework 2 provided a great opportunity to delve into the complexities of these
diagrams and gain a deeper understanding of their various properties and concepts,
especially for Class Diagrams. It will very likely be useful in future classes
as UML diagrams allow you to be able to communicate your design ideas effectively
to other members of your group, ensuring that everyone is on the same page and
working towards the same goal. They can also be a valuable resource for
documenting and maintaining software systems, making it easier to understand
and modify the system as needed. For example, the visibility of attributes and
the connections between classes, as represented by arrows, are crucial elements
that contribute to the overall coherence and functionality of UML diagrams.
Additionally, the provided examples helped to clarify and illustrate these
concepts in a clear and concise manner.

Source:

https://creately.com/blog/diagrams/uml-diagram-types-examples/

https://www.uml-diagrams.org/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.