> The fundamental problem with almost every Rails project (and I’m sure in other frameworks as well), is that there is no direct codifying of the business rules and use cases of the application.
This is a damn shame. Why do I say so? Because the exact same thing happened years ago in Smalltalk projects. It's easy to start and iterate quickly in a dynamic OO language and the technical debt sneaks up on you very quietly. The next thing you know, there's a quagmire of convoluted and deeply nested conditional logic.
If it was your business to curate lots of painted canvases, then you'd have an orderly and logical filing (or search) system for keeping track of those. If it's your business to curate lots of neat functionality embodied as pieces of code, then you need an orderly and logical system of keeping track of those. It's amazing how many large projects devolve into a big pile of stuff in a class for every screen.
"Enablement" or "security" or whatever you call the framework that lets particular users do particular things at particular times was one of the big wins for Smalltalk projects.
If someone asks you why user X can't do Y on screen Z, and the only way you can know this is for someone to just happen to remember or to painstakingly reverse engineer code, then you have a kind of technical debt.
Beware if your system just consists of putting in a breakpoint then reading code. There is no clear demarcation separating that from the quagmire. (The solution is to have some kind of consistent idiom/framework/something that people can learn to parse, and a way of reorganizing recurring ideas so they can be reused.)
This is a damn shame. Why do I say so? Because the exact same thing happened years ago in Smalltalk projects. It's easy to start and iterate quickly in a dynamic OO language and the technical debt sneaks up on you very quietly. The next thing you know, there's a quagmire of convoluted and deeply nested conditional logic.
If it was your business to curate lots of painted canvases, then you'd have an orderly and logical filing (or search) system for keeping track of those. If it's your business to curate lots of neat functionality embodied as pieces of code, then you need an orderly and logical system of keeping track of those. It's amazing how many large projects devolve into a big pile of stuff in a class for every screen.
"Enablement" or "security" or whatever you call the framework that lets particular users do particular things at particular times was one of the big wins for Smalltalk projects.
If someone asks you why user X can't do Y on screen Z, and the only way you can know this is for someone to just happen to remember or to painstakingly reverse engineer code, then you have a kind of technical debt.
Beware if your system just consists of putting in a breakpoint then reading code. There is no clear demarcation separating that from the quagmire. (The solution is to have some kind of consistent idiom/framework/something that people can learn to parse, and a way of reorganizing recurring ideas so they can be reused.)