Clairement. S'interfacer sur une base de code existante sans casser ni réécrire des pans entiers c'est bien plus délicat qu'avancer sur son petit projet avec son code qu'on connait bien.
Il y a en effet plein d'avantages à participer à des projets open-source (le libre reprend les mêmes bénéfices et en rajoute d'autres) :
travailler avec des personnes d'horizons différents (langues, cultures etc.)
apprentissage de bonnes pratiques : intégration continue, formatage, découplage, nommage, savoir lire et écrie une doc etc.
les premières PR, je m'en souviens : entre les "git squash" pour avoir des commits les plus propres, les tests cassés et corrections diverses... ça pique mais pour la bonne cause.
argumentation : soit votre fonctionnalité n'intéresse à priori personne soit votre implémentation est discutable... apprendre à défendre son point de vue (et dans la langue de Shakespeare) c'est la base.
écouter et se remettre en question. On peut vite avoir le nez dans le guidon et quand on propose un patch sur lequel on a passé des heures pour qu'au final on nous dise : c'est de la merde... ça nécessite de travailler pas mal de qualités : humilité, self contrôle etc.
avoir une vision d'ensemble. Souvent, en dehors du petit bugfix dans son coin, quand on participe à un projet, même 1 ligne de code produite peut nécessiter de bonnes capacités d'abstraction avant d'être produite.
[^] # Re: Argument supplémentaire
Posté par mothsART . En réponse au journal Du chemin à emprunter pour les développeurs débutants vers un premier emploi.... Évalué à 7.
Clairement. S'interfacer sur une base de code existante sans casser ni réécrire des pans entiers c'est bien plus délicat qu'avancer sur son petit projet avec son code qu'on connait bien.
Il y a en effet plein d'avantages à participer à des projets open-source (le libre reprend les mêmes bénéfices et en rajoute d'autres) :