A classic. Made me think of a refactoring that is upcoming where initially there was a Slideshow model that later (due to feature creep) became the child of a Presentation, when actually the relationship should have been named Slideshow -> Chapter from the very start.
I can’t complete this refactoring in 20 minutes, but I bumped it up the backlog
A couple of us wanted to rename a RepoAnalysis model to RepoScan, especially because repo_analysis / repo_analyses make for awkward names and plurals. A repo scan is also the term we use in our product discussions.
This was pretty technical to do (kids, don’t try this at home) since this model is a key part of the business and is thus used in many parts of the codebase, from class names to relations to variable names and whatnot. I spent 50 min doing some mass renames and made a PR with almost all tests passing. Way more than 20 min, but I wanted to do that for a while so today’s exercise was a good excuse.
A few pro-tips to help with these kinds of highly-risky renames, besides the usual find and replace from your code editor:
To mass-rename files, use something like find . | xargs rename 's/old_name/new_name/' (rename is a pretty cool utility that you can install via brew if on macOS)
To limit risk, rename the code only, not the table names or the foreign keys. This will allow you to likely deploy the PR with 0 downtime. Renaming tables is risky and can be part of a separate PR, or multiple separate PRs if you need 0 downtime deployment, or can even never be done if this is against engineering policy. Finally, doing only a code change means that you can easily revert it if something goes wrong in production. In the meantime, use self.table_name = 'old_name' in your freshly renamed model to make it use the legacy table name, and use foreign_key: 'old_name_id' in any freshly renamed relation that points to the freshly renamed model.
I guess you can be more careless if you’re working on a site with less traffic
Next steps for some other time will be fixing the few remaining failed specs, making sure no regressions happen in staging, and deploying carefully while being able to quickly revert at any time.
The project I’ve been working on grew from parsing only one source of information, to adding up different sources, but most of the parser code still had references that were unique to that first source.
I’ve spent a little over 20 minutes this morning going over the naming and that also made it so I could see some decent abstractions that would make it easier to add new sources (which is definitely coming next month or so). So that was cool.
Found a class that belongs to a different namespace. That namespaces already includes some similar classes. However, just renaming doesn’t make sense because namespace requires following certain conventions which involves some refactoring. This is a good chance to make the codebase more consistent. Great!
Had a SpreadsheetContent type that also sometimes was referred to as SpreadsheetGrid. Both usages are now based on a single type of just Grid (it’s defined in a module called “spreadsheet” so the prefix was superfluous).
We inherited (from tutorial of FastAPI web app) a module named crud. It is supposed to provide methods to deal with data persisted data (created, list, get item, delete, update…). These methods are isolated from views. The views deal with HTTP, the crud is an intermediate layer between the view and a database.
I am not very happy with current crud name, we call it by many other names and there is no common agreement how to call it in day to day work.
I have read articles about CRUD and REST and did not find nice name for what we call crud today.
Maybe later on.
In past I have developed CAD application for creating drawings used to build floors consisting of pre-fabricated panels. The panels were 1200 mm wide, they were produced in a factory and each piece could be unique (in outer shape, but also in inner holes).
We started calling the program “Omnia FLOORS”. And initially we used the term “floor” for both - single panel as well as complete floor. It was messy.
What helped us was to create analytical class model for the system. And there it came - single floor consists of 1…N panels.
Since then, things were much simpler to talk about.
Later on I used using UML class models to clarify terms with my clients. It is great tool allowing to split different concepts into different classes/nowns.
Naming story of transformers
We were developing system for creation of schemas used to deploy transformers (transforming electricity).
The confusion came with the term transformer.
After class analysis it turned out, this term was used for two differing concepts:
transformer as an item in a catalogue
transformer within electricity schema (in deployment schema)
There were three levels of abstraction:
specific transformer in a schema - instance which could represent real single instance of the transformer
specific item in a catalogue having type “transformer”. It served as something one can order.
abstract item in a catalogue - a person maintaining catalogue would use this abstract item (of type transformer) and instantiate it into specific item in a catalogue.
Lessons learned: Without class model, concepts are easy to mix. To resolve this issue, creation of (simplified - analytical) class model helps.
At the same time - class model helps to identify different concepts and their relationships but does not help directly with picking the best intuitively understood name for those concepts.
I improved a bunch of WIP names. In early phases of a new functionality my names are quite bad. However, I always try to force myself to refactor the code of a functionality or a tightly coupled bunch before moving to the next one. This refactoring includes giving everything a proper name.
We are implementing an integration with a new CRM system now. This is behind a feature flag that changes how our mail deliveries are handled, should they go via the old email provider or the new system.
Although feature flag toggles all emails, I’ve added two methods to refer to that flag: one is called NewCRM.enable_transactional_emails? and the other is NewCRM.enable_marketing_emails? so that it is easer to distinguish both emails in code that handles them
In a rewrite we’re prepping renamed a legacy ‘key’ field to something that is more inline with rails conventions and more descriptive of its purpose and relationship. Also materialized into actual objects two ideas that were distributed around several models – giving something a name is improving its name right?
I’m currently refactoring a lot and a great part of that is just for better understanding. Looking at today’s commits, there are fewer rename steps as expected, but in theory, every “extract class” also means giving a concept a name
This was a tough one for me. I tried to find a name to improve and I found myself just staring at random code for about 15 minutes. I was looking at some functions in one of our apps but I still didn’t know what I was going to do.
I had about 5 minutes left and I decided instead of doing nothing, I’ll just delete 2 of those functions that were no longer in use. For me the goal of this challenge is not to do exactly what it says, but to use it as guideline to improve our code base, 20 minutes per day.
I found a method called build_defaults where we create records in the database I talked with my pair and opened a ticket to rename the method to create_defaults. build_defaults gives the sensation that the record is not persisted in the database in that step
Thanks