From Chaos to Clarity: The Power of Refactoring

Resources:
1. Refactoring: Improving the Design of Existing Code (2nd Edition)
2. Refactoring Guru
3. https://martinfowler.com/

Books you may enjoy!
1. Refactoring: Improving the Design of Existing Code (2nd Edition)
2. Working Effectively with Legacy Code
3. Refactoring to Patterns

Transcript

1. FROM CHAOS TO CLARITY THE POWER OF dotnet konferansı 2024 Zikriye Ürkmez REFACTORING
2. ABOUT ME 10 + years backend developer developer trying to develop good habits leader of a great team always team member linkedin.com/in/zikriye-urkmez-cengiz Engineering Manager twitter.com/ZikriyeUrkmez github.com/zikriyeurkmezcengiz navlungo
3. kind of restructuring. restructure software by applying a series of refactorings without changing its observable behavior. a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. refactoring as a particular any kind of code cleanup good engineering practice professionalism right thing
4. If someone says their code was broken for a couple of days while they are refactoring, you can be pretty sure they were not refactoring. martin fowler small tiny steps Each individual refactoring is pretty small or a combination of small steps. code doesn’t spend much time in a broken state allows to stop at any moment even if I haven’t finished.
5. Worker Hat (Adding Function) Focus: Implementing new features and changes Goal: Deliver new value to the user. Approach: Prioritize getting new code to work correctly Example: Building a new user authentication system Artist Hat (Refactoring) Focus: Improving the structure of existing code Goal: Enhance code quality, maintainability and readability Approach: Optimize and clean up code without changing its external behavior Example: Simplify a complex function to make it easier to understand and test Two hat metaphor from Kent Beck CONTEXT SWITCHING QUALITY BALANCE INCREMENTAL IMPROVEMENT
6. Preparatory Refactoring When should we refactor? “if it were structured a little differently, my work would be much easier.” Jessica Kerr “Wait, I need to check the map and find the quickest route.” developers can work more efficiently improves code quality spend less time dealing with confusing code
7. Litter-Pickup Refactoring small, incremental improvements and quick wins When should we refactor? If it’s easy to change, I’ll do it right away Renaming variables for better clarity Simplifying complex conditional statements Extracting methods to reduce code duplication “I understand what the code is doing, but realize that it’s doing it badly.”
8. Refactoring making code easier to understand When should we refactor? “I have some understanding in my head, but my head isn’t a very good record of such details.” Comprehension team members can collaborate better improves code readibility an clarity fewer errors in the long time
9. Planned Refactoring opportunistic refactoring Planned vs Opportunistic Refactoring refactoring is natural part of adding a feature or fixing a bug refactoring isn’t an activity that’s separated from programming excellent code needs plenty of refactoring too. refactoring is not totally related clean up ugly code
10. for each desired change, make the change easy (warning: this may be hard), then make the easy change kent beck good developers know that, often, the fastest way to add a new feature is to change the code to make it easy to add.
11. What Do I Tell My Manager? for some workplaces refactoring has become a dirty word managers (and customers) believing that refactoring is either correcting errors made earlier, or work that doesn’t yield valuable features. Martin Fowler says don't tell! as a professionals our job is to build effective software as rapidly as we can. a schedule-driven manager wants me to do things the fastest way This code needs refactoring ... Do I have tIME?
12. proven solutions to common design problems. improving code readability maintainability scalability single responsibility reusability automatically updates one to many dependent objects Observer Pattern manages object creation particularly for dynamic objects Factory Pattern Strategy Pattern conditional logic and improving flexibility Top 3 Useful Design Patterns For Refactoring
13. Strategy Pattern For Refactoring behavioral design pattern defines a family of algorithms encapsulates behaviors enables dynamic behavior switching promotes object collaboration Before Refactoring: the PaymentProcessor class handles different types of payments using conditional logic. This makes the code harder to maintain and extend.
14. payment processor to use payment strategies Single Responsibility After Refactoring: Strategy Pattern a common interface for payment strategies and implementing each strategy in its own class. Extensibility Readability Strategy Interface Concrete Strategies Context Client
15. Observer Pattern For Refactoring behavioral design pattern defines a one-to-many dependency between objects the observers’ behavior is triggered by changes in the subject’s state. encapsulates the behavior of the dependent objects (observers) clean separation between the subject and its observers promotes loose coupling between the subject and its observers
16. Before Refactoring: The Stock class manages its own list of observers and notifies them directly when the stock price changes. This tight coupling makes it difficult to manage and extend. Observer Pattern
17. implement investor as an observer Extensibility After Refactoring: Observer Pattern a common interfaces for observers and subjects Loose Coupling Reusability observer concrete observer subject concrete subject
18. Factory Pattern For Refactoring creational design pattern encapsulate object creation decouple client code from concrete classes support multiple product variations support customization or configuration promoting loose coupling between the creator and the created objects Before Refactoring: The NotificationService class uses conditional logic to create different types of notifications (email, sms, push). This makes the code harder to extend and maintain.
19. Extensibility After Refactoring: Factory Pattern Single Responsibility Maintainability program just know the notification service notification service does not know the notification type and has only one Send() method creater concrete creater product concrete product
20. Books you may enjoy! Refactoring: Improving the Design of Existing Code (2nd Edition) Martin Fowler Working Effectively with Legacy Code Michael Feathers Refactoring to Patterns Joshua Kerievsky
21. THANK YOU! dotnet konferansı 2024 Z İ K R İ Y E Ü R K M E Z References Refactoring: Improving the Design of Existing Code (2nd Edition) Refactoring Guru https://martinfowler.com/