Es cierto que todo este tiempo, algo permaneció sin cambios. Es decir, el código se envía a una lista de correo (o varias listas), y allí se revisa y comenta hasta que se considera que está listo para su inclusión en el kernel de Linux. Pero a pesar de que este proceso de trabajar con código se ha utilizado con éxito durante muchos años, ha sido constantemente criticado. Por ejemplo, este
Un artículo reciente de Sara Novotny de Microsoft hizo mucho ruido en Internet. Ese artículo decía que las técnicas de colaboración de código utilizadas en el desarrollo del kernel de Linux están desactualizadas. Dice que si la comunidad de desarrolladores de Linux quiere atraer a jóvenes profesionales a sus filas, sería bueno reemplazar estos métodos con algo más moderno. En el debate en torno a estas ideas, sus defensores y oponentes chocaron.
Creo que mi puesto me permite aportar algunas ideas sobre el desarrollo del kernel de Linux. Durante casi diez años, he estado escribiendo código para Linux y otros proyectos que están organizados de manera similar. Cuando estaba en Red Hat, contribuí con el código de infraestructura del kernel x86, el hipervisor KVM y el código del emulador QEMU, y el código del hipervisor Xen. También participé en el desarrollo de otros proyectos. No hice mucho Linux durante aproximadamente 7 años, pero solo porque dediqué mi tiempo a trabajar en el marco C ++ Seastar y en la base de datos ScyllaDB... Ambos proyectos se desarrollaron utilizando una metodología muy similar a la utilizada en el desarrollo de Linux. Ahora trabajo como ingeniero principal en Datadog, una empresa donde los procesos de desarrollo de software son casi exactamente opuestos a los que se utilizan en Linux. Esto está mucho más cerca de cómo se organiza el desarrollo en otras empresas web.
Entonces, ¿de qué lado estoy? Permítanme aclarar de inmediato que no me gusta el proceso de desarrollo de Linux. Estoy bastante seguro de que esto no solo es una barrera para los nuevos desarrolladores, sino también una barrera para la alta productividad en su código (y no se trata de correo electrónico). Esta es la fuente de sentimientos negativos que experimentan los desarrolladores. Y no voy a seguir ese modelo para ningún proyecto en el que tenga el derecho exclusivo de tomar decisiones sobre cómo se organizará el trabajo.
Pero al mismo tiempo, parece que muchos críticos del proceso de desarrollo de Linux creen que el hecho de que sus defensores luchen tan ferozmente por él es solo una consecuencia del hecho de que la comunidad Linux está llena de personas mayores que tienen un dominio absoluto sobre la tradición y no dispuesto a cambiar bajo ningún pretexto. Este no es el caso (aunque estoy seguro de que hay personas así en la comunidad Linux). El proceso de desarrollo del kernel de Linux aporta algunos beneficios únicos e importantes a sus usuarios. Si aplica los mismos principios a cualquier otro proyecto, dicho proyecto solo se beneficiará de él.
Cualquier otra herramienta, además del correo electrónico, dicta a quienes las utilizan esquemas de trabajo bastante rígidos, privando a Linux de tal ventaja. Y las listas de correo son solo un mecanismo notable que atrae la atención de los debatientes. Necesitamos herramientas que puedan reducir las barreras de entrada para los desarrolladores de Linux. Herramientas que pueden corregir las fallas en el proceso de desarrollo. Uno que permite que diferentes organizaciones reconozcan las fortalezas de la organización de desarrollo de Linux. Herramientas como estas realmente pueden marcar la diferencia para toda la industria del desarrollo de software.
Hay muchos de estos mecanismos que son de gran beneficio. Para no prolongar nuestra conversación, me centraré en uno de ellos, que considero el más importante. Haré todo lo posible para revelar su esencia y hablar sobre por qué, a pesar de sus puntos fuertes, causa tantas emociones negativas en los desarrolladores. También te diré por qué, por un lado, puede beneficiar a otros proyectos y, por otro, por qué es increíblemente importante para Linux.
Confirmar mensajes y parches
En el mundo del desarrollo del kernel de Linux, existe una regla: el código destinado a ser incluido en el kernel debe dividirse en parches separados. Cada uno de ellos debe resolver un solo problema. Se debe preparar un mensaje de confirmación significativo para cada parche. A menudo sucede que estos mensajes son más largos que el código que describen.
Este es un excelente ejemplo de lo que generalmente falta en otros proyectos. La mayoría de los mensajes de confirmación que he visto en proyectos modernos en GitHub se ven algo así como "cambios a partir del 25 de agosto", o un poco (pero solo un poco) mejor, como "implementación de la función X". Si alguien necesita ver un código como este en el futuro, no será fácil para ellos averiguar por qué se hicieron tales cambios en el código. Algunos de los errores que corrigen estos commits pueden ser sutiles. Si no sabe exactamente cómo se solucionaron esos errores, pueden volver fácilmente al proyecto. Mientras leo el breve mensaje de confirmación sin sentido, es posible que no esté al tanto de las circunstancias bajo las cuales se descubrió el error.
He aquí un pequeño ejemplo. Eche un vistazo al compromiso con el kernel de Linuxhecho por mi buen amigo Johann Weiner. Es fácil para mí imaginar cómo, en otro proyecto, un mensaje a una confirmación similar se vería como "eliminar advertencias". Y cuando leo el mensaje del compromiso discutido aquí, aprendo por qué es posible, sin dañar el proyecto, deshacerse de estas advertencias, sobre las circunstancias bajo las cuales esto, de hecho, no conducirá a nada malo, y sobre qué Se deben seguir las reglas si algún día se decide cambiar este código.
Estoy seguro de que hay personas en muchas organizaciones que hacen esto. Pero cuando se trabaja en el kernel de Linux, todos los involucrados en este negocio deben hacerlo. Por lo tanto, estoy bastante seguro de que al leer el mensaje de confirmación, comprenderé todo lo que hay que comprender sobre los cambios de código correspondientes. Si estamos hablando de un error, entonces aprenderé sobre en qué sistemas se manifestó, en qué condiciones ocurrió, por qué no afectó a otros sistemas de ninguna manera y a qué se debe prestar atención para que este error no vuelva al proyecto.
Este tipo de trabajo es muy deseable en cualquier organización. Esto hace que sea más fácil para otras personas (y para el desarrollador mismo, cuando recurre a su código después de un tiempo) comprender las razones para realizar cambios en el código, comprender por qué el código funciona de la manera en que lo hace. Esto facilita que los nuevos programadores conozcan el proyecto. Esto resuelve el problema de devolver errores antiguos, reduce el peligro de que algún código, aparentemente no relacionado con el en cuestión, pueda romper algo en él.
En otros proyectos, esto es "muy deseable". Pero en Linux es absolutamente necesario por dos razones:
- Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
- (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .
Los backports no suelen ser un problema para las empresas online modernas que no necesitan mantener varias líneas de productos paralelas. Crean algo, se lo pasan a los usuarios y ahí es donde termina. Pero cuando entran en juego los backports, las cosas se complican más. Es posible que el desarrollador (probablemente no el autor del programa) deba decidir cómo adaptar ligeramente el código a una base de código más antigua que sea ligeramente diferente de la moderna. Y la solución que minimiza el riesgo a menudo puede ser (y a menudo lo es) una que consiste en crear un parche solo para implementar una cierta parte de un gran conjunto de cambios. Imagine una confirmación de 2000 líneas que contiene 5 líneas de código para corregir un error. Además, imagine que este error ocurrió después de refactorizar la API. Qué elegirías:¿Preparando un backport basado en un gran conjunto de cambios, o basado en parches bien documentados, bien documentados y desglosados? Yo, como persona que hizo innumerables backports, ya sé cómo respondería a esa pregunta.
Bueno, con o sin backports, los proyectos tienen que pagar un alto precio por los beneficios de estar organizados de esta manera cuando hay un gran énfasis en documentar cuidadosamente los cambios. Ahora, el programador debe ocuparse no solo del código, sino también de cómo reorganizarlo y adaptarlo a las reglas de trabajo del proyecto.
Algunas de estas refactorizaciones de código son simples. Digamos que estamos hablando de usar el comando git add -p y elegir qué se incluirá en un lote de cambios. Las cosas se complican un poco más si el programador se enfrenta a dependencias circulares entre fragmentos de código individuales. Imagine una función que devuelve un objeto de un tipo que se agregará al proyecto después de agregarle esta función. Para hacer frente a esta situación, deberá usar código que, como resultado, no entrará en el proyecto terminado, sino que solo desempeñará el papel de una solución temporal.
Todo esto agrega un dolor de cabeza a los programadores, pero no se puede decir que tales tareas sean completamente irresolubles. Suponga que, con precisión quirúrgica, ha dividido todo lo que hace en fragmentos que son fáciles y convenientes de usar. Los problemas reales comienzan después de que otros programadores comienzan a mirar su código. La revisión del código en cualquier organización es muy importante. Los expertos leen el código de otra persona y sugieren (o exigen) cambios.
Suponga que se le pide a un programador que agregue un nuevo parámetro a un determinado método presente en el primer parche de un conjunto de correcciones. Y supongamos también que este método se utiliza en todos los parches posteriores.
Esto significa que el programador tendrá que volver al primer parche y agregar un nuevo parámetro al método. Después de eso, los siguientes parches ya no se pueden aplicar. Por lo tanto, el programador no solo tendrá que preguntarse por qué es así, sino que también deberá corregir manualmente todos los errores. Si todos los parches individuales se probaron anteriormente, ahora los resultados de estas pruebas están desactualizados y los parches deberán probarse nuevamente.
Reorganizar el trabajo es un pequeño problema. Pero reelaborar lo que ya se ha hecho es un problema mucho más grave.
Esto es lo que me gustaría transmitir a la comunidad de desarrolladores de Linux y a aquellos que están relacionados con esta comunidad: todo esto, por supuesto, es bastante factible. Pero si esto no es una barrera de entrada para los jóvenes profesionales, entonces ni siquiera sé qué se puede llamar una "barrera de entrada". La necesidad de gastar su tiempo, esfuerzo, nervios y recursos informáticos en reorganizar, reescribir y reelaborar lo que ya se ha hecho claramente no es lo que los programadores buscan. En este sentido, me encontré con una idea que periódicamente aparece de esta forma: "... pero un buen programador no tendrá ningún problema con esto". También se expresa así: "pero enseña a los programadores un cierto estilo de pensamiento, exactamente el tipo que debería tener un buen programador". Este tipo de razonamiento me parece poco sincero e inútil. En efecto:Acabo de enumerar todos los puntos fuertes de este método, pero también encuentro que todas estas refactorizaciones de código son tareas engorrosas y tediosas. Se puede comparar a limpiar un apartamento. Digamos que alguien dice que es muy bueno que la casa se mantenga limpia (estoy de acuerdo con eso). La misma persona es bastante capaz de aspirar suelos (yo puedo), pero a menudo no lo hace. La razón de esto es simple: tiene otras cosas más importantes que hacer. Por ejemplo, es por eso que estoy increíblemente feliz de tener un robot aspirador Roomba. Esto me permitió disfrutar de la limpieza y al mismo tiempo no estar involucrado en poner las cosas en orden. Lo que me lleva a mi siguiente pensamiento, dirigido a personas fuera del mundo de Linux.que todas estas refactorizaciones de código son tareas engorrosas y tediosas. Se puede comparar a limpiar un apartamento. Digamos que alguien dice que es muy bueno que la casa se mantenga limpia (estoy de acuerdo con eso). La misma persona es bastante capaz de aspirar suelos (yo puedo), pero a menudo no lo hace. La razón de esto es simple: tiene otras cosas más importantes que hacer. Por ejemplo, es por eso que estoy increíblemente feliz de tener un robot aspirador Roomba. Esto me permitió disfrutar de la limpieza y al mismo tiempo no tener que ordenar yo mismo. Lo que me lleva a mi siguiente pensamiento, dirigido a personas fuera del mundo de Linux.que todas estas refactorizaciones de código son tareas engorrosas y tediosas. Se puede comparar a limpiar un apartamento. Digamos que alguien dice que es muy bueno que la casa se mantenga limpia (estoy de acuerdo con eso). La misma persona es bastante capaz de aspirar suelos (yo puedo), pero a menudo no lo hace. La razón de esto es simple: tiene otras cosas más importantes que hacer. Por ejemplo, es por eso que estoy increíblemente feliz de tener un robot aspirador Roomba. Esto me permitió disfrutar de la limpieza y al mismo tiempo no estar involucrado en poner las cosas en orden. Lo que me lleva a mi siguiente pensamiento, dirigido a personas fuera del mundo de Linux.La misma persona es bastante capaz de aspirar suelos (yo puedo), pero a menudo no lo hace. La razón de esto es simple: tiene otras cosas más importantes que hacer. Por ejemplo, es por eso que estoy increíblemente feliz de tener un robot aspirador Roomba. Esto me permitió disfrutar de la limpieza y al mismo tiempo no tener que ordenar yo mismo. Lo que me lleva a mi siguiente pensamiento, dirigido a personas fuera del mundo de Linux.La misma persona es bastante capaz de aspirar suelos (yo puedo), pero a menudo no lo hace. La razón de esto es simple: tiene otras cosas más importantes que hacer. Por ejemplo, es por eso que estoy increíblemente feliz de tener un robot aspirador Roomba. Esta cosa me permitió disfrutar de la limpieza y al mismo tiempo no ordenarme. Lo que me lleva a mi siguiente pensamiento, dirigido a personas fuera del mundo de Linux.dirigido a personas fuera del mundo Linux.dirigido a personas fuera del mundo Linux.
Esto es lo que me gustaría decirles a los que están fuera de la comunidad de Linux: Hay puntos fuertes muy reales en el proceso de desarrollo utilizado para trabajar en Linux. Alguna herramienta no es capaz de hacer frente completamente a la tarea que está funcionando en Linux. GitHub, por ejemplo, hace un gran trabajo en proyectos donde siempre se agrega código nuevo después del código existente. Por supuesto, puede usar el comando git push --force, incluyendo a la fuerza una determinada rama en el repositorio, pero luego los comentarios adjuntos a la confirmación estarán, de hecho, "suspendidos en el aire", y la discusión de esta confirmación no tendrá sentido.
Las herramientas de desarrollo modernas simplifican mucho. Le permiten desencadenar la ejecución de algunas acciones cuando ocurren ciertas condiciones, apoyan la integración continua y los procesos de implementación de proyectos, notifican a los programadores sobre cambios en el código y resuelven muchas otras tareas. Pero ciertamente complican el proceso de descomponer los resultados del trabajo de alguien en pequeñas partes con las que es fácil y conveniente trabajar. El uso de correos electrónicos de texto sin formato complica mucho, pero esta organización del trabajo, debe tenerse en cuenta, no interfiere con la aplicación de procesos de desarrollo que conducen a un objetivo específico.
Incluso si fuera posible evaluar de manera objetiva y precisa cuánto ganaría y perdería el ecosistema Linux (no habría perdido nada) al abandonar el proceso de desarrollo existente, difícilmente cambiaría nada. El hecho es que la situación actual ilustra perfectamente la naturaleza humana, cuando las personas se esfuerzan por preservar lo que anteriormente se ha mostrado muy bien en la práctica.
¿Hay alguna salida a esta situación?
Creo sinceramente que si tuviéramos herramientas a nuestra disposición que pudieran brindar a diferentes organizaciones los mismos beneficios que la comunidad Linux obtiene de su metodología de desarrollo, sería muy beneficioso para todos. Y si tales herramientas existieran, quizás incluso la comunidad de Linux podría reemplazar los correos electrónicos de texto regulares con ellas.
No tengo respuesta a la pregunta de cómo serían estas herramientas. Pero me permitiré arriesgarme y reflexionar un poco sobre ellos:
- Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
- , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
- , , , , - , . , , , . , , , , , , , , , .
-, Linux?
