¿Por qué a algunos desarrolladores les encanta criticar el código de otros desarrolladores?

No está claro qué quiere decir exactamente con “criticar” (o “criticar” para nosotros en los Estados Unidos de América). Hay críticas constructivas versus no constructivas , y también hay críticas , que suenan similares pero son diferentes. Todos ellos pueden ser importantes y útiles, en las circunstancias adecuadas.

En primer lugar, afirmemos que no todo el código es igual de bueno : la calidad del código es importante y, hasta cierto punto, posible de definir y evaluar. Su código puede ser más rápido que el mío, o más fácil de mantener, o más susceptible de cambio, etc., y, en igualdad de condiciones , eso lo hace objetivamente mejor.

Admitamos también que no todos escriben código perfecto, y la mayoría de nosotros ni siquiera somos 100% consistentes en producir el código de mayor calidad que podamos. Podemos estar cansados, o con limitaciones de tiempo, o perezosos, o distraídos, u otras 1000 razones que pueden hacer que escribamos un código sub-par.

En última instancia, queremos entregar un buen producto a nuestros clientes (pagando o de otro modo); Por eso estamos en este negocio. Por lo tanto, es útil obtener ayuda de otros para mejorar nuestro código: pueden captar las cosas por debajo del par y ayudarnos a mejorar nuestra calidad de referencia.

Por lo tanto, criticar el código de otras personas, generalmente en las revisiones de código, es una gran parte de lo que hacen los buenos desarrolladores. La crítica es parte de este proceso: si estoy usando un nombre pobre para mi método, espero que alguien me lo diga para que pueda solucionarlo; Si existe la oportunidad de reutilizar el código de una manera creativa que me perdí, sería genial saberlo, así que la próxima vez puedo hacerlo yo mismo.

Dicho esto, la clave de tal crítica es que debe ser justificada, respetuosa e idealmente constructiva. Simplemente decir “su código apesta” no tiene sentido, y solo sirve para molestar al codificador y ponerlo a la defensiva (reduciendo las posibilidades de que incluso quieran solucionar el problema). Debe explicar cuál es el problema y por qué es un problema, y ​​ofrecer un camino para solucionarlo , y debe hacerlo bajo el supuesto de que la otra persona (a) no es estúpida, (b) no es perezosa y (c ) tratando de hacer lo correcto. Finalmente, esté abierto a la posibilidad de que esté equivocado y que tengan razón.

Digamos que alguien está usando el ordenamiento de burbujas para ordenar una lista. Eso parece bastante tonto, ¿verdad? ¿Por qué no usar quicksort o algún otro algoritmo de tiempo de registro?

Aquí hay una mala manera de reaccionar en una revisión de código:

“WTF, ¿estás usando la clasificación de burbujas? Eso es lo más tonto que he visto en mi vida.

Aquí hay una manera mucho mejor:

“Si esta lista se alarga, esta implementación de clasificación puede volverse muy costosa (es O (N ^ 2)). Debería considerar usar algo como quicksort (hay una implementación en la biblioteca FooBarCollections), o al menos documentar por qué no lo está haciendo “.

Tenga en cuenta que en algunos casos, ¡espero que sea raro! – De hecho, su crítica puede no ser muy constructiva, porque si bien puede detectar un problema, es posible que no sepa cómo resolverlo. Cuando eso sucede, debes ser aún más cauteloso y respetuoso; el codificador original puede ser consciente del problema y simplemente tampoco tener una solución. No deberías dejar que se deslice necesariamente. Puede sugerir discutir esto en una sesión de lluvia de ideas; o consultar con un experto en dominios; o simplemente agregando un comentario al código para que los futuros desarrolladores estén al tanto del problema y por qué es difícil de resolver.

Algunas personas son imbéciles.

He trabajado como programador profesional durante unos 17 años, no creo que haya criticado mi código, tal vez algunas sugerencias constructivas, pero nunca críticas.

Creo que nunca he criticado el código de un compañero, simplemente no es una forma efectiva de administrarlo.

Algunas personas critican el trabajo de otras personas porque les hace sentir mejor o superior.

Internet también es un factor importante, es mucho más fácil ser un imbécil frente a una pantalla que frente a una persona real.

Porque es como cualquier otra cosa, es casi un deporte. Eficientemente es clave

Si jugaste deportes y eres el jugador estrella que recibe tiros de 3 puntos como loco, eres el hombre ideal, ¿verdad?

Lo mismo con la codificación, más si hay una mejor función o algo que siempre puede sugerir por qué su idea es mejor.

Compruebe en código abierto, por qué existe, es para hacer del mundo un lugar mejor, dejando el código donde otros pueden contribuir, puede mejorar el proyecto.