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

47

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

Me he dado cuenta de que algunos miembros del equipo utilizan patrones de codificación únicos hasta un punto en el que podía elegir un archivo al azar para decir quién era 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 alinear la función y agregar un comentario, en su lugar, se podría lograr el mismo efecto.

Ejemplo 2 (funciones no vinculadas)

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 solemos hacerlo (evita tener que aprobar estados y apoyos):

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) insinúa en tutoriales y ejemplos.

Necesitamos mantener un ritmo rápido para poder 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 podría requerir que entiendas 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 en lugar de permitir que las inconsistencias como estas permanezcan y se propaguen?

    
pregunta Andreas Warberg 07.07.2015 - 22:11

7 respuestas

48

Ventaja de transferencia de código

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

Problemas potenciales 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 ralentiza / detiene su futura actualización. No estoy seguro de cómo React trataría con los nuevos lanzamientos, pero he visto que esto ha sucedido antes.

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

Si sigues lo que proporciona el autor, es más probable que estés contratando a desarrolladores talentosos que utilicen tu marco y los comiences más rápido con tu sistema en lugar de enseñar nuevos patrones.

Problemas potenciales no descubiertos

Es posible que haya problemas en el futuro que aún no haya descubierto con su enfoque, que se resuelvan con el enfoque del autor.

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

    
respondido por el Alexus 07.07.2015 - 22:25
53

Las inconsistencias hacen que te detengas y pienses en por qué , cuales y donde :

  • Cuando lees parte del código y ves que usa un estilo diferente al resto del código, te hace preguntarte: ¿por qué esta parte en particular es diferente? ¿Tiene alguna razón especial por la que debo estar al tanto? Esto es peligroso, porque si realmente hay una razón para que esa parte sea diferente, debes ser consciente de ello o podrías crear algunos errores desagradables. Así que, 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 entenderlo, así que vas al autor original para preguntarles, perdiendo su tiempo también. peor aún: en el proceso, ambos pierden el modelo mental de los problemas en los que estaban trabajando.

    Multiplique por todos los demás desarrolladores del equipo que necesitan tocar / leer ese código.

  • Cuando necesite agregar a un código que use varios estilos, debe detenerse y decidir qué estilo usar para su adición. Debe tomar suficientes decisiones que sean importantes, es una pérdida de tiempo perder tiempo pensando en decisiones que no importan.

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

respondido por el Idan Arye 07.07.2015 - 22:37
4

El código puede estar bien escrito pero no es perfectamente consistente, 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 indicaron que tienen un estándar de codificación y lo siguen, sería escéptico.

  

Necesitamos mantener un ritmo rápido para poder entregar a tiempo y no lo hago   quiere cargar al equipo innecesariamente.

Mientras los estándares de codificación no sean demasiado locos, no debería ser tan difícil para todos subir a bordo. 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 muy lejos cuando se necesita una cantidad desproporcionada de tiempo. Con suerte, este no es tu primer rodeo.

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

    
respondido por el JeffO 07.07.2015 - 22:31
2

He tenido buena suerte al tratar los estilos de código tal como trato los estilos de escritura en inglés natural. Existe una gran variedad de estilos, desde el inglés conversacional, que imita la forma en que hablamos en cada conversación cotidiana, al inglés formal, que a menudo es pesado y se basa en su significado.

Considere cómo le gustaría que se vea el producto final en ese sentido. Algunas situaciones apoyan mucho 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 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 coherente sea su estándar de codificación, menos esfuerzo deberá realizar 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 que es 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 que los errores se deslicen porque es demasiado difícil verlos.

En la otra cara de ese argumento, cuanto más flexibles sean tus estándares de codificación, más libertad tendrán los desarrolladores para adaptar su sintaxis al problema. En un contraste irónico con el argumento de los estándares de codificación profesional, demasiada estandarización puede llevar a una estructura de código forzada, lo que también puede hacer que sea más fácil que los errores se deslicen.

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

    
respondido por el Cort Ammon 09.07.2015 - 01:10
2

Como han señalado otros, 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 real de que el estilo inconsistente se propague a otras secciones, lo que resultará en un gran lío más adelante.

Me da la impresión de que, en el fondo, ya conoces la respuesta a esta pregunta, y ni siquiera estarías enfrentándote si no fuera por esto:

  

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

Esto siempre parece ser la compensación universal ... hacerlo rápido frente a hacerlo correctamente. Solo usted puede evaluar las consecuencias de sacrificar las buenas prácticas de codificación en función de los plazos de entrega de los clientes. Sin embargo, estoy de acuerdo con JeffO cuando observa que seguir un estilo de codificación (posiblemente inusual o contraintuitivo) 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 debe considerar la deuda técnica que finalmente tendrá que pagar si no sigue un estilo disciplinado ahora.

Desafortunadamente, como lo indica eBusiness, a menos que su cliente tenga un conocimiento técnico particular o vaya a mantener el código por sí mismo 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 poder 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 de revelador desperdiciado más tarde, limpiando el lío).

    
respondido por el Michael C 09.07.2015 - 04:14
2

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 intentas hacer esa base de código perfecta, casi inevitablemente fallarás. Eso no quiere decir que no deberíamos intentar hacerlo mejor, pero tiene que haber un límite en cuanto a qué tan lejos de lo realista podemos establecer nuestras metas.

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

No me referiría a tu 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 el código inflado sin alza. Solo son 2 líneas adicionales, todavía 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 proliferación de códigos complicados. Funciones de Wrapper, 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 tienen ningún propósito real. Si hay una hinchazón obvia en el código, es probable que haya una hinchazón mucho más obvia. Es mucho más difícil hacer algo al respecto, y más difícil de detectar, pero también es un problema mucho más grande.

Acerca de los clientes

Los clientes tienden a enfocarse en obtener un producto que funcione y que resuelva sus necesidades. Incluso si tiene uno de los pocos clientes que se preocupa por la calidad del código, será una prioridad secundaria, y su idea de la calidad del código puede no ser perfectamente compatible con la suya. La compañía cliente puede tener sus propios programadores, pero aún así es la administración la que decidirá si usted hizo un buen trabajo o no, y es muy probable que la administración ni siquiera sepa qué significa la calidad del código.

    
respondido por el aaaaaaaaaaaa 08.07.2015 - 16:05
0

Se trata mucho de la legibilidad de las diferencias. Si el estilo del código se mueve, el diffs oculta los cambios sin un significado semántico para el programa, y puede hacer que las combinaciones sean difíciles o imposibles.

    
respondido por el Rob 08.07.2015 - 21:09

Lea otras preguntas en las etiquetas