Restructuring a giant, ancient codebase to make LibreOffice work well everywhere

Re:Restructuring a giant, ancient codebase to make LibreOffi... by manmal on Friday January 19, 2018 @03:02AM (#16184778)

IMO the most important thing when introducing a layer of abstraction is the name of the new component. I sometimes spend 2 or more minutes making up a name that best describes what this layer is about.

ProTip: Manager or Controller is not a good name. To me a good name is eg „PostDetailSerializerResolver“ - it’s a component that will resolve serializers for post detail objects. And according to concept of single responsibility, it should only do that. If you need it to do more, you must change the name.

[ Parent | on HN ]

Re:Restructuring a giant, ancient codebase to make LibreOffi... by vanderZwan on Friday January 19, 2018 @05:52AM (#16185337)

> I sometimes spend 2 or more minutes making up a name that best describes what this layer is about.

Some of the best refactoring I ever did for long-term code-maintenance was nothing more than untangling a web of abstraction layers and renaming them to fit the actual context, changing nothing to the functionality of the code.

Sometimes you start out with an idea for what the architecture will be, but then things change and the naming isn't updated.

[ Parent | on HN ]