Cómo evitar volver a escribir partes de una aplicación

13

Estoy trabajando en una empresa en un proyecto para su departamento de ventas. Es mi primer trabajo de programación profesional, pero he estado programando y aprendiendo por años. Parte del proyecto consiste en tomar algunos datos y combinarlos con información para producir y graficar. Luego guarde los datos ... y así sucesivamente. Así que escribí el código para esto en poco menos de un día. Al día siguiente le mostré a mi supervisor de proyecto, y a él le gustó, pero "qué pasaría si tuviéramos esto", y quería que agregara algo al gráfico. Este no fue un gran cambio en la apariencia o función del programa, pero cambió drásticamente la forma en que necesitaba almacenar los datos, procesarlos, etc.

Nuevamente, me tomó cerca de un día reestructurar la tabla de la base de datos y volver a escribir el código básicamente desde cero para admitir esta nueva solicitud. Se lo devolví a él, y sucedió exactamente lo mismo. Pidió otra cosa que cambió drásticamente la forma en que necesitaba procesar los datos. Así que tuve que reescribirlo de nuevo. Finalmente, lo aprobó y, con suerte, no tendré que volver a escribirlo.

Solo sea claro, no estoy criticando a mi manager ni nada de eso. Es un gran tipo y las cosas que solicitaba no estaban fuera de este mundo, simplemente eran incompatibles con lo que había hecho anteriormente.

Solo me pregunto si hay algo que pueda hacer en el futuro para evitar reescrituras completas. Entiendo que hago un código flexible y estaba tratando de hacerlo, pero me gustaría saber de cualquier práctica o cosas que podría haber hecho de manera diferente para facilitar esto, por lo que, en el futuro, no paso 3 días en algo que debería haber tomado 1.

    
pregunta SH7890 11.07.2017 - 20:51

5 respuestas

21

Como comenté, tengo la fuerte sensación de que los requisitos no estaban claros la primera vez o que probablemente te perdiste algunos detalles importantes.

No todo se puede abordar con un mejor código, mejores prácticas, patrones de diseño o principios OOP. Ninguno de ellos le impedirá rehacer toda la aplicación si la implementación se basa en suposiciones falsas o premisas erróneas.

No se apresure a codificar la solución. Antes de escribir un solo LOC, dedique algo de tiempo a aclarar los requisitos. Cuanto más profundice en los requisitos, más preguntas qué pasará si aparecen. No espere a que el administrador lo sorprenda con el siguiente what-if . Anticipe las cosas usted mismo. Este pequeño ejercicio puede reducir significativamente el factor sorpresa .

No tenga miedo de preguntar tantas veces como lo necesite. A veces, los árboles (detalles) no nos permiten ver el bosque (la imagen general). Y es el bosque lo que necesitamos ver primero.

Cuando los requisitos están claros, es más fácil tomar mejores decisiones durante la fase de diseño.

Finalmente, recuerda que la imagen general es un objetivo. El camino hacia esta meta no es ni sencillo ni directo. Los cambios continuarán ocurriendo, así que sea ágil.

    
respondido por el Laiv 11.07.2017 - 23:12
4

No hay forma de saberlo en base a lo que has dado. Es más rápido y sucio, que es lo que necesitabas en ese momento. Pero a alguien le gustó y se está volviendo complejo, por lo que ahora está empezando a ver que muchos problemas no se muestran hasta que la complejidad se establece. Hay tantas cosas diferentes que se pueden hacer que son simplemente abrumadoras.

Hay el viejo, "No Silver Bullet", y es cierto. Nuevamente, no hay manera de saber qué hacer con las especificaciones completas (o las mejores especificaciones en curso para Agile), y la capacidad de usar buenos principios de programación y buenos diseños. A los programadores les encanta reescribir, una y otra vez . No estoy diciendo que caigas en esto necesariamente, porque en este momento es pequeño.

Aproveche esta oportunidad para aplicar algunos principios básicos. Encontrarás que funcionan, pero entonces alguien dirá: "Oh no, eso es malo" o harás otra cosa que te guste. No puede hacerlo todo con el dinero de la compañía, pero si le dan tiempo para explorar, úselo como una oportunidad. Hay siempre alguien, alguna fundación, alguna persona, que tiene la "mejor" forma o alguna "nueva" forma de hacer las cosas.

    
respondido por el johnny 14.07.2017 - 18:29
2

Lo más probable es que su gerente tenga razón en cada uno de los pasos que ha seguido. No es porque él sea el gerente, sino porque está considerando los resultados y la facilidad de uso y probablemente el número de tratos anteriores con clientes o solicitudes de clientes.

La interfaz de usuario es difícil, por lo general, 5 personas tienen 15 vistas diferentes. Y los datos y la estructuración de datos y el análisis de datos tienden a cambiar eso multiplicado por el factor 10 :). La interfaz de usuario es como la moda, algunas combinaciones son geniales, algunas son terribles o carecen de sentido común.

Sin mencionar que, por ejemplo, durante el proceso LEAN, nada está escrito en piedra. Está experimentando algo así como una evaluación iterativa y durante cada paso, es poco mejor o se evita el camino incorrecto.

La respuesta tan simple es que no hay tal cosa como que no se pueda volver a escribir.

    
respondido por el ipavlu 13.07.2017 - 00:00
1

No tengo una respuesta, sino un ejercicio, uno que probablemente tendrá que hacer en su propio tiempo, aunque, dependiendo de su organización, podría obtener permiso para hacerlo durante las horas de trabajo .

Vuelva a diseñar su primera solución para hacer exactamente lo que hizo, pero haga que sea más fácil agregar los pasos 2º, 2º y 3º. No agregue esos pasos, no los apague. Simplemente cree una solución que cumpla con todos los requisitos originales pero que pueda actualizarse fácilmente para incluir la nueva función. Haz lo mismo con tu segunda solución.

    
respondido por el jmoreno 16.07.2017 - 01:34
1

El desarrollo iterativo (que es lo que hiciste básicamente, aunque las iteraciones de un día) a menudo es así. Los primeros intentos de encontrar soluciones a menudo están fuera de lugar, y al recopilar comentarios, el sistema converge en una solución. Tomaré prestada la Figura 2.2 del material del instructor de Craig Larman para su libro Applying UML and Design Patterns .

Aliniciodeunproyecto,aprendesavivirconlasversionesaparentementeinestables.Noestoydeacuerdoconlasrespuestasquedicen"tienes que cumplir con más requisitos desde el principio", porque ese es el pensamiento de Waterfall. Es cierto que debe esforzarse por obtener todo lo que pueda en términos de requisitos, pero por muchas razones no es posible tener requisitos completos y precisos.

Esto no quiere decir que no pueda reducir la cantidad que tiene que volver a escribir después de recibir comentarios. Una cosa que a menudo ha sido cierta es que es muy probable que la interacción del software entre humanos y computadoras cambie, porque es una parte difícil de corregir la primera vez.

Piense en Microsoft Word y en cómo su formato de datos (.doc) no evolucionó mucho a lo largo de los años. Esto se debe a que un documento de texto como un dominio problemático realmente no evolucionó mucho (una página sigue siendo una página, un párrafo sigue siendo un párrafo, etc.). Sin embargo, la interfaz de usuario de Word evolucionó mucho (y continúa). El código para la presentación o entrada tiende a ser inestable entre las versiones, por lo que es mejor no tener las otras partes del sistema acopladas directamente a ellas (para aislarlas de la reescritura).

Las arquitecturas de software que pueden separar la presentación de la lógica subyacente y los datos sobre el problema permiten menos reescrituras. Muchos patrones de software como Separación Modelo-Vista se produjeron debido a que personas como usted sufrieron durante muchos -Escribe, y buscó una mejor manera.

Esto puede sonar muy budista, pero eres afortunado de haber sufrido estas reescrituras. Muchas personas aprenden sobre patrones MVC u otros patrones de diseño sin haber "sufrido" las pesadillas de reescritura que se supone que los patrones deben evitar.

    
respondido por el Fuhrmanator 16.07.2017 - 04:24

Lea otras preguntas en las etiquetas