Hola Me llamo Nikolai Izhikov. En esta publicación quiero hablar sobre un elemento importante de interacción que encontramos en el proceso de desarrollo de software, especialmente en código abierto. Este es un tutorial y una revisión de código.
Daré consejos
perjudiciales sobre cómo crear mi función y la fusionaré en el asistente de proyecto de código abierto en el contexto de diferencias culturales, temporales, conceptuales y de otro tipo entre los miembros de la comunidad. Esta suele ser una pregunta difícil, especialmente para aquellos que recién están comenzando en código abierto.
Comencemos con una pequeña introducción. Cuando se comunique con personas, especialmente en el chat o por correo, especialmente en inglés, siempre tenga en cuenta que su mensaje se puede percibir de manera completamente diferente de lo que esperaba. Quién leerá la carta es desconocido. Puede ser hindú, inglés o simplemente una persona somnolienta. Siempre habrá diferencias en la comprensión de palabras específicas, y sin entrar en detalles técnicos, le diré cómo minimizarlas.
Advertencia: la historia contiene sarcasmo.
Malos consejos para un contribuyente
No discuta una nueva característica con nadie
Si desea implementar una nueva función, en ningún caso discuta su revisión con nadie. ¡Alguien puede espiar y hacerlo antes que tú! O, habiendo escuchado los detalles, pueden decirte que no entendiste algo para criticar tu idea. La crítica duele mucho. Tal vez una característica como la suya ya ha sido discutida, y necesita otra ... En general, en ningún caso diga a nadie lo que quiere hacer. Nunca
Nunca haga documentación técnica
Los encargados y los muchachos experimentados de la comunidad son muy aficionados a comprender el código del parche recibido. Por lo tanto, en ningún caso no haga documentación técnica. Wiki, Jira, discusión de la lista de correo: todo esto no tiene sentido. ¡Y la mierda no es para ti!
Cuando envía un parche a [+5000, -3500] con una descripción de las mejoras en forma de "Mejoras en los métodos de fábrica y algunas otras mejoras", todos lo descubrirán por sí mismos y, al mismo tiempo, comprenderán lo bueno que es.
Nunca ejecutes pruebas
Cualquier prueba es peligrosa porque puede romper algo. Si aún logró ejecutar las pruebas, no muestre sus resultados. ¡Los errores en los resultados pueden conducir al rechazo del parche! Y definitivamente nunca escribas nuevas pruebas. Run All será más largo, el consumo de CPU aumentará. De todos modos, los buenos desarrolladores escriben código sin errores: cualquier colega experimentado mirará sus parches y comprenderá que no hay errores allí.
Nunca lea cómo hacerlo
Al entrar en un proyecto de código abierto, nunca lea ningún tutorial. Están escritos para tontos, ¿verdad?
Diseña tu código a tu manera. De lo contrario, ¿cómo entenderán todos que usted es un buen desarrollador y una persona creativa versátil con un sentido desarrollado de belleza?
Envíe parches ya que es conveniente para usted. Por ejemplo, el proyecto está vinculado a la infraestructura de GitHub: envíelo tal como se envía al kernel de Linux, justo en la carta. Incluso puede no en el archivo adjunto, sino directamente en el texto. ¡Después de todo, Linus Torvalds no aconsejará nada malo! Y si el proyecto se adopta de manera diferente, entonces estos son problemas del proyecto.
Siéntase libre de complicar la API pública
Al desarrollar la nueva API pública, intente que sea lo más abstracta y compleja posible. Cualquier pregunta del usuario sobre el comportamiento no obvio de la API siempre se puede responder: “¿No ha leído el manual? ¡Página 42, todo está escrito claramente! ¡Léelo de nuevo! En proyectos serios, todo debería ser complicado. Tenemos un proyecto serio?
No aconsejar ni hablar sobre problemas.
No consulte con nadie y no le cuente a nadie sobre los problemas encontrados en el desarrollo. Es mucho más divertido entender una cosa. De todos modos, los buenos desarrolladores siempre tienen éxito la primera vez, no tienen problemas. Si otros descubren sus problemas, se volverán más inteligentes y escribirán código más rápido que usted. Esto no debería permitirse. Y, de hecho, no es costumbre hablar sobre sus problemas.
Tampoco vale la pena mencionar las limitaciones de la decisión final. Después de todo, se le puede pedir a la solución que finalice. ¿A quién le importan las restricciones? Cuando un usuario comienza a introducir su producto en el producto y encuentra restricciones, estará más interesado y será más divertido. Él vendrá a ti y te pedirá que lo termines. Y hasta este punto, en ningún caso no le cuente sobre las restricciones, ¿qué pasa si decide no implementar nada?
Un revisor muy bueno encontrará todo y le pedirá detalles. En ningún caso no le cuentes nada.
Si tiene preguntas, escriba a la lista de desarrolladores
Este consejo complementa el anterior. Es mejor no solo no decirle nada a nadie, sino también hacer preguntas principalmente en la lista de desarrolladores.
Aquí hay ejemplos de preguntas que a todos les gusta responder. Si escribe algún tipo de prueba, asegúrese de preguntar: "¿Necesita verificar la nula de esta colección?". No tiene que resolverlo por su cuenta, siempre puede preguntar en la hoja de desarrollo. Después de todo, hay muchas personas que solo esperan que se les haga esa pregunta. Buscarán responderle más rápido.
"¿Cómo hago la tarea?" - Otra gran pregunta. En ningún caso, no indique ningún detalle: la ID de la tarea será suficiente. Todos los que lo necesiten verán por sí mismos.
"¿Qué marco utilizar?" - También una muy buena pregunta. Siempre es interesante responderlo, y puedes debatir.
Solucione todos los problemas del proyecto en una solicitud de extracción
Este es mi consejo favorito. Solucione todos los problemas del proyecto en una solicitud de extracción, especialmente si está trabajando en una empresa. Solo había tontos en el proyecto antes que tú, escribieron mal el código. Y escribes bien. En consecuencia, simplemente debe:
- Refactorice todo el código existente que no comprende;
- cambiar el nombre de todas, en su opinión, las variables nombradas incorrectamente;
- arregla todos los comentarios existentes de javadoc.
En general, puede tomar y sacar algunas clases, fábricas, etc., hacer otras transformaciones para que el código sea mejor. Esto se verá especialmente impresionante en áreas que no son relevantes para su tarea. Para que pueda revelar más plenamente su potencial. ¡A la gloria de la OOP! Amén!
Solicite una revisión de código por adelantado
Cuando realiza una tarea y luego envía una solicitud de revisión de código, el proceso puede demorar un poco. Todos los expertos suelen estar ocupados. Aproveche el truco: cuando su tarea, como le parece, termine pronto, solicite una revisión por adelantado. Después de todo, no se verán de inmediato: hasta que tus manos te alcancen, puedes terminarlo todo.
Bueno, si el revisor de repente tiene tiempo, mientras la tarea aún no se ha completado, entonces tuvo mala suerte. Explique la situación, diga que mañana todo estará listo. De esta forma, acelera el proceso (al menos mediante revisión) y se fusiona más rápido.
Cansado de la tarea: suéltalo
Todos los que trabajan en código abierto tienen mucho tiempo. No hay necesidad de terminar nada. Revisión del código aprobado, comentarios recibidos. ¿Y por qué editar y traer algo para fusionar? Toma el siguiente rompecabezas y hazlo. Este es el camino hacia el éxito! El revisor tiene mucho tiempo, ¡y el próximo parche se verá sin resultado!
El crítico es tu enemigo
¿Y qué más nombrar a la persona que se interpone entre usted y el cometer en maestro? ¡La crítica del código es una crítica personal! ¿Quién se cree que es? En comunicación personal, "bombardea" tanto como sea posible! De lo contrario, ¿cómo sabe el revisor que le importa? ¡Esta es la regla básica del desarrollo!
Recomiendo este consejo en el desarrollo cotidiano. Esto ayuda a lograr el resultado y hacerlo bien.
Mal consejo para el revisor
No automatice las comprobaciones de rutina.
Si ha alcanzado el nivel en el proyecto cuando ya le están enviando parches para su revisión, ¡en ningún caso automatice las comprobaciones de rutina! Es mucho más divertido pasar un par de ciclos de revisión en solución de problemas y discusión:
- formato de código;
- nomenclatura variable;
- comprueba si esas variables están marcadas como finales, lo que puede marcarlas;
- ... y todo lo demás.
En ningún caso se deben automatizar los controles de rutina. Sí, y pruebas para conducir a la nada.
Nunca reveles todas las reglas del juego hasta el final.
Para adelantarse, siempre debe mantener un par de ases bajo la manga. No le digas a nadie sobre la necesidad de compatibilidad con versiones anteriores. Es mejor decir justo antes de la confirmación: "Aquí, de acuerdo con nuestras reglas, debe garantizarse la compatibilidad con versiones anteriores. Por favor corrija ". Esto será especialmente efectivo si ya ha revisado cinco veces. En el sexto todavía se puede decir: "No soy un experto, por lo que debe esperar la revisión del Sr. X, que volverá a mirar".
Tales comentarios, especialmente en la etapa final de la revisión, siempre agregan motivación a los contribuyentes.
Emociones, autoridades y no gracias.
Esta sugerencia se superpone con la última sugerencia de contribuyente. Escriba comentarios sobre la solicitud de extracción lo más emocionalmente posible. Si en algún lugar no se marca nulo o la variable no se nombra de esa manera, agregue pasión a sus comentarios. Deja que vean que te importa.
Si surge una disputa, en ningún caso dar argumentos técnicos. Con argumentos técnicos, puede resultar que estás equivocado. Consulte a las autoridades: este es el mejor argumento en la disputa, siempre ganará.
Si alguien revisó tu opinión, nunca deberías decir gracias. ¡Aún así quieren comprometerse con el código abierto! ¡En ningún caso no tienes que agradecer, y entonces vendrán otra vez!
Ahora en serio: ¿qué debe pensar al preparar y realizar una revisión de código?
Espero que todos hayan entendido cómo realizar y aprobar la revisión. En cada uno de estos consejos, además del sarcasmo, hay dolor que a menudo ocurre en la práctica.
Seré el capitán de Evidence y le diré lo que realmente necesita pensar al preparar y realizar una revisión del código. Las consideraciones se aplican tanto al que desarrolla la función como al que la revisará. Aún así, estas son dos caras de la misma moneda.
El consenso en la comunicación es, en primer lugar, alcanzable, y en segundo lugar, es necesario que el proyecto avance. Actualmente, pocos productos se pueden desarrollar solos. Por lo general, esto es trabajo en equipo.
Usa el sentido común
Este es el consejo más importante. Use el sentido común, se dirige. Me parece que este consejo se aplica a todas las situaciones de la vida. Si está haciendo algo, considere si esto cumple con la simple regla del sentido común.
Supongamos ...
Esto es sobre cultura. He estado en varias grandes comunidades de código abierto. No sé si esto es parte de la mentalidad rusa, pero a menudo una persona que puede ser percibida como un jefe es percibida simultáneamente como una persona que accidentalmente cayó en su lugar. Se cree que te quiere mal, por defecto hay dudas sobre su profesionalidad. Por lo tanto, es muy importante en cualquier trabajo asumir, al menos por un segundo, que:
- El revisor (colaborador, su jefe o colega) no es su enemigo . Él no quiere que seas malo. Esta es una suposición simple, pero a menudo no se hace. Le aconsejo que lo haga de todos modos.
- La persona que escribe sus comentarios también es un buen ingeniero. Usted, por supuesto, es bueno, ha hecho tal característica. Pero hay muchos otros buenos ingenieros en el mundo. Y el que te envió comentarios también se aplica a ellos.
- Esta persona también quiere que su tarea se cumpla.
Cuando pide algo, tiene algún tipo de motivación. Lo hace por una razón. Especialmente si esta persona no es el primer día en el proyecto. Seguramente hay alguna razón. Puede preguntar por esta razón: ¿Por qué necesita hacer exactamente eso? ¿Por qué se necesita compatibilidad con versiones anteriores aquí? Si hace preguntas simples con calma, razonablemente y escucha las respuestas, puede lograr más.
¿Qué valor aportará el producto?
La revisión no es solo parches listos, sino también mejoras del proyecto, correcciones. De hecho, la revisión del código comienza en el momento en que solo está discutiendo su revisión. En este punto, pregúntese: ¿qué valor aportará el producto al producto?
- ¿Será una nueva característica?
- ¿Es esta una mejora existente?
- Extensión de una característica existente?
- ¿Será la refactorización de código? No hay nada de malo en eso. Algunos son críticos de la refactorización, pero es necesario. Y debe tener en cuenta que lo está haciendo, y no una nueva característica u otra cosa.
- ¿Está acelerando un proceso, mejorando el rendimiento?
- ¿Es esto una corrección de errores?
Hay otras opciones En cualquier caso, al comenzar a desarrollar algo, para resolver un problema, debe comprender qué valor agregará al proyecto.
¿Por qué la revisión (característica) es así?
Hay una serie de preguntas útiles para hacer.
¿Por qué hacer una función? ¿Por qué se necesita esta característica? La respuesta a esta pregunta es importante.
¿Dónde está el inicio del trabajo? En mi práctica, sucedió que me pidieron que volviera a hacer una determinada aplicación. Hay una aplicación A, necesita hacer una aplicación B, que hace casi lo mismo con cambios menores. Empiezo a hacer el trabajo y resulta que A básicamente no funciona. De hecho, se usa en algún lugar de la producción usando la interfaz hombre-máquina, es decir, alguien se sienta y reinicia constantemente el programa, arreglando la excepción de puntero nulo literalmente en el aire. ¿Dónde está el inicio del trabajo? En este caso, será en la fijación del programa A para que funcione de manera estable, luego en la escritura del programa B.
¿Dónde está la finalización completa del trabajo? ¿Cómo debe ser ideal el trabajo realizado? Es importante formular desde el principio a dónde va.
¿Dónde está el final de la etapa actual? Está claro que no puedes comer un elefante de inmediato y es mejor dividir el trabajo en etapas. Es importante entender dónde está el final de la etapa actual. A menudo, los proyectos se inflan y no terminan solo porque el alcance del proyecto se vuelve infinitamente grande.
¿Por qué la función se desglosa precisamente en tales etapas? Esto es sobre MVP y todo eso. Por favor piensa en esto también.
Ahora sobre la API pública
Hay muchos artículos sobre las propiedades de la API pública. Léalo antes de implementarlo. Como buen ejemplo, puedo citar el framework JQuery, Spring en Java. También hay ejemplos negativos. Quien haya estado programando en Java durante años, probablemente recuerda lo que es terrible en términos de Public API EJB 2.1. La funcionalidad allí puede ser buena, pero si la API pública es mala, nadie puede convencer a los usuarios para que usen el producto.
La API pública no es solo una herramienta para usuarios de terceros. Esto y la API de componentes internos, que usted mismo reutiliza entre ellos. Propiedades importantes de la API pública:
- Simplicidad
- La evidencia
- Los valores predeterminados correctos. Vale la pena pensar en ellos si, por ejemplo, en un entorno de prueba crea 500 hilos, como en la producción. O viceversa, en la producción por defecto hay 3 hilos, como en un entorno de prueba.
- Borrar mensajes de error. Este es el flagelo de tantos productos. Cuando algo cae dentro del sistema, no está claro qué se hizo mal. Ayer funcionó, hoy una excepción de puntero nulo. Lo que exactamente hizo mal y cómo solucionarlo no está claro en el mensaje de error.
- Es difícil cometer un error. Hay muchas recomendaciones sobre este puntaje. Las comprobaciones en tiempo de compilación siempre son mejores que las comprobaciones en tiempo de ejecución, etc.
- Registros claros y suficientes. Esto es especialmente importante cuando escribe código que se reutilizará y desplegará en algún lugar del servidor.
- La capacidad de monitorear. Debe comprender que los registros y la supervisión también forman parte de su API pública. Al analizar los errores, los usuarios verán cómo se comportan las métricas que escupe en la supervisión.
Cambios de subsistema
Cuando se trata de la revisión del código, es importante tener en su cabeza una lista completa de los sistemas y subsistemas de un producto grande en el que está cambiando. En proyectos empresariales, puede que no esté claro: si se trata de un esquema de base de datos, o un controlador, o una presentación, algún tipo de sistema de informes, cargas, descargas, etc.
Al trabajar con un producto en caja, es importante hacerse la pregunta: ¿cómo afectan los cambios a los procesos existentes en el sistema? ¿Hay una compatibilidad con versiones anteriores? ¿Afecta el rendimiento? Si afecta, entonces el rendimiento de qué? ¿Cómo afecta esto a la experiencia del usuario?
Procesos estándar del sistema
Cada sistema empresarial tiene procesos estándar: inicio, instalación, alguna lista de operaciones. ¿Cómo van a fluir ahora? Antes de revisar el código, es importante entender esto. Debe pasar por el código que implementa estos procesos. En el caso de Ignite, esto es:
- Inicio / detención de nodos (servidor / cliente, coordinador / regular): iniciar, detener un nodo, iniciar un servidor o nodo de cliente, iniciar un coordinador o un nodo normal
- Unión de nodos: en términos de un nuevo nodo / coordinador / servidor / cliente
- Activación de clúster (y desactivación)
- Cambio de coordinador
- Crear / Eliminar caché
- Persistencia / BLT / MVCC
Está claro que el conjunto de estos procesos es bastante amplio. Es importante comprender que tales procesos existen y cómo cambian.
Casos de esquina
En su aplicación empresarial, puede ocurrir recuperación ante desastres, inicialización inicial del sistema, apagado de nodos, reinicio, actualización de su aplicación, etc. En el caso de Ignite, tenemos los siguientes casos de esquina:
- cambio de coordinador;
- caída de nodo;
- problemas de red: cuando los mensajes de red no llegan;
- archivos rotos
Debemos verificar y verificar estas cosas para que todo esté en orden.
Buenas características de código
Entonces llegamos al código. Te aconsejo que no seas flojo y busques en él:
- simplicidad
- extensibilidad
- comprobabilidad
- fiabilidad
- Alta velocidad de trabajo.
Concurrencia
Java tiene sus propias peculiaridades al escribir código de concurrencia. Si tiene un sistema de negocios y hay poca concurrencia allí, no necesita considerar estas características. Sin embargo, por lo general, algunas sincronizaciones pasan por la base de datos. En cosas como Ignite, esto es un poco más complicado. Y aquí, no solo la funcionalidad del código es importante, sino también sus propiedades:
- ¿Qué tan difícil es entender su modelo de concurrencia?
- Estructura de datos compartidos: ¿cómo se garantiza su integridad?
- Cerraduras: ¿qué y por qué?
- Hilos: ¿qué agrupaciones se utilizan? Por qué
- Garantías de visibilidad de los cambios: ¿para qué se proporcionan?
Estas preguntas deben hacerse antes de revisar el código de concurrencia. Está claro que esta lista puede continuar durante mucho tiempo.
Pruebas de desempeño. Puntos de referencia
Si está desarrollando algún tipo de sistema, tiene clientes, instalaciones, obviamente funciona con cierto rendimiento. En el mundo de hoy, es imposible aumentar la potencia del hardware de forma indefinida. Necesitamos pruebas y monitoreo del desempeño. Al realizar una revisión del código, es importante comprender:
- ¿Son necesarias las pruebas de rendimiento? ¿Quizás este es algún tipo de refinamiento que no necesita pruebas de rendimiento?
- Si es necesario, ¿cuál? Existen muchas técnicas y métodos de medición, etc.
- ¿Dónde, cómo, qué se debe medir?
- ¿Qué puntos de referencia son indicativos? ¿El número de nodos? Hierro? ¿Encender configuración? La naturaleza de la carga?
Total
En general, la revisión de código es una práctica muy gratificante. Espero que todos los desarrolladores (incluidos los productos empresariales) ya lo hayan implementado en casa. De lo contrario, implemente lo antes posible. Estaré encantado de discutir las prácticas de revisión de código con usted en los comentarios.
Video de la conferencia:La presentación está disponible aquí .