El proyecto está casi terminado, pero el código de espagueti de procedimiento. ¿Reescribo o sigo intentando enviarlo? [cerrado]

Soy un desarrollador web principiante (un año de experiencia).

Un par de semanas después de graduarme, me ofrecieron un trabajo para crear una aplicación web para una empresa cuyo propietario no es muy experto en tecnología. Me reclutó para evitar el robo de su idea, el alto costo de desarrollo cobrado por una empresa de servicios, y para tener a alguien joven en quien confiar a bordo para mantener el proyecto a largo plazo (llegué a estas conclusiones por mí mismo mucho después de ser contratado )

Engreído como era en aquel entonces, con un diploma en ciencias de la computación, acepté la oferta pensando que podía construir cualquier cosa.

Estaba llamando a los tiros. Después de un poco de investigación, me decidí por PHP y comencé con PHP simple, sin objetos, solo código de procedimiento feo. Dos meses después, todo se estaba volviendo desordenado y era difícil avanzar. La aplicación web es enorme. Así que decidí consultar un marco MVC que me facilitaría la vida. Ahí es donde me topé con el chico genial de la comunidad PHP: Laravel. Me encantó, fue fácil de aprender y comencé a codificar de inmediato. Mi código se veía más limpio, más organizado. Se veía muy bien.

Pero, de nuevo, la aplicación web era enorme. La compañía me estaba presionando para que entregara la primera versión, que querían implementar, obviamente, y comenzar a buscar clientes.

Debido a que fue divertido trabajar con Laravel, me hizo recordar por qué elegí esta industria en primer lugar, algo que olvidé mientras estaba atrapado en el sistema educativo de mierda.

Así que comencé a trabajar en pequeños proyectos por la noche, leyendo sobre metodologías y mejores prácticas. Revisé OOP, pasé al diseño y análisis orientado a objetos, y leí el libro Clean Code del tío Bob .

Esto me ayudó a darme cuenta de que realmente no sabía nada. No sabía cómo construir software DE LA MANERA CORRECTA. Pero en este punto ya era demasiado tarde, y ahora casi termino. Mi código no está limpio en absoluto, solo código de espagueti, un verdadero problema para solucionar un error, toda la lógica está en los controladores y hay poco diseño orientado a objetos.

Tengo este pensamiento persistente de que tengo que reescribir todo el proyecto. Sin embargo, no puedo hacerlo ... Siguen preguntando cuándo se hará todo.

No puedo imaginar este código implementado en un servidor. Además, todavía no sé nada sobre la eficiencia del código y el rendimiento de la aplicación web.

Por un lado, la compañía está esperando el producto y no puede esperar más. Por otro lado, no puedo verme yendo más allá con el código real. Podría terminar, envolverlo e implementarlo, pero solo Dios sabe lo que podría suceder cuando la gente comience a usarlo.

¿Reescribo, o simplemente sigo intentando enviar, o hay otra opción que me he perdido?

Te has topado con el talón de Aquiles de la mayoría de las educaciones de CS: te enseñan las herramientas y técnicas, pero no el oficio. La creación de software es un oficio, uno que solo se adquiere a través de años de práctica y la experiencia de utilizar su software (los usuarios son críticos mucho más duros que los maestros). La creación de software también es a menudo un negocio, uno donde los objetivos comerciales pueden anular las ambiciones técnicas.

En primer lugar, nave. Si le muestra el software al propietario de la empresa y siente que está listo para enviar, envíe. Si no es a ese punto, pero cerca, termínelo. El único software que importa es el que realmente se usa. El único negocio de software que gana dinero es uno que tiene un producto.

En segundo lugar, ha aprendido muchas cosas valiosas, por lo que debe apreciar la experiencia por lo que le ha enseñado :

1. Lanzar código sin un plan o arquitectura es una receta para el desastre
2. La programación es mucho más que escribir código
3. Los dueños de negocios no técnicos a menudo no entienden el impacto de las decisiones técnicas (como a quién contratar), y corresponde a los desarrolladores explicarles las cosas.
4. La mayoría de los problemas ya se resuelven mucho mejor de lo que los resolvería en los marcos existentes. Vale la pena conocer los marcos que existen y cuándo usarlos.
5. Las personas recién salidas de la escuela asignadas a un gran proyecto con poca orientación tienden a producir un plato de código de espagueti. Esto es normal.

Aquí hay algunos consejos más sobre cómo proceder:

1. Comunicarse, comunicarse, comunicarse. Debe ser muy abierto y franco sobre el estado del proyecto y sus ideas sobre cómo proceder, incluso si no está seguro y ve múltiples caminos. Esto deja al dueño del negocio la opción de qué hacer. Si te guardas el conocimiento, los privas de opciones.
2. Resista la tentación de la reescritura completa. Mientras está reescribiendo, el negocio no tiene producto. Además, una reescritura rara vez resulta tan buena como la imaginaste. En su lugar, elija una arquitectura y migre la base de código gradualmente. Incluso una base de código horrible se puede salvar de esta manera. Lea libros sobre refactorización para ayudarlo.
3. Aprenda sobre pruebas automatizadas / pruebas unitarias . Debe generar confianza en el código, y la forma de hacerlo es cubrirlo con pruebas automatizadas. Esto va de la mano con la refactorización. Mientras no tenga las pruebas, realice la prueba de forma manual e integral (intente descifrar su código, porque sus usuarios lo harán). Registre todos los errores que encuentre para poder priorizarlos y corregirlos (no tendrá tiempo para corregir todos los errores, ningún software se envía sin errores en el mundo real).
4. Obtenga información sobre cómo implementar una aplicación web y mantenerla en funcionamiento. El libro Operaciones web: mantener los datos a tiempo es un buen comienzo.

Esto suena como cualquier otro sistema que me han lanzado para arreglarlo.

Relájate, esto le pasa a mucha gente. Un joven arrojado al fondo sin experiencia, sin ayuda, sin apoyo y sin guía no es exactamente una receta para el éxito. Contratar y esperar que un programador junior construya un nuevo sistema desde cero que funcione bien, funcione bien y sea mantenible no es realista en absoluto. Demonios, tienes suerte si todo eso sucede con un programador sénior.

En mi opinión, tienes que estar limpio. Esto no será divertido. Dígales que ha hecho todo lo posible, funciona (principalmente), pero le preocupa que no funcione bien y que haya muchos errores ( siempre hay errores). Debe ser revisado por un programador senior, y deberían poder solucionar cualquier problema evidente de rendimiento / seguridad con bastante rapidez. O pueden desplegarlo y cruzar los dedos. O bien irá bien, o se volverá humo. Tal vez pueda solucionar los problemas a medida que surjan. Si tiene una gran base de usuarios, tal vez no.

O podría hacer lo que la mayoría de la gente hace en esta situación: tomar el dinero, desaparecer y dejar que lo resuelvan. Dejaré que usted decida cuál es la opción ética.

Editar (ya que esta pregunta tiene muchos votos, también podría agregar más contenido)

Parte de las alegrías de ser un programador es que las personas no técnicas (probablemente su gerente, definitivamente el resto del negocio) no tienen idea de lo que hace. Esto es bueno y malo. Parte de lo malo es que tienes que explicar constantemente cómo funcionan los proyectos de desarrollo de software. Planificación, requisitos, revisiones de código, pruebas, implementación y corrección de errores. Es su trabajo explicar la importancia de las pruebas y reservar tiempo para realizar las pruebas. Usted tiene que defender su posición aquí. La gente no entenderá la importancia ( "¿no podemos empezar a usarlo?") pero una vez que comiencen las pruebas (¡no en el entorno en vivo!) comprenderán rápidamente los beneficios. Una de las razones por las que lo contrataron es porque no saben nada sobre el desarrollo de software, por lo que depende de usted educarlos. Debe enfatizar la importancia de las pruebas y la corrección de errores aquí: recuerde que no son programadores, no conocen la diferencia entre una división entre cero y una etiqueta html rota.

A menudo, muchos de los problemas que surgen en realidad no son errores. Serán problemas de usabilidad, requisitos incumplidos, requisitos que han cambiado, expectativas del usuario (¿por qué no puedo usar esto en mi móvil?) Y luego los errores reales reales reales. Debe solucionarlos antes de ponerlo en funcionamiento; a menudo, se pueden solucionar o solucionar muchos errores unos días después. Si las personas esperan un sistema perfecto, sufrirán mucho dolor. Si esperan errores, su vida será mucho más fácil en las próximas dos semanas.

Ah, y no confunda las pruebas de usuario con las pruebas unitarias ni con las pruebas del sistema.

• Prueba de unidad: ¿la función de mi código devuelve el valor correcto?
• Prueba del sistema: ¿arroja un error cuando hago clic en X
• Prueba de aceptación del usuario (UAT): ¿cumple el programa con los requisitos? ¿Hace lo que te pidieron que hicieras? ¿Se puede ir en vivo?

Si no ha anotado los requisitos de lo que le pidieron que haga, UAT será mucho, mucho más difícil. Aquí es donde cae mucha gente. Tener lo que querían que el sistema hiciera escrito en papel hará que su vida sea mucho más fácil. Dirán "¿Por qué no hace X?" y puedes decir "Me dijiste que hiciera Y". Si el programa está mal, corríjalo. Si los requisitos son incorrectos, arregle el documento, solicite uno o dos días adicionales (no, insista en ello), realice el cambio, actualice la documentación y vuelva a realizar la prueba.

Una vez que haya pasado por este proceso varias veces, puede comenzar a buscar Agile ... pero ese es otro mundo :)

TL; La prueba de DR es buena

Siempre que comience desde cero, seguramente cometerá la misma cantidad de errores o más debido al Segundo Síndrome del Sistema . Sus nuevos errores serán diferentes, pero la cantidad de tiempo necesaria para la depuración será similar y, por lo tanto, se desesperará acerca de cómo no encaja bien. También retrasará la implementación en la producción o la implementación de nuevas características si se implementa la primera versión, lo que será un problema grave para la empresa. Joel Spolsky lo llama "el peor error estratégico" que cualquier empresa o desarrollador puede cometer.

El enfoque recomendado es, en cambio, limpiar el desorden inicial poco a poco durante el mantenimiento. Y ni siquiera intentes refactorizarlo por el simple hecho de hacerlo. Además, los gerentes generalmente ven eso como una pérdida de dinero (que a menudo es) y conlleva un riesgo innecesario de introducir nuevos errores. Una vez que haya depurado dolorosamente el código, puede que no sea bonito, pero funcionará. Así que déjelo hasta que necesite tocarlo por otros motivos (ya sea una corrección de errores, una nueva función o simplemente un cambio solicitado por el departamento de marketing). Luego limpie las partes que son más difíciles de ajustar. Esto a menudo se llama la Regla Boy Scout .

Y en ese punto no tiene que discutirlo con el gerente. Solo incluya la refactorización mínima deseada en la estimación de la solicitud. Aprenderá a través de la experiencia cuándo puede darse el lujo de ceder un poco porque la compañía está realmente en una situación y cuando no desea crear problemas en el futuro y simplemente no admite ninguna posibilidad de piratearlo rápidamente.

Por último, un poco más de lectura recomendada: la Gran Bola de Barro .

Olvidé dónde lo leí por primera vez, pero solo quería hacer eco, con algo más de fuerza, de lo que otras personas han dicho:

El envío es una característica.

No hay nada peor que ese tipo que sigue "limpiando" el código existente (posiblemente hacky, feo, sucio) que funciona perfectamente bien , presentando nuevos errores, etc. Lo que importa en el mundo real es hacer su trabajo. Has hecho eso. Embarcacion. No se pierda en los rediseños de un proyecto que funciona perfectamente bien, incluso si es feo debajo del capó. Cuando lo arregles, hazlo de forma incremental y conviértete en un buen conjunto de pruebas para que tengas la menor cantidad de regresiones posible.

Cada proyecto te deja más inteligente de lo que eras antes. Después de cada proyecto, habrá acumulado más experiencia, lo que habría sido muy útil cuando lo tuvo desde el principio. Sé que es difícil no volver a visitar todo y aplicar lo que has aprendido. Pero recuerda:

Lo perfecto es enemigo de lo bueno.

Para el cliente, siempre es mejor tener un buen software ahora que un software perfecto que nunca se lanzará.

Este fue solo tu primer proyecto. Habrá muchos más proyectos en el futuro donde podrá aplicar todo lo que ha aprendido desde el principio.

Leí el código limpio del tío Bob.

Tengo este pensamiento persistente de que tengo que reescribir todo el proyecto.

Este libro tiene una sección llamada, muy apropiadamente, "El Gran Rediseño en el Cielo".

No intentes reescribir todo porque, en el improbable caso de que tengas tiempo para hacerlo, enfrentarás los mismos problemas de todos modos. Cuando haya terminado el rediseño, habrá aprendido cosas nuevas y se dará cuenta de que las primeras partes no son muy profesionales, por lo que querrá volver a escribirlo.

El rediseño y la reescritura son buenos, pero solo si se realizan de forma incremental en un sistema de trabajo. Como señaló otro usuario, siga la Regla de Boy Scout, refactorizando su código poco a poco a medida que trabaja en él.

Lo estás haciendo bien.

Dices que tu código funciona y está casi listo para enviar, ¿verdad? Y percibes que tu código puede mejorarse enormemente. Bueno.

Su dilema me recuerda mucho a mi primera experiencia con el trabajo independiente (ser contratado durante mi segundo año en la universidad para crear un sistema de TPV multilingüe). Pasé por un interminable cuestionamiento ya que nunca estaba satisfecho con el código, quería escalabilidad, quería reinventar mejores ruedas ... Pero simplemente retrasé el proyecto (aproximadamente 12 meses aproximadamente) y ... ¿qué? Una vez que implemente la cosa, todavía necesita muchas pruebas, pruebas, parches, etc.

¿Tiene experiencia trabajando con bases de código profesionales? Muchas bases de código están llenas de código peculiar y difícil de mantener. Una alternativa para descubrir la complejidad del software al intentar construir un gran programa usted mismo sería mantener / extender un código igualmente desordenado escrito por otras personas.

Los únicos casos en los que he visto reescrituras completas hacen mucho bien es cuando el equipo adoptó simultáneamente una nueva cadena de herramientas / marco.

Si la lógica subyacente (lo que hace el programa, no cómo se presenta como funciones, clases, etc.) es sólida, funcionará igual de bien, por lo tanto, si crees que es un código de espagueti no significa No debe ser desplegado.

Debe dejar que su cliente tenga algo que pueda usar. Luego, cuando le piden que lo mejore / agregue funcionalidad, usted decide si es necesario un refactor, y está bien informarle a su cliente que "se necesita algún trabajo técnico para integrar dicha nueva característica". Por lo cual entenderán que les costará más dinero y tendrán que esperar más. Y lo entenderán (o puedes retirarte).

Un mejor momento para reescribir todo sería cuando otro cliente le pida que cree algo similar.

En resumen, a menos que pueda demostrar que todo el asunto explotará en la cara de todos si se implementa, retrasar la implementación no sería profesional y no beneficiará ni a usted ni a su cliente. Aprender a hacer pequeños refactores mientras corrige errores o agrega nuevas características, será una experiencia valiosa para usted.

La mayoría de lo que diría en respuesta a su pregunta ha sido dicho por otros. Lea "Cosas que nunca debe hacer, Parte I" de Joel Spolsky (junto con algunas de sus otras publicaciones sobre "astronautas de la arquitectura"). Recuerda que "lo perfecto es enemigo de lo bueno". Aprende a refactorizar gradualmente. El envío es importante, etc.

Lo que agregaría es esto: se le ha encomendado algo que un nuevo graduado considera factible trabajar con un pequeño presupuesto / marco de inicio. No debería necesitar nada mucho más sofisticado que una buena programación, estructurada y procesal. (Y para su información, "programación de procedimientos" no es una mala palabra. Es una necesidad en algún nivel en la mayoría de los casos, y es totalmente adecuada para muchos proyectos completos).

Solo asegúrate de hacer una programación estructurada y procesal. La repetición en su código no es necesariamente una señal de que necesita grandes estructuras polimórficas. Podría ser simplemente una señal de que necesita tomar el código repetido y ponerlo en una subrutina. El flujo de control de "espagueti" puede ser simplemente una oportunidad para deshacerse de un mundo.

Si hay aspectos del proyecto que legítimamente requieren polimorfismo, herencia de implementación, etc., sugeriría que tal vez se subestimó el tamaño del proyecto.

Si está realmente interesado en el dilema que tiene, también debe leer "Lean Startup". Muchos de los consejos que te están dando aquí resonarán más contigo si lees ese libro. Básicamente, la tasa de consumo de recursos es su peor enemigo y nada es más valioso para usted y su organización que los comentarios de los usuarios finales / clientes. Por lo tanto, lleve su producto a un estado viable (el Producto mínimo viable - o MVP) y luego envíelo por la puerta (independientemente de cómo se vea realmente el código). Deje que sus clientes dicten sus futuros conjuntos de cambios y versiones, no al revés. Si te enfocas en ese enfoque, tanto tú como tu jefe serán más felices a largo plazo.

Por razones que otros han explicado a fondo, es hora de terminar el proyecto y enviarlo, por muy doloroso que pueda ser.

Solo me gustaría enfatizar que probar la aplicación también es parte de "terminarla". Si no se han ejercido a fondo piezas significativas de funcionalidad y se han confirmado los resultados correctos, entonces está justificado su preocupación de que las personas tendrán problemas con esta aplicación cuando se implemente.

Las pruebas unitarias y las pruebas automatizadas de nivel superior son excelentes y son cosas que debe tener tanto como pueda antes de intentar refactorizar (o reescribir) esta aplicación. Pero en este momento, principalmente, debe probarlo , incluso si tiene que ejecutar cada prueba "a mano" y confirmar el funcionamiento correcto "a ojo". Si puede descubrir cómo automatizar esas pruebas más adelante, eso ayudará cuando llegue el momento de comenzar a trabajar en la próxima versión del producto.

Algunas personas tienen la habilidad de sentarse frente a un nuevo proyecto de software como usuarios de pruebas alfa y hacer que las cosas salgan mal. Es decir, son buenos para romper cosas. Si tiene la suerte de tener una persona tan talentosa trabajando con usted, permítale que pruebe la aplicación primero para que tenga la oportunidad de corregir cualquier error obvio antes. Si tiene que hacer esta tarea usted mismo, entonces:

• Sé metódico
• Prueba todas las funciones.
• Imagina que eres un usuario inexperto con tu aplicación. Cometa errores estúpidos y vea cómo los maneja el software.
• Escriba lo que está haciendo para que pueda volver a intentarlo después de pensar que ha solucionado los problemas.

Su pregunta dice: "Comenzó mal, debería comenzar de nuevo", mientras que el texto adicional en realidad dice "Proyecto terminado, pero lo hice mal, debería comenzar de nuevo". Solo para el título de la pregunta: si la cantidad de trabajo de programación que ha realizado es pequeña en comparación con el trabajo total necesario, entonces comenzar de nuevo tendrá sentido. Eso sucede mucho cuando el problema es complejo y mal entendido, y se dedica bastante tiempo a descubrir cuál es realmente el problema. No tiene sentido continuar con un mal comienzo, si tirarlo y comenzar de nuevo, esta vez con una buena comprensión del problema, significa que realmente terminará más rápido.

Esto es lo que haría personalmente:

1. Renunciar, poner una excusa y rendirse (incluso puede devolver parte de su salario para que no se vea mal)
2. Limpia tu código tanto como sea posible
3. Haga documentación sobre todas las partes buenas de su trabajo, como su buen diseño, buenas ideas, etc.

¿Por qué te sugiero todo esto?

Porque piensa en el futuro. Habrá tiempo en el futuro cuando ciertas personas se apoderarán de este código. Harán todo tipo de suposiciones y juicios sobre usted y su habilidad. No les importa cuando lo escribiste, no les importa la circunstancia. Solo quieren ver en él lo que quieren ver para confirmar lo que quieran confirmar.

Usted será calificado como cualquier mal nombre, término que puedan llegar a tener un impacto negativo en usted. Y aunque usted en el futuro bien podría ser totalmente diferente en términos de habilidad técnica, habilidades, conocimiento, estilo y la situación será muy diferente, este código se usará en su contra de todas las formas posibles. Es como un tribunal donde pueden decir todas las cosas malas sobre usted y su código y diseño, y ni siquiera lo saben para poder explicarse y defenderse. (y es posible que aprenda muy a menudo que están profundamente equivocados, repetidamente). No lo haga. Rendirse.

Confía en mí, hay personas que hicieron muchas suposiciones sobre ti porque hiciste algo para cualquier propósito en cualquier momento. Para ellos, si les gustó esto en la situación A, lo harán en la situación B. Piensan que es muy simple.

Dos sugerencias más, apostaría al menos una de estas que no ha hecho.

1) Coloque un rastreador de errores y enséñele a su jefe a usarlo. Esto puede ser parte de la conversación sobre cómo te equivocaste, aprendiste mejor y lo arreglarás de manera planificada

2) Comience a usar el control de versiones, aunque espero que ya lo esté haciendo.

Hay montones de sistemas alojados que ofrecen tanto lo anterior de forma gratuita en pequeñas cuentas. Soy particularmente aficionado a FogBugz, que también tiene un excelente sistema de estimación y finalización de tareas que le dará a su jefe aún más certeza de que está abordando las cosas de una manera bien administrada.

editar

Wow, a alguien realmente no le gustó esto: ¿un voto negativo Y una bandera de eliminación? ¿Por qué?

He estado desarrollando software durante más de treinta años, incluyendo mucho trabajo de consultoría y heredando el código de otras personas. Una gran cantidad de los sistemas problemáticos que he visto han sido donde las personas cavaron un pozo y no tenían notas detalladas sobre cómo llegaron allí ni tenían control de versiones.

Para responder a su pregunta: como tantos otros han dicho, no. Envíalo y límpialo poco a poco en el proceso de corregir errores.

Además, si bien los libros / StackExchange / webforums son buenos recursos de aprendizaje, es probable que descubra que nada puede igualar el aprendizaje que recibirá al trabajar (o incluso hablar sobre el trabajo) con otros programadores. Encontrar y asistir a un grupo local para una tecnología que está utilizando o le gustaría aprender es una maravillosa inversión de su tiempo. Además del conocimiento técnico que se va a adquirir, es una forma fácil de establecer contactos que es invaluable a medida que esperas conciertos futuros.

Tu jefe estaba al tanto de tu nivel de experiencia cuando te contrató. Solo expresa tus preocupaciones y hazle saber que estás nervioso por eso. También hágale saber cuánto ha aprendido y cuánto mejor puede hacer el próximo proyecto.

Eres un desarrollador web principiante, sin un buen desarrollador presente que te aconseje, tu jefe te contrató sabiendo esto completamente bien. Creo que lo estás haciendo tan bien como cualquiera podría esperar que lo hagas. En realidad, el hecho de que tenga la idea de que el trabajo podría haber sido mejor, y de que realmente aprendió cosas que le permitirían hacerlo mejor, significa que lo está haciendo mejor que la mayoría. Recuerde por su propia cordura que la versión de usted que comenzó el trabajo no podría haberlo hecho mejor. Alguien más experimentado (y por lo tanto mejor pagado), o usted con un proyecto de experiencia, podría haberlo hecho mejor.

Qué hacer ahora : Sé feliz de ser un mejor desarrollador que hace un año. El próximo proyecto lo hará mejor (y al final volverá a tener más experiencia y no estará contento con lo que ha hecho; eso es normal). Cambiar o reescribir el último proyecto le dará al negocio muy poco beneficio por el costo. Lo que puede hacer es reemplazar el código incorrecto con un código bueno cuando necesite hacer cambios de todos modos; eso tiene sentido porque modificar código mal mantenible puede ser más difícil que reemplazarlo con un buen código. Y si consigue que un nuevo desarrollador inexperto lo ayude, dígales que este código no es un ejemplo que deberían copiar.