It depends on the quality of scaffolding, and how well he deals with the inevitable changes which will arise during the course of the.
Generally speaking, every time a system (e.g., its application) needs to interact/integrate with another system (e.g., the database) it is necessary to map concepts, because not only does each one deal with a different abstraction (e.g., objects vs. tables) how it is necessary to establish which entity on one side corresponds to an entity on the other (e.g.: class X represents table Y). This is sometimes called Glue code ("code glue").
There are several ways to do this (hardcoding, configuration files, introspection/reflection, etc.), scaffolding one of them. The idea behind this technique is - assuming enough code Boilerplate needs to be written - facilitate the task by combining a smaller, more declarative code with data obtained through introspection, producing from it a complete code. This is different from, for example, generating a "skeleton" (Skeleton) from the data and let the programmer complete it (common in UML tools, for example - at least the oldest).
Personally, I don’t like the idea (at least the "scaffolding during the design") because I dispute the assumption that this code Boilerplate it is necessary - I believe that the same results could be obtained with generic code, via reflection. But in itself, the practice does not seem to me detrimental in any sense (maybe except for the piles of generated code...). I don’t see why it would be suitable for prototypes but not for production.
As for the problems in using this technique, I only see the potential for problems to arise as the project evolves. Let’s say that the scaffolding, and it was realized that some changes were necessary in the generated code. They were made, and in the future there was a need to evolve the scheme (i.e. make changes to the BD). What to do with the existing code? Normally, the answer would be to "generate it again", but as changes were made in it, one would have to do them all over again. Alternatively, one may not redo the scaffolding, making all the changes by hand, but the volume of these changes can be significant (and making them by hand brings potential for mistakes).
It is at this point that the idea bothers me: if a system is built under the philosophy of scaffolding, he will not hesitate to add more and more code to his generation process, assuming that this does not cause problems to the programmer. When in fact it does bring problems, as already mentioned. Already a system that uses an alternative philosophy, even if it is that of "hardcode everything", will always have in mind the cost of the changes to the programmer, and will attempt to minimize this cost in any way possible (through generic code, introspection/reflection, or simply via auxiliary tools to modify the settings).
I have no experience with Rails to say if the quality of your scaffolding is or is not good. So my recommendation is to observe the following parameters when deciding whether or not to use this feature: 1) if I need to redo the scaffolding, Am I gonna miss something? e 2) if my bank needs to change, radically until, how much code will I have to write by hand to adapt my current system to the changes? Simulate some scenarios like this, see what Rails offers you to help you with this, and then evaluate if it’s something feasible to do in production or not (where you can’t "throw it all away and start over", but whether you need to maintain it is difficult or not).
Good answer! This answer in Programmers should give you an idea of the use of scaffolding in Rails. The following phrase I find interesting: "I utilise the scaffolding, but don’t trust in it". In fact, in Rails, scaffolding is not as "deep" as it sounds. It generates the entire skeleton (Migration, model, controller, basic CRUD and HTML actions), but it is inevitable to add/remove/change things here and there. I find it unlikely that someone will generate it a second time: it is much easier to change the existing than to start from scratch.
– user7261
@Andrey Yeah, I remembered more or less of this (I did some Rails tutorials many years ago, before I decided I wasn’t interested in this platform), but how his question was about scaffolding in general - and not specifically on scaffolding in Rails - I wanted to give a general answer as well. The idea itself is not at all bad, but I am rather skeptical about the real possibilities of applying it in practice without incurring the problems cited in my answer.
– mgibsonbr