Copyright © 2014 Eric S. Raymond
Historique des Revisions | ||
---|---|---|
Revision 1.2 | 2014-11-30 | esr |
Nouvelle section sur le fait d'etre original. | ||
Revision 1.1 | 2014-11-23 | esr |
Incorporation de feedbacks de G+, inclusion d'une bonne suggestion de Peter da Silva et John D. Bell. | ||
Revision 1.0 | 2014-11-21 | esr |
Version initiale. |
Table des matieres
Le “hacking” dont on va parler dans ce document est particulierement lié a la programmation dans un environnement open-source. Si vous pensez que le “hacking” a quelque chose a voir avec le crime informatique ou le cassage de mesures de sécurité et que vous etes venu pour cela, vous pouvez partir maintenant. Il n'y a rien pour vous ici.
Le hacking est principalement[1] un style de programmation, et suivre les recommandations de ce document peut etre un bon moyen d'acquérir des connaissances générales en programmation. Il n'est pas garanti que cela fonctionne pour tout le monde; cela semble fonctionner pour ceux qui commencent avec un talent en programmation au dessus de la moyenne avec un niveau de flexibilité mentale minimal. Les personnes qui apprennent correctement ce style ont tendance a devenir généralistes avec des qualifications qui ne sont pas fortement liées a une application ou a un langage particulier. .
Notez que l'on peut faire du hacking sans etre un hacker. Le “Hacking”, de façon générale, est une description de méthodes et de style; etre “hacker” signifie que vous hackez,
et etes aussi attaché a une culture particuliere ou tradition historique qui utilise cette méthode.
Concretement, “hacker” est un honneur discerné par d'autres hackers.
Le Hacking n'a pas suffisamment d'appartenance formelle pour etre une méthodologie complete dans le sens ou le terme est utilisé un ingénierie logicielle, mais il a quelque caractéristiques qui ont tendance a le mettre a part des autres styles de programmation.
Apprendre a composer de la musique a trois étapes. D'abord vous devez apprendre les techniques mécaniques basiques d'un instrument — placer les doigts et jouer. Ensuite vous devez entrainer vos oreilles a comprendre le modeles musicaux. Enfin, vous devez apprendre a recombiner les modeles musicaux en créations originales. Le hacking est similaire. L'équivalent de placer les doigts en hacking est d'apprendre le potentiel des langages de programmation, et les mécaniques d'utilisation d'éditeurs de texte, interpréteur, et compilateurs. (Si vous ne comprenez pas ces termes, allez voir The Unix and Internet Fundamentals HOWTO.) On ne couvrira pas ces mécaniques puisqu'elles varient beaucoup selon le langage utilisé. Des tutoriels pour tous les langages que vous voulez utiliser sont disponibles sur le web, utilisez un moteur de recherche.
L'équivalent de jouer des échelles en musique est d'écrire des petits programmes, seul. Malheureusement, jouer des échelles (a) ne vous apprend rien sur la musique, et (b) en ennuyant à mourir. De la même manière, écrire des programmes jouets ne vous en apprend pas beaucoup sur le hacking , et (b) va vous démotiver si le programme ne résoud pas un problème immédiat. La plupart des instructions de programmation jouent des échelles et des stops. Cependant, cela tend à créer des codeurs nuls pour collaborer ensembles et qui ont l'équivalent de pas d'oreilles pour la musique — un mauvais sentiment pour le design logiciel.
Pour vous entrainer, commencez petit. Si possible, commencez par le cycle hacking incrémental comme exercice sur des petits programmes ou scripts, 10-50 lignes. Ils peuvent être difficiles à trouver, comme la plupart des programmes peu importe leut type sont plus grands que ça. La plupart des petits programmes de ce type sont des scripts shell, Perl, Python ou TCL; ce sont donc des modèles de ce type à trouver sur le net.
Lorsque vous avez fait ce cycle hacking incremental sur plusieurs petits programmes (ou si vous êtes trop malchanceux pour trouver des petits programmes), essayez le sur des programmes un peu plus gros. Regardez les codes qui font entre 100-500 lignes.
Lorsque vous maîtrisez ce niveau, augmentez la magnitude, 1000-5000 lignes. Une fois que vous maîtrisez le niveau 1K-5K, vous serez arrivé au maximum des possibilités de ce que peut habituellement faire un programmeur avancé.
Avant ou au niveau du 1K-5K, vous devriez parfois sentir un besoin de changer la structure ou l'organisation d'un programme, pas juste ces capacités.
Vous pourriez penser “ce code est dégueulasse” et à avoir envie de le rendre plus joli.
Lorsque ça arrive, retenez le. C'est votre sens du design qui se réveille. Ne vous precipitez pas pour changer d'autres fonctionnalités. Au lieu de ça, commencez par explorer le programme dont vous avez envie de changer la structure. C'est peut-être maintenant le bon moment pour essayer de lire tout le code, mais ce n'est pas un problème si vous n'y arrivez pas;
la plupart des programmes sont juste trop gros et confus pour les avaler d'un coup. Essayez simplement de vous accrocher pour savoir ce qu'il vous faut pour y voir plus clair.
Vous entrez maintenant dans une partie intermediaire dans votre apprentissage du hacking.
Cela implique que vous ne changerez plus beaucoup de choses visibles a la surface mais vous ferez plutot ce que l'on appelle le refactoring — reorganiser le code pour le rendre plus propre et trouver une meilleure architecture.
(mieux cacher les données, resserer les liens des interfaces entre différentes parties,
des séparations plus fonctionnelles entre modules).
Une fois que votre sens du design (l'équivalent de votre oreille musicale) est actif, vous allez remarquer que vous essaierez de refactorer tous les programmes sur lesquels vous travaillez au bout de la troisieme ou quatrieme fois du cycle hacking incremental.
En fait, c'est exactement comme ca que les hackers compétents apprenent le code des gros programmes — en refactorant et réecrivant jusqu'a comprendre le programme. Vous faites de petits changements pour comprendre comment faire les grands changements.
Si vous réusissez a la faire avec succes pour quelques systemes, vous ne deviendrez pas juste un bon programmeur, vous serez en train de devenir quelqu'un d'encore meilleur: un architecte logiciel, qui peut faire des designs originaux sur des gros systemes.
C'est la seule facon que je connaisse pour entrainer son sens du design.
Dans mon analogie avec la musique, j'ai dit que vous auriez peut-etre besoin d'apprendre comment recombiner des modeles musicaux (que vous avez appris en écoutant la musique et en pratiquant) en compositions originales. J'ai choisi cette facon de decrire la créativite avec précaution,
car elle s'applique aux logiciels encore plus que pour la musique.
Avant d'avoir lu et absorbé la lecon de beaucoup de code,
vous n'aurez probablement pas dans votre tete le modele dont vous avez besoin pour etre créatif sur des échelles plus grandes. Un des buts de ce cycle hacking incremental est de vous immerger suffisamment dans le code — a complexité grandissante — avec des circonstances vous permettant de rester motivé et de continuer.
Peut-etre que vous dirigerez des projets de groupe. Vous n'avez pas a vous depecher pour cela; si vous laissez a vos compétences le temps de grandir, votre premiere composition originale ne pourra etre que meilleure. En contribuant a des projets open source vous apprendrez les compétences (ainsi que votre communication) nécessaires pour lancer vos propres projets.
[1] Il est possible de hacker d'autres choses que les logiciels, et des gens le font. Mais le terme “hacking” est venu des gens qui travaillaient avec les logiciels et reste dont lie a cela. L'auteur n'est pas non plus qualifié pour écrire sur ces autres sujets.
[2] Dans le passé, les personnes hackaient avec des codes fermés, quand ils le pouvaient, parce-qu'il n'y avait pas d'alternatives. Les choses ont changées en mieux.
[3] Plus ou moins avant 1983 l'association entre hacking et Unix était moins forte, mais les détails sur ces changements ne sont maintenant qu'importants pour les historiens.