I was recently seeding data for a legacy database schema in a client project. A clear pattern had already been established.
The first few sets of reference tables we seeded earlier in the project's history had hundreds or even thousands of rows of data coming from a staging system. Rather than hand-coding those values in a giant PHP seeder, we set up a pattern where each seeder parsed a CSV dump from staging. This approach worked well.
So later on, when I needed to seed another set of reference tables, I naturally did the same thing. But in this case, they were all far smaller, having no more than ten rows each.
In code review, Aaron pushed back on it. The CSV approach was consistent, but it did bring along some friction and ceremony. We were opening the file, parsing the rows, coercing strings to proper types, handling empty cells as nulls.
None of it was terrible on its own, but for these tiny tables, all of that friction was unnecessary. In fact, factory calls directly in the seeder were more readable, even though it broke from the pattern.
It was a good suggestion.
In general, patterns in a codebase are good and consistency matters, but a pattern isn't an absolute truth. It's worth considering if the pattern fits a given context before reflexively using it.
Here to help,
Joel
P.S. As shown in today's tip, even experienced developers benefit from a code review. Would you like Aaron and me to review your code too?
