00:00:10.400
Are you excited? Yeah, thanks! Thanks for giving us your time today. This is the first day of the conference, so I’m excited to welcome you all. I am the founder of Rails Thailand and also the organizer of Rails Pacific. Our opening today will be a bit more formal. The reason we set up this panel and the workshop before the session is that we believe it should be a more interesting event during the conference. In my experience attending conferences in other countries, I've found that people are not just there to listen to speakers; they want to hear real-life experiences from them. That’s why we have this panel discussion this morning followed by a workshop. I hope everyone can gain valuable insights from the workshop.
00:00:35.840
Today's panel discussion will focus on two topics: the first part will be about refactoring, and the second part will address how to become a senior developer. I encourage everyone to ask questions because we have very seasoned developers here who can provide valuable insights. They are true experts in their fields. Now, I'll hand over the stage to our host, Mark, who will lead the panel discussions. Thank you!
00:01:12.800
Good morning, everyone! Welcome to the first panel. Today we will be discussing refactoring. My name is Mark, and I’ll be your host. We are very happy to have Mr. Shibata Hiroshi, Mr. Akira Matsuda, Mr. Ryan Bigg, and Mr. Nick Sutter with us today. To kick things off, can each of you briefly introduce yourself in one or two sentences? Let’s start with Akira.
00:02:00.800
Good morning! I’m Akira from Japan. I’m a Ruby on Rails committer and also the author of a Ruby gem called Kaminari. Tomorrow, I’ll be doing the opening talk and discussing Action View, so I hope to see you there!
00:02:57.680
Hello, good morning! My name is Hiroshi Shibata, and I work at GMO Pepabo as a chief engineer. I am also a Ruby on Rails committer, working on refactoring core Ruby code. My company uses Ruby on Rails extensively for our web services. I’m looking forward to seeing everyone tomorrow!
00:03:40.320
Ryan here, I work for a company called Lifx, where we make smart lights you can control with your phone. I’ll be giving out some tomorrow, but for now, I have some shirts with me. I’ve written a book called "Rails 3 in Action" and have just completed another book on "Multi-tenancy with Rails," which I’ll be discussing in my talk tomorrow. I hope you all will come by and listen!
00:04:46.080
Hello, everyone! I’m Nick, originally from Germany but currently living in Australia. I've been working with Ruby for about ten years and have contributed to several gems. Tomorrow, I’ll be talking about my gems and presenting a new architectural style for Rails. I hope to see you there! Now, let’s dive into the topic of refactoring.
00:05:57.040
I’d like to start the panel by discussing keywords that come to mind when we think about refactoring. For me, it’s important to note that you can’t refactor code that is already clean and well-structured. To refactor, the code has to be messy first. This idea connects with test-driven development (TDD). The mantra of TDD is red-green-refactor, which is the process of writing a test (red), making it pass (green), and then refactoring the code.
00:06:56.960
However, there’s a debate about TDD itself. Some say it’s dead; others believe it’s still valuable but might be in a zombie state. Regardless, I think we can all agree that tests and refactoring go hand in hand. You cannot efficiently refactor code without being aware of whether you’re breaking anything. Testing ensures that your refactorings don’t break the existing logic.
00:08:14.080
Shifting gears, I want to touch on my experience with IDEs for refactoring. Coming from Java and .NET, where IDEs like Eclipse make it easier to refactor code because of static typing, I find Ruby to be less friendly in this respect. Ruby’s dynamic nature makes it challenging since you’re often unsure of what types of data are being passed around. While tools in IDEs might help with method extraction, they often fall short when it comes to more complex structural changes like extracting classes.
00:09:26.960
In my view, regardless of the programming language, effective refactoring requires a careful understanding of the codebase. For Ruby, rather than entirely relying on IDE tools, I often search through files manually to understand the flow of methods and their dependencies before proceeding.
00:10:00.320
Refactoring does not simply mean breaking code into smaller units but should improve clarity and understanding. Often, I run into situations where one method can be over-refactored; we should remain mindful not to create methods that aren’t reused anywhere. Watching your tests fail can also serve as a reminder that changes might not always lead to a better design.
00:11:12.960
In my experience, it is beneficial to create dedicated time for refactoring rather than treating it as a low-priority task. In my role on a developer productivity team, I’m mostly focused on refactoring to enhance existing code. I frequently find myself improving code written by others, which is always a rewarding challenge. When it comes to over-refactoring, I often ask myself whether the changes I’m contemplating genuinely improve the codebase.
00:12:57.920
I believe the role of the refactoring expert is often defined by circumstances. Sometimes you may find yourself in that position because others delegate that responsibility to you; in my case, I've been hired to work on legacy codebases and improve their structure. I enjoy the process but also recognize the lack of immediate gratification that comes from modifying existing code since it is often invisible to the end-users.
00:14:58.000
At times, I have also participated in formal refactoring projects where we analyze a legacy codebase and document potential improvements. By creating a comprehensive report outlining modifications, we allow clients to carry out refactorings themselves or engage us to assist with the process. I think providing education around best practices for refactoring can be immensely beneficial.
00:15:58.480
In our ongoing discussions, one interesting question arose regarding the balancing act of developing a team dynamic around refactoring versus working independently. I think collaboration is crucial, especially when working through complex problems. But I also appreciate the need for solitary focus at times when the task requires deeper thought, such as restructuring classes or redesigning critical aspects of the codebase.
00:17:56.640
Simultaneously, maintaining open lines of communication within the team is vital to ensure that everyone has a solid understanding of the changes being made. It's easy to lose sight of project goals when individual efforts aren’t aligned, so maintaining that collaborative spirit can yield a more successful refactoring process. I think the goal should always be effective communication about significant changes.
00:19:39.840
When discussing the code refactoring process, I think the hardest to adhere to are large changes that might lead to breaking public APIs. As gem authors, we often find ourselves facing this dilemma, especially when we want to introduce new features while maintaining backward compatibility. Adopting a semantic versioning strategy is essential to navigate these complications. It allows you to communicate how much change took place with each version.
00:21:38.400
Understanding clarity around public and private APIs within a gem’s structure helps significantly when planning for refactoring. A detailed awareness of this makes it easier to identify what can change and what should not. In my approach, I am comfortable introducing changes to internal logic while ensuring I properly manage any documentation updates for future users.
00:23:07.040
As noted, larger teams can efficiently implement intricate refactoring processes in designs, especially if everyone can sync on the changes made. The risk associated with significant shifts is higher, but if the team can discuss and document impacts comprehensively, I think the refactoring journey allows for team growth and better resultant models.
00:24:55.680
Breaking down large, complex systems into more manageable components can lead to increased clarity and enhanced maintainability. When we work together, we're better equipped to handle the minutiae, keeping the broader implications in mind and adjusting accordingly. Each team member brings unique insights, making collaborative refactoring conducive to the overall improvement of the codebase.
00:26:22.560
I think a key consideration that helps prevent over-refactoring is balancing abstraction levels. It’s essential to be mindful of not introducing excess complexity through unnecessary abstractions, as having too many layers can muddy the user’s understanding of the system. Refactoring should clarify and not obfuscate, resulting in cleaner, more understandable code.
00:27:50.560
Past experiences have shown me that understanding when and how to refactor is a skill that develops over time through practice. We leverage common patterns and principles that work for us while remaining flexible to adapting our refactoring strategies according to each unique situation. Rigorous testing, feedback loops, and team discussions all lead us toward thoughtful improvements.
00:29:14.080
As we conclude, let's take a moment for questions and discussions from the audience. If anyone has particular topics or thoughts they wish us to dive into, feel free to raise your hand. We are eager to hear what insights you might share with us or receive any questions about refactoring practices!
00:30:44.160
Audience members begin sharing thoughts on refactoring while the panel discusses different scenarios, best practices, and common challenges encountered in the real world.
00:31:29.280
Finally, specific resources for refactoring knowledge were shared, including Martin Fowler's renowned book on refactoring, object-oriented design principles from Sandy Metz, and insights from Aaron Patterson's contributions to Ruby. All panelists agreed on the importance of these materials for developers.
00:32:42.720
In closing remarks, the panelists express gratitude for the audience’s engagement throughout the session and encourage continued exploration in their refactoring journeys.
00:34:50.080
Thank you for participating today. We truly appreciate your insights and questions. We hope everyone found this panel insightful and informative. Now, let’s take a break for snacks!
