Automating repetition of code is a sign that your stack is poorly factored for your needs. Automating code repetition up front won't save you from maintenance repetition, and maintenance is about 2/3 of average product cost.
The most productive stacks I have worked with trimmed out stuff that wasn't needed for our particular organization.
Every organization has common patterns they are used to and like. But, off-the-shelf stacks have to cater to a wide variety of organizations and organization preferences. Get a tunable stack and trim trim trim, and refactor duplication. Learn from each generation of product releases and make your API's better for the next.
Make special behavior as-needed plug-ins, not part of the main stack. Don't be a feature horder in the main stack, but keep a library of handy add-ons that are known to fit your stack when needed.
As an example of flexible factoring, you shouldn't normally have to specify the title and max length of an input field more than once (D.R.Y. Principle). If you have to keep doing it twice, find out why and factor it out. However, keep in mind that sometimes you do need to override the default title for specific needs such that you shouldn't remove the potential for task-specific customization in your effort to refactor. Use shared defaults for a field, but don't force shared defaults.
You should spend most of your coding time plugging in parameters to well-tuned API's, not copy and pasting repetitious code. Most of your actual coding should be for behavior that is unique to a project. Think twice, type once, instead of the other way around.
Comments
Automating repetition of code is a sign that your stack is poorly factored for your needs. Automating code repetition up front won't save you from maintenance repetition, and maintenance is about 2/3 of average product cost.
The most productive stacks I have worked with trimmed out stuff that wasn't needed for our particular organization. Every organization has common patterns they are used to and like. But, off-the-shelf stacks have to cater to a wide variety of organizations and organization preferences. Get a tunable stack and trim trim trim, and refactor duplication. Learn from each generation of product releases and make your API's better for the next.
Make special behavior as-needed plug-ins, not part of the main stack. Don't be a feature horder in the main stack, but keep a library of handy add-ons that are known to fit your stack when needed.
As an example of flexible factoring, you shouldn't normally have to specify the title and max length of an input field more than once (D.R.Y. Principle). If you have to keep doing it twice, find out why and factor it out. However, keep in mind that sometimes you do need to override the default title for specific needs such that you shouldn't remove the potential for task-specific customization in your effort to refactor. Use shared defaults for a field, but don't force shared defaults.
You should spend most of your coding time plugging in parameters to well-tuned API's, not copy and pasting repetitious code. Most of your actual coding should be for behavior that is unique to a project. Think twice, type once, instead of the other way around.