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.
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).
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.
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.
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:
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.
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.
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.
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:
Su situación mejorará con cada función nueva.
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).
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.
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.
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.
mosquito
Mónica Celio
Fresa
empleado-X
empleado-X