Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

The Unified Modeling Language (UML) has been playing a part in software development for years as it provided a standardized visual language for modeling the structure of complex systems. But there have been questions about UML and whether it is still useful because the software industry has shifted towards more iterative, flexible Agile methodologies, there have been questions about the relevance of UML. But the article explains that if you look at it closer then UML remains a valuable asset, especially when leveraged appropriately in an Agile context. UML has four main strengths which include visualization, abstraction, standardization, and design documentation. Visualization means that UML diagrams offer a powerful way to visualize and document the static structure and dynamic behavior of a software system. Abstraction is when UML supports modeling at various levels of abstraction, from high-level conceptual diagrams to detailed design specifications. Standardization is since it is a widely-adopted industry standard, UML provides a common language that can be understood by software professionals worldwide. Finally, design documentation means that UML diagrams can serve as a valuable reference for documenting the design of a system, which can aid in maintenance, support, and future enhancements.

Using these strengths there are many ways that UML can make its way into Agile environments. The first is ideation and communication, UML can be particularly useful during the initial stages of an Agile project, quick, lightweight UML diagrams can help the team visualize and communicate their concepts, leading to a shared understanding before diving into implementation. Next is agile modeling, rather than a complex upfront design, Agile teams can adopt a modeling approach where they create diagrams as needed through their current sprints. The third is architectural blueprinting, UML can play a role in defining and documenting the overall system architecture. By having a high level model, teams can ensure consistency and maintainability as the system evolves over time. The final one is knowledge capture and transfer. UML diagrams can serve as pieces for capturing and transferring info, particularly when gaining new team members or supporting the system in production.

The reason I chose this blog post to talk about is because we just recently did an assignment on UML and have talked a lot about it. During this time I always wondered why it was so important or what place it really had in a team of developers. Overall I believe that the blog itself did a great job at making me see why I was so wrong and what really was important. It can adapt so well over time and allows developers a way to help other members understand their work better and to communicate exactly what they are trying to accomplish. I plan to get better at using UML as a skill I can use in jobs to showcase Agile methodologies and hopefully it will help show not only a technical skill but also my ability to work more collaboratively in teams.

From the blog Thanas CS343 Blog by tlara1f9a6bfb54 and used with permission of the author. All other rights reserved by the author.