Importance of establishing clear practices and guidelines for engineering teams.
Role of inventory in understanding and managing technical debt effectively.
Significance of making refactoring processes visible, rewarding, and resilient.
Strategies for prioritizing refactoring tasks alongside product development.
Approaches for integrating refactoring into regular engineering workflows.
Refactoring code is a critical aspect of software development, yet it often gets overshadowed by the urgency of delivering new features. Establishing a clear framework for refactoring can help engineering teams address technical debt without derailing product development. This framework comprises three essential pillars: practices, inventory, and process.
The first pillar, practices, involves setting clear goals and guidelines for the engineering team. Practices act as a North Star, guiding the team toward consistent and effective code structure and architecture. This includes documenting coding guidelines, structuring code logically, and choosing preferred patterns for component composition. By having these practices in place, teams can avoid arbitrary refactoring driven by individual preferences and instead work toward a common goal.
The second pillar, inventory, is about understanding the current state of the codebase. Inventory involves logging technical debt and identifying areas that need refactoring. This process requires gathering facts about the codebase and assessing how far it is from the desired architecture. It also involves maintaining a separate document, such as a technical debt accounting document, to track and prioritize technical debt items. Such documentation helps prevent backlog tickets from becoming neglected and ensures that technical debt is addressed methodically.
The third pillar, process, involves the actual execution of refactoring tasks. It's essential to treat refactoring as any other task in the project management process. This means making refactoring tasks visible, assigning ownership, and tracking progress. Refactoring should not be done in isolation or hidden within product-related pull requests. Instead, separate PRs should be created for refactoring tasks to ensure they receive proper attention and do not interfere with product development.
Visibility is a crucial aspect of the refactoring process. Clearly separating refactoring tasks in project management tools helps teams manage them effectively. Additionally, making refactoring efforts rewarding can help gain buy-in from the engineering team. Celebrating code removal and organizing events like "Marie Kondo Fridays" to remove unnecessary code can motivate the team and make refactoring a shared achievement.
To ensure the sustainability of the refactoring process, teams need to make it resilient. Product delivery often takes precedence, and tight deadlines can push refactoring tasks aside. Assigning priorities to technical debt items helps teams focus on the most critical issues while planning for multi-month refactoring efforts. Regular engineering huddles, dedicated to discussing code health and technical debt, can keep refactoring efforts on track even during busy periods.
Managing technical debt requires a cultural shift within engineering teams. Refactoring should be treated as an integral part of the development process, rather than a separate phase that disrupts product delivery. By building a refactoring culture, teams can continuously improve their codebases without compromising on product development.
Refactoring versus rewriting is another consideration. While rewriting the codebase may have been a common practice in the past, refactoring offers a more sustainable approach. In today's stable front-end development environment, evolving the architecture and codebase gradually is often more effective than starting from scratch.
Communication with management is also crucial when dealing with technical debt. While engineers view debt as a burden, management may see it as leverage for faster delivery. Demonstrating the impact of technical debt on productivity through metrics and examples can help bridge this gap and align priorities.
Test coverage plays a vital role in ensuring the safety and effectiveness of refactoring efforts. Comprehensive testing, including unit tests and integration tests, provides the confidence needed to make changes without introducing new issues. Type safety and automated tests further enhance the reliability of refactoring processes.
Incorporating refactoring into regular workflows requires a pragmatic approach. Long-lived branches for refactoring tasks can prevent disruptions to delivery schedules while allowing teams to address technical debt incrementally. Collaboration and communication within the team are key to maintaining a balance between refactoring and product development.
Ultimately, establishing a strong refactoring framework can lead to healthier codebases and more efficient engineering teams. By focusing on practices, inventory, and process, teams can manage technical debt effectively while continuing to deliver valuable features to their users.
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 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.
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.
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 '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 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.
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.
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.
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