Cómo evitar reescribir partes de una aplicación

Estoy trabajando en una empresa en un proyecto para su departamento de ventas. Es mi primer trabajo de programación profesional, pero he estado codificando y aprendiendo por años. Parte del proyecto implica tomar algunos datos y combinarlos con entradas 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 "¿y si tuviéramos esto?", Y quería que agregara algo al gráfico. Este no fue un gran cambio en el aspecto o la función del programa, pero cambió drásticamente la forma en que necesitaba almacenar datos, procesarlos, etc.

Nuevamente, me tomó alrededor de un día reestructurar la tabla de la base de datos y reescribir el código básicamente desde cero para admitir esta nueva solicitud. Se lo llevé de nuevo y sucedió exactamente lo mismo. Pidió algo más que cambió drásticamente la forma en que necesitaba procesar los datos. Entonces, tuve que reescribirlo nuevamente. Finalmente lo firmó y, con suerte, no tendré que volver a escribirlo de nuevo.

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

Me pregunto si hay algo que pueda hacer en el futuro para evitar reescrituras completas. Entiendo hacer 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 pasaré 3 días en algo que debería haber tomado 1.

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 de OOP. Ninguno de ellos le impedirá rehacer toda la aplicación si la implementación se basa en suposiciones falsas o premisas incorrectas.

No se apresure a codificar la solución. Antes de escribir un solo LOC, dedique un tiempo a aclarar los requisitos. Cuanto más profunda es profundizar en los requisitos, más lo que si preguntas aparecen. No esperes a que el gerente te sorprenda con el próximo " qué pasaría si" . 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 dejan ver el bosque (la imagen general). Y es el bosque lo que necesitamos ver primero.

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

Finalmente, recuerde que la imagen general es un objetivo. El camino hacia este objetivo no es sencillo ni directo. Los cambios continuarán sucediendo, así que sea ágil.

No hay forma de saberlo en función de lo que ha 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á comenzando a ver que muchos problemas no se muestran hasta que se presenta la complejidad. Hay tantas cosas diferentes que se pueden hacer que es simplemente abrumador.

Está el viejo "No Silver Bullet", y es verdad. Nuevamente, no hay forma de saber qué hacer con las especificaciones completas (o mejores especificaciones continuas para Agile), y la capacidad de usar buenos principios de programación y buenos diseños. Los programadores adoran reescribir, una y otra vez . No digo que caigas en esto necesariamente porque, en este momento, es pequeño.

Aproveche esta oportunidad para aplicar algunos principios básicos. Encontrará que funcionan, pero luego alguien dirá: "Oh, no, eso es malo" o usted hará algo más que le 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, algún fundamento, alguna persona, que tiene la "mejor" manera o de alguna manera "nueva" de hacer las cosas.

Su gerente probablemente tenía razón en cada uno de los pasos que realizó. No es porque él sea el gerente, sino porque está considerando los resultados y la usabilidad y, probablemente, la cantidad de tratos previos 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 multiplicando por el factor 10 :). La interfaz de usuario es como la moda, algunas combinaciones son geniales, algunas son terribles o no tienen 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 un poco mejor o se evita un camino incorrecto.

La respuesta tan simple es que no existe tal cosa como no reescribir en absoluto.

El desarrollo iterativo (que es lo que hiciste básicamente, aunque las iteraciones de un día) es a menudo así. Los primeros intentos de 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 Aplicación de patrones UML y Diseño .

Al comienzo de un proyecto, aprende a vivir con las aparentes versiones inestables. No estaré de acuerdo con las respuestas que dicen "tienes que obtener más requisitos desde el principio", porque eso es pensar en 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 reescribir después de recibir comentarios. Una cosa que a menudo ha sido cierta es que es muy probable que cambie la interacción humano-computadora del software, porque esa es una parte difícil de hacer bien la primera vez.

Piense en Microsoft Word y cómo su formato de datos (.doc) realmente no evolucionó mucho con los años. Esto se debe a que un documento de texto como 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 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 una menor reescritura. Muchos patrones de software, como la separación de Model-View, se produjeron debido a que personas como usted sufrieron muchas reescrituras y buscaron una mejor manera.

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

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

Rediseñe su primera solución para hacer exactamente lo que hizo, pero facilite agregar los pasos segundo o segundo y tercero. 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. Haga lo mismo para su segunda solución.

Los requisitos cambian, eso es un hecho de la vida. En retrospectiva: ¿Podría la primera solución haber sido diferente para que el tiempo total de programación hubiera sido menor? Eso es lo que aprendes a hacer con la experiencia.

Esa es la primera curva de aprendizaje empinada. Cuando gestiones esto, habrá un segundo desafío: ¿cómo manejas los requisitos modificados cuando los usuarios han almacenado un año de datos que no quieren tirar?

Según su historia, es obvio que los requisitos y las decisiones arquitectónicas preferidas no se han comunicado lo suficientemente bien. Por lo tanto, uno de ustedes, o tal vez ambos, son malos comunicadores.

También podría ser el arquitecto, ya que algunos arquitectos obtienen un alto estatus por sus buenos logros al programar solos, o una gran educación (que también suele ser sobre estudiar solo), o ser el primer desarrollador de la empresa (obviamente solo) y son No es necesariamente bueno comunicarse con el equipo. No es raro que continúen centrándose en gran medida en la programación en lugar de documentar los diseños y apoyar al equipo.

Sin embargo, también en este caso puede intentar compensarlo hablando más, haciendo preguntas y tomando notas. Incluso puede escribir una pequeña especificación usted mismo y pedirle al arquitecto que la apruebe.