Cómo lidiar con un programador de html/css que comenta todos los cambios que realiza en CSS en lugar de eliminarlos [cerrado]

Actualmente estoy asesorando a un compañero de trabajo que se niega a eliminar el código. Actualmente trabaja estrictamente como desarrollador de html/css, pero cuando edita CSS, no elimina el código. Comentará cualquier cosa que quiera cambiar y aplicará sus cambios.

Aquí hay un ejemplo de lo que quiero decir: cuando se le pide que elimine el relleno de un elemento y cambie el color a rojo:

.sampleRule {
   /* padding:20px */
   margin-left:20px;
   color: /*black*/ red;
}

Cuando le pregunté sobre este comportamiento, dice que lo hace con fines de documentación. Quiere saber cuáles eran las propiedades antes de que se hiciera el cambio. Tiene experiencia como diseñador, así que puedo entender su forma de pensar, pero nuestra base de código está repleta de código que se parece a esto.

Le sugerí que use el control de fuente si tiene curiosidad por ver los cambios anteriores (puede usar TFS, por ejemplo, para mostrar todos los cambios realizados en un archivo).

Actualmente estoy revisando el código de todo su trabajo, pero no estoy seguro de cómo abordar esta situación. ¿Debo hablar con mi jefe? ¿Debo eliminar este comportamiento cuando lo veo? ¿Debería dejarlo solo?

Gracias por la ayuda.

Sí, nuestra empresa utiliza control de código fuente. Verificamos todos los cambios para que pueda usar eso, pero se niega a hacerlo en este momento.
Preguntar qué tan problemático es este comportamiento y si es lo suficientemente grave como para hablar con su jefe o si simplemente debe ignorarlo no es una pregunta apropiada para este sitio. Este no es un sitio de programación, no estamos aquí para emitir juicios sobre la idoneidad de los hábitos de codificación. Si cree que este comportamiento es inaceptable (y/o está claramente prohibido de acuerdo con sus estándares de codificación) y se debe hacer algo, la respuesta es bastante simple: hable con su jefe.
"Le sugerí que use el control de fuente si tiene curiosidad por ver los cambios anteriores..." Tonterías. También uso el control de fuente, pero para cambios rápidos no estoy al 100%, comento las cosas y luego solo las elimino más adelante en el proceso. Por ejemplo, hoy es viernes… Tengo una solicitud de cambio. Hice el cambio, implementé el código y me dirigí a casa... Pero realmente no quiero abrir una nueva ventana del navegador solo para revisar los cambios cuando regrese al trabajo el lunes con la cabeza más clara y descansada. Tiene sentido mantener cosas "una al lado de la otra" como esta hasta que esté 100% sólido.
@Emotive.io, ahora ha identificado 2 problemas: deja el código comentado en su lugar y elige no usar una herramienta de control de versiones. La segunda justifica la primera. No puedo creer que a los desarrolladores no se les presente el control de versiones en la primera clase de cualquier curso de CS. Explique los beneficios del control de versiones, la bifurcación privada, etc. (y el registro de cambios con comentarios de registro útiles) y cómo eso mejora su rendimiento. ¿Por qué/cuándo hizo ese cambio? Ver motivo y fecha de entrada. Listo y allí para que todos lo vean, a menos que sea en una sucursal privada.
¿Cómo eliminaría esa color: /*black*/ red;declaración, ya que los comentarios CSS no son anidables?
Para poner su pie sobre esto, necesita tenerlo como un estándar, no solo su opinión, y recomendaría que sea su estándar. Una vez que tenga eso, entonces necesita entender que el concepto de tutoría es aprender, no ignorar.

Respuestas (4)

Por lo que estoy recopilando, está usando el control de fuente como todos los demás, pero en lugar de simplemente eliminar el código anterior una vez que termina, le gusta mantener todo el código anterior como comentarios.

Esto debe ser abordado en una política de empresa. Si la política de su empresa establece que se debe eliminar todo el código antiguo para que los archivos permanezcan lo más pequeños posible, esa es la política que debe seguir.

Sí, debe hablar con su jefe para ver cuál es la política de la empresa. No, no borraría nada de su trabajo.

Si no hay una política y este es solo su sentimiento personal, entonces parece que debería estar de acuerdo en estar en desacuerdo. El hecho de que sienta que esta es la forma correcta de codificar no significa que todos estén de acuerdo con usted.

Si no hay una política, eso no significa necesariamente que sea "solo un sentimiento personal". Si cree que afecta la calidad de sus entregas, hable con su jefe al respecto y vea si puede ayudarlo a establecer una política. Cuando lo haga, tenga cuidado de que la conversación no se trate de gustos personales o de usted contra un compañero de trabajo. Concéntrese en la calidad y la mantenibilidad de su producto. Asegúrese de que la nueva política incluya una solución para satisfacer la necesidad de documentación de su compañero de trabajo.
Debería marcar esto en la revisión por pares y no aceptarlo hasta que se solucione. Uno de los muchos propósitos de un sistema de revisión de código es construir y establecer estándares en todos los repositorios. Como segunda opinión, cuando existe un sistema de control de fuente, cualquier código comentado es un juego justo para su eliminación.
su equipo necesita un acuerdo de trabajo que también describa cosas como esta: todos cumplen con el acuerdo y no lo dejen en manos de un 'sentimiento'
Uh, ninguna política de la empresa podrá abordar todo y debería ser necesario usar el sentido común. Este "estilo de código" es extraño, nunca lo había visto antes, y cualquier programador competente debería estar universalmente de acuerdo en que no es útil. El control de fuente es para rastrear el historial, no para los comentarios.

En realidad, esta es una práctica bastante común y lo "correcto" o incorrecto de esto varía enormemente según los estándares de la tienda.

Si no hay estándares de la tienda que prohíban esto, entonces no hay nada de malo, si los hay, está violando el procedimiento.

Pregúntele a su jefe cuáles son los estándares de la tienda para esto y actúe en consecuencia.

Si cree que estos deberían ser los estándares de la tienda y no lo son, comuníqueselo a su jefe y presente su caso para tenerlo como un estándar establecido para eliminar el código en lugar de comentarlo.

Ya sea que existan o no "estándares de la tienda" e independientemente de si se trata de una "práctica bastante común", generalmente es una mala práctica. Simplemente comentar el valor anterior no le dice POR QUÉ cambió, lo que a menudo es más importante después del hecho que cuál era el valor anterior.
Tampoco ayuda entender qué partes de un archivo cambiaron en un momento dado. Solo sabes lo que había antes, pero nada más. Con el control de fuente, en cambio, sabe exactamente cómo mutó el código con el tiempo.

Prefacio: He estado en el campo durante más de 11 años y he estado liderando equipos de desarrollo front-end durante más de 3 años en grandes empresas como Nike.

No estoy de acuerdo con las respuestas anteriores en algunos de sus puntos. (Esto se basa en el hecho de que dijiste que lo estás asesorando y que también eres su líder, si no, y por jefe te refieres al desarrollador principal, entonces escucha las respuestas anteriores y ve a hablar con ellos, si por jefe tú quiere decir propietario, jefe de departamento o algún otro no desarrollador, luego continúe leyendo)

En primer lugar: NO acudiría a tu jefe. Debes ver ir a tu jefe como una opción nuclear para ser reservada como último recurso absoluto. Su jefe confiaba en su capacidad para guiar a este desarrollador y manejar cosas como esta. Cada vez que acude a su jefe para que maneje algo como esto, se va a erosionar un poco la confianza. Le aseguro que su jefe tiene cosas mucho mejores que hacer que dictar normas de código. Solo involucre a su jefe si necesita una aclaración sobre algo o las cosas deben escalarse hasta el punto de una reprimenda formal o despido.

En segundo lugar: esta no es una decisión de política de la empresa. El formato del código y los estándares del código quedan totalmente a discreción del desarrollador principal. A su jefe no le importan ni necesitan preocuparse los matices como el formato y los comentarios.

En tercer lugar: esto no es común. En más de 11 años, solo me he encontrado con una empresa que permitiría dejar comentarios en código para el historial. Los únicos lugares en los que esperaría ver este tipo de codificación es una tienda obsoleta que ignora las mejores prácticas y no tiene control de fuente, relaciones públicas o repositorios GIT, y si ese es el caso, EJECUTAR correr muy lejos y nunca mirar hacia atrás.

Si yo fuera usted, primero le daría un recorrido por GIT y le mostraría cómo funciona, ya que claramente no entiende el historial de confirmación. Esperemos que eso ayude a aliviar sus preocupaciones y le haga entender de dónde vienes cuando dices que no lo haga y ese será el final.

En segundo lugar, me negaría a aprobar cualquiera de sus relaciones públicas hasta que siga sus sugerencias, usted es el líder, así que lidere. Si el código no cumple con sus estándares, entonces no debe fusionarse, es así de simple.

Si todavía se niega a cambiarlo y deja que sus relaciones públicas permanezcan para siempre con usted bloqueándolo, entonces es hora de hablar con su jefe sobre el desarrollador. Tal vez haga que el jefe le diga que lo escuche, o que lo escriba o posiblemente incluso lo despida dependiendo de cómo reaccione y su desempeño general.

Usted es su mentor y si se niega a escuchar su mentoría, entonces no está haciendo su trabajo y le impide hacer una parte importante del suyo. Tenga en cuenta que si su jefe siente que este desarrollador no está aprendiendo nada ni escuchándolo y usted no le ha dicho nada a su jefe, eso se refleja negativamente en usted, no en el desarrollador que está asesorando.

Por último, si su empresa no usa GIT o PR (solicitudes de extracción), entonces ese es un problema mucho mayor que el hecho de que el desarrollador deje comentarios y debería presionar para que la empresa siga las mejores prácticas modernas que previenen problemas como este o comienzan a ejecutar lejos y buscando un trabajo que sea más beneficioso para su carrera.

En muchos lenguajes, esta es una práctica bastante buena, al menos temporalmente, ya que permite que los cambios se reviertan fácilmente y otros en la base de código pueden ver la progresión reciente y los cambios que ocurrieron. Sin embargo, es un poco extraño hacerlo en CSS, donde los cambios son bastante pequeños y fáciles de intercambiar y, por lo general, es fácil ver los cambios de inmediato.

A pesar de eso, no es muy raro, pero lo que sería raro es dejar los comentarios del código después de un tiempo. Simplemente le diría que está bien, pero después de que se hayan realizado los cambios y él decida que es bueno quedarse, regrese y elimine los comentarios. Realmente no hay ninguna razón por la que deban estar allí si se aceptan los cambios y se espera que permanezcan.

También podría ser una buena idea agregar una herramienta para minimizar los archivos y eliminar los comentarios antes de la implementación, de esta manera no importa en un sentido técnico si los archivos son más grandes o sus comentarios permanecen. No es un remedio para el origen del problema, sino una medida útil para prevenir sus efectos.

Definitivamente, todo el beneficio de marcar los cambios recientes se pierde por completo si el código está cubierto por estas banderas.
No puedo imaginar que esto sea algo bueno, considerando que cosas como git cubrirán el caso por completo y un 10000% más elegantemente. ¿Mantiene los comentarios después de un segundo/tercer cambio? Es suficiente para hacer que mis ojos sangren solo de pensar en tratar de mantener tal cosa. "Solo voy a Ctrl + F donde se aplica este estilo... 1000000 resultados comentados..."
Está bien comentar el código mientras trabaja en él, pero no cuando confirma los cambios. Todos los sistemas de control de cambios brindan mejores métodos para hacer todas las cosas que enumeró. Temporaryestá bien, pero se vuelve permanentcuando lo cometes.
Cómo lidiar con un programador de html/css que comenta todos los cambios que realiza en CSS en lugar de eliminarlos [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v