Architecture: elaborate on refactoring

[amyjko]

In this chapter, the author discussed approaches to organizing code and the idea of software architecture and its principals; information hiding through encapsulation, functions, classes, and scope. Though beyond organizing code through components and connectors, the author discussed code refactoring which means changing the architecture of the code without really changing its behavior; the benefit of this that it eliminates mismatch and technical debt which means saving time and money in the future. But the one thing I want to understand more in-depth is why is refactoring often times challenges and very time consuming for developers or why IDEs are not trusted with refactoring code.

This chapter does a good job of explaining the purpose of architecture and different architectural styles. However, one question I have is about refactoring. I was wondering how we can determine whether it is worth it to refactor when it may take a lot of time and resources. The example that is given is that Google doesn’t let anyone change their Gmail because it is considered a unique identifier. Even though there may be a need from the user, they chose not to allow the change in a Gmail address. How did they decide that it was not worth it to refactor so that they can meet the users’ demand for change?

One part that I wish the chapter would elaborate on is how often do organizations refactor code? Additionally, when a team does decide to refactor code, is it only one person going through to make sure the logic is consistent or what system do engineers use to ensure that refactoring doesn't cause more issues?

Something I would like the chapter to go into greater depth is refactoring. Particularly, I would like to see more about the refactoring process and how different organizations/teams may go about doing it.