Par Jimmy Song
Si vous êtes développeur et que vous possédez des bitcoins, contribuer à Bitcoin Core est l’une des meilleures initiatives que vous puissiez prendre pour soutenir votre investissement. Dans cet article, je vais tenter de vous expliquer, étape par étape, comment vous pouvez apporter votre pierre à l’édifice.
Ainsi donc vous souhaitez devenir « Core Developer »…
Avant d’entrer dans le vif du sujet, quelques mises au point :
D’abord et avant tout, sachez que Bitcoin Core est une méritocratie. En tant que nouveau venu ne vous attendez pas à ce que l’on intègre votre proposition radicale de modification du proof-of-work dans la prochaine version du logiciel. Comme toute méritocratie, vous commencerez tout en bas et vous devrez bâtir patiemment votre réputation.
La bonne nouvelle c’est qu’on se moque de vos antécédents. Vous pouvez avoir 14 ans et vivre en Inde ou avoir 45 ans et être PDG d’une entreprise du classement Fortune 500, la seule chose qui compte c’est qualité de votre travail.
La mauvaise nouvelle c’est que vous devez être prêt à laisser votre ego de côté. Personne ne se soucie de vos années d’expérience ou de vos idées géniales pour améliorer Bitcoin. La qualité de votre code, de vos revues, tests et documents, c’est tout ce qui compte.
Ensuite, vous devez adapter vos attentes à vos capacités. Les développeurs les plus réputés comme Pieter Wuille, Cory Fields et Gregory Maxwell ont gagné le respect de leurs pairs après de nombreuses années de sang, de sueur et de larmes. Que l’on ait accepté votre « pull request » qui corrige une faute d’orthographe ne vous fera pas accéder au niveau de respect de Pieter Wuille. Un travail sérieux vous apportera la reconnaissance et le respect seulement si vous le soutenez dans la durée.
Enfin sachez que la route est dure. Que vous soyez le principal développeur de la société X ne fera pas nécessairement de vous un bon développeur de Core. Il y a plusieurs raisons à cela. De façon générale, votre travail doit répondre à des normes de test, de documentation et d’examen de code d’un niveau rarement observé même dans des entreprises techniques très compétentes.
Ceci dit, si vous êtes humble, motivé et que vous recherchez l’excellence, contribuer à Core fera de vous un meilleur développeur, examinateur et testeur de code.
Prérequis
Certaines connaissances et compétences sont indispensables pour commencer.
Bitcoin Core est codé principalement dans deux langages : C ++ et Python . Il est probable que vous aurez à en connaitre au moins un des deux si vous souhaitez y contribuer.
Le contrôle de la source est géré par Git. Au minimum, vous devez savoir comment récupérer du code, comment créer une branche et comment la modifier. Si vous testez le code de quelqu’un d’autre, vous devriez également savoir comment ajouter plusieurs référentiels à votre environnement de développement local.
Toutes les modifications apportées à Core sont intégrées par une « pull request » [1] sur Github, donc vous aurez besoin d’un compte GitHub.
Enfin, vous devrez savoir comment installer et supprimer des paquets sur votre plateforme […].
Se lancer
La première chose que vous aurez à faire lorsque vous commencez, c’est de lire des documents. Le README et les directives des contributions en priorité.
Ensuite, accédez au répertoire doc et lisez son README. Toute la documentation du répertoire DOC est décrite dans ce README, et vous pouvez vous y référer si vous vous perdez ou que vous ne comprenez pas quelque chose.
Notez que vous n’avez pas à tout comprendre dans chaque document que j’ai indiqué. Il y a beaucoup de gens très serviables qui pourront vous aider sur IRC , StackExchange et Slack si vous êtes confronté à une difficulté.
Partir de la source
Maintenant que vous connaissez les bases, commencez par la source. Tout d’abord, clonez le répertoire bitcoin Git :
Git clone git@github.com: bitcoin / bitcoin
L’étape suivante consiste à configurer votre environnement de développement. Cela dépend fortement de la plateforme sur laquelle vous êtes, mais compiler c’est quelque chose que vous aurez à faire fréquemment.
En outre vous devrez exécuter tous les tests d’intégration, alors assurez-vous d’allumer l’interface graphique et le ZMQ lorsque vous exécutez les instructions ci-dessous :
Lorsque vous configurez votre environnement, si quelque chose ne fonctionne pas, essayez Google tout d’abord. Comme mentionné précédemment, IRC, StackExchange et Slack sont de bonnes ressources, mais évitez de faire perdre du temps à tout le monde avec des questions trop basiques.
Tester
Maintenant que vous avez tout compilé, la prochaine étape consiste à tester le logiciel. Heureusement Bitcoin Core possède une variété de tests unitaire et d’intégration pour vérifier que ce que vous venez de compiler fonctionne correctement.
Tout d’abord, exécutez les tests unitaires que vous trouverez ici. Les tests unitaires sont compilés avec tout le reste, donc tout ce que vous devez faire est d’exécuter le binaire qui en résulte. Vérifiez que tous les tests sont réussis. S’ils ne le sont pas, des instructions ont probablement été manquées.
Si tous vos tests unitaires réussissent, exécutez les tests d’intégration situés ici. Vous pouvez exécuter des tests étendus. Le test de pruning en particulier prend beaucoup de temps, vous pourrez l’exclure lors de l’exécution des futurs tests d’intégration.
Encore une fois, vérifiez que tous les tests sont réussis […]. Si quelque chose ne passe pas c’est que vous avez probablement manqué quelques instructions. Parfois certains tests d’intégration peuvent être fluctuants en fonction de la RAM et du CPU.
Catégories de contributions
Maintenant que vous avez configuré votre système, vous pouvez commencer à apporter votre contribution !
On pourrait croire que contribuer c’est ajouter un tas de lignes de code, envoyer un « pull request » et obtenir la gloire, mais en réalité l’essentiel du travail consiste à évaluer et à tester le code des autres. Cette tâche est cependant formatrice car elle aide à comprendre les étapes de l’intégration d’un « pull request » :
1. Quelqu’un effectue une modification et soumet le code via une « demande de traction » (« pull request ») ;
2. Un certain nombre de personnes examinent le code ;
3. Un certain nombre de personnes testent le code ;
4. Lorsque le code a suffisamment été examiné et testé, un administrateur l’intègre – seule quelques personnes ont la possibilité de le faire.
La plupart des gens pensent contribuer à un projet open source en produisant du code, mais en réalité les tests et les examens sont encore plus importants pour le succès du projet. Dans de nombreux projets, le manque d’examen et de test provoque souvent des failles de sécurité. Nous l’avons vu récemment encore avec le bug de Parity sur Ethereum.
L’examen et le test sont aussi essentiels car il est souvent difficile pour un seul individu de prévoir tous les cas de figure. Le fait de soumettre le code à de nombreux yeux et à de nombreux tests permet de débusquer les failles les plus imperceptibles.
Enfin, si la relecture du code et les tests sont non seulement bons pour le projet, ils sont également bons pour vous ! Ils vous forceront à en apprendre davantage sur la base du code et vous en donneront une compréhension beaucoup plus fine de l’ensemble que ne le ferait l’écriture du code.
Pour commencer
Si vous voulez vous habituer au processus de contribution, il ne faudrait pas commencer par soumettre un grand nombre de « pull request ». En tant que nouveau développeur sans réputation, le meilleur choix c’est de commencer par examiner et tester le travail d’autrui. L’examen et le test ont tendance à être un passage obligé, mais si vous y contribuez efficacement ils vous permettront de gagner en réputation.
Notons ici que si Greg Maxwell a une si bonne réputation parmi les développeurs, c’est qu’il est vraiment performant quand il s’agit d’évaluer et de tester. Il a un talent hors du commun pour débusquer les failles et il examine et teste beaucoup plus de code qu’il n’en écrit. Je vous promets que vous l’apprécierez encore plus quand vous aurez vous-même examiné et testé du code.
Le code est généralement écrit une seule fois, mais il est lu une dizaine de fois. L’examen est une étape fondamentale car il révèle si le code est lisible ou non. La règle générale est que, pour chaque « pull request » que vous soumettez, vous devriez en examiner trois environ, et plus encore si vous débutez.
La révision du code
En règle générale il est très difficile d’effectuer une relecture efficace quand on ne comprend pas à quoi sert le code. Vous ne pourrez pas fournir un bon compte-rendu sur un « pull request » tant ce que vous comprenez pas son action. Comme on dit dans le codage, l’écriture c’est beaucoup plus facile que la lecture. Alors prenez le temps de bien comprendre le code.
Souvent, pour comprendre un « pull request », vous devrez vous intéresser aux fonctions et aux méthodes utilisées et examiner attentivement le contexte du code. Si vous vous égarez et que la personne dont vous révisez le code est sur IRC, adressez-vous à elle directement. La plupart du temps les codeurs apprécient beaucoup les examinateurs et seront heureux de vous aider.
Tout comme la critique d’un article ou d’un livre, il y a beaucoup de choses à considérer :
– Le code fait-il ce qu’il devrait faire ?
– Le code est-il suffisamment testé ?
– Est-ce que tous les commentaires autour du code sont utiles et précis ?
– Le code est-il clair et facile à modifier ultérieurement ?
En règle générale, si vous n’êtes pas d’accord avec quelque chose, il est préférable de dire que vous ne comprenez pas plutôt que de vous lancer dans un débat. L’empathie et le tact vous seront très utiles ici. C’est un peu comme si vous parliez du bébé de quelqu’un. Posez des questions et soyez bienveillant, au moins au début. Souvent les codeurs ne vous connaissent pas et ignorent vos intentions. Faites clairement la différence entre problème de style mineur et un problème majeur qui pourrait provoquer une défaillance. Il est préférable de ressembler à un étudiant qui essaie de comprendre en quoi consiste l’amélioration qu’à un inquisiteur.
Une fois que vous êtes vraiment sûr d’avoir compris ce que le code essaie de faire, vous pouvez donner votre avis. Mais tant que vous n’avez pas acquis une certaine réputation, évitez tout commentaire qui pourrait être perçu négativement.
Lorsque vous avez terminé d’examiner le code, faites un commentaire sur le « pull request » avec la codification indiquée ici. Si vous souhaitez rejeter le PR, conversez tout d’abord avec l’auteur, posez des questions et soyez positif. Si vraiment c’est un mauvais PR, conversez avec des personnes plus expérimentées pour vous en assurer.
Comment effectuer un test
Afin de d’effectuer correctement vos tests, vous devrez télécharger le code à partir du « pull request », compiler à nouveau et exécuter les tests. Si vous avez moyen de tester manuellement les fonctionnalités, tant mieux, mais cela n’est pas indispensable.
La plupart du temps, le « pull request » comprendra un ou plusieurs tests. Si le codeur n’en a pas fourni, essayez de comprendre pourquoi – les réfractaires ont parfois des raisons évidentes. Si vous pensez qu’il devrait y avoir un test, vous pouvez le préciser dans vos commentaires. Mieux encore, écrivez le test vous-même et indiquez à l’auteur où on peut le trouver ! C’est une excellente façon de stimuler la bonne volonté de la personne dont vous révisez le code.
Votre travail en tant que testeur est de vous assurer que les tests sont réussis et qu’ils couvrent suffisamment les fonctionnalités introduites. Un commentaire critique utile pourrait être formulé de la façon suivante : « Ce serait bien si telle situation pouvait être couverte par un test qui ferait ceci et cela ».
Après le test, n’oubliez pas de précisez dans le « pull request » que vous avez testé.
Pour de meilleurs « pull requests »
Finalement, vous arriverez à un point où vous vous sentirez suffisamment à l’aise pour soumettre vos propres « pull requests ». Un PR peut porter sur n’importe quoi. Du simple ajout de documentation à une fonctionnalité critique pour le consensus, quelle que soit la modification, la clé pour faire de bons PR est de faciliter la compréhension et l’examen.
À cette fin, évitez d’affliger vos lecteurs avec un « commit » unique comportant 3000 lignes de modifications. Fractionnez ces changements en des commits de moins de 300 lignes (voire même moins de 100 !) faciles à examiner et regroupés de façon appropriée. À titre d’exemple, vous pourriez mettre les modifications de mise en forme dans un seul commit, les modifications de fond dans un autre et les déplacements de gros de blocs de code dans un autre encore.
Prenez soin d’expliquer précisément, pour chaque commit, quelle a été votre démarche et ce que vous avez fait. Je n’insisterai jamais suffisamment sur ce point : donnez-vous du mal pour rendre votre PR facile à comprendre ! Si vous ne le faites pas, personne n’examinera votre code et vous n’aurez aucun retour sur votre travail.
Lorsque des évaluateurs commentent votre PR ou proposent des changements, essayez de comprendre quel est le raisonnement. Si vous ne comprenez pas, contactez-les pour éclaircir leur requête. Si vous êtes d’accord, faites les changements appropriés et informez-les. Dans le cas contraire, dialoguez avec franchise et tact et essayez de voir comment vous pouvez obtenir leurs ACK [3].
Quelques Idées de PR pour débuter
Voici quelques idées de « pull requests » que vous pourriez entreprendre pour commencer (rappelez-vous, évaluez trois fois plus de PR que vous n’en soumettez !) :
– Produire une documentation claire, en particulier sur les configurations ;
– Ecrire des tests unitaires ou des tests d’intégration pour quelque chose qui n’a pas encore été testé ;
– Rédiger des commentaires dans un code qui n’en contient pas pour aider les autres à trouver leur chemin.
Conclusion
Les pratiques de développement en vigueur pour Bitcoin Core ne sont souvent pas suivies dans d’autres environnements. La plupart des nouveaux venus trouvent le processus excessivement restrictif et contraignant. Je vous assure que nous avons de bonnes raisons de respecter ces procédures.
N’oubliez pas d’être courtois, bienveillant et discret. Venez avec une attitude humble et un désir d’apprendre et cela vous permettra non seulement de devenir un meilleur développeur, mais aussi une force positive dans la communauté Bitcoin.
Source : medium.com
[1] Avertissement : ce texte est une traduction non-professionnelle d’un article de Jimmy Song publié le 31 juillet 2017. En cas de doute veuillez consulter le texte original.
[2] Demande d’intégration.
[3] ACK = J’ai testé le code et je suis d’accord pour qu’il soit intégré.
