Pourquoi n'enseignent-ils pas ces choses à l'école?
Au cours de l'été, j'ai eu la chance d'entrer dans Google Summer of Code. J'ai beaucoup appris (probablement plus que ce que j'ai appris dans la somme de tous mes cours universitaires). Je me demande vraiment pourquoi ils n'enseignent pas certaines des choses que j'ai apprises plus tôt à l'école. Pour n'en nommer que quelques-uns:
- tests unitaires
- contrôle de version
- développement agile
Il me semble qu'ils passent beaucoup de temps à enseigner d'autres choses comme les structures de données et les algorithmes dès le départ. Bien que je pense toujours que ce sont très importants à apprendre dès le début, pourquoi n'enseignent-ils pas plus de ces trois avant eux? Ou est-ce juste mon école qui n'enseigne pas beaucoup de ce genre de choses?
Ne vous méprenez pas, je ne pense pas qu'il soit souhaitable que les universités enseignent toujours les modes de programmation les plus en vogue, mais mes professeurs ne devraient-ils pas m'apprendre autre chose que "dessiner un diagramme avant de commencer à coder?"
La réponse la plus simple à votre question est que les domaines de l'informatique et du développement de logiciels sont à la fois très nouveaux et mal compris. Bien que toutes les disciplines scientifiques et d'ingénierie progressent plus rapidement dans les temps modernes, d'autres domaines ont beaucoup plus d'expérience sur laquelle s'appuyer et il existe une compréhension partagée beaucoup plus large de leur fonctionnement.
Par exemple, malgré les récents progrès de la science des matériaux, les ingénieurs civils savent depuis environ 2000 ans comment construire une arche qui ne tombera pas, et c'est quelque chose qui peut être enseigné et appris à l'université avec relativement peu de controverse. Bien que je sois entièrement d'accord avec vous sur les techniques que les développeurs de logiciels devraient apprendre, cet accord est basé sur une expérience personnelle et un raisonnement informel. Pour être une "meilleure pratique" socialement acceptée, nous avons besoin de données quantitatives qui peuvent être très coûteuses à collecter: dans quelle mesure le contrôle de version aide-t-il? Comment ça aide? Tests unitaires? Nous pouvons raisonner sur l'efficacité de diverses techniques, mais prouver en fait que l'efficacité serait définitivement très coûteuse. Nous aurions besoin d'exécuter un projet logiciel complet et réaliste du début à la fin, plusieurs fois, avec des groupes de programmeurs qui ont une expertise équivalente, en utilisant différentes techniques. À tout le moins, nous aurions besoin de beaucoup de données sur des projets existants que ces projets ne voudraient pas publier.
Les ingénieurs civils ont des milliers d'années de ponts à regarder, avec beaucoup d'informations. Les développeurs de logiciels, en revanche, ne disposent que de quelques décennies d'informations, dont la plupart sont gardées secrètes, car les organisations sont peu motivées à rassembler et à publier des informations sur l'efficacité de leurs développeurs, même si elles les collectent (ce qui 't).
Il y a aussi une certaine confusion des champs. Le développement de logiciels, ou "génie logiciel", est vraiment différent de l'informatique. Les développeurs de logiciels ont besoin d'une connaissance pratique de l'informatique, mais travailler aux limites de la complexité algorithmique ou du raisonnement sur le parallélisme n'est pas quelque chose qu'un programmeur qui travaille tous les jours; de même, un véritable "informaticien" écrira des tonnes de code jetable qui ne fonctionne tout simplement pas ou ne fait rien d'intéressant, et ne bénéficiera pas autant du genre de rigueur qu'un véritable logiciel.
L'émergence d'Internet et de la communauté open source peut fournir suffisamment de données pour commencer à répondre à ces questions de manière concluante, mais même si les réponses étaient disponibles demain, il leur faudra probablement 100 ans pour imprégner la société internationale au point que tout le monde s'accorde sur ce que devrait être enseigné dans les écoles.
Enfin, il y a quelques considérations économiques. Cela fait relativement peu de temps car presque toutes les personnes impliquées dans le développement de logiciels avaient un accès facile et bon marché à des machines dédiées pour exécuter les outils de développement de leur choix. Il y a quelques décennies, consacrer complètement une machine à l'exécution de vos tests, ou même héberger une histoire infinie de code source, aurait semblé frivolement cher à beaucoup de gens.
Parce que nos professeurs:
- Jamais essayé les tests unitaires,
- Je ne sais pas comment utiliser le contrôle de version et
- N'ont même pas entendu parler de "développement agile".
Les élèves devraient prendre les choses en main. C'est ce que nous avons fait et nous nous sommes avérés très bien, non?
Léonard de Vinci a écrit:
Ceux qui aiment la pratique sans la science sont comme un pilote qui monte dans un navire sans gouvernail ni boussole et n'a jamais aucune certitude où il va. La pratique doit toujours être basée sur une bonne connaissance de la théorie.
Les bonnes écoles enseignent à la fois la théorie (structures de données, algorithmes, etc.) ainsi que la pratique (tests unitaires, contrôle de version, etc.). Cela nécessite un mélange approprié de professeurs afin que les deux faces de cette pièce puissent être correctement enseignées. Une faculté composée entièrement de types théoriques sans expérience réelle ne suffira pas. De même, une faculté entièrement composée de praticiens ne fera pas l'affaire. Vous avez besoin d'un mélange, et les bonnes écoles en ont.
L'informatique a toujours été quelque peu contradictoire; La partie qui concerne les ordinateurs n'est pas une science, et la partie qui est une science ne concerne pas les ordinateurs.
Les universités ont tendance à s'appuyer davantage sur la `` science '' (algorithmes, structures de données, compilateurs, etc.) car ces choses sont beaucoup plus `` intemporelles '' que les meilleures pratiques actuelles de l'industrie, qui ont tendance à évoluer et à changer d'année en année. Le contrôle de version, par exemple, a subi des changements incroyables au cours des 5 ou 10 dernières années, mais big-O est toujours big-O, et le hachage, les btrees et la récursivité sont toujours aussi utiles qu'ils l'étaient il y a 40 ans. Leur idée est généralement de vous donner suffisamment de bases pour que vous puissiez ensuite prendre des outils comme git et comprendre ce que cela signifie quand on vous dit que la structure de données sous-jacente est un graphique dirigé acyclique de hachages SHA-1, et que les développeurs ont travaillé dur pour optimiser le nombre d'appels système afin qu'il soit lié à io.
Maintenant, réfléchissez à l'endroit où vous avez appris toutes les choses que vous deviez savoir pour comprendre cette dernière phrase - si la réponse est "université", ils font du bon travail.
Tout est une mode passagère. Vous en apprendrez plus au cours de votre première année à l'université que toutes vos années à l'université. L'informatique n'a rien à voir avec les ordinateurs.
College vous propose une boîte à outils remplie d'outils. Il s'agit d'un tournevis, c'est-à-dire d'une clé à molette. Vous pourriez utiliser chaque outil une fois au collège. C'est lorsque vous entrez dans le monde réel que vous découvrez vraiment ce que vous avez. Vous triez ceux qui sont utiles du reste, ceux que vous souhaitez laisser à la maison sur l'établi, au cas où, et ceux que vous gardez dans votre poche tous les jours.
Tqm, Iso, Cmm, Agile, etc. Ce sont tous des modes qu'ils viendront et ils iront, aucun des succès n'est plus que du bon sens. Tous les ingénieurs et entreprises qui réussissent utilisent une certaine saveur de bon sens, c'est ce qui les a fait réussir, peu avaient besoin d'un nom pour cela. Le problème est que vous ne pouvez pas vendre le bon sens, un gestionnaire ne peut pas prouver sa valeur à l'entreprise en formant et en achetant du bon sens sans un nom accrocheur. Mettez un nom dessus que leurs supérieurs ont lu dans un article ou un magazine et le manager garde son travail et vous gardez le vôtre. Très peu d'entreprises qui prétendent suivre ces pratiques le font réellement. La plupart écrivent un chèque à un consultant et remettent leur certificat annuel et/ou à vie à un club afin qu'ils puissent mettre un graphique sur leur site Web ou une étiquette sur la boîte de leur produit. Beaucoup diront que c'est rare ... été là, vu, ça arrive. Tout cela fait partie des affaires, il faut parfois couper les coins pour rester rentable et garder les portes ouvertes et les lumières allumées. Les adeptes inconditionnels de toutes ces pratiques ont tous soutenu que la dernière était une mode et que celle-ci n'est pas, la dernière était vraiment trop chère à suivre, celle-ci n'est pas. Le dernier était faux, vous venez d'embaucher un consultant, celui-ci est réel. Comme les langages de programmation, ceux-ci évolueront également.
Votre capacité à comprendre les réalités de l'entreprise, le système universitaire et votre rôle dans celui-ci est la clé. Comme tout dans la vie, choisissez vos batailles. Ce n'est pas l'université ou l'entreprise ou le gouvernement ou le travail de quelqu'un d'autre pour vous enseigner que vous avez besoin ou que vous voulez savoir. C'est votre travail de chercher le numéro un. De même, vous ne pouvez pas blâmer quelqu'un d'autre pour vous avoir donné le temps de le faire, vous devez le faire. Vous allez tomber du cheval, vous n'êtes pas une victime, vous vous levez et vous remettez en marche, pas d'excuses, la vie n'est pas juste avec. Profitez des documents, ne prétendez pas être indépendant. Et certainement payer vos cotisations, ne pas aspirer une entreprise à sec de documents, sans leur donner quelque chose (votre meilleur à l'époque?) En retour.
Pourquoi les gens pensent-ils que cmm ou agile ou l'un des autres est une mode? Pourquoi pensent-ils qu'ils ne le sont pas? Pourquoi le professeur vous a-t-il enseigné le programme de cette façon? Pour éviter les gotos ou pour éviter les constantes ou pour éviter ceci et cela? Est-ce parce qu'il produit du code plus fiable? Un code plus performant? Réduit l'erreur humaine? Ou est-ce parce qu'il est plus facile de noter les articles/programmes en leur donnant plus de temps pour faire des recherches? Est-ce parce qu'ils ne savent pas programmer et qu'ils suivent simplement le livre de quelqu'un d'autre sur le sujet? Vous ont-ils appris que vous ne pouvez pas disposer d'un code maintenable, fiable et performant? Vous ne pouvez même pas "choisir deux" interférences maintenables à la fois avec des performances fiables et élevées? Parfois, vous sacrifiez la fiabilité pour les performances. Parfois, vous ne vous souciez pas de la fiabilité ou des performances, vous voulez simplement passer de la version 117.34.2 d'un autre logiciel de comptabilité à la version 118.0.0. Votre modèle commercial consiste à vendre des mises à niveau de version et un support technique et, en ce qui concerne les développeurs de logiciels, tout ancien robot qui peut écrire le même code de la même manière. Remplacez celui brûlé par celui fraîchement sorti du collège et continuez à vendre des améliorations.
Il n'y a pas de réponses universelles à ces questions, vous devez savoir ce que vous pensez, vivre avec et défendre. Changez d'avis, vivez avec et défendez-le.
Question tout ... vais-je vraiment me brûler si je touche la marmite du poêle? Les effets psychologiques de la peur causeront-ils plus de dégâts que de simplement se brûler? Existe-t-il un moyen sûr de tester la réponse sans se blesser?
Quand je pouvais me le permettre, j'achetais et finissais par faire fondre des transistors, des bouchons, des résistances, etc. dans ma chambre de dortoir, qui ont tous une mauvaise odeur distinctive. Il est beaucoup moins cher et plus facile d'acheter un ampli pour votre chaîne stéréo que d'essayer d'en construire un le lendemain de votre première classe de transistors. Linus étant l'exception bien sûr, il est plus facile d'acheter un système d'exploitation que d'en écrire un ... Vous pouvez en faire plus, bien que ce que vous apprenez à l'époque soit différent de ce que Linus a appris.
Le monde à l'intérieur et à l'extérieur de l'université adoptera ces formules (cmm, agile, etc.) pour résoudre les problèmes et lorsque la prochaine sortira, elles les abandonneront tout aussi rapidement. Vous n'avez pas besoin d'utiliser le contrôle de version pour réussir, il y a autant de succès avec que sans (enfin en raison de l'âge de l'industrie, il y a beaucoup plus de succès sans contrôle de version jusqu'à présent). De même, vous pouvez réussir avec un minimum de tests (regardez les très grands noms de l'industrie informatique comme exemples). Vous pouvez réussir en testant votre propre code, tout en réussissant en suivant la règle selon laquelle vous ne devez jamais tester votre propre code. Vous pouvez réussir avec emacs et vous pouvez réussir avec vi. Vous devez décider quel mélange vous convient et si vous avez de la chance, trouvez un lieu de travail qui vous convient. Avec le temps, ce qui fonctionne pour vous changera, des outils aux langages, en passant par le style de programmation, les peurs, le contrôle de version, la documentation, etc. Vous vous marierez et aurez des enfants et vous déciderez de vouloir vous cacher dans le coin de cette grande entreprise package d'assurance santé avec le travail ennuyeux et profitez de vos enfants au lieu d'être le programmeur hotshot à la petite startup.
Lorsque vous sortez de l'université et dans le monde réel, écoutez et travaillez avec et discutez avec les "anciens". Ils ont des décennies à des siècles d'expérience combinée, des pièges dans lesquels ils peuvent tomber et que vous pouvez éviter et ou tester par vous-même (peut-être vous rendez-vous compte que vous n'avez pas à toucher le hot pot pour découvrir qu'il vous brûlera). La plupart auront vu au moins un ou deux de ces modes, et en particulier à quel point ils ont été brûlés et ce qu'ils ont fait pour s'en remettre. Ils connaissent de nombreuses façons différentes de tester les choses, ainsi que les noms des styles de test qui sont passés et disparus également. Ce qui fonctionne, ce qui ne fonctionne pas. Où est le risque et comment éviter de perdre du temps sur une tangente. Au fur et à mesure que vous mûrissez et que vous devenez le vieux minuteur, passez-le en avant. Payez ce que vous avez appris en essayant d'enseigner à ceux qui vous suivent. N'oubliez pas de leur apprendre à pêcher, ne leur donnez pas seulement un poisson. Et parfois, vous devez les laisser échouer avant de réussir, les empêcher de se brûler trop gravement.
Ce que je voulais vraiment dire ici, c'est que nous sommes actuellement dans une situation rare où nous pouvons assister à une évolution d'un univers parallèle (et peut-être l'influencer). Oui, l'informatique est une science jeune par rapport à la physique. Mais en même temps, il a évolué plusieurs fois. Selon l'endroit où vous travaillez et avec qui vous travaillez, vous pourrez peut-être observer les ingénieurs du matériel. Les langages de programmation dans le monde matériel ne sont certes pas nouveaux, mais ils n'ont pas évolué aussi rapidement que le monde logiciel. Le logiciel avait une longueur d'avance de quelques décennies. Le matériel a toujours considéré les ingénieurs logiciels comme des citoyens de seconde zone. Notre travail est facile, leur travail est difficile. (Notez que je suis en fait à la fois ingénieur matériel et logiciel). Ce qui est intéressant, c'est qu'en ce moment, ils traitent toujours de ce que nous considérons comme des problèmes élémentaires ou infantiles. Pourquoi aurais-je besoin d'utiliser le contrôle de version, je suis le seul à travailler sur cette puce. Votre expérience avec gcc ou d'autres compilateurs bon marché ou IDE gratuits ne peut peut-être pas se comparer aux outils coûteux que j'utilise, si la société pensait que vous étiez assez digne de l'utiliser ou même savait comment l'utiliser, elle vous en achèterait une copie. Et une longue liste d'autres excuses. J'ai eu le plaisir d'apprendre à la fois le vhdl et le verilog et de devenir productif dans les deux en une semaine grâce à ce qui était presque un défi d'un tel ingénieur matériel (malgré mon diplôme disant ingénieur électricien mon titre de travail est ingénieur logiciel). Je voulais apprendre ces langues, lorsque les outils étaient à ma disposition, je suis resté au bureau pendant la nuit et j'ai appris par moi-même. À partir de ce moment-là, l'ingénieur en particulier s'est rendu compte que ce que je disais était vrai, les langages ne sont que la syntaxe, les principes de programmation sont les mêmes, les outils font tous la même chose. Ses pommes et pommes pas des pommes et des oranges.
En général, il est toujours difficile d'envoyer le message que l'une de ces deux industries parallèles a beaucoup plus d'expérience que les autres dans les langages, les habitudes de programmation, le contrôle de code source, les tests, les outils, les environnements de programmation, etc. Le problème que j'essaie de résoudre est de prendre les conceptions matérielles au fur et à mesure de leur développement, de créer des simulateurs fonctionnels abordables que nous pouvons associer à une simulation (machine virtuelle) du processeur afin que nous puissions commencer à tester le matériel et à développer le test et logiciel livrable bien avant de passer au silicium. Non, il n'y a rien de "nouveau" à ce sujet, mais nous n'avons aucun mécanisme pour obtenir le dernier code, suivre les changements dans le code pour voir où nous devons concentrer notre temps. Aucun mécanisme de suivi de la documentation définissant l'interface utilisateur (programmation) avec le matériel. La seule copie d'or se trouve dans la boîte de réception de quelqu'un sous forme binaire et ne change que lorsque, eh bien, il n'est pas nécessaire de lire le verilog pour savoir ce qui se passe. Attendez, ce verilog a quel âge? Ce bug que j'ai passé toute la semaine sur toi a été résolu il y a trois semaines et corrigé? Alors volons-nous vers un lieu de vacances et faisons la fête pendant six mois en attendant que les quincailliers terminent leur tâche et nous la jettent par-dessus le mur, ou saisissons-nous cette occasion pour essayer d'être patient et optimiste et leur enseigner qu'ils il existe des méthodes de bon sens qui ne sont pas si intrusives qui leur permettent à la fois de faire leur travail, de sauvegarder leur travail et de partager leurs trucs pour un examen par les pairs ...
N'oubliez pas que les ingénieurs en matériel ont quitté l'université avec une boîte de nouveaux outils brillants, tout comme vous. Vous avez appris 17 langages de programmation différents dont vous ne pouvez utiliser qu'un seul, les autres langages que vous aurez dans votre carrière seront inventés après votre sortie du collège. Lorsqu'ils ont quitté l'université, ils peuvent vous dire ce qu'ils savent sur le calcul et la théorie de la relativité combien d'électrons sont dans chacun des éléments et calculer la charge autour d'une surface gaussienne. Mais l'essentiel de leur carrière est un, zéro, et, et ou non (hé nous avons ceux en commun, tout ce que vous devez vraiment savoir sur les ordinateurs, un, zéro, et, et ou pas ingénieur matériel ou logiciel). Compte tenu des lois fondamentales de la physique, du calcul, les électrons ne changeront pas aussi vite que les langages de programmation. Mais les principes fondamentaux de la programmation sont les mêmes dans toutes les langues et continueront de l'être à l'avenir. Avez-vous quitté l'université en sachant cela ou avez-vous quitté la pensée Java est différent et meilleur que C++ parce que ceci et cela et l'autre?
Comme toute autre entreprise, le travail des universités est de rester rentable. Ils doivent embaucher les bons universitaires pour amener à la fois les bons étudiants et les bons dollars en recherche et les bons types de recherche pour rentabiliser l'université. Ils doivent offrir les bonnes classes pour amener les bons étudiants et produire les bons diplômés afin que, au fil des décennies, les employeurs à la fois près de l'université et, espérons-le, loin, reconnaissent que cette université produit des employés productifs et rentables. (oui et parfois vous devez attirer les bons athlètes dans le bon sport pour obtenir la bonne quantité de temps TV et la bonne quantité de reconnaissance de nom et de revenus sportifs). Certaines universités enseigneront le C++ et Java, d'autres non. Certains inventeront le CMM, et certains enseigneront l'Agile, certains ne feront ni l'un ni l'autre. Si l'université a une quelconque valeur, il y a quelque chose à apprendre. Ils ne vous apprendront pas tout ce qu'il y a à apprendre, mais ils auront quelque chose d'utile. Apprenez que quelque chose pendant que vous y êtes, rassemblez un nombre raisonnable de différentes formes d'outils dans votre boîte à outils. Quittez l'université et trouvez un emploi. Si votre boîte à outils craint, trouvez peut-être une autre université et ne mentionnez jamais la première. Si c'est une boîte à outils correcte, utilisez ces outils et créez-en de nouveaux à votre rythme. Si c'est une assez bonne boîte à outils, dites de bonnes choses à propos de cette université et des bons universitaires que vous avez appris ceci et cela de et rembourser l'école pour ce qu'ils vous ont donné. Même si vous n'avez pas obtenu tous les outils possibles dans le catalogue universel d'outils universitaires, vous repartirez avec un certain sous-ensemble. Même si vous n'êtes pas diplômé ...
J'ai enseigné ces choses quand j'étais auxiliaire à l'Oregon Institute of Technology. Ils sont enseignés, mais avec parcimonie.
oh mon dieu ne me lance pas
une fois, le doyen de cs dans une université réputée m'a dit que la programmation orientée objet n'était qu'une `` mode '', donc ils n'ont pas offert de cours en passant des fantaisies comme C++
pourquoi ils n'enseignent pas ces choses, eh bien, le collège est là pour vous enseigner les principes fondamentaux de la discipline, pas nécessairement les meilleures pratiques de l'industrie
La réponse la plus simple est que vous étudiez l'informatique et les choses que vous avez énumérées ne sont pas vraiment liées au domaine académique de l'informatique. Le développement logiciel peut être quelque chose que vous faites avec l'informatique, quelque chose qui s'appuie sur les blocs de ce que vous avez appris ... mais l'informatique et le développement logiciel ne sont pas la même chose.
Des cours qui vous ont appris le contrôle de version, ou comment écrire des tests unitaires efficaces ... qui vous apprendraient un commerce, à savoir, un (bon) développement logiciel.
Eh bien, le problème avec les universités, c'est qu'elles doivent enseigner des choses qui sont vraiment universelles. Quelque chose comme le développement agile est encore assez nouveau et malgré combien on en parle sur Internet, il n'est pas utilisé partout, donc l'enseigner à toute une classe d'étudiants ne profiterait potentiellement qu'à quelques personnes qui ont atterri dans des magasins agiles.
Le contrôle de version est cependant quelque chose qui est de nos jours inexcusable. C'est quelque chose que tout le monde doit comprendre, c'est un outil qui est presque aussi utile qu'un compilateur et CVS existe depuis plus de 20 ans. Les concepts doivent au moins être compris par tout programmeur quittant une université. Heureusement, si vous faites un travail de groupe à l'université, vous aurez peut-être la chance d'atterrir avec quelqu'un qui connaît déjà le contrôle de version et convainc votre groupe de l'utiliser. Je sais que je suis content que cette personne fasse partie de mon groupe.
Les tests unitaires sont également à peu près aussi inexcusables. La seule chose que je dirais, c'est que le livre est toujours sur le développement piloté par les tests et opter pour une couverture de code à 100% peut parfois être plus difficile qu'il ne vaut. Mais les tests unitaires sont extrêmement précieux et devraient être couverts dans un cours de génie logiciel. J'imagine que certains de ces trucs font leur chemin dans certaines universités mais ne les ont pas encore tous atteints.
Pourquoi pas, en effet? Mon expérience d'obtention de mon diplôme CS était à peu près la même. La raison en est que les gens qui enseignent la programmation ne programment pas, pour autant que je sache. Il n'est pas nécessaire d'enseigner ce genre de choses pour l'accréditation, les enseignants ne le connaissent pas et les étudiants ne développent jamais de projets importants dans le cadre de leurs cours. Il n'y a aucune motivation pour enseigner la programmation, contrairement à l'enseignement de la théorie CS ou de la syntaxe Java.
Cela dépend de l'université. J'ai obtenu mon diplôme en 2003 dans une université australienne. Pendant ce temps, nous avons appris UML, les tests unitaires, XP (et d'autres méthodologies agiles), ainsi que toutes les choses formelles comme Z, les algorithmes et les structures de données, les systèmes d'exploitation, etc.
Cependant, ils n'ont pas couvert les tests unitaires dans les moindres détails, ils l'ont simplement payé en passant le service pour une conférence. Il aurait été formidable d'avoir appris à rédiger des tests unitaires efficaces, plutôt que simplement "Qu'est-ce qu'un test unitaire".
En ce qui concerne le contrôle de version, nous l'utilisions (CVS) dans nos projets de programmation à partir de la 2ème année.
Je suis également tout à fait d'accord avec ce que Glyph a dit. CS est un domaine tellement immature, vraiment seulement au cours des 50 dernières années, que nous ne savons pas ce que nous devrions apprendre et ce qui n'est qu'une mode passagère. Donnez-lui 150 ans, alors les choses pourraient se calmer davantage. Le nombre de projets Realworld ayant échoué montre clairement qu'il s'agit d'une industrie immature. Imaginez si 80% des projets de construction échouaient!
Les informaticiens pensent qu'ils sont des mathématiciens et non des ingénieurs et ils préfèrent donc enseigner les parties mathématiques que les parties techniques. Les tests, le contrôle de version et la documentation ne sont pas plus à la mode que dans toute autre discipline d'ingénierie.
Tout cela peut facilement être couvert (superficiellement) dans une seule classe sur les pratiques de développement logiciel. Cela ne fait pas partie de la plupart des programmes de CS, car ce n'est pas de cela qu'il s'agit, bien que je pense qu'une couverture de ce genre de choses est utile. Mon école avait une telle classe; il ne couvrait pas le contrôle de version, mais il couvrait UML, la collecte des exigences, les méthodologies de développement (diverses agiles et cascade), les tests unitaires, les tests d'intégration, etc., et nous obligeait à travailler en équipes de 4-5 pour développer un projet (une arnaque Clue assez simple en Java). Si vous ressentiez le besoin de suivre d'autres cours de génie logiciel, ils étaient disponibles au choix.
Bien que le contrôle de version n'ait jamais été mentionné une seule fois dans les cours que j'ai suivis, la plupart de mes amis l'utilisaient pour des projets personnels, des travaux de classe, etc., ce n'est donc pas comme si nous n'y étions pas exposés. Les personnes qui ne l'ont pas récupéré par elles-mêmes ont été obligées de l'utiliser par un camarade de classe au cours d'une mission d'équipe.
L'université est censée enseigner des concepts et des théories, car ce sont des choses difficiles à comprendre par vous-même. Le contrôle de version est un outil assez facile à prendre en main. Utilisez-le un peu, lisez quelques tutoriels sur le Web, et vous êtes prêt. Si vous avez besoin de conférences et de devoirs pour comprendre comment vérifier quelque chose dans SVN, vous aurez beaucoup de mal avec les choses qui SONT réellement difficiles.
N'oubliez pas qu'il existe de nombreuses façons d'apprendre des choses au collège en dehors des cours; en profiter. Vous payez beaucoup pour assister aux cours et utiliser les installations, alors traitez-le pour tout ce qu'il vaut et allez aux réunions LUG et ACM, participez aux équipes de projet (il y a toujours des ME construisant un robot qui ont besoin d'un programmeur), ou obtenez un travail d'administration du serveur du département des sciences humaines. Trashpick un ordinateur à partir du quai de chargement du bâtiment de génie des matériaux, téléchargez une iso Linux avec votre connexion Internet rapide et jouez.
Vous en avez nommé 3, dont certains ne me semblent pas aussi importants pour la compréhension des systèmes informatiques (par exemple, le contrôle de version). Ces choses font partie d'un travail et vous pouvez devenir un bon programmeur/informaticien sans avoir besoin de le savoir.
de même pour les tests unitaires - pourquoi choisir les tests unitaires? Certes, les tests d'utilisabilité, les tests de système, les tests d'acceptation des utilisateurs et les tests d'acceptation en usine sont plus importants? Eh bien, ils le sont sauf si vous considérez que votre travail est terminé une fois le code expédié au service de maintenance :)
Pensez aux autres concepts que j'utilise quotidiennement, qui seraient de peu d'utilité pour un étudiant qui se réconcilie avec les fondamentaux des logiciels et des systèmes informatiques:
- bonnes pratiques de commentaires
- conformité aux normes (pas seulement internationales, mais normes de codage d'équipe)
- documentation
- changement de contrôle (pas nécessairement le même que le contrôle de version qui concerne le stockage des différences, c'est plus sur quoi et pourquoi vous avez changé quelque chose)
- développement de l'utilisabilité
Ce qui précède sont tous des "compétences non techniques" que vous n'avez pas besoin pour écrire du bon code.
Cependant, si vous manquez les compétences "dures", comme les structures de données et les algorithmes, alors votre chance d'écrire du bon code est presque impossible.
Je pense que le problème est que les universités ne pensent pas qu'elles doivent vous apprendre à être un professionnel, mais se concentrent plutôt sur le côté académique de la programmation. J'aurais pensé qu'il devrait au moins y avoir une référence aux dernières méthodes et techniques utilisées dans l'industrie, car ces choses présentent également un intérêt académique.
Dans notre cours, nous avons appris le processus de logiciel personnel, qui couvrait des choses comme l'enregistrement du temps passé sur des projets, de bons commentaires, etc., mais aucune mention des fondamentaux professionnels comme le contrôle de version.
J'ai appris tout ça l'année de première année, à l'exception du développement agile.
Il s'agit de choisir la bonne école, à mon humble avis. Si vous allez dans le top 10, vous apprendrez rapidement tout cela.
En ce qui concerne CS Education en général, nous demandons essentiellement aux professeurs d'enseigner tant (langues de toutes les saveurs, structures de données, efficacité d'exécution, comment les choses fonctionnent réellement au niveau du bit). J'aimerais soulever la question: pourquoi les enfants ne prennent-ils pas la décision d'en apprendre davantage sur le génie logiciel?
C'est simplement parce que les structures de données et les algorithmes constituent le cœur de l'informatique et sont donc beaucoup plus importants. Les tests unitaires, le contrôle de version et la méthodologie agile ne sont que des outils du métier (et si nécessaire, on s'attend à ce qu'ils les ramassent sur le tas).
J'ai appris tout cela à l'université. Cela dépend peut-être des cours que vous choisissez? Mes cours étaient très diversifiés (conception de logiciels, conception d'interface utilisateur, commerce électronique, IA, programmation fonctionnelle, etc.). La conception de logiciels était exposée aux modèles de conception et aux tests unitaires (un grand projet qui impliquait diverses choses). UI Design ... nous étions un groupe de trois personnes travaillant sur un projet. Nous ne pouvions rien faire sans contrôle de version, nous l'avons donc compris. Et le développement agile était quelque chose dont nos professeurs nous parlaient continuellement, mais ils l'ont laissé à chaque groupe pour l'utiliser.
Je trouve que de nombreux étudiants universitaires ont suivi des cours "faciles" ou des cours qui leur donneraient un GPA élevé. D'autres se concentrent sur ce qu'ils veulent apprendre et explorent en grande partie pour trouver quel domaine les intéresserait. Et puis il y a ceux qui savent exactement ce qui les intéresse ... ce qui est bien, sauf qu'ils ont tendance à ne pas diversifier leurs cours.
Tout comme les étudiants, chaque collège est différent. Certains collèges, ou plus précisément certains professeurs, résistent au changement ou sont paresseux. Heureusement, la plupart ne le sont pas. Les théories, les concepts, l'histoire, etc. sont importants et vitaux pour tout programme CS. Mais il en va de même de préparer l'étudiant à son environnement de travail. Pas étonnant, les collèges communautaires de ma région offrent des cours de CS très récents et applicables. Pas tant avec une grande université établie et prestigieuse.
Ils n'enseignent pas de tels sujets parce que la plupart des écoles sont académiques et non commerciales. Autrement dit, ils sont conçus pour enseigner des idées et des théories, pas pour vous former à une carrière. Le concept entier de QA n'a rien à voir avec l'informatique au-delà de passer une preuve mathématique. De plus, les pratiques d'AQ et les workflows de développement diffèrent énormément d'une maison de développement à l'autre, donc les enseigner à l'école est une perte de temps et d'argent.
Pour répondre aux raisons pour lesquelles ces choses ne sont pas les premières choses enseignées: les programmes de premier cycle vous forment généralement à devenir un étudiant à la maîtrise. Ce n'est qu'une fois que vous commencez à choisir vos propres cours (ce qui se produit généralement au cours des dernières années) que vous pouvez choisir d'apprendre des choses utilisées en dehors du monde universitaire. C'est pourquoi ils se concentrent sur les algorithmes, les structures de données, vous présentant des problèmes non résolus, etc.
Je pense personnellement que c'est bien qu'ils le fassent. La programmation n'est pas aussi simple que beaucoup d'entre nous le semblent; beaucoup de gens ont du mal avec ça. Je préfère que ces personnes comprennent d'abord comment fonctionne une boucle for avant de comprendre le monstre qu'est Perforce.
Les trois choses que vous mentionnez (tests unitaires, contrôle de version, développement agile) sont enseignées dans une certaine mesure dans le programme de science informatique de l'Université de Groningen. Que ce soit une bonne chose ou non, je vais laisser une question ouverte; mais il n'est pas vrai qu'aucune université ne vous enseigne les "trucs pratiques".
Ceux-ci sont basés sur mes expériences limitées dans un programme CS avant de changer de majeure et mon expérience en tant que stagiaire dans une grande société de logiciels. Les tests unitaires ne sont pas enseignés car la plupart des programmes que vous devez créer ne sont pas assez grands pour nécessiter des tests automatisés, vous avez donc garanti un ensemble spécifique d'entrées, vous pouvez donc tout tester manuellement. Vous apprendre à automatiser les tests peut également interférer avec la notation de votre projet car la plupart des projets sont notés avec des scripts qui exécutent des tests automatisés, avec un rapide coup d'œil au code pour vous assurer que vous n'avez pas int foo1; int foo2; et vous utilisez une indentation appropriée.
Je ne sais pas pourquoi le contrôle de version ne serait pas enseigné, mais une partie de cela est probablement la taille des projets. Je n'ai jamais eu de projet assez grand pour le contrôle de version, et en gros je veux dire plus de 1000 lignes de code et j'ai mis un semestre entier à écrire. Je suppose qu'ils pensent que vous vous l'apprendrez si vous en avez besoin. Tous les projets de groupe que j'avais étaient censés être des projets de programmation en binôme, et pourquoi utiliser le contrôle de version si vous êtes tous les deux sur le même ordinateur?
Je ne sais pas pourquoi le développement agile ne serait pas enseigné mais cela revient probablement à la même chose avec la taille du programme. Bien que le développement adgile soit courant avec les nouveaux logiciels qui s'exécutent sur des ordinateurs personnels et de petits serveurs, il n'est généralement pas utilisé sur des systèmes tels que les ordinateurs centraux IBM ou dans des domaines problématiques tels que les services bancaires ou médicaux où la documentation est reine. Cela a probablement aussi à voir avec le fait que le développement adile n'existait pas il y a environ 20 ans lorsque de nombreux professeurs étaient formés.
Je ne pense pas que la programmation agile soit une mode, mais en même temps, j'aurais du mal à penser à un moyen qu'un enseignant pourrait vous donner des projets pour vous permettre de l'apprendre. À moins qu'ils ne vous aient donné le projet A projet B développer sur a. Le problème est le temps et la portée. Dans un cours de 4 mois, ce serait difficile.
Les méthodes de contrôle de version et de test unitaire sont en constante évolution et dépendent de la langue ou de la personne qui les définit.
Les structures de données et les algo sont quelque chose qui peut être travaillé dans un cadre de classe. Honnêtement aussi, ils prennent un peu plus d'efforts pour comprendre les tests unitaires et les versions. Essayez de vous rappeler qu'une partie de l'université est de vous apprendre à vous enseigner. Le collage n'a pas tout à fait le même mandat. Ou du moins pas dans la même mesure. A MON HUMBLE AVIS.
Je pense que de bons programmes CS devraient enseigner les principes fondamentaux qui serviront de base à toute formation future en programmation. Les méthodologies de développement comme Agile et les outils de contrôle de version sont comme des modes; ils vont et viennent. En outre, ils ont tendance à être utilisés dans des environnements industriels et non universitaires, donc je pense qu'il est rare que les universités couvrent des choses telles que celles que vous apprendrez probablement sur le tas. Je ne dis pas que c'est vrai, mais c'est probablement la mentalité académique.
Je suis d'accord avec ce que vous dites. J'ai récemment commencé à travailler dans le monde du développement logiciel et j'ai déjà commencé à apprendre le développement agile, quelque chose qui ne m'a jamais été enseigné à l'université.
Le fait est que les professeurs d'université ne suivent pas les nouvelles techniques de développement autant qu'ils le devraient. Ils peuvent également penser qu'il y a d'autres choses plus importantes dans leur programme.
Les professeurs d'université ne savent pas comment écrire un logiciel, ils le recherchent, l'enseignent et parfois dénichent du code qui ne fonctionne que jusqu'à la publication du document.
C'est seulement grâce à des gens comme Titus que nous recevons des universitaires qui se moquent vraiment de la programmation - Lisez ses commentaires sur ce sujet ici
Quand j'étais étudiant, je lisais des livres dans la bibliothèque sur la programmation extrême, et nous en avons discuté brièvement dans les classes - les mêmes classes qui exigeaient que nous nous conformions au "modèle en cascade" du développement logiciel, où la "compilation" est une étape de son posséder.
Je vous souhaite bonne chance dans votre carrière, j'espère que vous obtiendrez votre diplôme, c'est bien d'avoir des lettres après votre nom. :)
Je pense que cela dépend du type de programme d'informatique dans lequel vous vous trouvez, ceux qui visent le côté recherche et science et ceux qui sont orientés vers le côté mise en œuvre. J'ai spécialement refusé contre certaines écoles qui n'avaient que des professeurs qui restaient dans le monde académique. Si vous n'avez pas de professeurs qui n'utilisent pas ce qu'ils enseignent, tout est dans leur tête, littéralement.
Plug: Ayant obtenu un BS en Comp Sci et une MS en Soft Eng à DePaul University, j'ai été principalement enseigné par des instructeurs/professeurs qui enseignaient à temps partiel, ce qui me convenait bien car je préférerais qu'ils viennent avec une anecdote de la veille et le relier à la classe. De plus, étant principalement une école de banlieue/à temps partiel, la plupart des étudiants ont un emploi dans l'utilisation de ce qu'ils apprennent.
Le processus d'apprentissage commence toujours par toute la théorie, mais on nous demande généralement "combien d'entre vous utilisent réellement cela dans votre travail?" et la réponse typique est "nous l'utilisons mais d'une manière simplifiée ou simplifiée" et ensuite nous entrons dans les scénarios pratiques du monde réel.
Pendant mon unité scolaire, les tests étaient toujours présents. Même s'ils vous lancent sur Java, ils nous ont fait utiliser ANT et JUnit pour tous les projets. Ce qui était un bon début pour la configuration de la construction et les tests unitaires.
Et Extreme Programing était inclus dans environ 3 ou 4 des cours que j'ai suivis. Je me souviens qu'ils ont tous commencé avec les 12 aspects différents, de la programmation par paires aux tests unitaires (voir ci-dessus). Et maintenant, il semble que l'accent soit mis sur l'Agile.
Donc, la réponse rapide est oui, il y a des écoles qui ont une approche plus pragmatique que d'autres.
La plupart des projets de logiciels universitaires doivent s'inscrire dans les limites d'une seule classe, ce qui signifie effectivement un projet de 5 à 6 semaines impliquant entre 1 et 4 programmeurs inexpérimentés raisonnables. Les tests unitaires et le contrôle des sources ne deviennent efficaces de manière convaincante qu'une fois que vous évoluez au-delà de cela dans des projets à plus long terme impliquant plus de personnes. En conséquence, il est difficile d'intégrer de telles techniques dans un projet de classe d'une manière qui ne semble pas simplement être des exigences inutiles.
La raison principale est que de nombreuses universités (la plupart?) Se considèrent comme ayant un objectif différent d'une école de métiers. En tant que tels, ils veulent enseigner aux étudiants comment apprendre, et les principes fondamentaux de la discipline. De plus, les algorithmes et les structures de données s'appliqueront à n'importe quel langage de programmation et ne dépendent pas d'outils spécifiques (qui peuvent ou non encore être utilisés par l'obtention du diplôme).
En informatique, cela signifie des algorithmes, des structures de données, la théorie de l'informatique, la théorie du compilateur, etc. Les choses que vous listez concernent moins la compréhension de la programmation, la résolution des problèmes, etc. Il s'agit de la pratique de la programmation (qui, soit dit en passant, est un livre étonnant pour quiconque à l'université avec l'intention de travailler en tant que programmeur). Maintenant, une grande partie de cela ne sera pas utilisée à une position de singe de code d'entrée de gamme, ce qui conduit certaines personnes à penser que ce n'est pas utile. Je ne suis pas d'accord. Je pense que cela peut être extrêmement utile. Cependant, cela ne signifie pas qu'après avoir obtenu votre diplôme CS, vous savez tout ce dont vous aurez besoin pour travailler en tant que programmeur.
Ce qui ne veut pas dire non plus que les choses que vous mentionnez ne sont pas utiles. Elles sont. Vous aurez du mal à travailler en tant que programmeur si vous ne les apprenez pas, et je pense qu'ils devraient être enseignés à l'université, au moins dans une certaine mesure. Je regarderais l'enseignement du contrôle de version, les tests unitaires, etc., de la même manière que je regarderais une programmation de premier cycle en art, et l'enseignement de ce que sont les pinceaux et lesquels devraient être utilisés dans divers cas.
Les tests unitaires et le contrôle de version ont tous deux été enseignés dans des cours d'informatique de 2e année où je suis allé à l'université. Les tests unitaires relevaient de la partie des tests qui comprenait également des différences entre la boîte blanche et la boîte noire et une bonne partie des notes dans les affectations de programmation de 3e année visaient une bonne gestion des erreurs qui peuvent facilement provenir des tests unitaires.
Le développement agile peut être assez difficile à enseigner dans un milieu universitaire, je pense. Bien que j'aie appris la méthode Waterfall en théorie, je ne l'ai vue sur le terrain qu'après avoir obtenu mon diplôme et pénétré dans le monde réel, ce qui peut être très différent du milieu universitaire, par exemple. en 3e année, je fais tous les cas d'erreurs étranges et réussis presque une tâche où je n'ai jamais touché au cœur de ce que la tâche a essayé de m'apprendre sur les sémaphores.
De plus, depuis combien de temps l'agile existe-t-il et de quelle forme d'agile vouliez-vous parler? Il existe de nombreuses implémentations différentes de ce que j'ai vu.
Idéalement, je suppose qu'ils n'ont pas le temps d'enseigner ces choses, ou bien il est plus important d'enseigner l'algo et les langues, des choses que la plupart des élèves auront du mal à apprendre.
L'école est l'opposé de l'auto-apprentissage, et puisque ces choses (contrôles de version, tests unitaires) sont les plus faciles à apprendre, elles doivent s'assurer que même l'élève le moins capable est capable de faire la programmation et l'algorithme de base les plus importants, et faire les "choses autour" plus tard.
Ces choses dont vous parlez changent au fil du temps, et il est difficile de changer d'outils, etc. Les grandes structures éducatives aiment rester simples.