¿Cómo puedo evitar que me castiguen por un proyecto que heredé que ya tenía errores, pero me dijeron que agregara funciones en lugar de arreglarlo?

Prodnegel

¿Cómo puedo evitar que me castiguen por un proyecto que heredé que ya tenía errores, pero me dijeron que agregara funciones en lugar de arreglarlo?

Pasado: Comenzar un nuevo trabajo como ingeniero de software fuera de la universidad. Se le asignó un lío de un proyecto sin comentar, sin documentar, sin capacitación ni mentores. Soy la única persona que trabaja en este proyecto, nadie más sabe o ha visto el código en absoluto .

Le digo a mi gerente que el código está muy desordenado y tiene errores, pero me dice que trabaje en las funciones en lugar de arreglar el código. Ahora han pasado meses y pronto será el momento de mostrar el programa al cliente, y me preocupa que me castiguen por dar un programa parcialmente "roto".

Dado que la refactorización no es y nunca fue una opción debido a las limitaciones de tiempo y los deseos del gerente, ¿qué puedo hacer para evitar mi muerte inminente? Siento que, sin querer, me prepararon para el fracaso desde el principio. Incluso creo que empeoré las cosas al agregar funciones además del código con errores, ya que tuve que hacer algunas cosas extrañas para evitar los errores.

¿Cómo puedo evitar ser castigado por un proyecto que heredé que ya tenía errores, mientras que me dijeron que trabajara en más funciones en lugar de corregir errores?

EDITAR: Siento que esto es diferente a la pregunta marcada como duplicada, ya que soy un desarrollador nuevo con 0 años de experiencia. Siento que este es un aspecto importante de mi situación.


Mónica Celio

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .

Fresa

Ah, el cáliz envenenado. Creo que tuve este proyecto por un tiempo.

empleado-X

@Simba Referencia obligatoria a Scotty .

empleado-X

Por muy bien (o mal) que vaya, agradece haber aprendido la lección al principio de tu carrera, en lugar de hacerlo más tarde. Esta no es una situación poco común y veo muchos buenos consejos aquí: si vuelve a suceder, estará preparado para manejarlo con tacto y profesionalidad desde el comienzo de la relación.

usuario44108

Ahora conoce esta pieza de software mejor que nadie.

Entonces, cuando se trata de la demostración, concéntrese en las partes que funcionan bien (o al menos funcionan como deberían). Cualquier otra característica que actualmente no funcione tan bien se puede etiquetar como "en progreso" o "prototipo". Utilícelos para analizar cómo se pueden mejorar estas funciones (o, mejor aún, permítales decirle que no son importantes).

Además, sería una buena idea anotar los pasos para la demostración y ejecutar la versión del programa que se demostrará de antemano para que pueda anotar cualquier cosa que pueda salir mal. A continuación, puede decir "esto debería..." y, antes de hacerlo en la demostración, diga lo que puede salir mal y que está en su cola de "cosas por hacer" para solucionarlo. De esa manera no te quedas pensando "umm... umm... eso no estaba destinado a suceder".

Obviamente, eche un vistazo a lo que está demostrando y sepa qué funciona y qué no. También mire cualquier documentación / hable con la gente y comprenda qué debería funcionar y cómo. Demostrar conocimiento y mostrar confianza en el sistema generará confianza en usted y en lo que dice. Esto te ayudará a que las cosas vuelvan a la normalidad.

Es entre usted y su gerente cómo presenta su papel en esto, es decir, si les dice que el desarrollador original ha dejado el proyecto y que ha tenido que tomar las riendas. La gente tiende a respetar la honestidad más que la deshonestidad, y los intentos de encubrir a un desarrollador anterior invariablemente serán vistos como un encubrimiento (y a la gente no le gusta eso).

Ser sincero puede generar beneficios al permitir que el proyecto se vuelva a enfocar (el desarrollador anterior puede haber llevado el proyecto por una ruta no deseada de todos modos).

Prodnegel

Creo que su respuesta me ayuda mejor en esta situación, pero dudo un poco en usar la línea "el antiguo desarrollador lo dejó..." debido a que tal vez parezca que estoy tratando de culpar a alguien más.

usuario44108

@Prodnegel - ¿Por qué? Es perfectamente natural que el personal siga adelante. También puede denominar esto como "retirado del proyecto" o "ahora estoy asignado a este proyecto". No hay necesidad de que se base en la culpa, son solo hechos simples.

Nate diamante

Se trata menos de pasar la culpa y más de pasar la responsabilidad. Creo que es mejor decir "Me encargaron agregar x funciones nuevas, que les mostraré aquí". Por otro lado, parece "Me dieron esto, encontré estos y decidí no arreglarlos porque no eran mi problema". El problema es que para el cliente, si él es el desarrollador del proyecto, entonces es su problema hasta cierto punto (realmente el problema del gerente, pero él es el representante en este caso).

andres morton

Además, sería una buena idea anotar los pasos para la demostración y ejecutar la versión del programa que se demostrará de antemano para que pueda anotar cualquier cosa que pueda salir mal. A continuación, puede decir "esto debería..." y, antes de hacerlo en la demostración, diga lo que puede salir mal y que está en su cola de "cosas por hacer" para solucionarlo. De esa manera no te quedas pensando "umm... umm... eso no estaba destinado a suceder".

luan

@AndrewMorton Esto es demasiado bueno para dejarlo en un comentario. Cuando esté haciendo una demostración, prepare la demostración . No se limite a improvisar: planifíquelo, ensáyelo, corrija o evite cualquier error que descubra de esta manera, y realice la interpretación. Piense en lo que es probable que el cliente pregunte o quiera ver, y descubra una buena respuesta. Revise todo con su gerente, para que ambos tengan claro exactamente lo que está entregando y de qué debe tener cuidado. Elimine las cosas que no funcionan lo suficientemente bien: una función faltante ("WIP") a menudo es mejor que una función horriblemente rota.

Lilienthal

@Pete Admitir que está bien en un proyecto interno, pero absolutamente no se hace en las presentaciones de los clientes. Pero, de nuevo, en la mayoría de los casos, el desarrollador no debería ejecutar esas presentaciones de todos modos.

parche y eso

@Prodnegel es que los problemas van a ser realmente obvios e inevitables, en lugar de decir "el antiguo desarrollador lo dejó así", tenga una lista de "problemas conocidos", de los que esté al tanto, y que necesite solucionar, y que se le haya dado una prioridad menor para usted por parte de su gerente que agregar nuevas funciones.

andres morton

@Luaan Siéntase libre de usar mi comentario como material para editar esta respuesta si Pete no lo hace de manera oportuna.

joe mc mahon

Cabe señalar que la demostración de algo con errores está lejos de ser poco común. El iPhone demostrado por Steve Jobs solo pudo hacer el conjunto de demostraciones que hizo durante la presentación; desviarse del "camino de oro" haría que se bloqueara, AT&T trajo una torre celular portátil para asegurarse de que tuvieran servicio, y había varias unidades en el escenario para permitirle cambiar si una moría - nytimes.com/2013/10/ 06/revista/…

Kilisi

En este tipo de situación necesitas cubrirte la espalda. Siempre tenga por escrito cuáles son los problemas y, especialmente, la respuesta de los gerentes para ignorarlos y agregar funciones. Es tan simple como enviar un correo electrónico.

'Hola jefe, después de nuestra conversación, ¿puede aclarar qué debo priorizar, por favor? Hay un montón de errores en X, o debería ir con las cosas nuevas. También tuve que hacer algo de kung fu digital para evitar un error en W, ¿está bien?'

Si tienes las espaldas cubiertas, no importa tanto, el gerente está en eso, no tú, solo estás haciendo tu trabajo.

Prodnegel

Mi jefe siempre vendría a verme en persona, aquí es donde surgieron la mayoría de esas conversaciones. Escribí sus respuestas, por lo que no tengo mucho rastro en papel de él diciéndome: "Olvídate de ese error, haz esto en su lugar". Me preocupa que al final vengan a mí y me pregunten por qué hay tantos errores, y no creo que decir "el gerente me lo dijo" funcione.

Kilisi

¿Por que no? Los trabajadores no se van solos (con suerte). Es responsabilidad de los gerentes administrar proyectos básicamente en términos de su equipo. Sería más probable que despidiera a los gerentes yo mismo si todo se derrumbara.

Kilisi

Pero incluso los correos electrónicos que detallan los problemas que NO se responden siguen siendo una prueba sólida.

Prodnegel

Sin embargo, no creo que tenga ningún correo electrónico que indique los errores, ya que son lo suficientemente pequeños como para no obstaculizar la MAYORÍA del programa. Siempre le decía a mi jefe que "no creo que este sea un código muy estable" y le señalaba las cosas pequeñas que no funcionan al 100 %.

Viejo_Farolero

@Prodnegel tener 'conversaciones rápidas' es la cantidad de personas sin escrúpulos que intentan hacer cosas por debajo del radar. De ahora en adelante en su carrera y cada vez que esto suceda, envíe un correo electrónico de seguimiento que comience con "Según nuestra conversación" y detalle lo que se le indicó. Esa es la única forma de cubrirte el trasero cuando alguien insiste en hablarte "fuera de línea"

Droide lacónico

Enviar un resumen de la conversación por correo electrónico no solo es una buena manera de CYA, sino que también es una verificación valiosa de que ambas partes tienen la misma comprensión de los problemas.

J...

Probablemente me abstendría de usar frases como "kung-fu digital" , particularmente con gerentes que no son técnicos. Si la solución implementada tuvo que ser deficiente para adaptarse a la restricción de tiempo, entonces debe tener claro qué compromisos se hicieron, de lo contrario, no tendrán idea de lo que están acordando, ni habrá una expectativa de que deben entender que "kung fu" significa que hay deficiencias latentes en el código base que pueden causar complicaciones futuras.

bradley thomas

Es una buena respuesta, pero "kung fu digital" suena mucho más glamoroso de lo que realmente es. Lo que realmente es, es tener que apilar basura sobre basura. Si una base es inestable, a veces tienes que tener todo tipo de trucos de ingeniería innecesarios en la parte superior para hacer que la cosa sea apenas estable.

Kilisi

Oh, diablos, pensé que 'kung-fu digital' era un término tecnológico legítimo, lo he estado usando durante una década :-)

prefecto de vado

Si utiliza un sistema de emisión de boletos, cree boletos de deuda tecnológica con estimaciones de puntos altos temprano para todo lo que vea como un problema y sepa que tomará tiempo solucionarlo. Jira y creo que Trello tienen registros de auditoría y, de esta manera, puede realizar un seguimiento de los errores y lo que debe hacer, además de tener un registro digital de sus reservas.

Emory

Voy a robar 'kungfu digital'.

jeremy francés

Este tipo de situación no es tan infrecuente como parece. Seguro que puede sentirse como una muerte inminente.

Es muy probable que estén tratando de salvar algo de su inversión en algo por la menor inversión adicional posible. Es por eso que solo le han asignado un desarrollador junior.

Hasta que el software resuelva un problema para alguien de tal manera que esté dispuesto a pagar por él, el software no vale nada. Si necesita funciones para llegar a esta etapa, entonces ese es el mejor lugar para invertir en el software. Dedicar tiempo a arreglar algo por lo que nadie pagará no es una buena asignación de recursos.

Imagínese si no hizo lo que se le pidió y dedicó tiempo a corregir errores, y luego, en la demostración, una característica crítica para el cliente no estaba presente. Eso podría resultar en una venta perdida y sería completamente su culpa. No conoce las razones de todas estas decisiones, así que apéguese a ellas.

Sé que, idealmente, las cosas deberían estar bien escritas desde el principio, pero usted no comenzó el proyecto, por lo que no puede ser responsable de todo el sistema.

Es poco probable (aunque no imposible) que esté configurado para fallar. Es más probable que la empresa esté tratando de hacer algo con lo que actualmente es una pérdida total.

Así que haz lo que puedas para ayudar a que la demostración funcione bien. Habéis tenido claro desde el principio el estado del código y habéis tomado prioridades de la dirección. Si la demo no sale bien no es porque no estabas haciendo bien tu trabajo.

Si su empresa tiene una cultura razonable, entonces esto debería estar bien.

Si la empresa tiene una cultura de culpa y lo culpan por la demostración o el estado del código, a pesar de todos sus consejos a la gerencia, entonces puede estar más a la defensiva la próxima vez. Obtenga todo por escrito, sea más terco en corregir errores. Si lo llaman por esto, señale que ha recibido críticas en el pasado por no hacerlo. Trabajar en una cultura así no es agradable y debes cuidarte las espaldas (si conseguir otro trabajo es una opción, entonces busca uno)

Pero sugeriría darle una oportunidad a su empresa. Haga lo que le han pedido lo mejor que pueda y acepte que la empresa es un trabajo conjunto.

Prodnegel

"Hasta que el software resuelva un problema para alguien de tal manera que esté dispuesto a pagar por él, el software no vale nada". Gracias, necesitaba escuchar eso y tiene mucho sentido.

Rocoso

Esta es una respuesta muy razonable, +1. Haz el mejor trabajo que puedas, siempre. Haz que tu empresa vuelva a ser grande.

gazzz0x2z

Reescribir desde cero suele ser una mala idea. joelonsoftware.com/articles/fog0000000348.html . Dicho esto, cada vez que un error existente le impide escribir una nueva característica, es hora de hacer una limpieza local. Solo local, para mantenerse enfocado.

jared smith

@ gazzz0x2z ese artículo al que hace referencia tiene 15 años y trata casi exclusivamente con el software de envoltura retráctil. No digo que estés equivocado, pero ten cuidado con las generalizaciones.

luan

@JaredSmith Es antiguo, pero todos esos argumentos siguen siendo perfectamente válidos. Tampoco son exclusivos de la envoltura retráctil: la reescritura es un costo enorme y elimina todas sus ventajas. Si necesita comenzar su software de consultoría desde cero, ¿dónde obtiene la ventaja sobre su competencia?

gazzz0x2z

@JaredSmith: Dije "por lo general", porque siempre puede haber contraejemplos. en el software interno, he visto muchas reescrituras que terminan mal (mal como en 100 millones de euros de esfuerzo en la papelera). No digo "nunca reescribir", digo "reescribir con precaución, en pasos muy pequeños".

jared smith

@Luaan, estamos hablando de software, en el contexto de la pregunta de los OP, que aparentemente nadie está usando para nada . No hay un documento de diseño, ni especificaciones, ni un conjunto de pruebas que indiquen la funcionalidad deseada. Tiene errores en formas que son obvias para un desarrollador junior. Tratar de salvarlo bien puede ser una pura falacia del costo irrecuperable. Spolsky estaba hablando de reescribir el software funcional que usa mucha gente. Tienes toda la razón sobre los argumentos que usa en ese caso.

luan

@JaredSmith Claro, eso hace que las cosas se equilibren de manera un poco diferente. Pero aún no tiene idea de cuántos casos extremos y problemas sutiles ya ha solucionado el autor original, posiblemente mientras se comunicaba con el cliente. El hecho de que no haya especificaciones es una carga tanto para tratar de reescribirlo como para mantenerlo vivo. Es muy posible que una reescritura completa sea más barata que tratar de arreglar esto; también puede ser que, dada la elección, el gerente simplemente detenga el proyecto. Pero en última instancia, esa es una decisión de la gerencia, y es una buena apuesta que Prodnegel tenga poca idea sobre el panorama general.

jared smith

@Luaan muy cierto. Si realmente se trata de un archivo adjunto de costo irrecuperable, entonces su suposición es casi segura de que deshacerse del proyecto es lo mejor para el negocio.

smci

Este tipo de base de código existe sorprendentemente a menudo, y muchos de nosotros hemos trabajado en algo similar. (Se ha comentado que un código base es un reflejo de la estructura de la organización que lo produce, o de hecho, una crónica conmovedora de la organización). Aquí hay un enfoque pragmático que he aprendido:

  • La administración no conoce el código base (que en realidad es una fortaleza y una debilidad), no se preocupa en absoluto por los errores y solo se les incentiva para agregar nuevas funciones. Por lo tanto, es infinitamente más fácil venderles que está trabajando en lo último (generación de ingresos), no en lo primero (disminución de costos); es más fácil para ellos vender esto tanto internamente como al cliente.
  • Entonces, cuando comience el proyecto, haga una evaluación súper rápida de cuáles son los peores errores y agregue casos de prueba o arneses que fallan, o como mínimo documente los escenarios en un sistema de seguimiento de errores ( "Cuando hago X en Y, falla con resultado/error Z" ). Vuelva a revisar esto de forma intermitente, según lo permita el tiempo, o según cambie lo suficiente la existencia aparente o la gravedad de los errores con respecto a las funciones en desarrollo. Es una disciplina muy difícil evaluar rápidamente las cosas que deberían arreglarse pero el tiempo no lo permite. Pero escriba los informes de errores y analice las correcciones con la actitud de que un día y un presupuesto desconocidos pueden llegar mágicamente.
  • Luego, a medida que agrega funciones, cualquier refactorización relacionada y corrección de errores se convierte en una dependencia de la función, se incluye en el trabajo, las estimaciones de tiempo y los escenarios de prueba. Cómo define e informa ese trabajo, es su decisión. Solo tú sabes cómo superarlos. Mientras el resumen ejecutivo diga "Implementación de la característica X", no les importará.
  • Acérquese a las demostraciones teniendo ensayos internos semanas antes, como una oportunidad para mostrarles "Implementamos el código para X pero tiene errores A, B, C que deben corregirse". En realidad, programe una demostración interna para su administración, independientemente de si el cliente la solicita. Gradualmente acostúmbrelos a tener en cuenta el x% del tiempo para la corrección de errores y las pruebas en sus estimaciones, o por el contrario, haga las primeras semanas de demostración antes de que espere que el código funcione.
  • "Trabaja en su mundo, no en el tuyo"

CodificaciónFeles

Buena respuesta y me encanta el último punto. En los comentarios, OP dijo que son solo "pequeños engranajes". Pero eso solo es cierto si no está tratando de influir más en el proyecto, además de la codificación. Trabaje con su gerencia, bríndeles ideas y nuevas soluciones sobre cómo abordar los desafíos desde su punto de vista. Ellos toman decisiones, pero tú tienes influencia para ofrecer soluciones. Primero, pregúnteles, como sugiere esta respuesta, para los ensayos. Intente negociar tiempo para ello, al menos una semana antes de la demostración del cliente. Luego intente que sea una práctica común para todas las demostraciones, luego puede seguir el consejo de @TheWanderingDevManager...

CodificaciónFeles

e intente hacer demostraciones con el cliente más frecuentes. Y así. Escuchará muchas razones para no implementar su solución, eso está bien. Una buena gestión tiene más información sobre los recursos disponibles y, a veces, simplemente no es posible utilizar grandes soluciones en el flujo de trabajo del proyecto. ¡Pero no te detengas! Algunas soluciones serán apropiadas y se implementarán. Y así es como influyen los profesionales en el proyecto y la empresa, sin cargo de gerente. Y así es como puedes dejar de ser un pequeño engranaje y convertirte en un profesional serio.

smci

@CodingFeles Sí, depende de qué tan alto en la cadena de administración llegue la incompetencia. En última instancia, depende del OP decidir cuán limitante es todo esto, cuánto cambio cultural pueden lograr y cuánto tiempo quieren intentar antes de irse por algo mejor. Probablemente, no una gran cantidad.

Jorgen Fogh

¡Esta es una respuesta brillante! En lugar de solo esperar que no se culpe al OP, en realidad describe cómo asegurarse de que no suceda.

smci

@JørgenFogh: ¡Diablos, no! Las malas cadenas de gestión siempre te echarán la culpa. Solo ofrecí algunos consejos sobre cómo prevenirlo o minimizarlo. No hay nada que impida que carguen aún más solicitudes de funciones, salten demostraciones, se nieguen a reconocer errores graves, etc. Solo estaba sugiriendo cómo explotar su falta de idea para tratar de crear pequeñas ventanas de tiempo para arreglar lo que realmente necesita ser arreglado.

Jorgen Fogh

@smci: Estoy totalmente de acuerdo en que esto no es una panacea. Es mucho mejor que no hacer nada y esperar lo mejor.

HLGEM

Y esos errores pueden convertirse repentinamente en una prioridad cuando la demostración de práctica para la administración interna se encuentra con uno o más de ellos.

HLGEM

Puede tomar menos tiempo corregir un error en lugar de crear una gran solución al agregar una nueva función. Considere esta parte de agregar la nueva función y es un beneficio que el error también se solucione.

gidds

Esto coincide con mi experiencia: es mejor corregir errores, refactorizar el mal diseño y realizar mejoras sobre la marcha . De esa manera, ya comprende esa área del código tan bien como lo hará, no necesitará muchas pruebas adicionales, evitará los riesgos asociados con los cambios importantes y no necesitará justificar lo que podría verse como trabajo improductivo. Sepa dónde quiere terminar y esté constantemente dando pequeños pasos en esa dirección.

El administrador de desarrollo errante

Se le asignó un lío de un proyecto sin comentar, sin documentar, sin capacitación ni mentores. Soy la única persona que trabaja en este proyecto, nadie más sabe o ha visto el código.

Paso 1: primero escribe pruebas unitarias para cualquier cosa que toques, tanto para verificar que ya hace lo que debería (o mostrar que no) como para demostrar que no lo has empeorado. Usted tiene esto en cuenta en cualquier estimación. Esto también forma documentación para el código, ya que las personas pueden entenderlo a partir de las pruebas.

Ahora han pasado meses y pronto es hora de mostrar el programa.

Paso 2: asegúrese de tener demostraciones/vistas previas periódicas con el cliente, tanto para establecer expectativas como para asegurarse de que está haciendo lo correcto/prioridades.

Dado que la refactorización es y nunca fue una opción debido a las limitaciones de tiempo y los deseos del gerente

Paso 3: cuando tengas una discusión como esta, documéntala en un correo electrónico para confirmar. De esa manera, te aseguras de que el palo sucio apunte en la dirección correcta cuando comiencen a culpar.

ya que tuve que hacer algunas cosas raras para evitar los errores

Nunca oculte los errores, plantéelos, agréguelos a un rastreador de errores y obtenga una decisión sobre cómo solucionarlo (ver arriba)

¿Cómo puedo evitar ser castigado por un proyecto que heredé que ya tenía errores, mientras que me dijeron que trabajara en más funciones en lugar de corregir errores?

Haga su diligencia debida cuando retome el proyecto, no cuando todos estén a punto de descubrir que se ha ido al sur.

david schwartz

" Nunca oculte los errores, plantéelos, agréguelos a un rastreador de errores y obtenga una decisión sobre cómo solucionarlos (ver arriba). " Esto es oro. Si informó un error y no se le indicó que lo corrigiera (o no se le indicó que lo corrigiera), aún habrá un error. (Si se resiste a usar un rastreador de errores, señale que no hay otra manera de realizar un seguimiento de los errores. No querrá olvidarlos). Debe haber muchos correos electrónicos de ida y vuelta sobre cómo priorizar las correcciones de errores. sobre características.

Prodnegel

Creo que algunos de los consejos realmente no se aplican tanto a un desarrollador nuevo como a mí en mi situación. #1) Cuando le pregunté a mi gerente acerca de las pruebas/corrección de errores, me dijo que no lo hiciera, pero su primera respuesta es escribir pruebas unitarias. Estoy de acuerdo en que esto es lo que se debe hacer, pero no creo que sea permisible ir en contra de los deseos de mi gerente. #2) No puedo asegurar que el cliente obtenga demostraciones periódicas, soy un pequeño engranaje en el sistema, sin poder en esta situación. No creo que a ningún desarrollador nuevo fuera de la escuela se le permita planificar demostraciones.

Prodnegel

#5) ¡Ya se había ido al sur desde el principio! Le dije a mi gerente que quería comenzar con la refactorización/corrección de errores, pero me dijo que no lo hiciera. No estoy seguro de qué más podría haber hecho en mi situación.

smci

En su mayoría, este es un buen consejo, sin embargo, "Cualquier cosa que toque, primero escriba pruebas unitarias para" : insistir en TDD completo generalmente no va a funcionar con / obtener soporte de mal mgmt. Debe evaluar los peores casos y tratar con ellos, como prioridad; consulte mi respuesta para obtener más información. Es frustrante.

alefcero

@Prodnegel "Le dije a mi gerente que quería comenzar con la refactorización/corrección de errores, pero me dijo que no lo hiciera", y si acaba de salir de la universidad y su gerente es razonablemente competente, esa fue exactamente la instrucción correcta. De lo contrario, después de 5 años de trabajo, tendría una base de código bellamente estructurada que aún no cumple con ninguno de los nuevos requisitos del usuario, y cuando comenzó a implementarlos, ¡probablemente tendría que refactorizar todo de nuevo! ¡El desarrollo de software del mundo real no es como hacer proyectos universitarios!

alefcero

@Prodnegel "No creo que a ningún desarrollador nuevo fuera de la escuela se le permita planificar demostraciones": la característica común de todas las buenas demostraciones de software es "solo demuestras las cosas que funcionan". Todos en el mundo real saben que el software tiene errores, pero no quieren perder el tiempo mostrando errores que ni siquiera les importan.

El administrador de desarrollo errante

@smci - ¿Quién dijo tdd? escribe las pruebas que necesita para demostrar que aún funciona después de cambiarlo.

smci

@TheWanderingDevManager a menudo no está permitido por programación escribir pruebas unitarias completas, ya sea antes, durante o después de la codificación. (De hecho, a menudo las pruebas unitarias completas son excesivas según la habilidad del desarrollador y si las características se ejercen mediante pruebas de integración o pruebas semimanuales. Depende de muchas cosas).

luan

@Prodnegel Diría lo mismo que su gerente. ¿Llegas a un nuevo proyecto, no tienes idea de lo horrible que es y quieres comenzar a reescribirlo ? ¿Jugar con cosas que funcionan, sin entender cómo y por qué funcionan? Es mucho más probable que sus cambios disminuyan la calidad del producto, convirtiéndose en una serie de "Oh, no esperaba que esta parte del código dependiera de esto..." Trabajo desperdiciado, sin valor para el cliente, y usted Parezco un sabelotodo incompetente con un título. Reportar errores. Pero arreglarlos es una decisión del gerente, no de usted.

El administrador de desarrollo errante

@smci: "a menudo, escribir pruebas de unidades completas, ya sea antes, durante o después de la codificación, no está permitido según el cronograma", pero pasar 5 veces más tiempo haciendo reelaboración/corrección de errores es la historia habitual. Dirigí equipos en un código base compartido con quizás 150-200 desarrolladores trabajando en él al mismo tiempo, siempre hay tiempo para las pruebas, lo incorporas en cualquier estimación. El tiempo propio que obtienes (no para combatir incendios) vale más que la pena, no contrataría a ningún desarrollador que se comprometiera con esto.

smci

@TheWanderingDevManager: estas cosas son un juicio. 150 desarrolladores es una historia completamente diferente a un equipo de 1-2 desarrolladores.

El administrador de desarrollo errante

@smci: no, no lo es (también lo hice en una empresa en la que era el empleado número 5). Si le doy un poco de código que digo que hace X, y quiero que solo agregue la función Y, ¿cómo verifica a) que realmente hace lo que digo y b) no lo ha roto al agregar Y? Necesita pruebas para hacer esto (todavía no hablo de TDD). Estarás escribiendo pruebas como parte de la codificación de todos modos (como dijo Justin Trudeau sobre algo desconectado "porque es 2016"), por lo que factorizar un par de horas adicionales para verificar tu comprensión escribiendo algunas pruebas es cómo funciona. Si no haces esto, te puedo recomendar algunos buenos libros.

JMK

Cada desarrollador piensa que cada proyecto que hereda es un desastre, es una reacción natural, y entiendo el instinto de querer refactorizar todo para que sea como crees que debería ser.

Sin embargo, si el código ya funciona y cumple su propósito, y la empresa necesita que se agreguen nuevas funciones, entonces debe concentrarse en agregar las nuevas funciones.

No significa que no puedas refactorizar sobre la marcha.

A medida que agregue las nuevas funciones, probablemente trabajará con el código ya existente y, cuando lo haga, arréglelo y agregue pruebas, y asegúrese de que el nuevo código también esté cubierto por las pruebas.

El desarrollo brownfield (es decir, trabajar y mejorar las bases de código de mala calidad existentes) es una habilidad en sí misma, y ​​no puede simplemente reescribir cada base de código en esta categoría que encuentre.

Eres mucho más valioso como desarrollador si, en lugar de simplemente encontrar un nuevo trabajo , realmente haces el esfuerzo de trabajar y mejorar la base de código que tienes.

Gusdor

"funcionando y sirviendo a su propósito" : parece que este proyecto problemático no está haciendo eso.

Marcos Miller

A riesgo de ser frívolo, el mundo tiene hambre de programadores. Algunas organizaciones están rotas, si tal vez ese es el caso, entonces busque un nuevo trabajo .

Otros carteles han señalado con razón que el desorden heredado es común, incluso inevitable cuando se trata de proyectos grandes y de larga duración. Depende de la empresa aportar el esfuerzo para arreglarlo o mejorarlo, no de usted (a menos que tenga una participación accionaria). Si es hora de reescribir, entonces ellos deben decidir (usted solo puede sugerir).

Cuídate en esta situación.

Llevo más de 30 años programando y después de un tiempo te das cuenta de lo importante que es la infraestructura circundante para que hagas bien tu trabajo. Y tienes derecho a intentar hacerlo bien.

Si no es bueno, siga adelante, comience a buscar mientras está en el trabajo actual, si es posible. Solo tenga cuidado con la forma en que le dice eso a los posibles nuevos empleadores, quejarse de lo mal que estuvo en su último trabajo le hace ganar muy pocos puntos.

mcottle

Me temo que es demasiado tarde para hacer mucho sobre el problema inminente. No puede culpar a su predecesor ahora, ya que hace mucho que se fue; podría haberlo hecho (con un rastro de correo electrónico) durante el primer mes más o menos, pero no ahora.

Si esto sucede en el futuro, lo que debe hacer es:

  • Evalúa rápidamente lo que has heredado.
  • Informe a su gerente por correo electrónico y recomiende la acción correctiva adecuada en lugar de la corrección de errores durante algunas semanas antes de continuar.
  • Archivar (Imprimir y guardar en un archivo en el trabajo Y en casa) cualquier negativa/insistencia en las nuevas funciones para cubrirse más adelante.
  • Rechace suavemente cualquier solicitud de nuevas funciones diciendo que tiene miedo de que pueda desestabilizar una base de código frágil. Archiva la decisión final de tu gerente como se indicó anteriormente.
  • Escriba pruebas unitarias para todo lo que agregue.
  • Rellene cada estimación que dé para una nueva característica más allá de agregar pruebas unitarias (¿Cómo puede alguien contradecir su estimación, no conocen el código?).
    Luego, usando su tiempo "extra":
  • Agregue más pruebas unitarias para las áreas con más errores (como sugirieron otras personas).
  • Arreglar las pruebas de ruptura.
  • Refactorizar el código antiguo.

Su situación mejorará con cada función nueva.

Pablo Becotte

Está en una situación en la que tiene 0 experiencia profesional y se le ha pedido que trabaje en un lío de errores de una base de código y le han dicho que no puede corregir los errores o refactorizar.

Sin embargo- 1. No tienes idea si el código base es bueno/malo/típico. No tienes ninguna técnica anterior con la que compararlo. 2. Nadie está revisando el trabajo que haces, lo que significa que sería imposible para ti saber si estás mejorando el código base incluso si estuvieras refactorizando... nuevamente, no tienes experiencia. 3. Nadie más mira el código base, por lo que en realidad podría corregir tantos errores y refactorizar como quisiera, ya que su gerente no podría notar la diferencia.

Entiendo que todos tienen situaciones diferentes, pero encontrar un entorno con un par de personas que sepan lo que están haciendo y un proceso de revisión de código saludable valdrá más para su carrera que lo que ganará en 10 años en esta empresa. Por lo tanto, no me preocuparía por la próxima demostración (que irá mal por causas ajenas a usted, más bien, su gerente tiene toda la culpa aquí) ... En cambio, me concentraría en lograr una mejor situación, ya sea que eso signifique encontrar otro trabajo o encontrar una manera de obtener apoyo de desarrolladores más experimentados en el actual.

(Alguien con cierta experiencia sólida podría adaptarse a estas situaciones, como describen las otras respuestas. Sin embargo, al salir de la universidad, su primera prioridad debe ser aprender a hacer su trabajo, que no está haciendo en este momento).

Richter65

Se ha dicho mucho con lo que estoy de acuerdo, pero creo que hay una cosa más que debería mencionarse: esta es una gran oportunidad para usted.

Piénsalo. Usted, un programador junior recién egresado de la universidad y sin ninguna experiencia, es la única persona asignada para trabajar en una aplicación de software. Eso me dice que el software está muy bajo en la escala de prioridad de gestión. Lo han cancelado efectivamente; en sus mentes, el software ya ha fallado (y por lo que ha dicho, no es difícil ver por qué han llegado a esa conclusión).

Eso significa que no puedes fallar; solo puedes tener éxito.

Mi consejo es que confíe en su administración, agregue las características y haga una demostración de ellas de la forma en que Pete las expuso en su respuesta. Si su administración es inteligente, están tratando de venderle al cliente las capacidades que brinda la aplicación, que no es lo mismo que vender la aplicación en sí. Supongo que si el cliente muerde, negociará un precio que incluye arreglar (o incluso reescribir) las partes del código con errores. Si eso sucede, usted estará al frente y en el centro de esa parte del esfuerzo. Si no es así, su gerencia no ha perdido nada excepto unos pocos meses de trabajo de un programador extremadamente joven (es decir, económico).

Hay un par de implicaciones en esta forma de pensar. La principal es que, además de lo que ya estás haciendo, deberías empezar a pensar en cuánto tiempo y esfuerzo te llevaría arreglar el código. Comience a pensar en un plan y un cronograma, para que pueda brindar algunas opciones a su gestión. Si no tienen un comprador, no estarán interesados. Pero si hay compradores potenciales, ese tipo de información será crucial para ellos cuando comiencen a negociar el precio.

komodosp

Con suerte, no solo le has dicho, sino que le has hecho saber por escrito sobre el desastre. De esta manera, conoce la situación desde el principio y no puede hacerte responsable.

¡Ha sido mi experiencia que en este tipo de situación, el gerente a menudo está tan feliz como el desarrollador de culpar al tipo que dejó la empresa!

Probablemente le resulte útil hacer un seguimiento de todos los errores que descubra y guardarlos en un lugar donde su gerente pueda verlos fácilmente (no de una manera pasivo-agresiva, eso sí, simplemente dígale lo que está haciendo). Incluso si está en una hoja de cálculo compartida de "problemas conocidos" en algún lugar si su empresa no tiene un software de seguimiento de errores. Tal vez anime a los usuarios a hacer lo mismo (en el mismo documento) si la política y la logística lo permiten. Incluso podría hacer que su gerente evalúe la gravedad y asigne una prioridad a cada uno (con respecto a las nuevas funciones que se le ha pedido que agregue)

Supongo que no tiene un departamento de control de calidad completamente funcional o no habría llegado tan lejos, pero si lo tiene, su aporte aquí sería realmente beneficioso.

Esto no solo muestra que estás tratando de limpiar el desorden de manera proactiva, sino que también te proteges si surge un problema en el que él podría culparte.

comojudo

Haz que tu jefe te respalde. Asegúrese de que su jefe esté convencido de que existen problemas graves para que pueda obtener el tiempo y el acuerdo de la alta dirección. Luego, contrate al mejor arquitecto de la empresa para que lo ayude a rediseñar, refactorizar o reescribir el proyecto. Trabaje con su gerente y el arquitecto para crear un programa demostrablemente mejor. Esto me pasó los últimos 6 meses.