Rails Technical Design

Hi Everyone,

It will be nice if every one can share the process and the best
practices followed for technical design of a Rails project. May be in
the end we can come up with a common template(if needed).

Let me start first

Following are the steps I do before starting to code a Rails project.

1.) Identify the resources : like user, article, comments etc.
2.) Identify the tables and their fields with data types.
3.) Identify the models and their relationships.
4.) Identify controllers and actions in them, and corresponding views.
5.) List of plugins to use.
6.) Identify methods in models their inputs and outputs(most of this
is done at run time.)

Regards,
Pankaj
http://www.railsguru.org/

pankaj wrote:

It will be nice if every one can share the process and the best
practices followed for technical design of a Rails project. May be in
the end we can come up with a common template(if needed).

Let me start first

Following are the steps I do before starting to code a Rails project.

1.) Identify the resources : like user, article, comments etc.
2.) Identify the tables and their fields with data types.
3.) Identify the models and their relationships.
4.) Identify controllers and actions in them, and corresponding views.
5.) List of plugins to use.
6.) Identify methods in models their inputs and outputs(most of this
is done at run time.)

The problem with any attempts to "standardize" the technical design
process is that different people work in very different ways. Sometimes
we even approach different projects in different ways.

My general process is practically inverted from what you describe here.
I generally start by designing the user interfaces first, then let the
resources naturally flow in support of the user interface.

This basic process is described here:
http://gettingreal.37signals.com/ch06_From_Idea_to_Implementation.php

What you have described above is a model-driven design. This process
might work if much is known upfront about your system's requirements.
However, from my experience, that doesn't often line up with reality.

The design of the user interface is the primary consideration for great
software. It should be considered even above features. Contrary to
popular belief, greatness in software is not directly related to feature
count. Many of the best applications actually have a somewhat limited
feature set. Instead they rely on outstanding implementation of the
features they do provide through intuitive and creative user interfaces.
To be successful one must focus on providing access to the features of
an application. Features are of no use to the user if they can't find or
understand those features.

Efforts to "standardize" the software development process have been
attempted innumerable times since the early days of software
development. Strict engineering principals are almost always
ineffective, and are in opposition to the creative processes involved in
most software design.

http://martinfowler.com/articles/newMethodology.html#SeparationOfDesignAndConstruction

pankaj wrote:

Following are the steps I do before starting to code a Rails project.

1.) Identify the resources : like user, article, comments etc.
2.) Identify the tables and their fields with data types.
3.) Identify the models and their relationships.
4.) Identify controllers and actions in them, and corresponding views.
5.) List of plugins to use.
6.) Identify methods in models their inputs and outputs(most of this
is done at run time.)

Ack!!! Like Robert, you seem to work in reverse from what I attempt...

1. Who are the stakeholders and what are the desired outputs? (what
delivers the value for the system?)
2. What are the perceived entities/models and their relationships?
3. Scaffold a proof of concept with basic functionality.
4. Present the scaffolded app for conceptual review/commentary/usability
comments ('parking lot' UI quibbles in the first round or two for an
'area' of the app). See what a concrete example provokes from the
stakeholders - are the models the right ones, what additional
information is desired, what outputs, are there additional unforseen
stakeholders, etc, etc?
5. Iterate at step 1.

Iterations (generally weekly) are a mix of presenting new scaffolded
items and refining previous items.