Category Archives: Week 11

Refactoring

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

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

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

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.

Week 11-Software Architecture patterns

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.

View at Medium.com

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.

Week 11: Create Feedback Loops

For this week, I chose to read the pattern ‘Create Feedback Loops’ from Chapter 5: Perpetual Learning. The name is pretty self explanatory as to what the pattern will be on, finding feedback on your progress. I chose this pattern because chapter 5 had the best info to digest, in my opinion, because I’m at that stage in my software craftsman career that where these patterns are the most relatable to me and will only prove to be more useful to me as time goes on. The context for this pattern is, not being able to tell if you’re unaware of how unskilled you actually are. By being unaware of your skill level, you are worse at assessing your own skills and when you do receive feedback, it’ll come as a surprise to your self assessment instead of a support mechanism to help you improve. I thought the context of this problem was spot on, the Dunning-Kruger effect came into my mind when I read this, sometimes people are too falsely confident of their own skills and clearly haven’t been told their real skill level on a certain subject matter. Ever since I became aware of the Dunning-Kruger effect, I’ve been trying to be more open minded to discussion and debate if I’m wrong on something.

For the problem of this pattern, it says your self assessment is only relative to the abilities you used opt have, you will always lack objectivity. I was not sure what this meant at first and I still don’t, however the next few parts that it describes I can relate to. It describes how being in a above-average team will make you feel like a superstar when in reality you’re more of a back up dancer, and how being on a below-average team will make you feel complacently smug. I can relate to this because in class, the backend team for the guest info system, they are definitely gonna go far in life as software craftsmen, I feel like they know what they’re doing which in turn makes me feel like I should know what I’m doing but, I’m just a back-up dancer.

For the solution of this pattern, you want to create mechanisms to regularly gather more or less objective external data about your performance. You will also want to be able to process the raw data from these mechanisms in order to get useful feedback about yourself. Honestly, the solution for this pattern was kind of confusing at first, I didn’t understand some of the mechanisms described but I’m sure in practice it is better than it is described.

From the blog CS@Worcester – Brendan Lai by Brendan Lai and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Retreat Into Competence”

This apprenticeship pattern describes how we should approach difficulties that we encounter along our way of being an apprentice. There will be times when we are working on projects and are faced with difficult challenges that we don’t know if we can overcome, and there are ways to get around this. In the future we will try and expose our ignorance to learn new things, but in doing so we might take on more than we can handle. In doing so, it is okay to take a step and work on something else. Sometimes taking some time away from what you’re struggling on will help you in the long term. It is important that once you take that step back that you then take two steps forward and use that momentum to better yourself. Taking a step back might feel as though you are retreating into failure, but when you work on something you’re comfortable it also adds to your expertise in that area. This then leads to needing to grow as a software engineer and having to learn new things. What we must also remember is to seek support from our mentors and use them to help us become better equipped with handling these situations.

What I’ve taken from this pattern is that taking a step back from what we’re uncomfortable with okay. Sometimes it is okay to go backwards in order for us look back at what we’ve preciously done, then use that to our advantage of progressing forward with our skills. Growth can be looked at from many different views and that’s what we can take from this apprenticeship pattern. There is nothing wrong with facing failure head on, but it’s about how we bounce back that will make us better software engineers.

This pattern has reminded me of experiences I have had in my life. There have been times where I have been put into situations at work where I was required to do work I was unfamiliar with. In doing so, I reverted back to completing work I knew I could do, and once that was done I was then forced to work the things I was not too sure about. In this situation, I then reached out to engineers and other people who could assist me in my work. This then helped me to better understand how to approach this new situation and helped me gain knowledge and experience in completing it later on without the assistance of others.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship patterns – Kindred spirits

The pattern I have chosen today is one about kindred spirits which is when one finds themselves in an unfavorable situation regarding the workplace they reside in or the kind of organization they work for, they should seek some sort of help from someone else. That someone else should be a mentor to you, someone that you want try to emulate, feel intimidated by while also feeling secure around them. These people will help you on your journey on becoming better software programmer whether it be by sharpening your skills or even just giving some extra motivation for you to push on.

The pattern mentions that on the long road, nobody walks alone and that some sort of cooperation is well needed for you to push on with your career. The path one has taken so far should be proof of that, you should have always had someone to help stimulate your learning with your teachers and classmates available for help. They have done a great deal of work helping you realize your career and you will soon see these go away as your enter your career. This means that you will need to start to put in work yourself to build new connections to new mentors and friends that have similar career interests. The sooner this is done, the better so that way the experience is gained earlier and you are setup before any new hardships happen.

I myself should start looking into different ways on getting of connecting to a camaraderie of those who are looking into similar lines of work regarding software programming. There are tons of different sites to look through and resources to use to obtain these connections and there are probably several in the university that I can use. The pattern does mention of it creating an irregular meetup of craftsman in the region that eventually becomes large enough to be self sustaining. I disagree on getting such thing to happen to be easier than one might think and that it is probably something the average craftsman wouldn’t be able to create. I myself don’t see myself creating such a group.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

Apprenticeship pattern: Sustainable Motivations

The more I read this book, the more I understand about software and how it works, the things, and sacrifices to make to become that person we see in us every day and turn it into a reality. This week I read about “Sustainable Motivations” and while I was reading, one thing that I understood is that all the motivations that we have are good but we need to define our priorities from our most to our least and then go from there. Many times in the computer science field, I felt like giving up because sometimes I will think that I need to get into something else and most of the time it is when things get very difficult and challenging. And it’s true that most of the time, not just me but also any other programmer thinks first about the money behind the work and that keeps us even when sometimes we don’t want to keep going. It is true that when I think of what I want to achieve, I love what I am doing even more and go for it. One thing that I learned is that when we define our motivations, we need to go with what really makes us happy and want to continue, keep going because that is what will help us align with walking The Long Road. We need our ambitions not to be first about money but what we want to achieve in the technology field and master it/them. This pattern helped me to be more aware of my future decision and what I really want to do it, so I don’t find myself trapped because I want to enjoy what I will be doing to the fullest and master whatever I will decide to do.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

The Deep End

For this week’s pattern, I decided to go with the deep end. The last pattern I wrote was about rubbing elbows and that pattern was all about how you have reached your plateau of your skills and how to get out of it, while this pattern “the deep end” is the other side of that plateau where you begin to fear that this isn’t a plateau but a rut. On a plateau, you consolidate your skills through diligent practice in order to attain the next level while in a rut, your bland competence eventually decays into mediocrity.

The problem is that you need to grow your skills, your confidence, and the portfolio of successful work. Talking about successful work, when I sent my resume to a mentor/friend to review and ask them for their opinion about how my resume is, he said my resume will not get me anywhere. I had decent projects such as discord bot, android app, website, etc. I thought this much project was enough to set my foot into IT field, but my friend asked me one question which left me speechless, “the projects you built, how has this helped you or anyone else?”. At that moment, I realized that I have just been wasting my time. My projects have done nothing. It was solely built for my own interest, and it had no impact to anyone or not even myself. It didn’t have any positive results where it catches recruiter’s eye. I began to think that I need to challenge myself with bigger things, bigger projects, larger teams, more complex tasks.

The actions are to ask yourself a question such as what is the biggest successful project you have eve worked on in terms of lines of code and number of developers. What is the biggest codebase you have ever built on your own?. The answers to these question will show you other dimensions of project complexity and other ways of measuring your projects. Use this metrics to measure every project you have ever been involved in and draw a chart. After a while, you will be able to use this chart to track down where your career is heading and even start to make choices based on the chart.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.