Comment pratiquer délibérément le génie logiciel?
Je viens de terminer la lecture cet article récent . C'est une lecture très intéressante, et elle soulève d'excellents points. Le point qui m'a particulièrement sauté aux yeux était le suivant:
La différence était dans la façon dont ils ont passé ce temps [égal]. Les joueurs Élite consacraient près de trois fois plus d'heures que les joueurs moyens à une pratique délibérée - le travail inconfortable et méthodique d'étirement de vos capacités.
Cet article (si vous ne voulez pas le lire) traite des joueurs de violon. Bien sûr, étant ingénieur logiciel, mon esprit s'est tourné vers la capacité logicielle. Certes, il y a des individus très naturellement talentueux, mais maintes et maintes fois, ce sont ces gens qui étirent leurs capacités par une pratique délibérée qui deviennent vraiment exceptionnels dans leur métier.
Ma question est - comment procéder pour pratiquer les "échelles" du génie logiciel et de l'informatique? Quand je pratique le piano, je passe plus de temps sur des gammes et moins sur une chanson amusante. Comment puis-je faire de même dans le développement de logiciels?
Pour éviter les premières réponses, je ne pense pas que "travailler sur un projet open source", et des réponses similaires, soit vraiment juste. Bien sûr ... cela peut améliorer vos compétences, mais vous pourriez tout aussi bien rester coincé en vous concentrant sur quelque chose qui n'a pas d'importance pour votre métier dans son ensemble. Il peut devenir l'équivalent d'apprendre "Twinkle Twinkle Little Star" et de ne jamais pouvoir jouer à Chopin.
Donc, encore une fois, je demande - comment suggéreriez-vous que quelqu'un pratique délibérément le génie logiciel?
Il y a une différence entre ce que nous faisons en tant qu'ingénieurs logiciels et ce que ferait un violoniste (ou toute autre chose qui nécessite une pratique physique). Un violoniste passe des heures à pratiquer méthodiquement parce qu'il enseigne à son cerveau des schémas très spécifiques de la façon d'interagir avec un instrument.
La pratique du génie logiciel implique également des schémas d'apprentissage. Plus vous faites de projets, plus vous en apprendrez (espérons-le) sur ce qui fonctionne et ce qui ne fonctionne pas. Il n'y a pas de recette standard pour écrire un excellent logiciel (c'est pourquoi certaines personnes comparent notre profession à un "métier" plutôt qu'à de la science pure). Donc, mon conseil # 1, écrivez du code, puis écrivez plus de code. Et ne pensez pas que si ce sur quoi vous travaillez est amusant, cela ne vous apprend pas autant. Je dis choisir quelque chose qui IS amusant; cela gardera votre intérêt plus longtemps et vous vous amuserez beaucoup plus.
Vous n'êtes pas obligé de rejoindre un projet open source si vous ne le souhaitez pas. Fixez-vous un objectif, quelque chose pourrait vous intéresser et commencez à coder. Vous n'avez même pas besoin de le terminer, alors ne soyez pas déçu si à mi-chemin du projet vous décidez de l'abandonner et de passer à autre chose. Plus important encore, lorsque vous vous éloignez de ce projet, vous devez vous en éloigner avec de meilleures compétences et une meilleure connaissance de la technologie que vous avez utilisée.
Conseil # 2, lisez Programmeur Pragmatique . La principale chose à retenir de ce livre est que, tout comme vous pensez à la façon d'écrire un logiciel, vous devez de temps en temps prendre du recul et revoir votre processus pour penser à écrire un logiciel. Chaque fois que vous travaillez, ne vous contentez pas de le mettre sur une étagère et de passer à autre chose, mais jetez un autre coup d'œil et pensez à des façons dont vous auriez pu mieux le faire. Vous n'avez pas besoin d'aller le refaire, mais en y réfléchissant, vous exercerez votre cerveau pour reconnaître les schémas que j'ai mentionnés dans l'intro.
Conseil n ° 3, parlez à d'autres personnes passionnées par l'écriture de code. Écoutez ce qu'ils ont fait et comment ils ont abordé les choses. Et expliquez-leur ce que vous faites. J'ai peu d'amis au travail et, périodiquement, je me contentais d'entrer dans leur cube et de dessiner rapidement la conception du logiciel sur lequel je travaille. Parfois, ils vont simplement hocher la tête, mais d'autres fois, pourraient-ils dire, eh bien, si vous déplacez cette boîte ici et que vous vous débarrassez de cette classe, vous pourriez vous épargner 2 jours de travail et bénéficier des avantages A, B et C.
Conseil n ° 4, après avoir fait quelques projets et trouvé quelques modèles. Revenez en arrière et lisez des livres comme le célèbre livre du GoF . Si vous avez déjà travaillé, vous a) reconnaîtrez certaines des choses dont les auteurs parlent et b) vous découvrirez différentes façons dont vous auriez pu aborder vos projets.
Conseil n ° 5, continuez toujours à lire et à vous mettre au défi. Ne vous mettez jamais dans le mode maintenant que je connais la technologie X, donc je suis un expert. Peu importe combien vous pensez avoir appris, rappelez-vous simplement qu'il y a infiniment plus à faire pour vous, donc dans le grand schéma des choses, vous ne savez toujours pas grand-chose. Continuez à lire les blogs; apprendre une nouvelle langue. Par exemple, j'ai lu sur F # et la programmation fonctionnelle même si je programme principalement en C++ et j'ai commencé à appliquer des concepts fonctionnels à mon code orienté objet. Dans certains endroits, cela a grandement simplifié l'utilisation de plusieurs threads et la synchronisation des données.
Rien de ce qui précède n'est du génie logiciel. Ce n'est que de la programmation au hasard.
Le génie logiciel (SE) est une discipline d'ingénierie soucieuse d'une approche systématique, rigoureuse et disciplinée de la conception, du développement, de l'exploitation et de la maintenance des logiciels et de l'étude de ces approches; c'est-à-dire l'application de l'ingénierie aux logiciels.
En particulier, les logiciels peuvent être conçus lorsque vous appliquez des techniques d'ingénierie. Pour apprendre de telles techniques, le mieux est d'étudier un Master SE pertinent. Lorsque vous vous enseignez vous-même, vous pouvez en apprendre davantage sur la programmation, mais je ne peux pas imaginer que vous apprenez l'ingénierie par vous-même.
Exemple: le programmeur vient et commence à écrire du code, à optimiser le code, etc. (tout ce qui compte pour un programmeur est du code et rien que du code). Les projets complexes sont souvent en retard, le budget est dépassé jusqu'à quelques ordres de grandeur et le logiciel ne résout pas bien les exigences. Ceci est connu comme une crise logicielle. La réponse à cela est la discipline SE.
SE vient et veut comprendre le domaine du problème comme la première chose. Une approche d'ingénierie est appliquée, en particulier l'ingénierie des exigences (RE) (élicitation des exigences -> analyse des exigences -> spécification des exigences -> validation des exigences).
Le résultat de RE est généralement un ensemble de modèles tels que le modèle contextuel, le modèle comportemental et le modèle de processus métier. À partir de ces modèles, SE comprend le problème commercial et conçoit une solution logicielle.
La conception signifie généralement que SE traduit les modèles d'exigence en architecture système basée sur les composants, puis conçoit la conception des composants pour chaque composant individuellement. Il en résulte une certaine spécification des limites des composants, des interfaces de composants et des classes à partir desquelles composer les composants.
L'étape suivante est quelqu'un qui vient à ces interfaces (généralement générées automatiquement) et crée leur implémentation. Cette personne peut être programmeur. Enfin, SE suit avec la validation du logiciel où tout est testé par rapport à la conception et aux exigences d'origine.
En SE, les projets ont généralement un plan de projet qui permet aux ingénieurs de planifier, contrôler et surveiller les projets. En particulier, les logiciels sont conçus dans les délais, le budget et les spécifications.
Pendant la phase d'implémentation du logiciel, une documentation est produite pour chaque artefact et de nombreux éléments de configuration (CI) sont générés. Ceux-ci doivent être gérés d'une manière ou d'une autre. Habituellement, dans SE, il existe un référentiel SCM (Software Configuration Management) et une gestion des changements. Une autre partie de SE est le processus logiciel (SP), c'est-à-dire RUP, Scrum, DSDM, Crystal, Waterfall, ...
Le SP doit être documenté et rigoureusement suivi comme dans la documentation, sans aucune exception, afin que les résultats soient toujours reproductibles. (ISO 9000). Il s'agit de la qualité du logiciel.
Un autre sujet SE est le logiciel de mesure et d'estimation qui vous permet de mesurer l'efficacité de votre SP, les performances de l'équipe, la taille estimée du projet (LOC - Lignes de code), c'est-à-dire COCOMO, la livraison estimée du projet (jours-homme) et similaires.
Il y a encore beaucoup plus dans SE que cette courte réponse ne le décrit. L'application des approches SE au lieu d'écrire uniquement du code est la façon dont vous pratiquez SE.
Parce que SE est encore un domaine émergent, il arrive que les non-ingénieurs s'appellent eux-mêmes ingénieurs. À moins qu'ils n'appliquent des approches d'ingénierie, ils ne sont que des programmeurs.
Pour plus d'informations, voir Software Engineering par Ian Sommerville et www.ieee.org/www.computer.org. Dans ces ressources, SE est la discipline d'ingénierie. Sur Stack Overflow et dans de nombreuses entreprises, malheureusement, ils empruntent le terme SE et l'utilisent comme autre nom pour la programmation.
Deux choses qui me viennent à l'esprit sont Project Euler et Google AI Challenge . Surtout si vous le faites dans une langue autre que votre langue de travail de jour, ces types de problèmes sont suffisamment limités pour étirer vos capacités, mais aussi assez simples pour avoir des approches claires.
J'ai fait le défi de l'IA cette année, et ce que je trouve le plus fascinant, c'est que le problème est assez simple pour être résolu avec des algorithmes de base, mais vous atteindrez la limite de temps par tour si vous le faites de manière naïve . Vous devez comprendre non seulement la partie par cœur des principes de base, mais aussi les raisons sous-jacentes derrière eux afin de le faire fonctionner dans les contraintes de temps.
Après avoir écrit un bloc de code qui fonctionne et passe un test, demandez-vous "ce code peut-il être meilleur?". Dans ce contexte, mieux ne signifie pas nécessairement plus rapide ou plus efficace, bien que cela en fasse partie. La clarté du code est également importante - quelqu'un peut-il le regarder et comprendre ce qu'il fait. Demandez-vous si vous soumettez ce code à un employeur potentiel comme étant représentatif de votre meilleur travail.
Ne faites pas cela uniquement pour votre propre code personnel. Venez sur des sites comme celui-ci et répondez aux questions qui vous demandent de fournir un exemple de travail. Écrire du code qui peut un jour être copié et utilisé par des personnes qui apprennent peut être un puissant facteur de motivation. Assurez-vous de le faire avec votre vrai nom afin de n'avoir d'autre choix que de le revendiquer comme le vôtre.
Une autre façon de le faire - et je vois que vous l'êtes - est d'écrire un blog qui vous oblige à fournir du code. Encore une fois, cela vous oblige à écrire du code qui sera aux yeux du public, ouvert à la critique.
Lorsque vous écrivez du code qui sera lu et examiné par d'autres, je pense que c'est l'équivalent de pratiquer des échelles.
Une approche pourrait être de prendre un projet relativement non trivial (disons, plus de 1000 lignes) et de le porter dans d'autres langues. Vous constaterez que cela met en évidence de nombreuses hypothèses formulées pour vous par votre langue.
Une autre approche pourrait être de déterminer un projet plus vaste - au moins 10KLoC selon votre estimation - et de commencer à l'écrire, en l'écrivant rapidement. Continuez à l'écrire, puis après avoir atteint son objectif, maintenez-le. Cela vous apprendra à gérer les bases de code en mutation dans le temps.
Juste quelques réflexions.
Comment un écrivain s'entraîne-t-il à écrire des livres?
OK, ce que je voulais dire, c'est qu'écrire du code n'est pas comme maîtriser un instrument de musique. Le rôle d'un programmeur est plus un écrivain ou un composer essayant de trouver le bon accord. Vous devriez donc vous demander comment ces professionnels pratiquent leur métier à la place. En fait, je pense que notre profession a plus en commun avec ceux qu'avec d'autres disciplines de l'ingénierie.
Un écrivain s'entraîne à écrire en écrivant des livres et un composer s'entraîne à composer en composant de la musique, donc un programmeur doit pratiquer la programmation par programmation.