Introducción al desarrollo de una solución típica de código abierto.

El 11 de septiembre, se realizó un Meetup de Java en San Petersburgo, dedicado por completo a Apache Ignite . Muchas gracias a los organizadores por la invitación y la oportunidad de hablar sobre Open Source en nombre del desarrollador de este Open Source. Dada la reacción positiva de la audiencia, decidí compartir la presentación con aquellos que no pudieron asistir a la reunión.

Debajo del corte, encontrará una versión de texto de la presentación, llena de percepción subjetiva del Código Abierto, tanto positiva como negativa.




Entonces, mi nombre es Anton Vinogradov, y durante los últimos 4 años he estado desarrollando el proyecto Open Source Apache Ignite. Usando su ejemplo, quiero hablar sobre cómo se hace Open Source, qué beneficios personales puede obtener al participar en la comunidad y, en última instancia, quiero inspirarlo a participar.




Hablaré sobre Open Source usando el ejemplo de Apache Ignite, uno de los muchos proyectos de Apache Software Foundation. ASF es una de las comunidades de código abierto más grandes con casi 20 años de historia. Debe sus éxitos, en primer lugar, a los procesos y principios de motivación, establecidos en 1999, pero que aún hoy son relevantes. Este lado "filosófico" de la comunidad fue descrito en detalle en su artículo por Dmitry Pavlov , pero consideraremos el lado "aplicado" del desarrollo de código abierto utilizando el ejemplo de Apache Ignite.

Suponga que decide contribuir al desarrollo de la comunidad. Como hacerlo


En general, no se puede decir que Open Source se trata de código. Muchas actividades diferentes pueden hacer una contribución significativa, y solo algunas de ellas están directamente relacionadas con el código.

• Si encuentra un problema, indíquelo en la lista de usuarios, donde se resolverá;
• Si está listo, puede participar en el estudio de tareas en el devlist y en la coordinación de acciones;
• Si eres un desarrollador genial, esta es una oportunidad para que escribas mucho código bueno;
• Que podrá revisar un buen crítico;
• Si es un buen administrador, puede ayudar con el lanzamiento de la versión;
• Si eres un buen narrador de historias o simplemente un fanático del proyecto, como yo, entonces puedes participar en popularizar la solución.

La contribución más importante a Open Source es informar a la comunidad sobre los problemas del producto y sus defectos. Pero aquí es importante comprender que Open Source no es un desarrollo personalizado y que la comunidad no le debe nada. El 90% del éxito depende de usted. Si encuentra un problema, su contribución a Open Source será su análisis detallado y la búsqueda de soluciones. Se espera que participe activamente en la discusión del problema. Si lo informa y se va, el problema no se resolverá.

Opción ideal: usted vino, habló sobre el problema y está listo para conducir este hilo hasta el final, para resolver el problema.

Cada problema discutido, pero no resuelto en la lista de usuarios, cae en el devlist, donde se está resolviendo. Aquí, los desarrolladores discuten cómo implementar adecuadamente una característica o cerrar un error.


Devlist es una especie de "lugar de poder" del proyecto donde puedes hablar con desarrolladores geniales que potencialmente podrían ganar mucho dinero en capacitaciones, seminarios, consultas, redacción de artículos. Pero estas personas están ocupadas escribiendo código real, exactamente el código que ahora está a la vanguardia del progreso. Me parece que simplemente no tienes otra forma de comunicarte con estas personas, excepto en el devlist.

Además, un devoto es una correspondencia reflexiva, donde tiene la oportunidad de pensar durante una hora o dos y solo luego responder con una carta, a diferencia de los mensajeros, donde es difícil leer la correspondencia y comprender todo a nivel mundial. Según tengo entendido, un devlist es una revista técnica especializada tan buena que no solo puede leer, sino que también participa directamente en su creación.

El trabajo en un devlist, como cualquier trabajo en Open Source, es público. Si realiza alguna contribución, su empleador actual o futuro o sus colegas lo buscarán en Google. Para mí personalmente, al evaluar a un candidato para un empleo, su participación en las doncellas es más importante que su perfil en el github. Un perfil en un github caracteriza solo la capacidad de escribir código, y la experiencia en un devlist también caracteriza la experiencia del desarrollo del equipo. Por otra parte, tal experiencia donde es importante la responsabilidad individual, y no colectiva. En mi opinión, esta habilidad es más importante para un buen desarrollador, y se desarrolla mejor cuando se comunica en dispositivos en Código Abierto.

Procedemos directamente al desarrollo.


Después de acordar mejoras en el devlist, y generalmente se acuerdan decisiones de diseño fundamentales, la tarea está lista para su implementación. La tarea se realiza con mayor frecuencia por las mismas personas que la propusieron y la entregaron, pero no siempre. Algunas características no pueden dominar a una persona en un período de tiempo razonable, especialmente si es una característica a la mitad de Ignite.

Si es un buen desarrollador y está listo para ver Open Source, venga y elija una de las tareas resueltas, coordínela con el autor y comience a cortar.

En código abierto, todas las comunicaciones son públicas. La discusión está en el devlist o en el tracker de problemas. Es importante tratar de evitar implementar algo sin discusión, porque hay una alta probabilidad de hacer algo mal. Es una buena práctica aclarar todos los puntos clave antes de comenzar el desarrollo, para no hacer demasiado trabajo.

Ahora sobre lo importante.

El desarrollo de código abierto es una escuela buena y gratuita. Desarrolladores geniales, profesionales en su campo, descomponen tareas, le permiten implementarlas, ayudan con cualquier dificultad, y finalmente aparece un compromiso que lo caracteriza como un excelente desarrollador. Como dije, esto se puede buscar en Google, esto es parte de su cartera.

Si no desea vender algo gratis, considere que esta contribución es, en términos generales, su historial de crédito. Demuestra que está haciendo todo bien, puede escribir código y discutir tareas, y es fácil trabajar con usted.

Un momento peligroso en el desarrollo de código abierto es que absolutamente cualquier persona puede entrar en él. Creo que en cada proyecto de Código Abierto hay una persona que distrae a todos por años y luego se va sin hacer ninguna contribución. Y es bueno si se va.

¡No ser esa persona es una contribución importante para la comunidad de código abierto!

Entonces, decidió archivar algo en código abierto. Es probable que la primera vez que hagas todo mal. Con el tiempo, obtendrá experiencia que lo ayudará a hacer todo bien, pero no la primera vez.

En este caso, la revisión lo ayudará.


En la mayoría de los proyectos (en Apache Ignite, por supuesto), la revisión se realiza antes de la confirmación, lo que le permite mantener limpios los brunches maestros o de desarrollo. Y tenemos una serie de requisitos fundamentales que deben cumplirse antes de enviar el código para su revisión.

Código de estilo.
El proyecto tiene mucho código, está escrito por diferentes personas, con diferentes motivaciones y en diferentes momentos. Si hubiera sido escrito de diferentes maneras, habría sido imposible de leer. Por lo tanto, el estilo del código es fundamental para nosotros. Si en una revisión le dicen que necesita una línea vacía, eso es importante.

Cada característica debe pasar por una regresión.
Si el proyecto es grande, nunca adivinará cómo su pequeña terminación afectará toda la funcionalidad. Actualmente, tenemos alrededor de 50 mil pruebas, cada característica está cubierta por una o más. Con respecto a las pruebas caídas, la regresión ayudará a determinar que has roto algo. Para usted, esta es una buena manera de no pensar demasiado y comprender rápidamente todo: ¿hay un colapso o no? Si hablamos de los costos de las pruebas, tenemos un grupo de ~ cien máquinas que ejecutan una regresión de un brunch en dos horas.

Cambios en áreas materiales.
Si cambia algo en el "núcleo", debe pasar por la evaluación comparativa. No importa cuán difícil y resolviendo todos los problemas sea la característica, si empeora el par de rendimiento / latencia, entonces no se puede fusionar. La degradación del rendimiento en nuestro producto es inaceptable.

API
Hay dos puntos La nueva API no debe interrumpir la compilación de aquellos que utilizaron la versión anterior del producto. Y no deberían aparecer métodos que quedarán obsoletos en un par de meses. Hacer una API: hágalo de inmediato.

La aportación del revisor es la más importante de las contribuciones de código abierto más difíciles. El revisor es la persona que está lista para ayudarlo, en algunos casos realiza hasta el 90% del trabajo. El revisor empuja, explica, casi escribe código para usted, si es necesario. El problema es que cuando una característica se convierte en maestra, el contribuyente la enumera y no el revisor. Apreciar el trabajo gratuito del revisor.

Si trabaja en la comunidad de código abierto, intente que el revisor se sienta cómodo. Las reglas básicas son hacer que la solución sea lo más mínima posible, pero lo más clara posible. Si antes de la revisión ve que puede reducir el volumen de la solución y aumentar su comprensión, hágalo.

La versión actual de Apache Ignite es 2.6. Los lanzamientos ocurren aproximadamente cada 3 meses.


La versión 2.7 está siendo preparada por un empleado de Sbertekh Nikolai Izhikov, desde hace casi un año como responsable del proyecto. Este es un evento significativo para el proyecto, porque por primera vez en su historia, el lanzamiento no lo lleva a cabo un empleado de Gridgain, la compañía que creó Apache Ignite y lo transfirió a ASF. Esto es muy bueno, porque nos estamos moviendo hacia el Código Abierto ideal, cuando el producto no está vinculado a una empresa comercial específica y existe de forma independiente. Esperamos que la experiencia sea exitosa, y los próximos lanzamientos ya serán realizados por empleados de otras compañías, de las cuales tenemos comisionados: Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo, etc.


La popularización de la solución, como en el caso del devlist, es una contribución no solo al proyecto, sino también a usted mismo. Tales cosas están en Google y afectan las decisiones de contratación. Además, esta es una forma de posponer el código por un tiempo y hacer algo interesante, pero no menos útil.

Pasamos a la pregunta principal: ¿por qué vale la pena participar en proyectos de código abierto?


No pararé de repetir: la participación en Open Source es su rápido crecimiento. Según mis observaciones, son aproximadamente tres años, si no más, en comparación con el desarrollo aplicado. Esta es tu oportunidad en una entrevista para sorprender a tu oponente con la frase "Vi esto, sé exactamente cómo funciona, ¡pero te equivocas!" - Hice esto dos veces, la experiencia es inolvidable.

Cualquier buen programador debe estar atento a las tendencias. Open Source es la tendencia más prometedora de nuestro tiempo en el desarrollo de software. La participación en esta tendencia ofrece una garantía de respeto por parte de sus colegas (en este momento) y cierta estabilidad, garantías financieras (en el futuro).


Muchas compañías no tienen tantos Open Source, como comúnmente se piensa. Muchas empresas buscan empleados fundamentalmente con experiencia en Código Abierto, o para un proyecto específico a tiempo completo. Es importante que las empresas tengan experiencia interna en el proyecto, para poder influir en su desarrollo. Por ejemplo, una empresa puede pedirle que agregue seguridad a un producto o repare un error que solo existe en su producción. Y hágalo rápidamente, no cuando la comunidad esté de acuerdo. Si tiene experiencia trabajando en Open Source o en un proyecto específico, esta será una ventaja competitiva para usted cuando contrate o continúe trabajando en su empresa.

Como evidencia, nuestro equipo, que está cortando el código abierto en Sberbank Technologies, tiene vacantes extremadamente interesantes ( MSK y SPB ) y Apache Ignite no es el único producto que estamos finalizando.



Espero que todos estén interesados, y muchos pensarán en participar en el movimiento Open Source, y aquellos que ya lo hayan pensado pasarán a acciones concretas.

Ps Para aquellos que les gusta el sonido cálido y de tubo, hay disponible una versión de audio de "Sin categoría".