Cómo evitar reescribir 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 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.


2
¿Qué paradigma de programación estás usando? ¿Procesal, orientado a objetos, funcional, otro?
Tulains Córdova

2
Para evitar reescrituras, desacople su base de datos y su capa de aplicación. No es un concepto simple de aplicar a cómo se escribe el código. Es un concepto complejo que hace que su código sea simple y adaptable.
StackOverFowl

66
Parece que los requisitos no estaban claros o los malinterpretaste. Ningún principio o práctica recomendada puede salvarlo de volver a hacer una aplicación completa si la implementación se realizó sobre suposiciones falsas. Antes de escribir por una sola LOC es bueno preguntar a los requisitos de " ¿Qué pasaría si ... " ... No espere a que el gerente que sorprende con un nuevo ¿Qué pasaría si ... . Pasar algún tiempo buscando las brechas funcionales también reducirá el factor sorpresa .
Laiv

3
La inyección de dependencia es tu amiga. Busca en Google y ve cómo aplicarlo a tu idioma / marco. Le permitirá escribir un código mucho más modular, lo que debería disminuir la cantidad de código que debe reescribirse cuando cambian los requisitos.
Eterno21

2
Si bien puede parecer que muchas reescrituras son malas, lo que realmente importa es qué tan rápido puede responder a las solicitudes de sus usuarios finales. Si bien depende de la complejidad del proyecto, diría que 1 día es un tiempo de entrega bastante bueno: ¡debe estar haciendo algo bien! De hecho, el software que ve cambios significativos es una buena señal, significa que es útil y está mejorando. El software que no ha sido alterado significativamente durante años es mucho más difícil de mantener.
Justin

Respuestas:


22

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.


3
Esta. Esta respuesta es la mejor forma en que se podría decir. Obtenga esos requisitos antes de hacer absolutamente cualquier cosa.
Rhys Johns

1
Esta es una buena respuesta, pero tengo la sensación de que hay una mejor manera de estructurar la aplicación para que sea más fácil acomodar estas solicitudes. No creo que ninguno de los llamados "principios" flotantes ayudaría; La solución debe ser específica para el problema. Sin más información, su respuesta es la única que tiene sentido.
Frank Hileman

Bueno, tuve la fuerte sensación de que el problema fue el que comenté porque fue exactamente lo que me sucedió en mis primeros días como desarrollador. Traduje instantáneamente frases a LOC o módulos, y cuando tuve que cambiar algo fue bastante dramático para mí. Refactorizar sobre refactorizar todos los días o semanas. Ni siquiera hice mi mejor esfuerzo con SoC, SPR, polimorfismo, ... Muchos de los conflictos que tuve con los cambios fueron causados ​​por mi pérdida de visión general.
Laiv

2
Para construir sobre esta respuesta: es importante ser también ágil con respecto a la recopilación de requisitos. A veces las personas obtienen nuevas ideas o recuerdan algo que olvidaron cuando ven el producto. Pueden decir: "Sé que te pedí que construyeras esto, pero no es lo que quise decir" o "Sé que pedí esto, pero ahora que lo veo, quiero algo más". Puede evitar que esto cause frustración y retrabajo creando una "Prueba de concepto" rápida y sucia. Esto incluso puede ser una maqueta como un gráfico falso. Ayuda a su cliente a pensar.
Akhil

1
Algunos pueden argumentar que no es necesario abstraer la base de datos del código porque "los proveedores de base de datos rara vez cambian". Estoy de acuerdo con usted, pero el punto de mi respuesta es: al reunir los requisitos, olvide que es un desarrollador, concéntrese en la recopilación de requisitos. Piensa como un gerente, pregunta como un gerente. No te apresures a pensar como un desarrollador.
Laiv

4

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.


Buen artículo que vinculaste.
SH7890

1
Buen artículo de hecho! Creo que no es el caso de OP, pero no podría estar más de acuerdo con el autor.
Laiv

1
No pensé que fuera uno por uno, pero decía que podría ser algún día. Esperemos que esto ayude al OP.
johnny

2

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.


2

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 .

ingrese la descripción de la imagen aquí

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.


Preferiría que esta respuesta fuera la aceptada. Iterar hacia una solución es mejor que tratar de establecer todos los requisitos por adelantado. Especialmente si la aplicación completa puede reescribirse dentro de un día.
Eufórico el

Estoy seguro de que el jefe no sabía lo que quería en la segunda iteración hasta que se completó la primera. “Reunir más requisitos de antemano hubiera sido imposible.
gnasher729

1

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.


1

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?


-1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.