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

Te has tropezado 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. Construir software es un oficio, uno que solo adquieres a través de años de práctica y la experiencia de utilizar tu software (los usuarios son críticos mucho más duros que los maestros). La creación de software también suele ser un negocio, donde los objetivos comerciales pueden anular las ambiciones técnicas.

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

En segundo lugar, has aprendido muchas cosas valiosas, por lo que deberías apreciar la experiencia de lo que te ha enseñado :

1. El código de enrollamiento 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 propietarios de negocios no técnicos a menudo no entienden el impacto de las decisiones técnicas (como a quién contratar), y los desarrolladores tienen que 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 existentes y cuándo usarlos.
5. Las personas recién egresadas asignadas a un gran proyecto con poca orientación tienden a producir un tazón de código de espagueti. Esto es normal.

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

1. Comunicar, comunicar, comunicar. 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 sobre qué hacer. Si mantiene el conocimiento para sí mismo, los privará de opciones.
2. Resiste 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 imaginabas. En su lugar, elija una arquitectura y migre el código base gradualmente. Incluso una base de código horrible puede ser salvada de esta manera. Lee libros sobre refactorización para ayudarte.
3. Obtenga información acerca de las pruebas automatizadas / pruebas unitarias . Tienes que aumentar la 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, hágalas manualmente y de manera exhaustiva (intente romper su código, porque los usuarios lo harán). Registre todos los errores que encuentre para que pueda establecer prioridades y solucionarlos (no tendrá tiempo para solucionarlos, no se enviará ningún software 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 se me haya lanzado para corregirlo.

Relájate, esto le pasa a mucha gente. Un junior que no tiene experiencia, que no tiene ayuda, ni apoyo ni 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, se desempeñe bien y se pueda mantener, no es realista en absoluto. Demonios, tienes suerte si todo eso sucede con un programador senior.

En mi opinión tienes que venir limpio. Esto no será divertido. Dígales que ha hecho todo lo posible, funciona (en su mayoría), pero le preocupa que no funcione bien y que haya muchos errores (siempre hay errores ). Debe ser revisado por un programador senior, y deben ser capaces de solucionar cualquier problema evidente de seguridad / rendimiento con bastante rapidez. O pueden desplegarlo y cruzar los dedos. O bien irá bien, o irá a fumar. Tal vez usted puede solucionar los problemas a medida que surgen. Si tienes una gran base de usuarios tal vez no.

O puedes hacer lo que la mayoría de la gente hace en esta situación: toma el dinero, desaparece y deja que lo resuelvan. Dejaré que usted decida cuál es la elección ética.

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

Una parte de la alegría de ser 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, despliegue y corrección de errores. Es su trabajo explicar la importancia de las pruebas y reservar un tiempo para realizar las pruebas. Usted tiene para defender su posición aquí. La gente no entenderá la importancia ( "¿no podemos comenzar a usarla?" ) pero una vez que comiencen a realizar pruebas (¡no en el entorno real!), 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. Debes enfatizar la importancia de las pruebas y la corrección de errores aquí. Recuerda, no son programadores, no saben la diferencia entre una división por cero y una etiqueta html rota.

A menudo, muchos de los problemas que surgen no son realmente errores. Serán problemas de usabilidad, requisitos perdidos, requisitos que han cambiado, expectativas del usuario (¿por qué no puedo usar esto en mi móvil?) Y luego los errores reales reales. Debe solucionar estos problemas antes de ir a vivir, a menudo se pueden solucionar muchos errores unos días después. Si la gente espera un sistema perfecto, sufrirá mucho dolor. Si esperan errores, tu vida será mucho más fácil en las próximas semanas.

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

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

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

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

TL; DR Las pruebas son buenas

Siempre que comience desde cero, es casi seguro que cometerá la misma cantidad de errores o más debido al Síndromme del segundo sistema . Sus nuevos errores serán diferentes, pero la cantidad de tiempo necesario para la depuración será similar y también lo hará la desesperación 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 "peor error estratégico" que cualquier empresa o desarrollador puede cometer.

El enfoque recomendado es, en cambio, limpiar el error inicial poco a poco durante el mantenimiento. Y ni siquiera intentes refactorizarlo por el simple hecho de hacerlo. Además, los gerentes suelen ver eso como un desperdicio de dinero (lo que a menudo es) y conlleva un riesgo innecesario de introducir nuevos errores. Una vez que haya depurado el código, puede que no sea bonito, pero funcionará. Así que déjalo estar hasta que necesites tocarlo por otras razones (ya sea una corrección de errores, una nueva función o simplemente un cambio solicitado por marketing). Luego limpie las partes que sean más difíciles de ajustar. Esto suele denominarse Regla de Boy Scout .

Y en ese momento no tiene que discutirlo con el gerente. Simplemente 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 rendirse un poco porque la compañía está realmente en una situación difícil y cuando no quiere 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 Big Ball of Mud .

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

  

El envío es una función.

No hay nada peor que ese tipo que sigue "limpiando" el código existente (posiblemente hacky, feo, sucio) que funciona perfectamente bien , introduciendo nuevos errores, etc. Lo que importa en la realidad El mundo es hacer tu trabajo. Has hecho eso. Enviar. No te pierdas en los rediseños de un proyecto que funciona perfectamente bien, incluso si es feo debajo del capó. Cuando lo arregles, hazlo de manera incremental y conviértete en un buen conjunto de pruebas para tener la menor cantidad de regresiones posibles.

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

Perfecto es el enemigo del bien.

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 de Bob de tío.

  

Tengo este pensamiento persistente de que tengo que volver a escribir el conjunto   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 finalizado el rediseño, habrá aprendido cosas nuevas y se dará cuenta de que las primeras partes son muy poco profesionales, por lo que querrá volver a escribirlas.

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

Lo estás haciendo bien.

Usted dice que su código funciona, y está casi listo para ser enviado, ¿verdad? Y percibes que tu código puede ser mejorado enormemente. Bien.

Su dilema me recuerda mucho a mi primera experiencia con el trabajo independiente (ser contratado en mi segundo año en la universidad para crear un sistema POS multilingüe). Pasé por un sinfín de preguntas ya que nunca estuve satisfecho con el código, quería escalabilidad, quería reinventar mejores ruedas ... Pero solo retrasé el proyecto (aproximadamente 12 meses aproximadamente) y ... ¿qué? Una vez que implementas la aplicación, todavía se necesitan muchas pruebas, pruebas, parches, etc. ...

¿Tiene experiencia trabajando con bases de códigos profesionales? Muchas bases de códigos están llenas de códigos extraños y difíciles de mantener. Una alternativa a descubrir la complejidad del software al tratar de construir un programa grande usted mismo sería mantener / extender el 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 correcta, funcionará igual de bien, entonces, usted piensa que el código spaghetti no funciona. t significa que no debe ser implementado.

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

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

En resumen, a menos que pueda demostrar que todo saldrá en la cara de todos si se implementa, retrasar la implementación sería poco profesional y no beneficiará ni a usted ni a su cliente. Aprender a hacer pequeños refactores al corregir errores o agregar nuevas funciones, será una experiencia valiosa para usted.

La mayoría de lo que diría en respuesta a su pregunta ha sido dicho por otros. Lee "Cosas que nunca deberías hacer, Parte I" por Joel Spolsky (junto con algunos de sus otros artículos sobre "astronautas de la arquitectura"). Recuerda que "lo perfecto es enemigo de lo bueno". Aprende a refactorizar de forma incremental. El envío es importante, etc.

Lo que agregaría es esto: se le ha asignado una tarea que un solo graduado recién graduado consideró factible y que trabaja con un pequeño presupuesto / calendario de inicio. No debería necesitar nada 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úrese de que en realidad haga la programación procesal estructurada. La repetición en su código no es necesariamente una señal de que necesita grandes estructuras polimórficas. Simplemente podría ser una señal de que necesita tomar el código repetido y colocarlo en una subrutina. El flujo de control de "Spaghetti" puede ser simplemente una oportunidad para deshacerse de un global.

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í te resultarán más interesantes si lees ese libro. Básicamente, tasa de quema de recursos es tu peor enemigo y nada es más valioso para ti y tu organización que el usuario final / comentarios de los 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 el código). Deje que sus clientes dicten sus futuros cambios y versiones, y no al revés. Si se enfoca en ese enfoque, tanto usted como su jefe serán más felices a largo plazo.

Por razones que otros han explicado detalladamente, es hora de finalizar el proyecto y enviarlo, por más doloroso que sea.

Me gustaría enfatizar que testing la aplicación también es parte de "terminarla". Si piezas significativas de funcionalidad no se han ejercitado a fondo y correcto resultados confirmados, entonces usted está justificado en su preocupación de que la gente tendrá problemas con esta aplicación cuando se implementa.

Las pruebas de unidad y las pruebas automatizadas de nivel superior son excelentes y son cosas que debería tener tanto como pueda antes de tratar de refactorizar (o reescribir) esta aplicación. Pero en este momento, principalmente necesita probar , incluso si tiene que realizar cada prueba "a mano" y confirmar el correcto funcionamiento "a ojo". Si puede descubrir cómo automatizar esas pruebas más adelante, eso ayudará cuando sea 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 usuario de prueba alfa y hacer que las cosas salgan mal. Es decir, son buenos para romper cosas. Si tienes la suerte de tener a una persona tan talentosa trabajando contigo, déjala probar la aplicación primero para que puedas corregir cualquier error obvio antes. Si tiene que hacer esta tarea usted mismo, entonces:

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

Su pregunta dice: "Comenzó mal, debería volver a empezar", mientras que el texto adicional realmente dice "Proyecto finalizado, pero salió mal, debería comenzar de nuevo". Solo para el encabezado 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, comenzar con todo 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 lo tira y comienza de nuevo, esta vez con una buena comprensión del problema, significa que realmente terminará más rápido.

Esto es lo que yo haría personalmente:

1. Renuncie, invente una excusa y renuncie (incluso puede devolver parte de su salario para no verse 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 obtendrán una retención de este código. Harán todo tipo de suposiciones y juicios sobre usted y su capacidad. No les importa cuando lo escribes, no les importa la circunstancia. Solo quieren ver en él lo que quieren ver para confirmar lo que quieran confirmar.

Serás calificado como cualquier nombre de pila, término que pueden crear para impactarte negativamente. Y aunque el usuario en el futuro podría ser totalmente diferente en términos de capacidad técnica, habilidades, conocimientos, estilo y la situación será muy diferente, este código se utilizará contra usted 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 usted ni siquiera lo sabe, por lo que puede explicarse y defenderse. (y es posible que aprendas muy a menudo que están profundamente equivocados, repetidamente). Así que no lo hagas. Renunciar.

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 te gustó esto en la situación A, lo harás en la situación B. Piensan que es muy simple.

Dos sugerencias más, apuesto al menos a una de estas que no has hecho.

1) Coloque un rastreador de errores en su lugar y enséñele a su jefe a usarlo. Esto puede ser parte de la conversación sobre cómo se equivocó, aprendió mejor y lo arreglaremos de manera planificada

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

Hay montones de sistemas alojados que proporcionan lo anterior de forma gratuita en cuentas pequeñas. 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.

edit

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

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

Para responder a tu pregunta: como muchos otros han dicho, no. Envíelo y límpielo 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 encuentre que nada puede igualar el aprendizaje que recibirá de trabajar (o incluso de hablar de trabajo) con otros programadores. Encontrar y asistir a un grupo local para una tecnología que está utilizando o que le gustaría aprender es una maravillosa inversión de su tiempo. Además de los conocimientos técnicos que se deben adquirir, es una forma fácil de conectarse en red, que es invaluable a medida que espera futuros conciertos.

Tu jefe era consciente de tu nivel de experiencia cuando te contrató. Solo expresa tus inquietudes y déjale 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 para aconsejarte, 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 pudo 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, para 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 : esté contento de ser un desarrollador mejor que hace un año. El próximo proyecto lo harás mejor (y al final volverás a tener más experiencia y no estarás contento con lo que has hecho; eso es normal). Cambiar o reescribir el último proyecto 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 el código mal conservado puede ser más difícil que reemplazarlo por un buen código. Y si recibe ayuda de un nuevo desarrollador sin experiencia, dígales que este código no es un ejemplo que deban copiar.