Wow, esta pregunta es realmente complicada y creo que obtendrás muchas respuestas interesantes y diferentes. Comenzaré diciendo que creo que estás haciendo la pregunta equivocada.
Su pregunta supone que debe abordar su sitio en segmentos horizontales, es decir: realice TODO el modelado primero o realice TODA la interfaz de usuario primero. Si haces esto, estarás luchando con la forma en que Rails quiere hacer las cosas. Rails está diseñado para un desarrollo ágil, lo que significa abordar su proyecto en sectores verticales, es decir: hacer el esquema de la base de datos, modelo, enrutamiento, controlador, interfaz de usuario para una sola característica antes de continuar.
Entonces, lógicamente, la siguiente pregunta se convierte en “¿Qué función debo hacer primero?”, Y para lidiar con eso, necesitaremos profundizar un poco en la gestión de proyectos. Esta no es la forma de hacer un desarrollo ágil, pero es una forma, y debería servir como iniciador para la discusión si tiene algún interés en seguirlo.
- ¿Se contrata a los estudiantes de los campamentos de codificación basándose únicamente en su trabajo realizado en el campamento?
- Cómo reparar los ciclos de desarrollo de software que tardan demasiado
- ¿Puedo estudiar python al mismo tiempo con C ++?
- ¿Cuál tiene el mejor ROI para la informática, UT Austin o Pitt?
- ¿Por qué debería aprender Machine Learning siendo un estudiante de pregrado de CS?
1. Escriba una lista de objetivos, roles y características.
- Objetivos: cuáles son los objetivos de todo el proyecto: negocios y otros. Esto lo ayudará a decidir qué características son importantes.
- Roles: ¿quién va a usar el sitio? ¿Visitantes, miembros registrados y administradores? ¿Diferentes personas tienen diferentes puntos de vista de la misma información en el sitio?
- Características: ¿cuáles son las categorías básicas de interacción en el sitio? Por ejemplo: Usuarios: registro, uso de foros y blogs; Administradores: moderando el contenido del usuario
2. Escribe una lista de historias
- Una historia es diferente a una característica porque representa un hilo único de interacción desde la perspectiva de un usuario en particular.
- Es común expresar historias en forma “Como ____ quiero ____ para poder _____”. Esto te obliga a responder tres preguntas importantes: ¿para quién es esto? ¿Qué quieren hacer? ¿Por qué quieren hacerlo?
- Si no puede completar una historia de esta forma, es probable que todavía no tenga una respuesta a una de estas tres preguntas, por lo que deberá pensar un poco para obtener las respuestas antes de que la historia sea procesable.
- Ej: “Como administrador, quiero excluir a los usuarios del foro, para poder mejorar la calidad del contenido enviado por los usuarios en el sitio.
- Escriba estas historias en tarjetas de notas. Esto lo ayudará en la estimación y priorización.
3. Estima las historias
- La estimación es un tema enorme en sí mismo, pero la idea básica es asociar un nivel particular de esfuerzo con cada historia.
- Las escalas más comunes son 0/1/2/3/4, 0/1/2/4/8. No creo que esto sea increíblemente importante, pero elige algo y quédate con él.
- No se obsesione con la exactitud de las estimaciones. Muchas cosas afectan el tiempo que lleva terminar una historia, por lo que pequeñas diferencias en la complejidad de la historia tienden a perderse en el ruido.
- Su objetivo aquí es diferenciar las cosas que requieren poco esfuerzo, como las historias que resultarán en que cree un modelo simple con un controlador REST, de las historias que requieren mucho esfuerzo, como la interfaz de su aplicación con una API de terceros desafiante, o una historia que requerirá que uses una tecnología con la que no estás muy familiarizado.
- Escriba la estimación en cada tarjeta.
4. Prioriza las historias
- Reorganice las tarjetas en el orden en que le gustaría abordar las historias.
- Solo el propietario del producto puede realmente tomar esta decisión. Hay muchas cosas que entran en la priorización: plazos, pruebas de usuario, valor comercial, etc. La estimación puede tener mucho que ver con la priorización, ya que ilumina el costo de oportunidad. Tal vez el propietario del producto realmente quiera ese Panel de administración detallado, pero si todas las historias para hacer que ese trabajo sume un total de 40 puntos, ¿vale la pena gastar un mes solo en esta función? Quizás el dueño del producto todavía quiera la historia
- ¿Hay alguna historia que no se ajuste al mínimo producto viable para lanzar? Si es así, debes moverlos hacia abajo. Intenta completar una aplicación que funcione lo más rápido posible para que puedas ponerla frente a los usuarios.
- En este punto, generalmente muevo mis tarjetas a Pivotal Tracker, pero conozco a muchas personas que prefieren lápiz y papel.
5. Pruebe la primera historia hasta completarla
- Comience con Cucumber Escriba una función de Pepino que cubra la interacción del usuario con el sitio de principio a fin. Defina los pasos indefinidos cuando llegue a ellos, y cuando llegue a su primer fallo, sabrá que hay un comportamiento que desea que su aplicación no tenga (esto sucederá muy rápidamente al principio, porque su aplicación en blanco no tener mucho comportamiento).
- Si tengo interacciones de JavaScript que son una parte clave de la interacción del usuario, trato de que Cucumber las pruebe usando la etiqueta @javascript.
- Continúe con RSpec Escriba la prueba del comportamiento que desearía tener.
- Escriba su código Escriba el código para hacer pasar la especificación. Esto lo llevará a través de su aplicación, desde el enrutamiento a la interfaz de usuario, a los modelos, al esquema de la base de datos y al controlador. Abordará estas piezas de código en el orden en que sus pruebas lo dirijan.
- Repita hasta que pase el pepino, y haya terminado con la historia.
- Ahora es un buen momento para arreglar el estilo CSS, suponiendo que haya realizado el diseño. Si estoy trabajando solo o sin un diseñador, me gusta intentar trazar la interfaz de usuario en papel o en algo como Balsamiq Mockups antes de comenzar a codificar la historia.
6. Acepta la historia
- ¿Es aceptable la historia? ¿Hace lo que querías que hiciera? Si no, debe regresar y hacer que funcione de la manera en que se suponía que debía hacerlo. Escribir pruebas de pepino de antemano ayuda a evitar que esto suceda.
- ¿Pasan todas tus pruebas? No rompiste la construcción, ¿verdad? Si es así, debes arreglar lo que rompiste.
- Si está trabajando solo, puede ser útil que alguien más lo acepte, ya que puede ser difícil ver su propio trabajo con ojos objetivos.
6. Repita hasta que termine
Así es como hago las cosas. De ninguna manera es la única forma de hacer cosas, pero es una forma muy común de hacer cosas en Rails. Creo que hay un buen debate en torno al valor de la estimación ágil, o de tecnologías particulares como Cucumber vs. Steak o RSpec vs Test :: Unit, pero la mayoría de los desarrolladores de Rails estarán de acuerdo en que el flujo de trabajo adecuado es: 1) Identificar un historia única 2) Escribir pruebas para ello 3) Completarlo.
Las ventajas de este enfoque son numerosas. Tiene algo que poner en frente de los usuarios para recopilar comentarios desde su primer registro. Su plan de proyecto es extremadamente flexible en términos de prioridades cambiantes y altamente tolerante a los requisitos cambiantes. Si ha realizado alguna cantidad de ingeniería, sabe que los requisitos cambiantes no son una cuestión de si, sino de cuándo y cuánto. Solo por esas 3 razones, debe abordar el desarrollo de su aplicación en sectores verticales en lugar de los sectores horizontales que sugirió en su pregunta.