¿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. 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?


50
¿Cuál es el valor de una ortografía consistente? Una aceleración permanente y constante en la lectura y escritura de textos. ¿Cuál es el valor del estilo de código consistente? Una aceleración permanente y constante en la lectura y escritura de código. ¿Qué más podrías querer?
Kilian Foth

99
Cuando lees cosas, te acostumbras a los patrones de lo que estás leyendo y anticipas cómo leer cosas futuras. Si no hay coherencia, uno no puede anticipar patrones y se debe hacer una mayor interpretación del código, disminuyendo la velocidad del lector.
Codificador canadiense

1
Joel tiene algunas buenas ideas sobre ese tema. En resumen, un buen estándar de codificación hace que los errores sean fáciles de ver. joelonsoftware.com/articles/Wrong.html

13
Quiero agregar que las funciones con nombre casi siempre se prefieren a las funciones anónimas en JavaScript. Al depurar, esto ayuda muchísimo a determinar dónde se encuentra en la pila.
Mike McMahon

1
@yoniLavi deberías preguntar eso en meta.
RubberDuck

Respuestas:


48

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!


Gracias por estos excelentes puntos. Generalmente estamos siguiendo los patrones proporcionados por la biblioteca. Los ejemplos que he dado (que se encuentran en las revisiones de código) se desvían. Me preocupaba que el cliente pudiera rechazar y exigirnos que volvamos a hacer una parte de nuestra entrega porque no "parecía y reaccionaba". Ahora sé por qué harían eso.
Andreas Warberg

2
+1 "rather than teaching new patterns": la capacitación procesal es un sumidero de tiempo muy grande con nuevas contrataciones. Esfuércese siempre por minimizar el costo del tiempo mediante el uso de patrones conocidos
Gusdor

1
@Alexus: con respecto a la compatibilidad con versiones anteriores, React todavía no está en la versión 1.0. La versión actual, 0.13, rompió la compatibilidad de algunas maneras bastante drásticas, aunque si estas fallas sucederán depende de qué mecanismo se use para llamar a los componentes React. Tener reglas muy consistentes sobre cómo llamar a React puede no evitar que las actualizaciones de React rompan el código, pero arreglar un código consistente es más fácil, más rápido y más confiable. Sus preocupaciones sobre problemas de compatibilidad con versiones anteriores definitivamente están justificadas en el caso de React. Por ejemplo, vea mi comentario en stackoverflow.com/a/20913637/18192
Brian

53

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.


66
Genial, visión fanática. ¿Por qué algunos desarrolladores parecen simplemente "entender" esto y otros luchan contra él?
Dogweather

2
Sospechoso porque un estilo consistente que se propone ahora es profundamente inconsistente con lo que han trabajado en proyectos anteriores. Especialmente para aquellos con una gran cantidad de experiencia en diferentes entornos.
Kickstart

4

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.


2

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.


2

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).


El cliente tiene conocimientos técnicos y probablemente se hará cargo del mantenimiento y el desarrollo de la solución en algún momento. El esfuerzo de preguntas y respuestas hasta ahora se ha centrado en el diseño visual y no tanto en la funcionalidad. Una vez que comiencen a aparecer los errores de funcionalidad, tendremos una idea de cómo es el mantenimiento. Creo que las revisiones de código serían más rápidas con más consistencia (reducen nuevas formas sorprendentes de hacer lo mismo). El cliente obviamente quiere la máxima consistencia (pero quizás no pague más por ello).
Andreas Warberg

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 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.


Al revisar el código, busco varias cosas que creo que son definitivamente importantes, como la manipulación directa del DOM, cadenas no orientadas hacia el usuario, oportunidades de reutilización (un componente existente, auxiliar, biblioteca de terceros ya cargada, etc.), cambios incompatibles o incorrectos. al código compartido, desviación de las convenciones del cliente y del equipo. El valor de la consistencia del estilo y los patrones de codificación no estaba claro para mí, así que no estaba seguro de cómo responder a los que estaban en las revisiones de código.
Andreas Warberg

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.