Je n'ai pas encore trouvé de bon cours de sciences informatiques qui prépare de manière adéquate à l'emploi. ingénieurs en informatique pour le lieu de travail. Si vous en trouvez un qui propose les éléments suivants [bien que je doute qu'il puisse être appelé CompSci, il s'agit plutôt de Real-World Software Design qui est une chose très différente].
L'informatique est un sujet plus théorique qui a des implications très concrètes dans le monde réel, mais qui est plus utile d'un point de vue académique. La conception d'algorithmes, par exemple, est extrêmement utile aux ingénieurs en informatique, mais n'est pas vraiment utile au consommateur. Par exemple, savoir comment construire un algorithme de tri sélectif ou comprendre la traversée d'une liste chaînée n'est pas vraiment donc utile dans l'environnement actuel de l'ingénierie logicielle - bien sûr, la compréhension de la théorie est utile pour choisir les bons outils pour le travail, ne vous méprenez pas. En tant que développeurs, nous sommes nombreux à nous appuyer sur les résultats du monde de l'informatique pour perfectionner nos outils de développement ; en fait, sans eux, de nombreux développeurs seraient laissés à l'abandon, mais mettez un diplômé en informatique en face d'un utilisateur et demandez-lui de concevoir un logiciel utile pour lui, et l'intellect académique va s'effondrer parce que les deux parlent des langages complètement différents.
Un cours beaucoup plus utile pour les ingénieurs en logiciel inclurait autant (et peut-être plus) des composants suivants que je peux penser en haut de ma tête :
- Langage de programmation - le déroulement des programmes de base, les paradigmes, la syntaxe, etc. Ceci est généralement bien enseigné, donc je ne m'attarderai pas trop sur ce point. Cependant, il serait utile d'enseigner quelques classes de langages de programmation complètement différentes - par exemple, j'ai appris le C, le Pascal et le VB 3( ? je ne me souviens pas de la version exacte). Il serait bien plus utile que les programmeurs apprennent au moins un langage fonctionnel, un langage impératif et un langage déclaratif.
- Débogage - Lorsque l'on écrit des applications nTier [ce qui est le cas de la plupart des applications dans le monde réel], il serait utile de pouvoir déterminer où quelque chose ne va pas, jusqu'au niveau du protocole si nécessaire. Des outils d'analyse tels que WireShark sont utiles à cet effet.
- Dispositifs de communication - XML, XQuery, XPath, XSL, XSD [qui semblent être très utilisés].
- Conception de bases de données relationnelles - Cet aspect est déjà assez bien enseigné.
- Optimisation des performances des bases de données relationnelles - Il ne suffit pas de concevoir les tables, il faut aussi savoir quand il est approprié d'indexer certains champs et quand il ne l'est pas, ce qui ne semble pas être abordé dans de nombreux cours.
- Normalisation des données Cela semble également être enseigné raisonnablement bien dans de nombreux cas. Bien que la plupart des étudiants semblent sortir dans le monde réel en vomissant les théories qu'on leur a enseignées - "tu dois toujours utiliser la forme normale de Boyce-Codd", etc, sans vraiment réfléchir aux implications de ces théories. Dans le monde réel, nous avons parfois de très bonnes raisons d'enfreindre les règles.
- Optimisation des requêtes - L'écriture de requêtes de base semble souvent être à la limite de la zone de confort des diplômés, l'optimisation devrait être enseignée. De même, des outils tels que les profileurs de requêtes devraient être enseignés afin d'aider les étudiants à déboguer les problèmes de performance des applications.
- Procédures stockées/déclencheurs - Je n'ai encore jamais rencontré d'étudiant capable d'écrire une procédure stockée ou un déclencheur ou d'utiliser l'un ou l'autre de manière efficace. Les Selects/Joins/Selects imbriqués semblent être la limite de ce qui est enseigné lorsqu'il s'agit de la conception de requêtes.
- Algorithmes de base - D'après mon expérience, cet aspect est assez bien enseigné, mais beaucoup d'étudiants ne semblent pas savoir comment décider quels algorithmes s'appliquent à quelles situations sans qu'on leur dise "à l'aide de tel ou tel algorithme, résolvez ce problème". Il serait utile de leur dire "résolvez ce problème" et qu'ils se disent "d'accord, j'ai une flotte d'algorithmes qui seraient utiles dans cette situation, celui-ci est le meilleur à cause de x, y ou z raison et voici comment il peut être appliqué pour fournir une solution".
- Récursion - Je n'ai pas encore trouvé d'approche qui permette d'enseigner la récursivité, il semble que soit vous l'obtenez, soit vous ne l'obtenez pas. Un de ces jours, je trouverai une bonne métaphore qui fera comprendre cela même au programmeur le plus élémentaire.
- Abstraction - Il s'agit d'un aspect que de nombreux cours négligent, bien qu'il s'agisse de l'un des principes fondamentaux de la POO.
- Refonte du code - Savoir quand de refactoriser et, ce qui est presque aussi important, quand les no à.
- Réutilisation du code - Il semble qu'un grand nombre de cours produisent des singes coupés/collés. no ce que la réutilisation des codes est censée signifier !
- Contrôle à la source - Je n'ai appris le contrôle des sources qu'à mon troisième ou quatrième emploi dans la programmation, et je ne connais personnellement aucun ingénieur logiciel qui ait appris le contrôle des sources dans le cadre de sa formation... pourquoi cela ?
- Sauvegarde et restauration - Je n'ai pas entendu parler de cours qui enseignent cela. Combien de programmeurs débutants ont perdu tout leur travail parce qu'ils ne savaient pas ce qu'il fallait faire ? penser de la sauvegarde ? Je sais que je l'ai fait par le passé, mais pas récemment. Ce n'est pas que j'ignorais l'importance de la sauvegarde, mais comme le dit l'adage, "cela ne m'arrivera jamais". C'est un peu comme si je ne savais pas que cela ne m'arriverait jamais. volonté Il est garanti que cela vous arrivera juste avant que vous ne deviez démonter tout ce que vous venez de perdre !
- Maintenance du système de fichiers - D'accord, certains cours abordent brièvement cette question, mais ce n'est pas le cas de la plupart d'entre eux.
- Rédiger des spécifications de conception de bonne qualité - Cela semble toujours être fourni dans le cadre d'un travail de cours, mais il est rarement demandé à l'étudiant de le concevoir lui-même. La rédaction d'un cahier des charges et la compréhension des modèles de documents semblent dépasser largement le cadre de la plupart des cours de logiciels.
- Documentation pour l'utilisateur - Les utilisateurs ne pensent pas comme vous, et leur donner un logiciel "qui s'explique de lui-même" ou "si simple qu'un idiot peut l'utiliser" vous explosera à la figure. Un célèbre dicton dit que "la programmation aujourd'hui est une course entre les ingénieurs en logiciel qui s'efforcent de construire des programmes de plus en plus grands et à l'épreuve des idiots, et l'univers qui essaie de produire des idiots de plus en plus grands". Jusqu'à présent, c'est l'univers qui gagne". Rédigez une documentation utilisateur qu'un enfant de 8 ans peut suivre - cela peut sembler pénible à écrire, mais une fois que ce sera fait, et pour toujours, vous vous en remercierez.
- Documentation technique - Par exemple, il serait utile que les étudiants puissent utiliser Sandcastle, nDoc ou tout autre outil de documentation.
- Planification des tests - la conception des tests et des logiciels qui permettent les tests. nUnit ou un outil similaire serait un excellent outil à enseigner dans les cours de développement de logiciels. En fait, enseigner cualquier tester le cadre serait mieux que de n'en enseigner aucun... comme cela semble être le cas.
- Test FAT/SAT/UAT - Il serait utile de comprendre les différents scénarios de test dans le monde réel, tels que les contrôles d'intégrité, les tests d'acceptation en usine et les tests d'acceptation par l'utilisateur. L'approbation de votre logiciel est aussi importante que son développement. Si vous ne livrez pas ce que le client pensait obtenir, vous ne serez pas payé, quelle que soit la qualité technique de votre solution.
- Architecture des logiciels - comprendre les différents composants des applications n-tiers du monde réel, ainsi que les avantages et les inconvénients de leur utilisation.
- Interaction avec les utilisateurs - Ce n'est peut-être pas vraiment de l'informatique, mais apprendre à parler à des personnes qui ne sont pas souvent sur votre longueur d'onde et qui ne pensent pas de la même manière que vous, cela va de pair avec la communication, mais c'est vraiment quelque chose dont les développeurs doivent être conscients.
- Le bon sens - Ding, ding, ding, ding - il y a beaucoup de programmeurs qui n'ont pas la moindre idée de ce que c'est ! Les cours sont conçus pour prouver que vous pouvez penser par vous-même, je ne comprends pas pourquoi tant de diplômés arrivent dans le monde réel en pensant qu'il leur suffit d'appliquer aveuglément les règles qu'on leur a enseignées sans réfléchir aux raisons et aux implications. Je répète ce que j'ai dit précédemment : dans le monde réel, nous trouvons parfois de très bonnes raisons d'enfreindre les règles. Nous ne les suivons pas aveuglément, et nous ne les enfreignons pas aveuglément non plus. Le développement de logiciels est un art, et comme tous les arts, nous devons savoir quand nous pouvons et quand nous ne pouvons pas, et surtout quand nous devons et quand nous ne devons pas enfreindre les règles. En tant que diplômé, vous avez appris les règles, vous l'avez prouvé. Vous devez maintenant faire ce que le cours essayait vraiment de vous apprendre - appliquer ce que vous avez appris pour penser par vous-même.
- L'écoute - Vous seriez surpris du nombre de fois où j'ai vu du code écrit parce que le développeur "pensait savoir ce que le client voulait" au lieu d'écouter ce que l'utilisateur disait et de comprendre ses besoins réels.
- Comprendre - Cela va de pair avec l'écoute.
- Compétences en matière de communication
- Parler aux personnes techniquement inaptes - c'est-à-dire une grande partie de votre base d'utilisateurs
- Médiation de projet - vendre vos idées à ceux qui signent les chèques
- Établissement de priorités - comment décider quelles caractéristiques sont plus importantes que d'autres.
- Budgétisation - estimation du temps
- Gestion du temps - comment faire les choses à temps quand tout le monde autour de vous empiète sur votre temps et ne se soucie pas de vos échéances. Comme lorsque tous vos amis veulent que vous alliez boire une pinte au pub alors que vous avez un travail de cours que vous n'avez pas encore commencé et que vous devez rendre avant la fin de la journée de demain.
- La dérive du champ d'application - lorsqu'il s'agit de dire, non, ce n'est pas dans le cahier des charges/budget.
Et même si vous a fait de tout cela au cours de votre formation, j'ose dire que vous auriez encore Apprendre plus en trois ou quatre mois de stage dans une société de conseil en développement de logiciels d'un calibre décent que sur l'ensemble du cursus. J'ai plus appris au cours des six premiers mois qui ont suivi ma licence que pendant toute la durée de mes trois années d'études. Il est vrai que je serais tombé à la renverse. sans J'ai appris beaucoup de choses dans ce cours, mais il y avait tellement de choses enseignées inutilement qui auraient pu être remplacées par un contenu bien plus utile.
