¿Cuántos detalles poner en la primera iteración del proyecto?

15

Acabo de comenzar un nuevo proyecto personal (Python) y estoy escribiendo lo que equivale a un "borrador" del programa, el mínimo requerido para hacer lo que quiero hacer. Todavía no estoy implementando un extenso control de errores / excepciones o elementos estéticos de la interfaz de usuario (incluso en los casos en que sé que estas cosas serán finalmente necesarias), y la documentación es suficiente para ayudarme a ver lo que estaba haciendo en el futuro.

¿Es contra cualquier principio establecido de diseño / gestión de proyectos comenzar tan bruscamente? Soy un científico, no un programador, así que no estoy al tanto de estas cosas. Entonces, la pregunta principal es si existe un consenso sobre dónde se debe tratar de caer entre los dos extremos de:

  1. Escriba código completo y de alta calidad desde el principio, con toda la excepción manejo y tal que usted sabe que finalmente necesitará.

  2. Escriba un borrador mínimamente funcional desde el principio, y vaya a completar todos los detalles más tarde.

Pregunta relacionada: ¿Cuándo está bien sacrificar la" pulcritud "del diseño para realizar un proyecto?

    
pregunta neuronet 08.02.2015 - 19:41
fuente

3 respuestas

10

No hay una respuesta única, ya que esto depende completamente del proyecto. Tenemos que pensar en dos cosas aquí. ¿Cuál es tu objetivo final? ¿Cómo esperas llegar?

Resultado final

¿Estás escribiendo el software de control Mars Orbiter? Entonces es mejor que te asegures de estar escribiendo el código más robusto posible. Será mejor que compruebes que todas las excepciones se manejan de forma razonable.

¿Está escribiendo un programa que solo ejecutará, y solo ejecutará manualmente de vez en cuando? Entonces no te molestes con las excepciones. No te molestes con la arquitectura pesada. Haz que funcione hasta el punto en que te funcione.

¿Cómo esperas llegar?

¿Está haciendo un gran desarrollo de cascada, donde pasa mucho tiempo descubriendo lo que se necesita y luego se va a desarrollar durante meses? Si es así, entonces quieres alcanzar esa calidad objetivo mencionada anteriormente bastante pronto. Obtenga toda su infraestructura de comprobación de errores planeada al inicio.

¿Está haciendo un gran desarrollo ágil, en el que está organizando algo durante una semana o dos, que luego se mostrará a los interesados, que pueden solicitar revisiones radicales, y en los que espera poder iterar durante muchos años? 2 sprints hasta que alcanzas el objetivo? Entonces es mejor que consigas que algo funcione, pero que sean frágiles juntos rápidamente, y solo agregue cinturones y tirantes cuando los requisitos del producto se solidifiquen.

Si tiene el control sobre la cascada o la decisión ágil (que en realidad es un continuo no una opción binaria), tome esa decisión basándose en el cambio esperado. Si está seguro de saber exactamente cuál será el resultado final, entonces la mejor opción es la cascada. Si solo tienes una vaga noción de lo que necesitas para terminar, ágile es tu mejor opción. (Agile es más popular en estos días no porque sea inherentemente mejor, sino porque la segunda situación es mucho más común).

Ahora encuentra tu propia respuesta

Para la mayoría, la respuesta estará en algún lugar en el medio. Responda las dos preguntas sobre su proyecto, y esto lo guiará en una dirección básica.

Puedo decir eso por mí mismo, si a menudo escribo scripts de una sola vez que están diseñados abismalmente y no tienen ninguna comprobación de errores. También manejo el código de producción, donde el manejo de errores y la arquitectura reciben mucha atención. Todo depende de lo que estés haciendo.

Una advertencia final: si decides que estás haciendo scripts únicos que pueden hacerse rápido y sucio, asegúrate. Desafortunadamente, a menudo sucede que los scripts rápidos y sucios que hacen algo interesante se aprovechan para un uso amplio cuando otros los notan. Asegúrese de que, cuando esto sucede, se conceda tiempo para el endurecimiento.

    
respondido por el Steven Burnap 08.02.2015 - 20:02
fuente
11

Todos los conceptos y patrones de diseño y codificación de software surgen en respuesta a algún problema. El patrón o concepto es una solución a ese problema. Con el tiempo, algunos patrones se vuelven "conocidos" como soluciones preferibles porque resuelven el problema de una manera que cumple con ciertos requisitos de coherencia, familiaridad, rendimiento, capacidad de mantenimiento, etc.

De ello se deduce que, si el problema que el patrón de software debe resolver no existe en su software particular, entonces no necesita el patrón. Además, cualquier discusión sobre qué patrones Su software podría también debe incluir discusiones detalladas sobre el software propuesto: ¿qué se supone que debe hacer? ¿Qué problema soluciona? ¿Cuántos usuarios habrá? ¿Los usuarios compartirán datos de alguna manera? Y así sucesivamente.

El problema que se supone que deben resolver las excepciones es cuando sucede algo sobre lo que el código no puede hacer nada. Un ejemplo sería una operación de Archivo / Abrir donde se especifica un nombre de archivo que no existe en el medio de almacenamiento. Las excepciones le dan al código una forma de decirle a la persona que llama "Algo sucedió que me impide continuar, y no hay nada que pueda hacer al respecto, por lo que me estoy rindiendo". Si no tiene ningún lugar en su código donde existan condiciones como esa, entonces no necesita excepciones. O, simplemente puede devolver un código de error y evitar la excepción por completo.

A medida que adquiera experiencia, aprenderá acerca de los patrones de software y cuándo su uso es apropiado. También sabrá cuánto diseño inicial necesita; De nuevo, eso depende totalmente de la aplicación que estés escribiendo. En otras palabras, las pequeñas utilidades se escriben de manera fundamentalmente diferente de las grandes aplicaciones empresariales.

    
respondido por el Robert Harvey 08.02.2015 - 19:59
fuente
4

Hay un enfoque muy simple y práctico para esto, que funciona para una amplia gama de proyectos de tamaño pequeño a mediano. Aunque probablemente no funcionará bien para Mars Explorers.

Primero, averigüe qué desea que haga el sistema y anote cada una de las características individuales. Esto puede ser tan sofisticado como un tablero de historias de usuario completo o tan simple como unas pocas viñetas anotadas en un papel frente a usted. Pero es importante que sepa qué quiere que haga.

En base a eso se traza la estructura general del sistema. Nuevamente, esto es muy a menudo solo un dibujo rápido de las diferentes clases / módulos y cómo se relacionan entre sí, pero puede ser tan complejo como un documento completo. Lo importante es que tiene algún tipo de idea de cómo que va a implementar el sistema. Sin embargo, es probable que esto se refine a medida que trabaja en él, así que no intente ir a lo complejo y detallado.

De todas estas características se resuelven cuáles son las cosas clave que debe hacer el programa: las funciones principales.

Luego implementa uno por uno. Ahora, la clave aquí es que, en realidad, para asegurarse de que una vez que implementó una función, esto se hace y funciona completamente; idealmente, esto se acompaña de una prueba de unidad que se asegura de que siga funcionando. Normalmente supongo que estaré tan ocupado que nunca tendré tiempo para volver a la función y arreglarla.

Una vez que se implementan las funciones principales, generalmente trato de poner el sistema en uso lo más cerca posible del entorno de producción. Esto le da a) cualquier error que pueda haber omitido anteriormente yb) tiene una buena idea de la prioridad de las siguientes funciones.

Luego puedes seguir implementando las funciones restantes según sea necesario.

Calidad de código frente a características

Teniendo en cuenta lo anterior, tiendo a sacrificar funciones por la calidad del código, si tengo que hacer una fecha límite. Simplemente porque, al menos en mi línea de trabajo, cuando termino algo, mi administración asume que está hecho. Y que me puedan dar la siguiente tarea. No tengo mucho tiempo para hacer el código mejor después del hecho.

Ahora, ¿qué pasa con el manejo de excepciones?

Si no desea implementar eso de forma instantánea, solo puede enumerarlo como otra característica de la lista. Y cuando llegas a eso puedes implementar eso. Pero lo más probable es que en tu caso, probablemente haya muchas otras cosas que son más importantes primero.

Sin embargo, hay un requisito mínimo para las excepciones: asegúrese de que se notifique al usuario si algo sale mal, sin importar cuán feo sea el resultado. No trague las excepciones en alguna parte.

    
respondido por el ced-b 09.02.2015 - 02:07
fuente

Lea otras preguntas en las etiquetas