Refactoring is an integral part of software development, often overshadowed by the glitz of new features and product launches. It's not just about rewriting code but involves a strategic framework encompassing practices, inventory, and process. To navigate refactoring effectively, it's essential to establish clear practices, conduct a thorough inventory, and follow a structured process. This framework is not about achieving perfection but closing the gap between the current state and desired architecture.
Practices form the foundation of refactoring. They guide engineers in making consistent changes aligned with team goals. Without clear practices, refactoring becomes a personal preference rather than a collective effort. Practices should be well-documented, providing a North Star for the team. This includes coding guidelines, structure, and patterns agreed upon by the team.
The Significance of Inventory in Refactoring
Inventory plays a crucial role in refactoring, yet it is often overlooked. It's about understanding the current state of the codebase and identifying technical debt. Inventory helps in logging technical debt in a structured manner, ensuring it doesn't get lost in the backlog. At Code Sandbox, a technical debt accounting document is used to track and prioritize these debts, ensuring visibility and accountability.
Visibility is key in the inventory process. Technical debt should not be hidden. Separate tickets for refactoring tasks in project management tools help in distinguishing them from product development tasks. This separation ensures that refactoring efforts are visible and prioritized appropriately.
Executing the Refactoring Process
The process is where the actual changes occur. It involves planning, executing, and tracking refactoring tasks like any other project task. Assigning ownership and defining a clear 'done' criteria are crucial for the success of refactoring projects. Engineers should be encouraged to contribute to refactoring efforts, making it a rewarding experience.
Refactoring should not be done in isolation. It should be integrated into the regular workflow, with engineers contributing to both refactoring and product development. This integration ensures that refactoring does not disrupt the product delivery pipeline.
Making Refactoring Visible and Rewarding
Visibility and reward are essential for successful refactoring. Making refactoring efforts visible through clear documentation and separate PRs helps in maintaining transparency. It's important to celebrate refactoring successes, treating them with the same importance as product launches. This boosts team morale and encourages continuous improvement.
Regular meetings focused on the health of the codebase can help in maintaining visibility. These meetings should be separate from product delivery discussions, focusing solely on refactoring and technical debt. Assigning owners to refactoring tasks ensures accountability and continuous progress.
The Balance Between Refactoring and Product Development
Balancing refactoring with product development is a common challenge. Technical debt should not be seen as a burden but managed effectively. It's essential to prioritize technical debt based on its impact on productivity and delivery timelines. Not all technical debts are equal, and understanding their priority helps in effective management.
Long-living branches for refactoring tasks can help in managing this balance. These branches allow for gradual refactoring without disrupting the main development branch. This approach minimizes conflicts and ensures that refactoring efforts are integrated at the right time.
The Role of a Refactoring Culture
Building a culture that embraces refactoring is vital. This involves educating the team on the importance of refactoring and integrating it into the development process. It's about creating an environment where engineers feel empowered to address technical debt without waiting for a dedicated refactoring phase.
Refactoring should be seen as an ongoing task, not a one-time project. Regular discussions, documentation, and prioritization help in maintaining a healthy codebase. Encouraging a culture where refactoring is part of the daily workflow ensures that technical debt is managed effectively, leading to a more robust and maintainable codebase.
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
This talk has been presented at React Day Berlin 2022, check out the latest edition of this React Conference.
Alex comes from Romania and works at Code Sandbox. He is also an organizer of JS Heroes, a community event based in Cluj, Romania.
Alex's talk focuses on the culture of refactoring rather than specific techniques. He discusses how to integrate refactoring into the regular workflow of engineering teams without disrupting product development.
The Code Sandbox team manages technical debt by documenting it in a specific technical debt accounting document, prioritizing it, and incorporating it into their regular engineering processes, ensuring it's handled continuously and transparently.
The 'three pillars of refactoring' mentioned by Alex include practices, which define the goal or desired architecture; inventory, which involves assessing and prioritizing technical debt; and process, which outlines the steps to manage and execute refactoring tasks.
Technical debt accounting is a document used at Code Sandbox to track technical debts introduced during development, including their reasons, possible solutions, ownership, and priority.
Alex suggests making refactoring visible and rewarding within the team, ensuring it is treated like any other task, documented, and celebrated to maintain team motivation and awareness.
Alex advocates for refactoring, which involves making incremental improvements to the codebase, rather than rewriting, which entails starting from scratch. He believes refactoring is generally more beneficial as it evolves the existing codebase progressively.
Alex discusses creating a technical debt accounting document, making refactoring efforts visible and rewarding for the team, and ensuring the refactoring process is resilient even during tight deadlines or lower priorities.
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
Hello, everyone. It's such a nice view to be in front of a stage after such a long time. I've been here before. I had a great time. So as Yanni said, my name is Alex. I work at code sandbox. I'm organizing JS Heroes. Our next event is May 2023. I want to talk today about refactoring. But before I start, there's this link at the bottom. Bit.ly slash Alex refactoring. You can find the slides there. You can also find me on Twitter at Alex and Moldovan. That's pretty much about it.
2. Why I want to talk about refactoring
I want to talk about refactoring culture. I'm fascinated by why we haven't figured out how to refactor our code without impacting product development. We can build engineering teams and cultures around introducing refactoring as any other task. Understanding that it's okay to live with technical debt, we need to manage it. I will present a framework called the three pillars of refactoring: practices, inventory, and process.
3. Goal, Practices, and Inventory
Your goal is to reach a certain architecture and have a way of composing components and consuming a design system. Establish coding practices and guidelines to structure code and document your team's way of working. Inventory is often overlooked but crucial. It involves gathering facts, logging technical debt, and prioritizing solutions in a separate document called technical debt accounting.
4. Assigning Priority and Planning
Not all technical debt is equal. A funny example of this is a component we built more than a year ago. It's a markdown renderer for code sandbox. We never bothered to refactor it because it works and hasn't been touched. Once you have your priority straight, start planning for the important technical debt using documentation like RFCs. Stick with the plan but don't stop other processes.
5. Refactoring Framework and Rules
To successfully refactor, you need to have clear practices, an understanding of your technical debt, and a well-defined process. These three pillars form a framework for effective refactoring. Without all three pillars, refactoring becomes challenging and less methodical. In the second part of the talk, I will provide examples of rules that the engineering team at code sandbox follows to make refactoring successful. The first rule is to make the refactoring process visible.
6. Visibility, Reward, and Resilience
One big problem with refactoring is the misconception that it should be done in the dark. In a methodical team, visibility is crucial. Have separate tickets for refactoring in your project management tool. Make separate PRs for refactoring. The second rule is to make refactoring rewarding and celebrated. Celebrate code removal and involve the whole team. Get rid of code that doesn't spark joy. Make the refactoring process resilient.
7. Ownership and Refactoring Culture
Even if it's on low priority, even if it's on low effort, it's still there, right? We have weekly engineering huddles with the entire team to discuss the health of the code and raise any technical debt concerns. Assigning owners to these efforts is crucial, even during busy periods. Ideally, someone in the team should take ownership of the bigger refactoring process. Every team has a person that drives the refactoring culture, and if you don't know who that is, it is probably you. Thank you very much, and happy refactoring.
8. Managing Technical Debt with Management
Debt is leverage for management, but it's important to have a conversation with senior management about the consequences of accumulating technical debt. Showing metrics of productivity can help them understand the impact on the team's speed. Pick one specific issue and demonstrate how it affects productivity. Making a big diff may please people like Elon Musk who want to see a lot of code written.
9. Prioritizing Tech Debt and Refactoring
There's no specific number for how much time should be allocated to refactoring in an engineering team. It varies from team to team. However, it's beneficial if everyone in the team is involved in refactoring. This distributes the workload and ensures that everyone is contributing to both refactoring and product development. Having a process in place, such as documenting and creating tickets, can make it easier for the team to prioritize and contribute to refactoring efforts.
QnA
Refactoring with PRs and Test Coverage
I suggest showing this talk video to your bosses. Refactoring with PRs can be hard, especially in complex delivery processes. One approach is to keep refactoring PRs alive for longer and merge them after important releases or QA. Long-living branches can help manage refactoring work. Test coverage is crucial for safe refactoring, providing certainty and allowing changes to propagate. A variety of tests, including unit tests, are important for refactoring.
Refactoring versus Rewriting
If you have integration tests and end-to-end tests to complement that, then those should become your anchor. Always try to refactor and evolve the architecture and code base rather than starting from scratch. Please talk to Alex in the speakers' Q&A room for more questions.
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
This Talk explores the concepts of impact and growth in software engineering. It emphasizes the importance of finding ways to make the impossible possible and the role of mastery in expanding one's sphere of impact. The Talk also highlights the significance of understanding business problems and fostering a culture of collaboration and innovation. Effective communication, accountability, and decision-making are essential skills for engineers, and setting goals and finding sponsors can help drive career growth. Feedback, goal setting, and stepping outside of comfort zones are crucial for personal development and growth. Taking responsibility for one's own growth and finding opportunities for impact are key themes discussed in the Talk.
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
This Talk introduces the Epic Stack, a project starter and reference for modern web development. It emphasizes that the choice of tools is not as important as we think and that any tool can be fine. The Epic Stack aims to provide a limited set of services and common use cases, with a focus on adaptability and ease of swapping out tools. It incorporates technologies like Remix, React, Fly to I.O, Grafana, and Sentry. The Epic Web Dev offers free materials and workshops to gain a solid understanding of the Epic Stack.
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™? Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster? At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.
Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.
Table of contents: - Introduction to Vue3 - Composition API - Core libraries - Vue3 ecosystem
Prerequisites: IDE of choice (Inellij or VSC) installed Nodejs + NPM
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Top Content
Featured WorkshopFree
2 authors
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
Build Modern Applications Using GraphQL and Javascript
Featured Workshop
2 authors
Come and learn how you can supercharge your modern and secure applications using GraphQL and Javascript. In this workshop we will build a GraphQL API and we will demonstrate the benefits of the query language for APIs and what use cases that are fit for it. Basic Javascript knowledge required.
Comments