Steps to clean up and organize your code We started working on our React application a few years ago. We started with Flux, but shifted to Redux when it became available. Over time, requirements evolved and the application grew. We also moved to newer frameworks for forms, modals and charting to name just a few. In fact, a significant part of our code now uses GraphQL so state management with Redux is reduced. We were learning as we went along and the implementation of new features often took priority over cleaning up working code. As a result, the time was ripe for an exercise in decluttering the application. At the start of this exercise, the application had more than 500 components and hundreds of reducers and actions. So, this wasn’t a toy application. We use so individual files were relatively clean. But ESLint will not help if a module is unused or an exported function is never called. ESLint The challenge was to remove unused code and to reorganize existing code so that the code was smaller, easier to understand, and more maintainable. To get started, we used the utility and a commercial tool to create a map of the dependencies of our application. For any file, it allowed us to see what it imports and who imports it. It was also easy to follow dependency chains. The underlying data comes from that can be freely downloaded. lxjs Lattix Architect madge Armed with this data, we proceeded to refactor the application. Remove Unused Files We quickly identified files that were no longer in use. Of course, it wasn’t enough to remove just the unused files, we also had to follow it up for code that was used only by these files. Organize components Components were the largest part of our client code. Roughly 70% of our client code was components. This is where the most work went into. We ended up dividing the components into two parts: and . Views were the top level components that often corresponded to pages while the lower level components were the shared components used by views. Components that were specific to a view were normally kept within that view, but we weren’t rigid about it. We knew we had reasonably clean separation when there were no cross dependencies within views and no backward dependencies from components to views. views components Clean up actions and reducers As our application evolved, many actions were no longer in use. Since actions are used by components and reducers, looking for unused actions is not straightforward. We had to identify all actions that weren’t used by any component. It helped that we had strong naming conventions for our actions and reducers. Once unused actions were removed it was easy to identify and remove all reducers that referenced those unused actions. Remove unnecessary couplings While most of our selectors were in reducers, there were a few that were in components. We simply co-located the selectors with the reducers. This also helps encapsulate the state within the reducers and hides the details from the component. Sometimes selectors use other selectors. This creates a coupling between reducers. We co-located selectors with reducers to avoid creating a cyclic coupling between reducers. Selectors were a source of unwanted couplings. There were helpers that were created to support one component initially, which were then used by other components. For instance, any component that dealt with time/date selection had to deal with time zone adjustment. Initially, many of these helper functions were part of the time zone selection component. These functions were moved to a separate helpers directory for use by all components. Ad-hoc helpers were another source of unwanted coupling. Cleanup styles We had more than 50 css files. Most were located in a separate directory but some were colocated with components. We got rid of unused css files easily. We didn’t attempt to rationalize the multiplicity of styles used by different components because it wasn’t perceived to be an issue. styles Lessons Learned This was a surprise. Cleanup is perceived as hard and thankless that doesn’t add to the bottom line. However, it is t which takes an incremental bite every time you make a change. Initial estimates were that this exercise could take months. In fact, the bulk of this exercise was completed in two weeks. It’s easier than it looks. technical deb One of the valuable by-products of this exercise is that it aligns the current team. You can often organize the code . We used a combination of these two approaches at different levels. However, we always mediated both approaches by dependencies to ensure that we weren’t introducing . Know your code organization. by feature or by type cyclic dependencies This is not an exercise to reduce the bundle size, even though it did help us get rid of a few libraries. For instance, our application uses both Redux-form and Formik. To get rid of one or the other would help reduce the bundle size and reduce library clutter but we kept it outside the scope of this effort. Reducing the bundle size isn’t the goal. The multiplicity of libraries is its own form of clutter. Why do we accumulate clutter Often code starts out as well organized but erodes over time. It is easy to blame deadlines and business needs but they do not fully explain this common phenomenon. Other reasons include: We solve business problems by using the right combination of technologies. We write tests. We then move to the next issue on our sprint. Cleaning up isn’t measured or valued in our development processes. Programming culture doesn’t emphasize cleaning up. The problems arise as newer people come in or as new functionality is added that others aren’t familiar with. For current programmers, the problem becomes apparent only when the application grows and they no longer understand parts of the code base developed by others. For current programmers, it is not a priority. This is true even for expert programmers. Moving a helper function from one file to another requires changing unfamiliar files. Removing a piece of code requires understanding why it was created in the first case and ensuring that it really is unused. All this distracts from the task at hand and comes in the way of completing the sprint. Programmers minimize changes to code that they didn’t write. Without an organizing principle for the code and without a culture of continuous cleanup, code rot is inevitable. What we achieved At the end of this exercise, we ended up reducing the size of our code by about 25%. There were half as many actions and 40% fewer reducers. The number of components also came down by about 10%. Years of accumulated clutter was gone.
