TL; DR: Preguntas debajo del texto
Soy desarrollador de software en el centro de I+D. Debido a mi antigüedad, a menudo me piden que revise los cambios críticos de tiempo/alcance en nuestro código base. Debido al estado agitado del proyecto, no es raro que me pidan que revise el código de otros el día o incluso horas antes de una entrega importante.
A menudo reviso las solicitudes de extracción de un contratista, Joe. A Joe se le paga por cada característica que completa en lugar de una tarifa por hora. Tengo la impresión de que Joe trata de realizar tantas funciones como sea posible, a menudo escatimando en documentación/calidad del código en el proceso. En el pasado, he tenido que hacer horas extras para solucionar los problemas con el código de Joe, porque una vez que se aprueba y se paga, él no se siente y nadie lo hace responsable de la corrección de errores. Nuestro equipo ha señalado que la situación no es ideal, pero la decisión gerencial actual es que esto no cambiará.
Con frecuencia solicitaría cambios en el código de Joe porque no cumple con nuestras pautas. Joe solía acercarse a mí con una historia sobre cómo no le pagarían si su código no se aceptaba a tiempo. Durante un tiempo, aceptaba problemas menores con la condición de que Joe los arreglara más tarde, pero eso nunca sucedió. Eventualmente, dejé de aceptar envíos incompletos y le pedí a Joe que escalara el problema si no está satisfecho con mi veredicto.
En general, el código de Joe tendría los siguientes problemas, en orden ascendente de gravedad:
Dado que las características de Joe a menudo se prometían al cliente en esa semana en particular y no habría tiempo para que Joe las corrigiera, eventualmente otras personas comenzaron a acercarse a mí para aceptar el código de Joe, desde el propietario del producto, pasando por la gestión de proyectos, mi jefe, hasta el jefe de mi jefe.
En las discusiones, mi gestión de proyectos/mis superiores generalmente me piden que encuentre una manera de aceptar el código de Joe de todos modos. En general, dejaría pasar 1 y 2 en este punto, pero me negaría a aceptar algo más serio, citando mi responsabilidad por la calidad del código y la deuda técnica como ingeniero. Para decirlo sin rodeos, aceptar un código como este nos costaría más tiempo de lo que vale.
En algunas situaciones, mis superiores solicitaron aceptar el código de todos modos, incluso si los problemas eran graves, citando características prometidas al cliente y la próxima entrega. En este punto suelo responder diciendo:
No hago esto necesariamente como una táctica de CYA, sino que creo que las personas piensan dos veces sobre las decisiones que están tomando si las ponen por escrito. Hasta la fecha, nadie ha decidido hacer nada de lo anterior, incluso si he recibido algunas burlas como resultado.
Sin embargo, algunos compañeros de trabajo me han dicho en privado que no llegaría muy lejos con esta actitud, por lo que me pregunto:
Agregar una respuesta porque las otras respuestas bailan a su alrededor, pero en realidad nunca llaman específicamente en la frase más breve posible:
Necesitas una "definición de hecho"
Las definiciones generalmente aceptadas de hecho incluyen no sólo el código de trabajo , sino también las pruebas de unidades de trabajo y la documentación . Hasta que se completen esas cosas, la tarea no se realiza y el código no puede ni debe publicarse.
Si bien a menudo encontrará el concepto bajo el paraguas Agile/Scrum, ese marco de trabajo no es necesario para implementar esta idea.
Como yo lo veo, no es la política la que tiene la culpa, es la persona que trata de abusar de la política.
Como ingeniero, la calidad del código es mi responsabilidad. ¿Hasta qué punto debo luchar por ello?
Siempre que usted sea responsable de algo, debe seguirlo hasta que pueda demostrar que cualquier desviación no es causada por "usted" . Dado el contexto que mencionaste, parece que estás luchando por la causa correcta. No se trata solo de las "directrices de codificación", el objetivo es tener un código que realmente se ejecute y produzca el resultado esperado.
¿Es apropiado que pida a mis superiores que pongan sus decisiones por escrito?
En este caso, mucho que sí. Ha dado una crítica negativa, y si alguien le pide que renuncie a los bloqueadores y permita que ese código encuentre su lugar en el código de producción, asegúrese de que se pueda rastrear hasta la "pregunta", en un momento posterior.
Si la calidad del código se ve afectada debido a problemas organizativos (la forma en que se compensa a un contratista), ¿es apropiado que yo sea "un juez" o plantee el problema a mis superiores o al departamento de recursos humanos?
No diría que es el RR.HH. quien lo puede manejar, esto debe ser informado a sus superiores y gerentes técnicos que puedan entender el impacto.
Ya ha probado algunas de las cosas adecuadas para probar en este escenario, sin embargo, hay una cosa más que sugeriría:
No señale a la persona culpable, más bien señale la parte problemática del código y también intente documentar los problemas que puede prever si ese código llega a la versión final. Además, señale un par de instancias, en las que permitió algunos de los casos menores que permitió en el pasado, esperando que se solucionen en el futuro, pero nunca se hizo.
Parece que el proceso de gestión de proyectos es problemático. A veces, es mejor tener una función parcialmente completa en lugar de no estar disponible, pero hay un lado positivo. El punto aquí es que la perspectiva de seguimiento necesita mejorar. Solo entregar el código (o emitir una solicitud de extracción) no debe ser la medida para la entrega, es responsabilidad del propietario asegurarse de que el código se revise y fusione con el código de producción (final).
En resumen:
Finalmente:
Sin embargo, algunos compañeros de trabajo me han dicho en privado que no llegaría muy lejos con esta actitud,
Bueno, eso no es una muy buena señal. Permitir un código incorrecto no solo es malo para la calidad, también es una indicación de que aquellos que abogan por la concesión no respetan el tiempo y el esfuerzo dedicados al proceso de revisión y, a su vez, no respetan el trabajo realizado por uno o más empleados Si esto continúa, es mejor que encuentre una organización que valore los esfuerzos de sus empleados.
Intente que los criterios de aceptación sean objetivos.
Como ingeniero, la calidad del código es mi responsabilidad. ¿Hasta qué punto debo luchar por ello?
Sí, la calidad del código es su responsabilidad, pero eso no significa que deba asegurarse de que la calidad del código sea del más alto nivel. Su trabajo es asegurarse de que la calidad del código esté en un nivel adecuado. El código de alta calidad puede evitar errores y mejorar la capacidad de mantenimiento en el futuro, pero generalmente tiene un costo (dinero o tiempo), por lo que no siempre es lo que se necesita, especialmente cuando no está escribiendo software para marcapasos o aviones.
Escribes que trabajas en I+D y en ese campo es muy común escribir prototipos que se tirarán en el 90% de los casos.
Encontrar el compromiso correcto entre la calidad del código y la velocidad y el costo es difícil y, si no se hace de forma centralizada, puede variar fácilmente entre diferentes desarrolladores.
Si usted es el que siempre dice no a las nuevas características que necesita la empresa, se le percibirá principalmente como un alborotador. Tal vez dentro de 4 años, alguien se dará cuenta de que siempre has tenido razón al presionar por la calidad, pero podría ser que ya te hayan dejado ir para entonces.
La forma de evitarlo es tener criterios objetivos para la calidad del código que estén respaldados por las partes interesadas del negocio.
Sin documentación
¿Está documentado el resto del código o solo falta el código de Joe? ¿Cuál es el impacto de no tener documentación?
formato contra nuestras directrices
Este debería ser un caso claro, tiene pautas (supongo que están sancionadas por la empresa o el departamento) que se aplican a todos. A veces, sin embargo, las pautas están desactualizadas y nadie las sigue. Si otras personas mayores los siguen, debe estar seguro de insistir en ellos.
falta de pruebas
No existe una regla global de que el código deba tener tipos específicos de pruebas o tener pruebas en absoluto. El hecho de que generalmente sea una buena idea para ellos no significa que sea una práctica que aplique en su empresa.
Arquitectura incompatible con lo que intentábamos conseguir en el futuro Cuestiones de rendimiento.
Este me parece el más difícil, ya que es muy difícil juzgar si la arquitectura del código es buena o mala. Pero puede tener dos criterios objetivos: a.) ¿Se cumplen los requisitos no funcionales? (Solo si ha definido requisitos no funcionales de antemano) b.) ¿Encaja el código en la arquitectura general del sistema (Solo si ha documentado la arquitectura del sistema)
De plano no funciona
Esto es obvio, nadie debería criticarlo por un código que no funciona. A menos que se exceda y requiera un código perfecto, donde un buen código sería suficiente.
Tuve que hacer horas extras para solucionar los problemas con el código de Joe, porque una vez que se aprueba y se paga, él no se siente y nadie lo hace responsable de la corrección de errores.
Este es el problema. Podría presentar el mejor argumento del mundo sobre la calidad del código, pero si su pago se basa en las funciones, eso es precisamente lo que hará. Después de todo, ¿por qué perdería el tiempo arreglando un código ya aceptado cuando no le pagan por ello?
Recuerdo una época en la historia en la que LOC (Líneas de código) era la forma principal en que te ascendían o te pagaban. Estarías escribiendo todo el día por cosas simples. Es muy difícil agregar funciones o incluso seguirlas.
Joe solía acercarse a mí con una historia sobre cómo no le pagarían si su código no se aceptaba a tiempo.
Incluso te dijo que no lo arreglaría porque no le pagan por ello.
El primer argumento es averiguar cómo arreglar los términos de este contrato. En última instancia, depende de su negocio, pero sus 3 argumentos principales son:
Ya has respondido tu propia pregunta:
A Joe se le paga por cada característica que completa en lugar de una tarifa por hora. Tengo la impresión de que Joe trata de realizar tantas funciones como sea posible, a menudo escatimando en documentación/calidad del código en el proceso.
Cambie a Joe a un contrato por hora y vea qué sucede. Si es bueno, su calidad mejorará, a menos que juegue con el sistema alargando las cosas, así que imponga plazos razonables.
Si su calidad no mejora, reemplácelo.
Creo que haces tu trabajo con honor, aunque sea bastante estresante. Como ingeniero de calidad, no debe permitir que pase un trabajo de muy baja calidad.
Tal como lo veo ahora, hay algunas alternativas, ninguna de ellas perfecta.
Si considera que tanto los jefes como sus colegas tienen una mala mentalidad sobre la necesidad de calidad del trabajo, la opción 4 parece ser su mejor amiga.
Sí, estás siendo irrazonable. Siempre que no sea de vida o muerte, debe pasar el código porque a la gerencia solo le importa el dinero, y la deuda técnica no es algo que puedan entender. He escrito un código de mierda porque me han dado plazos que no me dan suficiente tiempo para hacer un buen trabajo y, como contratista, no me pagan por hacer horas extra. Si pudiera establecer la fecha límite, entonces sería diferente.
desarrollo suave
erupción solar
chris stratton
chris stratton
neil
dwizum
Thorbjorn Ravn Andersen