¿Cuál es el valor real de un estilo de código consistente?

Soy parte de un equipo de consultores que implementa una nueva solución para un cliente. Soy responsable de la mayoría de las revisiones de código en la base de código del lado del cliente (React y javascript).

Me he dado cuenta de que algunos miembros del equipo usan patrones de codificación únicos hasta el punto de que podría elegir un archivo al azar para saber quién fue el autor del estilo solo.

Ejemplo 1 (funciones en línea únicas)

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

El autor argumenta que al asignar un nombre significativo a someFunc, el código será más fácil de leer. Creo que al incluir la función y agregar un comentario, se podría lograr el mismo efecto.

Ejemplo 2 (funciones independientes)

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

Así es como lo hacemos habitualmente (evita tener que pasar estado y accesorios):

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

Si bien estos patrones de codificación son técnicamente correctos, no son consistentes con el resto de la base de código ni con el estilo y los patrones que Facebook (el autor de React) sugiere en los tutoriales y ejemplos.

Necesitamos mantener un ritmo rápido para entregar a tiempo y no quiero cargar al equipo innecesariamente. Al mismo tiempo, debemos estar en un nivel de calidad razonable.

Estoy tratando de imaginarme a mí mismo como el desarrollador de mantenimiento de los clientes frente a inconsistencias como estas (cada componente puede requerir que comprenda otra forma de hacer lo mismo).

Pregunta:

¿Cuál es el valor percibido por el cliente y sus desarrolladores de mantenimiento de una base de código coherente frente a permitir que persistan inconsistencias como estas y se propaguen potencialmente?

Ventaja de transferencia de código

Seguir los patrones proporcionados por una biblioteca, Reacten su caso, significa que el producto que entregue será fácilmente recogido y mantenido por otros desarrolladores que también estén familiarizados con React.

Posibles problemas de compatibilidad con versiones anteriores

Algunas bibliotecas tendrían una nueva versión principal, y la compatibilidad con versiones anteriores podría verse comprometida si sus patrones son significativamente diferentes, lo que ralentizaría / detendría su futura actualización. No estoy seguro de cómo Reactlidiar con los nuevos lanzamientos, pero he visto que esto suceda antes.

Los nuevos miembros en el equipo comienzan a ser productivos más rápido

Si sigue lo que proporciona el autor, es más probable que contrate desarrolladores talentosos utilizando su marco y comience más rápido con su sistema en lugar de enseñar nuevos patrones.

Posibles problemas no descubiertos

Puede haber problemas en el futuro que aún no ha descubierto con su enfoque, que se resuelven con el enfoque del autor.

Dicho esto, la innovación siempre es un riesgo, si sientes firmemente que tu enfoque es mejor y funciona para tu equipo, ¡adelante!

Las inconsistencias te hacen parar y pensar por qué , qué y dónde :

• Cuando lees parte del código y ves que usa un estilo diferente del resto del código, te preguntas: ¿por qué es diferente esta parte en particular? ¿Tiene alguna razón especial que deba tener en cuenta? Esto es peligroso, porque si realmente hay una razón para que esa parte sea diferente, debe ser consciente de ello o de lo contrario podría crear algunos errores desagradables. Entonces, en lugar de pensar en el problema original que te hizo tocar ese código, ahora pierdes el tiempo pensando en por qué es diferente, y no puedes resolverlo, así que dirígete al autor original para preguntarles, perdiendo su tiempo también, y peor aún: en el proceso, ambos pierden el modelo mental de los problemas en los que estaban trabajando.

  Multiplique por cualquier otro desarrollador del equipo que necesite tocar / leer ese código.

• Cuando necesita agregar a un código que usa múltiples estilos, debe detenerse y decidir qué estilo usar para su adición. Debe tomar suficientes decisiones importantes: es una pérdida de tiempo perder el tiempo pensando en decisiones que no importan.

• Cuando el estilo es consistente, es fácil navegar por el código, porque la consistencia lo ayuda a encontrar rápidamente dónde se encuentran las cosas. Con un estilo inconsistente, incluso el grepping se vuelve más difícil porque no sabes qué estilo está usando lo que estás buscando.

El código puede estar bien escrito pero no es perfectamente coherente, por lo que a algunos clientes no les importará. Cuando las cosas empiezan a ir mal, ¿quieres darles otro golpe en tu contra? Si contratara a una empresa para trabajar en un proyecto de múltiples desarrolladores y no me indicaran que tienen un estándar de codificación y lo sigan, sería escéptico.

Necesitamos mantener un ritmo rápido para entregar a tiempo y no quiero cargar al equipo innecesariamente.

Mientras los estándares de codificación no sean demasiado locos, no debería ser tan difícil para todos participar. Los proyectos se estancan porque la gente no sabe qué código escribir o no escribir y no por escribir y formatear. Sabrá que ha llegado demasiado lejos cuando se necesita una cantidad desproporcionada de tiempo para cumplir. Con suerte, este no es tu primer rodeo.

Realice su propia prueba Todo lo que necesita hacer es cambiar las tareas a mitad de camino de un desarrollador a otro y hacer que terminen el archivo de otra persona. ¿Pasan tiempo reformateando completamente las cosas a su versión? ¿Es demasiado difícil de seguir? Empeorará para el equipo de mantenimiento de su cliente.

He tenido buena suerte tratando los estilos de código al igual que trato los estilos de escritura en inglés natural. Hay una gran variedad de estilos, desde el inglés conversacional, que imita la forma en que hablamos en la conversación diaria, hasta el inglés formal, que a menudo es pesado y forzado por su significado siempre muy preciso.

Considere cómo le gustaría que se viera el producto final en ese sentido. Algunas situaciones apoyan el uso de la estructura que sea mejor en ese momento. Otros requieren una cadencia y estructura uniformes. Esto es especialmente cierto si su producto es mejor aunque como si estuviera escrito en inglés formal. Los coloquialismos pueden ayudar en ese caso, pero desgarran la sensación general del producto.

En general, cuanto más consistente sea su estándar de codificación, menor será el esfuerzo de un desarrollador para llamar su atención sobre algo interesante. Si admite una gran diversidad en los estándares de codificación, los desarrolladores deben ser más fuertes al anunciar que están haciendo algo inusual o único. Este intento de expresar lo que un desarrollador considera importante a menudo puede eclipsar el rango dinámico del código en sí. Cuando esto sucede, es fácil dejar pasar los errores porque es simplemente demasiado difícil verlos.

Por otro lado, cuanto más flexibles sean sus estándares de codificación, más libertad tendrán los desarrolladores para adaptar su sintaxis al problema. En irónico contraste con el argumento de los estándares de pro-codificación, demasiada estandarización puede conducir a una estructura de código rígida, lo que también puede facilitar que los errores se escapen.

Lo que está buscando es el medio feliz de su propio equipo.

Como varios otros han señalado, cuando los desarrolladores de mantenimiento tienen que ir detrás de usted, una sección de código en un estilo diferente hará que se detengan e intenten descubrir qué tiene de especial esa sección. También existe el riesgo muy real de que el estilo inconsistente se propague a otras secciones, lo que resulta en un gran desastre más adelante.

Tengo la impresión de que, en el fondo, ya sabes la respuesta a esta pregunta, y ni siquiera la enfrentarías si no fuera por esto:

Necesitamos mantener un ritmo rápido para entregar a tiempo y no quiero cargar al equipo innecesariamente.

Esto siempre parece ser la compensación universal ... hacerlo rápido versus hacerlo bien. Solo usted puede evaluar las consecuencias de sacrificar las buenas prácticas de codificación en la modificación de los plazos de los clientes. Sin embargo, tengo que estar de acuerdo con JeffO cuando observa que seguir un estilo de codificación (posiblemente inusual o contra intuitivo) no debería ralentizar a su equipo de manera tan drástica que los plazos se reduzcan significativamente.

Aunque conozco el concepto desde hace años, solo recientemente aprendí el término " deuda técnica ". Realmente necesita considerar la deuda técnica que finalmente tendrá que pagar si no sigue un estilo disciplinado ahora.

Desafortunadamente, como dijo eBusiness, a menos que su cliente sea particularmente experto en tecnología o vaya a mantener el código ellos mismos después, es difícil para ellos apreciar el valor de los estándares de codificación consistentes. Sin embargo, cualquier hombre de negocios razonable debería ser capaz de comprender el concepto de que "un poco de mantenimiento preventivo ahora" (en forma de una buena codificación) "ayudará a evitar costos de reparación significativos más adelante" (en forma de tiempo desperdiciado del desarrollador que luego limpia el lío).

Las respuestas más votadas aquí repiten las mejores prácticas teóricas fácilmente aceptables que detallan cómo nos gustaría que fueran nuestras bases de código. Pero el código real de alguna manera nunca se ve así. Si intenta hacer esa base de código perfecta, casi inevitablemente fallará. Eso no quiere decir que no debamos tratar de hacerlo mejor, pero tiene que haber un límite de cuán lejos de lo realista es posible alcanzar nuestros objetivos.

Demasiado enfoque en cosas menores tiene el riesgo de perder el enfoque en temas más importantes, como cómo resolver el trabajo de la manera más eficiente en general.

No me referiría a su primer ejemplo como estilo, el estilo son las opciones en las que no hay un claro correcto o incorrecto, en este caso la función adicional es un código inflado sin ninguna ventaja. Son solo 2 líneas adicionales, aún fáciles de leer y fáciles de arreglar, por lo que este ejemplo en sí no es un gran problema.

El problema mucho más grande es la hinchazón de código enrevesada. Funciones de envoltura, jerarquías de clase y todo tipo de otras construcciones, donde el código circundante es lo suficientemente complejo como para que no sea obvio que no tengan ningún propósito real. Si hay una hinchazón obvia en el código, probablemente haya mucha más hinchazón no obvia. Es mucho más difícil hacer algo y más difícil de detectar, pero también es un problema mucho mayor.

Acerca de los clientes

Los clientes tienden a centrarse en obtener un producto que funcione y que resuelva sus necesidades. Incluso si tiene uno de los pocos clientes que se preocupan por la calidad del código, será una prioridad secundaria, y su idea de la calidad del código podría no ser perfectamente coherente con la suya. La compañía del cliente puede tener sus propios programadores, pero sigue siendo la administración la que decidirá si hizo un buen trabajo o no, y la administración probablemente ni siquiera sabe qué significa la calidad del código.

Se trata mucho de la legibilidad de las diferencias. Si el estilo de código se agita, los diferenciales ocultan cambios sin significado semántico para el programa y pueden hacer que las fusiones sean difíciles o imposibles.