Pourquoi n'enseignent-ils pas ces choses à l'école? [fermé]

Au cours de l'été, j'ai eu la chance de participer à 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 à l'avance. Bien que je pense toujours qu'il est très important d'apprendre tôt, pourquoi n'enseignent-ils pas plus de ces trois avant eux? Ou est-ce juste mon école qui n'enseigne pas grand-chose 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 à la mode, 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 tous deux très nouveaux et pas très bien compris. Bien que toutes les disciplines scientifiques et techniques 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 progrès récents 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 dont la collecte peut être très coûteuse: dans quelle mesure le contrôle de version aide-t-il? Comment ça aide? Test unitaire? On peut raisonner sur l'efficacité de diverses techniques, mais en réalité prouver que l'efficacité de manière concluante coûterait très cher. Nous aurions besoin de lancer un projet logiciel complet et réaliste du début à la fin, de nombreuses fois, avec des groupes de programmeurs qui ont une expertise équivalente, utilisant différentes techniques. À tout le moins, nous aurions besoin de beaucoup de données sur les projets existants que ces projets ne seraient pas disposés à publier.

Les ingénieurs civils ont des milliers d'années de ponts à examiner, 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 ne sont guère 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 «ingénierie» de logiciels, est vraiment une chose différente 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 raisonner sur le parallélisme n'est pas quelque chose qu'un programmeur en activité fera tous les jours; de même, un vrai "informaticien" écrira des tonnes de code jetable qui ne fonctionnent tout simplement pas ou ne font rien d'intéressant, et ne bénéficieront pas autant de la sorte de rigueur qu'un logiciel réel ferait.

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 où tout le monde s'accorde sur ce qui devrait être enseigné dans les écoles.

Enfin, il y a quelques considérations économiques. Cela fait relativement peu de temps que presque toutes les personnes impliquées dans le développement de logiciels ont 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 à la simple exécution de vos tests, ou même héberger une histoire infinie de code source, aurait semblé frivole à beaucoup de gens.

Parce que nos professeurs:

1. Jamais essayé de tests unitaires,
2. Je ne sais pas comment utiliser le contrôle de version et
3. Je n'ai même pas entendu parler de «développement agile».

Les élèves devraient prendre les choses en main. Nous avons fait cela, et nous avons très bien réussi, n'est-ce pas?

Léonard de Vinci a écrit:

Ceux qui sont amoureux de la pratique sans science sont comme un pilote qui monte dans un bateau sans gouvernail ni boussole et n'a jamais aucune certitude où il va. La pratique doit toujours être basée sur une solide connaissance de la théorie.

Les bonnes écoles enseignent à la fois la théorie (structures de données, algorithmes, etc.) et la pratique (tests unitaires, contrôle de version, etc.). Cela nécessite un mélange approprié de facultés 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 fera pas l'affaire. De même, une faculté composée entièrement de praticiens ne fera pas l'affaire. Vous avez besoin d'un mélange, et les bonnes écoles l'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 le côté `` scientifique '' (algorithmes, structures de données, compilateurs, etc.) parce que ces éléments sont beaucoup plus `` intemporels '' que les meilleures pratiques actuelles du secteur, 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'il y a 40 ans. Leur idée est généralement de vous donner suffisamment de bases pour que vous puissiez ensuite choisir des outils comme git et comprendre ce que cela signifie quand on vous dit que la structure de données sous-jacente est un graphe 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, pensez à 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 un 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 fournit une boîte à outils pleine d'outils. Ceci est un tournevis, c'est une clé à molette. Vous pourriez utiliser chaque outil une fois à l'université. C'est lorsque vous entrez dans le monde réel que vous découvrez vraiment ce que vous avez. Vous triez les éléments 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 toutes des modes, elles viendront et elles iront, aucune des réussites 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 a fait leur succès, peu avaient besoin d'un nom pour cela. Le problème est que vous ne pouvez pas vendre du 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 de presse 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 obtiennent leur certificat annuel et / ou à vie dans un club afin qu'ils puissent mettre un graphique sur leur site Web ou une étiquette sur la boîte dans laquelle leur produit entre. Beaucoup diront que c'est rare ... été là, vu, ça arrive. Tout cela fait partie des affaires, il faut parfois couper les coins ronds 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 ne l'est pas, la dernière était vraiment trop chère à suivre, celle-ci ne l'est pas. Le dernier était faux, vous venez d'embaucher un consultant, celui-ci est réel. Tout comme les langages de programmation, ceux-ci évolueront eux aussi. Le dernier était faux, vous venez d'embaucher un consultant, celui-ci est réel. Tout comme les langages de programmation, ceux-ci évolueront eux aussi. Le dernier était faux, vous venez d'embaucher un consultant, celui-ci est réel. Tout comme les langages de programmation, ceux-ci évolueront eux aussi.

Votre capacité à comprendre les réalités des entreprises, 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, au gouvernement ou à quelqu'un d'autre d'enseigner que vous voulez ou voulez savoir. C'est votre travail de rechercher le numéro un. De même, vous ne pouvez blâmer personne de vous avoir donné le temps de le faire, vous devez le faire. Vous tomberez du cheval, vous n'êtes pas une victime, levez-vous et remettez-vous en marche, pas d'excuses, la vie n'est pas juste avec elle. Profitez des documents, ne prétendez pas être indépendant. Et certainement payer vos cotisations, ne pas sucer 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 un 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 ne font que suivre le livre de quelqu'un d'autre sur le sujet? Vous ont-ils appris que vous ne pouvez pas avoir de code maintenable, fiable et performant? Vous ne pouvez même pas «choisir deux» interférences maintenables à la fois fiables et performantes? Parfois, vous sacrifiez la fiabilité au profit de la performance. Parfois, vous ne vous souciez pas de la fiabilité ou des performances, vous voulez simplement obtenir 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, dans la mesure où les développeurs de logiciels le feront, tout ancien robot peut écrire le même code de la même manière. Remplacez le brûlé par celui qui vient de sortir du collège et continuez à vendre des mises à niveau.

Il n'y a pas de réponses universelles à ces questions, vous devez découvrir votre opinion, vivre avec et la défendre. Changez d'avis, vivez avec et défendez-le.

Tout remettre en question ... vais-je vraiment me brûler si je touche le pot chaud sur la cuisinière? Les effets psychologiques de la peur causeront-ils plus de dégâts que le simple fait de 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'achèterais et finirais par faire fondre des transistors, des capuchons, des résistances, etc. dans mon dortoir, qui ont tous une mauvaise odeur distinctive. Il est beaucoup moins cher et plus facile d'acheter simplement 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, même si ce que vous apprenez à ce moment-là est 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 suivante sortira, ils 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 fait à cause 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, ainsi qu'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 quelle combinaison vous convient et si vous avez de la chance, trouvez un lieu de travail qui vous convient.

Lorsque vous sortez de l'université et que vous entrez dans le monde réel, écoutez et travaillez avec et discutez avec les «anciens». Ils ont des décennies, voire des siècles d'expérience combinée, des pièges dans lesquels ils sont tombés que vous pourriez éviter et / ou tester par vous-même (peut-être réalisez-vous que vous n'avez pas à toucher le pot chaud pour savoir qu'il vous brûlera). La plupart auront vu au moins une ou deux de ces modes aller et venir, et en particulier à quel point elles ont été brûlées et ce qu'elles 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 ont évolué. 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 l'ancien, faites-le passer. 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 simplement un poisson. Et parfois, vous devez les laisser échouer avant de réussir, les empêcher de trop se brûler.

Ce que je voulais vraiment dire ici, c'est qu'en ce moment nous sommes 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 reprises. Selon l'endroit où vous travaillez et avec qui vous travaillez, vous pourrez peut-être observer des ingénieurs en matériel. Les langages de programmation dans le monde du matériel ne sont certainement pas nouveaux, mais ils n'ont pas évolué aussi rapidement que le monde du logiciel. Les logiciels avaient quelques décennies d'avance. Le matériel a toujours considéré les ingénieurs en logiciel comme des citoyens de seconde zone. Notre travail est facile, leur travail est difficile. (Notez que je suis en fait à la fois un ingénieur matériel et logiciel). Ce qui est intéressant, c'est qu'à l'heure actuelle, ils sont toujours aux prises avec 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 pas être comparée aux outils coûteux que j'utilise, si l'entreprise pensait que vous étiez assez digne de l'utiliser ou même de savoir 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 en une semaine grâce à ce qui était presque un défi d'un tel ingénieur en matériel (malgré mon diplôme disant ingénieur électricien, mon titre de poste est ingénieur logiciel). Je voulais apprendre ces langues, lorsque les outils étaient à ma disposition, je suis resté au bureau toute la nuit et j'ai appris moi-même. À partir de là, cet ingénieur en particulier s'est rendu compte que ce que je disais était vrai, les langues ne sont que de la syntaxe, les principes de base de la programmation sont les mêmes, les outils font tous la même chose. Ses pommes et ses pommes, pas ses pommes et ses oranges.

En général, il est encore difficile d'envoyer le message que l'une de ces deux industries parallèles a beaucoup plus d'expérience dans les langages, les habitudes de programmation, le contrôle de source, les tests, les outils, les environnements de programmation, etc. que l'autre. Le problème que j'essaie de résoudre est de prendre les conceptions matérielles au fur et à mesure qu'elles sont développées, 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 modifications du code pour voir où nous devons concentrer notre temps. Aucun mécanisme de suivi de la documentation définissant l'interface utilisateur (de programmation) avec le matériel. La seule copie dorée 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 vous a découvert il y a trois semaines et corrigé? Alors, nous nous envolons pour un lieu de vacances et faisons la fête pendant six mois en attendant que les gens du matériel finissent leur tâche et nous la jettent par-dessus le mur, ou profitons-nous de cette occasion pour essayer d'être patient et optimiste et leur apprendre 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 affaires pour examen par les pairs ... ce verilog a quel âge? Ce bug que j'ai passé toute la semaine sur vous a découvert il y a trois semaines et corrigé? Alors, nous nous envolons pour un lieu de vacances et faisons la fête pendant six mois en attendant que les gens du matériel terminent leur tâche et nous la jettent par-dessus le mur, ou profitons-nous de cette occasion pour essayer d'être patient et optimiste et leur apprendre 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 affaires pour examen par les pairs ... ce verilog a quel âge? Ce bug que j'ai passé toute la semaine sur vous a découvert il y a trois semaines et corrigé? Alors, nous nous envolons pour un lieu de vacances et faisons la fête pendant six mois en attendant que les gens du matériel finissent leur tâche et nous la jettent par-dessus le mur, ou profitons-nous de cette occasion pour essayer d'être patient et optimiste et leur apprendre 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 affaires pour 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 en utiliser qu'un, le reste des langages que vous avez dans votre carrière seront inventés après votre sortie du collège. Quand 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, ou et non (hé nous avons ceux en commun, tout ce que vous devez vraiment savoir sur les ordinateurs, un, zéro et, ou et non ingénieur matériel ou logiciel). Compte tenu des lois fondamentales de la physique, du calcul, les électrons ne changeront pas aussi vite que le font les langages de programmation. Mais les principes fondamentaux de la programmation sont les mêmes dans toutes les langues et continueront de l'être dans le futur. Avez-vous quitté l'université en sachant cela ou avez-vous quitté en pensant que 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 attirer les bons étudiants, les bons fonds de recherche et les bons types de recherche pour rentabiliser l'université. Ils doivent offrir les bonnes classes pour attirer les bons étudiants et former les bons diplômés afin qu'au fil des décennies, les employeurs à la fois près de l'université et, espérons-le, très 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 à la télévision et la bonne quantité de reconnaissance de nom et de revenus sportifs). Certaines universités enseigneront le C ++ et Java, d'autres ne le feront jamais. Certains inventeront la CMM, d'autres enseigneront l'Agile, d'autres 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 ce 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 est nulle, 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 très bonne boîte à outils, dites de bonnes choses à propos de cette université et des bons universitaires avec lesquels vous avez appris ceci et cela et payez 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 des 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 adjoint à l'Institut de technologie de l'Oregon. Ils sont enseignés, très peu.

La réponse la plus simple est que vous étudiez l'informatique et que les choses que vous avez énumérées ne sont pas vraiment liées au domaine académique de l'informatique. Le développement de logiciels 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 de logiciels 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 métier , à savoir, le (bon) développement de logiciels.

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'offraient aucun cours de fantaisie comme le C ++

quant à la raison pour laquelle ils n'enseignent pas ces choses, eh bien, le collège est là pour vous enseigner les bases de la discipline, pas nécessairement les meilleures pratiques de l'industrie

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é tout ce dont on 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.

Cependant, le contrôle de version est quelque chose qui est inexcusable de nos jours. C'est quelque chose que tout le monde doit comprendre, c'est un outil 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 travaillez en groupe à l'université, vous aurez peut-être la chance de trouver quelqu'un qui connaît déjà le contrôle de version et convaincra votre groupe de l'utiliser. Je sais que je suis content que cette personne fasse partie de mon groupe.

Les tests unitaires sont également pratiquement inexcusables. La seule chose que je dirais, c'est que le livre est toujours sur le développement piloté par les tests et que la couverture de code à 100% peut toujours être plus problématique que cela ne vaut la peine. Mais les tests unitaires sont extrêmement précieux et devraient être couverts dans un cours de génie logiciel. J'imagine que certaines de ces choses font leur chemin dans certaines universités mais ne les ont tout simplement pas encore toutes atteintes.

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 cela pour l'accréditation, les enseignants ne sont pas familiers avec cela et les étudiants ne développent jamais de projets d'importance 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.

Les informaticiens pensent qu'ils sont des mathématiciens et non des ingénieurs et préfèrent donc enseigner les parties mathématiques plutôt que les parties techniques. Les tests, le contrôle de version et la documentation ne sont pas plus à la mode que dans aucune autre discipline d'ingénierie.

Cela dépend de l'université. Je suis diplômé en 2003 d'une université australienne. À cette époque, nous avons appris UML, les tests unitaires, XP (et d'autres méthodologies agiles), ainsi que tous les éléments formels tels que Z, les algorithmes et les structures de données, les systèmes d'exploitation, etc.

Cependant, ils n'ont pas couvert les tests unitaires en détail, ils ont plutôt payé le service de passage pour une conférence. Il aurait été formidable d'avoir appris à écrire 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'utilisons (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. La CS est un domaine tellement immature, vraiment seulement dans les 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 ratés montre clairement qu'il s'agit d'une industrie immature. Imaginez si 80% des projets de construction échouaient!

Tout cela peut facilement être couvert (de manière superficielle) dans un seul cours sur les pratiques de développement de logiciels. Cela ne fait pas partie de la plupart des programmes de CS, parce que ce n'est pas le but de CS, même si je pense qu'une certaine couverture de ce sujet 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 en 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 cours supplémentaires de génie logiciel, ils étaient disponibles au choix.

Bien que je n'ai jamais mentionné le contrôle de version une seule fois dans aucun cours que j'ai suivi, la plupart de mes amis l'utilisaient pour des projets personnels, des devoirs de cours, etc., donc ce n'est pas comme si nous n'y étions pas exposés. Les personnes qui ne l'ont pas ramassé elles-mêmes ont été forcé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 des didacticiels sur le Web et vous êtes prêt. Si vous avez besoin de cours et de devoirs pour comprendre comment vérifier quelque chose de SVN, vous allez avoir beaucoup de problèmes avec les choses qui SONT réellement difficiles.

N'oubliez pas qu'il existe de nombreuses façons d'apprendre des choses à l'université en dehors des cours; profitez-en. Vous payez beaucoup pour assister aux cours et utiliser les installations, alors traitez-le pour tout ce que cela vaut et allez aux réunions LUG et ACM, participez aux équipes de projet (il y a toujours des ME qui construisent un robot qui ont besoin d'un programmeur), ou obtenez un poste d'administration du serveur du département des sciences humaines. Récupérez un ordinateur sur le quai de chargement du bâtiment de l'ingénierie des matériaux, téléchargez une iso Linux avec votre connexion Internet rapide et jouez.

Je pense que le problème est que les universités ne pensent pas qu'elles doivent vous apprendre à devenir un professionnel, mais plutôt se concentrer sur l'aspect académique de la programmation. J'aurais pensé qu'il faudrait au moins faire référence aux dernières méthodes et techniques utilisées dans l'industrie, car ces éléments présentent également un intérêt académique.

Dans notre cours, on nous a enseigné le Processus logiciel personnel, qui couvrait des choses comme le temps d'enregistrement passé sur des projets, de bons commentaires, etc., mais aucune mention des fondamentaux professionnels comme le contrôle de version.

Vous en avez nommé 3, dont certains ne sont pas à mon avis 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? Les tests d'utilisabilité, les tests du système, les tests d'acceptation des utilisateurs et les tests d'acceptation en usine sont certainement plus importants? Eh bien, ils le sont, sauf si vous considérez votre travail comme terminé une fois que le code est expédié au service de maintenance :)

Pensez aux autres concepts que j'utilise quotidiennement, qui seraient de peu d'utilité pour un étudiant qui appréhende 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
• le contrôle des modifications (pas nécessairement le même que le contrôle de version qui consiste à stocker les différences, il s'agit davantage de savoir quoi et pourquoi vous avez changé quelque chose)
• développement de l'utilisabilité

Ce qui précède sont toutes des «compétences générales» dont vous n'avez pas besoin pour écrire un bon code.

Cependant, si vous manquez les compétences «techniques», comme les structures de données et les algorithmes, alors vos chances d'écrire du bon code sont presque impossibles.

J'ai appris tout cela à l'université. Cela dépend peut-être des cours que vous choisissez? Mes cours étaient très variés (conception de logiciels, conception d'interface utilisateur, commerce électronique, IA, programmation fonctionnelle, etc.). La conception de logiciels a été exposée aux modèles de conception et aux tests unitaires (un grand projet impliquant diverses choses). UI Design ... nous étions un groupe de trois personnes travaillant sur un projet. Nous ne pouvions rien faire sans le contrôle de version, alors nous l'avons obtenu. Et le développement agile était quelque chose dont nos professeurs nous parlaient continuellement, mais ils ont laissé à chaque groupe le soin de l'utiliser.

Je trouve que de nombreux étudiants universitaires ont suivi des cours ou des cours «faciles» qui leur donneraient une moyenne générale élevée. D'autres se concentrent sur ce qu'ils veulent apprendre et explorent largement 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 parcours.

Pour expliquer pourquoi 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 dans les années suivantes) que vous pouvez choisir d'en apprendre davantage sur les choses utilisées en dehors du milieu 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.

Personnellement, je pense 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 cela. Je préférerais que ces personnes comprennent d'abord comment fonctionne une boucle for avant de comprendre le monstre qu'est Perforce.

Ils n'enseignent pas de tels sujets parce que la plupart des écoles sont universitaires et non commerciales. Autrement dit, ils sont conçus pour enseigner des idées et des théories, pas pour vous entraîner à une carrière. L'ensemble du concept d'AQ n'a rien à voir avec l'informatique au-delà du passage d'une preuve mathématique. En outre, les pratiques d'assurance qualité et les flux de travail de développement diffèrent énormément d'une maison de développement à l'autre, donc leur enseigner à l'école est une perte de temps et d'argent.

J'ai appris tout cela en 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 tout cela rapidement.

En ce qui concerne CS Education en général, nous demandons essentiellement aux professeurs d'enseigner autant (langages de toutes sortes, structures de données, efficacité d'exécution, comment les choses fonctionnent réellement au niveau du bit). J'aimerais poser la question suivante: pourquoi les enfants ne prennent-ils pas l'initiative d'en apprendre davantage sur le génie logiciel?

Tout comme les étudiants, chaque collège est différent. Certains collèges, ou plus exactement, 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 de CS. Mais il en va de même pour 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 actuels et applicables. Pas tellement avec une grande université établie et prestigieuse.

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'on les récupère sur le tas).

Je pense que les bons programmes CS devraient enseigner les principes de base qui serviront de base à toute future formation 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 contextes 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é universitaire.

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 que je n'ai jamais appris à l'université.

Le fait est peut-être que les professeurs d'université ne suivent pas autant qu'ils le devraient les nouvelles techniques de développement. Ils peuvent aussi avoir le sentiment qu'il y a d'autres choses plus importantes dans leur programme.

Les professeurs d'université ne savent pas comment écrire un logiciel, ils se contentent de le rechercher, de l'enseigner et parfois de dénigrer du code qui ne doit fonctionner que jusqu'à la publication du document.

Ce n'est que grâce à des gens comme Titus que nous obtenons des universitaires qui vraiment grok 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.

Bonne chance avec ta carrière, j'espère que tu obtiendras ton diplôme, c'est bien d'avoir des lettres après ton nom. :)

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 laisserai une question ouverte; mais il n'est pas vrai qu'aucune université ne vous enseigne les «choses pratiques».

Celles-ci sont basées sur mes expériences limitées dans un programme CS avant de changer de filière et sur mon expérience en tant que stagiaire dans une grande entreprise de logiciels. Les tests unitaires ne sont pas enseignés car la plupart des programmes que vous devez créer ne sont pas assez volumineux pour nécessiter des tests automatisés, vous avez garanti un ensemble spécifique d'entrées afin de pouvoir tout tester manuellement. Vous apprendre à automatiser les tests peut également interférer avec la notation de votre projet puisque la plupart des projets sont notés avec des scripts qui exécutent des tests automatisés, avec un rapide coup d'œil sur le 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 volumineux pour le contrôle de version, et en gros, je veux dire plus de 1000 lignes de code et a pris un semestre entier à écrire. Je suppose qu'ils pensent que vous l'enseignerez à vous-même si vous en avez besoin. Tous les projets de groupe que j'avais étaient censés être des projets de programmation par paires, 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 la banque ou le médical où la documentation est reine. Cela a probablement aussi à voir avec le fait que le développement adgile n'était pas il y a environ 20 ans, quand beaucoup de professeurs ont été formés.

La raison principale est que de nombreuses universités (la plupart?) Se considèrent comme ayant un objectif différent de celui d'une école de métiers. À ce titre, 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 être encore utilisés par l'obtention du diplôme).

En informatique, cela signifie algorithmes, structures de données, théorie de l'informatique, théorie du compilateur, etc. Ce que vous énumérez est moins de comprendre comment programmer, comment résoudre des problèmes, etc. d'ailleurs, est un livre étonnant pour toute personne à l'université avec l'intention de travailler en tant que programmeur). Maintenant, une grande partie de cela ne sera pas utilisée à un poste de singe de code d'entrée de gamme, ce qui amènera 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 non plus dire 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é, du moins dans une certaine mesure. Je regarderais l'enseignement du contrôle de version, des tests unitaires, etc.

Je pense que cela dépend du type de programme d'informatique dans lequel vous vous trouvez, il y en a ceux qui visent le côté recherche et science et il y en a qui sont axés sur 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'ont pas «utilisé» ce qu'ils enseignent, tout est dans leur tête, littéralement.

Plug: Ayant suivi un BS en Comp Sci et une MS en Soft Eng à l'Université DePaul, j'ai principalement été enseigné par des instructeurs / professeurs qui enseignaient à temps partiel, ce qui me convenait car je préférerais qu'ils viennent avec une anecdote de la veille. et reliez-le à la classe. De plus, étant principalement une école de banlieue / à temps partiel, la plupart des étudiants ont un emploi en utilisant 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 l'utilisent réellement dans votre travail?" et la réponse typique est «nous l'utilisons mais de manière simplifiée ou simplifiée», puis nous entrons dans les scénarios pratiques du monde réel.

Pendant ma scolarité, les tests unitaires étaient toujours présents. Même s'ils vous ont commencé sur Java, ils nous ont fait utiliser ANT et JUnit pour tous les projets. Ce qui était un bon début sur la configuration de la construction et les tests unitaires.

Et Extreme Programing a été 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 Agile.

La réponse rapide est donc oui, il y a des écoles qui ont une approche plus pragmatique que d'autres.

Les tests unitaires et le contrôle de version ont tous deux été enseignés dans les cours d'informatique de 2ème 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 allaient à une bonne gestion des erreurs qui peuvent facilement provenir des tests unitaires.

Je pense que le développement agile peut être assez difficile à enseigner dans un cadre académique. Bien que j'aie appris la méthode Waterfall en théorie, je n'ai pu la voir sur le terrain qu'après avoir obtenu mon diplôme et déménagé dans le monde réel qui peut être très différent du monde universitaire, par exemple en 3ème année, je fais toutes les erreurs bizarres cas et presque réussir une mission où je n'ai jamais touché au cœur de ce que la mission a essayé de m'apprendre sur les sémaphores.

De plus, depuis combien de temps l'agilité existe-t-elle et de quelle forme d'agilité parlez-vous? Il existe de nombreuses implémentations différentes de ce que j'ai vu.

Je ne pense pas que la programmation agile soit une mode, mais en même temps, j'aurais du mal à imaginer un moyen pour un enseignant de vous proposer des projets pour vous permettre de l'apprendre. À moins qu'il ne vous donne le projet A, build 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 algorithmes peuvent être travaillés dans un cadre de classe. Honnêtement aussi, ils demandent un peu plus d'efforts pour comprendre que les tests unitaires et les versions. Essayez de vous rappeler qu'une partie de l'université est de vous apprendre à vous enseigner. Collage n'a pas tout à fait le même mandat. Ou du moins pas dans la même mesure. A MON HUMBLE AVIS.