Une question courte, certes, mais qui est tellement chargée de
complexité. Est-ce qu'ils demandent des compétences ? De génie ? Des cours ?
Des concepts aussi immuables que des lois ? Des choses contre lesquelles personne ne peut argumenter
?
Difficile à dire.
Mon penchant va plus naturellement vers le philosophique que le purement
pragmatique dans ces discussions, je vous préviens.
*******
La façon dont vous abordez un problème ou une opportunité détermine la façon dont la solution
se terminera.
L'un des aspects clés du génie logiciel est la capacité à
investiguer avec curiosité la forme et l'espace du problème, à
comprendre ses parties, et à être capable de les assembler en quelque chose
d'utile et de précieux.
Cela s'applique *non seulement* au logiciel proprement dit, mais à l'ensemble du
système de conception, d'invention, de mise en œuvre, de déploiement et de
maintenance. Il examine non seulement comment cette fonctionnalité particulière va
être décomposée en objets, fonctions, procédures, ou
que sais-je, mais comment ces parties vont être vérifiées,
validées et assemblées, mais aussi comment les personnes qui travaillent sur ces
différentes parties et assemblages vont travailler ensemble.
Donc, un des fondamentaux du génie logiciel est :
**Pouvoir voir le tout ainsi que les parties,
comment elles
se séparent et se remettent ensemble.**
*******
On doit apprendre à le faire, bien sûr, car la plupart des gens ne sont pas
nés avec cette capacité. Certaines personnes l'acquièrent plus tôt que d'autres,
certaines peuvent ne jamais l'acquérir, mais c'est quelque chose qui peut être enseigné et
appris.
Mais comment ?
Le génie civil est sans doute le premier type d'ingénierie que les humains
ont développé. Apprendre à construire des ponts qui enjambaient les rivières, les gouffres et
généralement facilitaient le commerce fait partie de la civilisation humaine depuis
des millénaires.
Mais comment cela a-t-il commencé ? Principalement, parce que les ponts sont tombés. Jeter une
couple de bûches à travers le cours d'eau finissait par être suffisant, mais si
vous vouliez que quelque chose dure plus longtemps que la prochaine inondation, vous deviez
concevoir des moyens d'empêcher de telles choses d'être emportées par les eaux ou de tomber et
de tuer des gens dans le processus.
Les premiers ingénieurs ont donc appris à étudier l'échec, et à apprendre pourquoi les
choses que nous construisons se brisent et tombent en morceaux. Un ingénieur logiciel doit faire
la même chose afin de comprendre comment construire de meilleurs
logiciels. Il'est pas tout à fait suffisant de *juste* étudier l'échec, bien sûr;
il faut aussi comprendre les projets réussis.
En cela, nous étudions mieux quand nous étudions ensemble, ce qui est une des raisons pour lesquelles le
mouvement Open Source a été un réel avantage pour l'apprentissage de l'ingénierie
logicielle. Même dans le développement propriétaire, cependant, le partage du code
avec des collègues par le biais de revues par les pairs, de l'appariement et de l'étude est très
bénéfique.
Donc, un autre fondamental du génie logiciel est :
**Un sens profond de la curiosité pour les internes des logiciels et
des projets qui fonctionnent et qui échouent, et la compréhension de ce qui fait
quelque chose de bien et ce qui causera des problèmes futurs.**
*******
J'ai mentionné la notion de "lois", ou de concepts fondamentaux de l'ingénierie logicielle.
Il en existe qui s'approchent de cette sorte d'immuabilité, mais aucune avec
une telle rapidité que la loi de la gravité.
Je'vais juste en énumérer quelques-uns, il't plus qu'adéquat
d'informations à ce sujet là-bas, et différentes personnes ont leurs
favoris.
* Ne vous
répétez pas
* Principe du moindre étonnement
* Principe du moindre savoir
* Faites-le fonctionner, puis faites-le joli, puis faites-le rapide.
**Comprendre les principes de ce qui fait une bonne architecture
logicielle.**
*******
Déplacement un peu, je'vais maintenant parler plus techniquement et
pragmatiquement, et ceux-ci seront un peu plus dirigés.
* N'apprenez pas une syntaxe, apprenez les idiomes d'un langage ou d'un framework's,
les pratiques, les espaces de problèmes dans lesquels il fonctionne le mieux, ceux dans lesquels il ne fonctionne pas
* N'apprenez pas un seul langage ou framework. Dans *Pragmatic
Programmer*, ils vous incitent à apprendre un nouveau langage chaque année. Le
truc, c'est que ne vous contentez pas d'apprendre un langage du même genre, apprenez-en un
qui a différentes façons de résoudre les problèmes. Si vous utilisez un langage impératif comme le C, apprenez Lisp ou Smalltalk. Si vous
écrivez principalement en Perl, apprenez Ruby et Python. L'apprentissage n'est jamais
perdu.
* Travaillez à la fois avec des exercices (kata) et avec des problèmes réels. Il n'y a
rien de vraiment plus satisfaisant que de résoudre un de vos propres
problèmes, et ce sont les véhicules idéaux pour appliquer l'apprentissage à.
* Si vous rencontrez un élément d'un projet que vous ne savez pas
mettre en œuvre, ou un domaine dans lequel vous avez besoin de plus de compétences, cassez-vous dans un
petit exemple et pratiquez cela jusqu'à ce que vous le compreniez.
Un autre principe du génie logiciel est :
**S'exercer et apprendre constamment son métier.**
*******
J'espère bien que d'autres personnes proposeront d'autres pensées et idées. Bonne
chance.
Il y a des choses à faire.