Différences entre la programmation à l'école et la programmation dans l'industrie? [fermé]

50

Beaucoup d’étudiants qui obtiennent leur premier emploi et qui obtiennent leur premier emploi ont l’impression de ne pas savoir programmer, même s’ils ont pu être de bons programmeurs au collège.

Quelles sont les différences entre la programmation dans un contexte académique et la programmation dans le "monde réel"?

rdasxy
la source
4
Je dirais que dans les universités, vous apprenez en profondeur: vous apprenez des concepts, vous vous posez des questions, vous améliorez la pensée abstraite. Dans l'industrie, on apprend en profondeur: on apprend à utiliser de nombreuses technologies sans se poser trop de questions, il faut faire avancer les choses. Grâce à votre expérience du secteur, vous apprenez également à gérer des projets vastes et complexes: c’est un problème très pratique que vous ne pouvez pas apprendre à l’université faute de temps.
Giorgio
9
Cette question concerne-t-elle les universitaires au niveau du doctorat, ou après l’obtention du diplôme, ou s’il s’agit simplement d’un contexte général «classe vs monde réel»?
Bob
@Bob. C'était plus à propos de l'académie générale. Classes / recherches / lectures dirigées / devoirs / programmes "réels" dans l'industrie.
rdasxy
D'accord. Ce n’était pas très clair, car il existe des «programmes académiques» qui sont réalisés par des personnes qui veulent dire aux biologistes d’aider les biologistes à comprendre des simulations de cellules.
Bob

Réponses:

72

Dans un programme traditionnel de premier cycle en informatique, vous apprenez simplement à programmer. Mais le monde réel ne veut pas de gens qui ne sont que des programmeurs. Le monde réel veut de vrais ingénieurs en logiciel. Je sais que beaucoup de descriptions de travail ne semblent pas exprimer cette distinction, qui ne fait que compliquer les choses. Dans le monde réel, vous devez être capable de:

  • Rassemblez et analysez les besoins quand ils ne vous sont pas directement donnés
  • Concevoir et analyser une architecture avec des possibilités presque infinies
  • Créez des plans de test et agissez sur eux pour évaluer et améliorer la qualité d'un système
  • Travailler en collaboration sur une équipe de personnes ayant des antécédents et des niveaux d'expérience différents
  • Estimez et planifiez le travail même si vous ne savez pas exactement quoi construire
  • Communiquer efficacement avec les intervenants qui ont des besoins différents qui ne correspondent pas nécessairement
  • Négocier le calendrier, le budget, la qualité et les fonctionnalités sans décevoir les intervenants

Ah oui, et vous devez aussi être capable d'écrire du code, bien que cela ne prenne en moyenne que 40 à 60% du temps d'un ingénieur logiciel.

Donc, ce n’est pas que les étudiants en informatique fraîchement frappés ne savent pas programmer (beaucoup sont en fait de très bons programmeurs). C'est que beaucoup d'entre eux ne savent rien faire d'autre.

Michael
la source
18
Oh yeah, and you also have to be able to write code too, but that's, on average, only 40 - 60% of a software engineer's time.- Ou même entre 0 et 20% dans des magasins vraiment mauvais et très grands.
Ritch Melton
1
+1 pour une très bonne réponse et +1 (devrait être plus) pour Ritch. Si ingénieur as / w consacre plus de 20% de son cycle de vie à la codification, il y a quelque chose qui cloche. 50% design, 30% test, 20% pour le reste ... tout le reste, y compris le codage, semble à peu près correct. Avec une conception appropriée, le codage devrait être trivial. Sans cela, ce que les gens appellent le "codage" est en fait une réécriture sans fin, qui tente de pirater ensemble un
motif
36

À l'Université...

Votre professeur vous donne:

  • Un problème bien défini et isolé, dont la solution peut être apportée dans un laps de temps court et bien défini (et il sera jeté par la suite)
  • Un ensemble bien défini d'outils que vous avez été présenté avant l'affectation
  • Une mesure bien définie de la qualité de votre solution, avec laquelle vous pouvez facilement déterminer si votre solution est suffisamment bonne ou non.

Dans le monde réel"...

  • Le problème est flou, complexe et intégré au contexte. Il s'agit d'un ensemble d'exigences contradictoires qui changent avec le temps et votre solution doit être suffisamment souple et robuste pour vous permettre de réagir à ces changements dans un délai raisonnable.
  • Les outils doivent être choisis par vous. Peut-être y a-t-il déjà quelque chose d’utilisable dans la base de code de votre équipe, vieille de 10 ans, il existe peut-être un projet open source, ou peut-être une bibliothèque commerciale ou vous devrez peut-être l’écrire vous-même.
  • Pour déterminer si l'itération courante de votre logiciel est une amélioration (parce que vous êtes presque jamais réellement fait avec un projet de logiciel), vous devez faire des tests de régression et les tests d'utilisation, ce dernier qui signifie généralement que le flou, complexe, contradictoire , les exigences liées au contexte changent encore une fois.

Conclusion

La programmation à l'école et la programmation dans le monde réel sont si fondamentalement différentes au point qu'il y a très peu de chevauchement. CS vous préparera au développement de logiciels "réels", comme l’entraînement en athlétisme préparerait une armée au combat.

back2dos
la source
11
C'est fondamentalement ce que j'allais répondre. À l'école, tu connais le problème et tu connais la solution. Dans le "monde réel", vous connaissez rarement la solution et souvent même le véritable problème.
Bob
20

Ils font face à un aspect différent du problème:

Les universités se concentrent principalement sur la "science de la programmation" et étudient par conséquent la manière de rendre efficace un algorithme particulier ou de développer des langages sur mesure pour rendre certains paradigmes plus expressifs. L’industrie se concentre principalement sur la production de biens devant être vendus. Il doit s'appuyer sur des "outils" qui ne sont pas seulement les langages et les algorithmes, mais aussi les bibliothèques, les frameworks, etc.

Cette différence de "focus" est ce qui rend un maître académique en C pratiquement incapable d'écrire une application Windows (puisque les API Windows ne sont pas au standard C99!), Se sentant ainsi "incapable de programmer". Mais, en fait, il a toutes les capacités pour apprendre lui-même ce qui lui manque. Quelque chose qui - sans études académiques appropriées (pas nécessairement faite dans les universités) - est assez difficile à trouver.

Emilio Garavaglia
la source
10

Bonnes réponses. Laissez-moi juste ajouter que la programmation académique a tendance à ressembler à un jouet. C'est bon pour enseigner. En tant qu'enseignant, vous essayez de transmettre les idées le plus efficacement possible. L'inconvénient est que la programmation est tellement différente qualitativement qu'il est difficile de combler l'écart.

L'analyse des performances constitue l'un des domaines de différence. J'ai écrit de nombreux articles en essayant de le souligner. L'analyse des performances ne concerne que superficiellement les algorithmes et les mesures. Pour le faire vraiment efficacement, vous devez l’aborder comme un processus de débogage.

Un autre domaine de différence est la maintenabilité. Cela englobe tout, du style à la conception linguistique spécifique à un domaine. Vous ne pouvez le faire efficacement que si vous savez réellement ce que vous essayez de minimiser.

Ces choses ne sont pas enseignées et elles font une énorme différence de productivité.

Mike Dunlavey
la source
1
Je me demande comment ces choses pourraient être enseignées, car elles ont besoin de beaucoup de temps et d’expérience sur le terrain. J'assistais à un cours de génie logiciel où des équipes de 10 étudiants devaient développer un petit logiciel en quelques mois (deux semestres, d'octobre à avril). Cela leur a permis d'avoir une idée de la programmation, de la planification, de la hiérarchisation des exigences et des tâches, de la communication, etc. Mais, bien sûr, c'est peu comparé à ce à quoi ils seront confrontés dans le monde réel. Mais vous ne pouvez pas passer 4 ans à étudier uniquement sur ce sujet.
Giorgio
@Giorgio: Pour les performances, j'ai une base de code préexistante (pas très grande) que je montre comment optimiser via une série d'itérations, en obtenant des facteurs d'accélération importants. C'est une compétence facile à enseigner. Pour les DSL et la facilité de maintenance, j'ai aussi quelques exemples préférés qui pourraient être utilisés pour l'enseignement. Tous les deux pourraient facilement s'intégrer dans un cours semestriel, avec suffisamment d'espace. Donc, je pense que cela pourrait être fait.
Mike Dunlavey
1
Ok, je comprends: utilisez de grands exemples du monde réel et laissez les étudiants y travailler. Très bonne idée.
Giorgio
@Giorgio: J'étais professeur il y a 30 ans, donc je me souviens encore de la façon de le faire. J'ai également mis ces idées dans un livre qui s'est mal vendu, ce qui signifie simplement que j'ai eu le temps de réfléchir et d'expliquer comment tout cela s'emboîte.
Mike Dunlavey
Je n’ai pas beaucoup d’expérience, j’ai été assistante à l’enseignement pendant quelques années au cours de ma thèse. Je travaille maintenant dans une entreprise. En ce qui concerne la programmation à l'université, à mon humble avis, la vérité est quelque part au centre: il existe un enseignement très utile à l'université, mais il est difficile de couvrir tous les problèmes importants qu'un ingénieur en logiciel rencontrera au cours de sa carrière. Avec quelques efforts, vous pouvez réellement enseigner certaines choses du monde réel, comme vous l'avez souligné. Tous les professeurs d'université ne sont pas disposés à le faire, bien sûr.
Giorgio
8

Dans le monde universitaire, la plupart des gens étudient l'informatique ou des cours connexes. Dijkstra a déjà observé que "l'informatique ne concerne pas plus les ordinateurs que l'astronomie, elle concerne les télescopes". Une personne qui étudie en informatique apprend avant tout à devenir un scientifique et non un programmeur. En tant que programmeur, il restera amateur et la transition vers un programmeur professionnel est donc ardue.

thiton
la source
8

Mise à jour: Comme si quelqu'un lisait dans mon esprit: attentes des diplômés versus réalité ...

Ma prise, deux autres facteurs:

Taille du problème : Dans le monde universitaire, je devais principalement développer un logiciel "à partir de zéro", ce qui voulait dire que la plupart du temps, le plus grand programme que j'avais rencontré était le plus grand que j'avais écrit. Cela met moins l'accent sur la capacité nécessaire pour gérer et gérer la complexité résultant de la interaction de différents logiciels. Si j'avais conscience de l'effort nécessaire pour comprendre la complexité, j'aurais peut-être choisi de ne pas être dans l'industrie du tout.

Lecture VS Rédaction : Un autre effet secondaire de la taille du problème est que, souvent, dans le "monde réel", nous sommes exposés à des travaux écrits par d'autres personnes, que ce soit à des fins de maintenance (je n'ai effectué aucune maintenance dans le monde universitaire), d'extension ou simplement. division du travail. Par conséquent, lire le code devient beaucoup plus important que l'écrire.

Une proposition pour améliorer la formation à la programmation : les universités devraient nous exposer davantage à des situations réelles sans revenir à la formation professionnelle. Les médecins doivent faire face à un cadavre à un moment donné pour voir s'ils sont «faits pour ça» (j'ai entendu parler de personnes qui abandonnaient le cours après cette expérience). Si j'avais vu au début de la vingtaine un projet de 20K LOC composé de différents styles de programmation, que je devais comprendre en un jour et modifier un bogue en trois, j'aurais peut-être envisagé d'autres choix de carrière, mais probablement pas.

Dimitrios Mistriotis
la source
Pour étendre votre métaphore et à partir de ma propre expérience en médecine: les docteurs apprennent les concepts généraux en faculté de médecine, mais nous apprenons tous les détails pratiques et les raccourcis du monde réel dans la formation en cours d'emploi en tant que stagiaires et résidents.
Aéroglisseur plein d'anguilles
2
Cette! La première fois que vous plongez dans un million de bases de code LOC, vous réalisez que cela ne ressemblera en rien à ce que vous avez fait à l'université. Il est clair très rapidement que vous ne comprendrez jamais l'intégralité de cette base de code, et tout ce que vous comprenez doit provenir de la lecture et de la compréhension du code d'autrui, plutôt que de l'architecture et de l'écriture du vôtre.
Roman Starkov
4

La plus grande différence que j'ai trouvée entre la programmation académique et industrielle concerne la robustesse. La plupart des gens ont expérimenté le paradoxe "ça marche pour moi" dans leur carrière, et ceci est une extension de cette condition. En milieu universitaire, l’accent est mis sur les algorithmes et les fonctions et l’importance accordée à la convivialité et à la stabilité du logiciel dans les conditions de tous les jours.

Par exemple, dans mon bureau, nous avons un ingénieur qui s’occupera du logiciel et qui maîtrisera les collisions provoquées par des conditions difficiles. Il cliquera sur un bouton aussi vite qu'il le pourra jusqu'à ce que quelque chose se bloque ... si une opération prend trop de temps, il commence simplement à cliquer de manière aléatoire sur l'écran (par frustration? IDK ...)

Changer nos philosophies de programmation afin de rendre les choses "Steve proof" a généralement amélioré la stabilité de notre application.

Dave Nay
la source
3

Je n'ai aucune expérience personnelle de la formation en programmation à l'école - j'étais un majeur en anglais. Posez-moi des questions sur Keats et Byron! - mais j'ai reçu plusieurs nouveaux diplômés, que je les ai éduqués et encadrés dans le monde du développement de logiciels professionnels. Je peux donc parler de ce point de vue.

D'après mon expérience, TOUTES leurs études ont été consacrées à la programmation. Leurs compétences ont varié de zéro à négligeable. Leur capacité à s'auto-diriger était inexistante même chez les plus qualifiés d'entre eux. Leur pensée n'était pas seulement à petite échelle; ils pensaient réellement en miniature. Un système comprenant plus d'une vingtaine de lignes de code les faisait tomber entièrement en morceaux.

Mais tu sais quoi? Ils ont acquis un intérêt , et c'est un gros problème. Un intérêt vaut beaucoup . Je peux travailler avec quelqu'un qui est intéressé. Je peux en faire un développeur, à condition qu'ils veuillent bien en devenir un. Enfer, c'est tout ce que j'ai commencé avec. Cela et une appréciation des romanciers américains post-modernes.

Dan Ray
la source
2

Dans le monde universitaire,

DÉSAVANTAGES

  • Nous avons des délais qui consistent principalement à marquer des points.
  • Les bugs ne causent pas vraiment de problèmes, car la plupart des projets ne sont jamais utilisés dans des applications du monde réel.

PLUS

  • Nous avons suffisamment de temps pour la recherche.
  • S'éloigner des objectifs initiaux ne cause pas beaucoup de problèmes.

Dans l'industrie,

  • Nous travaillons sur des projets qui seront effectivement utilisés par les entreprises.
  • Nous travaillons sous le stress de l'évolution constante des exigences de nos clients.
  • Les délais sont rarement flexibles, car cela pourrait entraîner d’énormes pertes financières pour la société de logiciels ainsi que pour les clients.

Regarde ça:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

SHOUBHIK BOSE
la source
Je vais devoir être en désaccord sur la partie "être réellement utilisé". Au début du milieu des années 90, j'ai passé cinq ans dans trois entreprises différentes, grandes, petites et moyennes, et rien de ce que j'ai écrit n'a été mis en production. Je ne pense pas que ce soit une expérience si rare.
Bruce Ediger
2

La programmation académique concerne davantage le code vous-même. Ceci est important pour apprendre comment cela fonctionne. La qualité du code et le contrôle de révision ne comptent pas beaucoup. À quelques exceptions notables près, le code n'a pas de durée de vie au-delà de l'attribution. La portée des projets a tendance à être très limitée et peu probable.

Dans le monde réel, vous devriez avoir le moins de code original possible. Beaucoup de code est développé par les équipes. Il est préférable d’utiliser des routines de bibliothèque que de le coder vous-même. La qualité du code et le contrôle de révision deviennent plus importants. Le code a tendance à avoir une durée de vie bien au-delà de ce à quoi on s'attendait à l'origine. La portée du projet est généralement assez large et a tendance à s’inspirer si elle n’est pas gérée.

BillThor
la source
1

Réellement,

il est impossible de faire une distinction complète entre la programmation de niveau universitaire et la programmation du monde réel.

Je dirais que la plus grande différence est peut-être la suivante: dans la programmation réelle, il faut en savoir plus que sur la programmation et pouvoir s'adapter rapidement.

Selon le secteur dans lequel vous travaillez, vous devez vous conformer à ses lois.

Michael a seulement touché le sommet de l'iceberg en énonçant des tâches liées à la programmation, que je classerais comme étant des tâches faciles (si vous valez la pâte que vous êtes payé).

En général, vous rencontrez au moins deux défis par sujet dans un secteur:

  • Lois applicables (ex. Confidentialité des clients pour des raisons médicales)
  • Savoir-faire du sujet (ex. Système de facturation-taxe, inventaire, gestion des ressources, régimes médicaux, normes de l'industrie)
  • Exigences du client inexistantes, inexistantes ou différentes des normes de l'industrie / lois en vigueur

Si vous comparez un projet de programmation de niveau doctoral en recherche à un projet dans le monde réel, il est probable qu’ils soient très similaires en termes de difficulté, de savoir-faire au niveau débutant, etc.

La seule différence est alors que le projet du monde réel

  • a un client
  • a des budgets (temps, argent, ressources humaines)

C'est un jeu de balle différent quand quelqu'un d'autre établit les règles :)

Schalk
la source
0

Si vous examinez les matières étudiées en informatique dans le monde universitaire, vous constaterez qu'environ la moitié du temps perdu en mathématiques, en sciences, en cours au choix, etc., Optimisation, systèmes d’exploitation, électronique numérique et quelques autres cours liés à l’industrie tels que la programmation C et la programmation Web.

La plupart des sujets mentionnés ci-dessus sont agréables à connaître, mais ne fourniront pas non plus une base solide sur ce qui est requis dans les TI au quotidien.

Prenez les exigences de la programmation Web de Microsoft (c'est-à-dire les zones nécessaires à une personne pour être un membre de l'équipe productive dans une organisation):

1- C # .NET ou VB.NET

2- ASP.NET

3- HTML et CSS

4- SQL Server (ou une autre base de données)

5- Programmation et conception d'applications OO

6- Script Java

7- cadre MVC

8- Quelques expositions aux outils de contrôle de source

9- Quelques expositions aux outils de tests automatisés

Outil de suivi de 10 bogues

11-Concepts de commerce électronique (facultatif)

12-ORM

13-Quelques compétences en analyse d'entreprise

14-Quelques compétences en communication

15-Probablement, quelques bases du cloud computing

Comme vous pouvez le constater, la plupart des exigences ci-dessus sont rarement axées (vous pouvez ne recevoir qu'un seul cours au maximum) pendant les études collégiales ou universitaires.

On ne peut pas complètement blâmer les institutions, car il existe de nombreuses technologies de ce type et elles continuent à évoluer.

La plupart des solutions ci-dessus de Microsoft n’aideront pas ceux qui souhaitent développer des applications en Java.

Le vrai problème est qu’aucune des technologies dont les entreprises ont besoin aujourd’hui n’est jamais entièrement couverte.

Ce qui précède couvre la question de l’adéquation des diplômés aux emplois dans les entreprises, comme la programmation dans un environnement professionnel. Les besoins en recherche de laboratoires, etc. ne sont pas couverts par cette réponse. En outre, d'autres domaines nécessitent davantage de compétences que les précédents, tels que le développement de jeux, le développement intégré, le développement de systèmes en temps réel, etc.

Aucune chance
la source
12
Vous avez 15 articles dans votre liste. J'imagine que je pourrais en ajouter 30 autres. Les universitaires ne sont pas chargés de vous enseigner tout cela, mais plutôt de vous apprendre à trouver votre chemin à travers tout cela. Et aussi, avoir des connaissances qui seront toujours utilisables quand toutes les technologies actuelles seront obsolètes (dans 10 ans?) C'est pour ça que toute la théorie est bonne et non une perte de temps !
Giorgio
2
@ Giorgio, merci pour votre commentaire, votre argument est valide. J'ai explicitement déclaré qu '"on ne peut pas complètement blâmer les institutions". Bien que la question initiale ne concerne pas la nature de la formation universitaire, ma vision personnelle est qu’il existe un énorme fossé entre ce que les universitaires enseignent et ce que l’entreprise attend. Auparavant, la facture pour combler le fossé était payée par l'entreprise au moyen d'une formation en entreprise coûteuse. Avec la forte concurrence et la période difficile que traversent toutes les économies, je me demande qui paiera le prix pour combler ce fossé aujourd'hui?
NoChance
@Emmad Kareem: Oui, il y a un grand fossé, je suis d'accord. Les professeurs d'université n'ont souvent aucune idée de ce qui se passe dans le "monde réel" parce qu'ils se concentrent sur la recherche abstraite. Pourtant, ce sont ces capacités de pensée abstraites qui me permettent maintenant d’apprendre une nouvelle langue en quelques semaines (apprendre Scala en ce moment). Je comprends aussi que peut-être pour vous la question de l’argent est ressentie plus fortement. J'ai grandi en Italie et quand j'étudiais les frais universitaires, je payais environ 200 dollars par an (en plus, nous devions acheter les livres nous-mêmes). J'imagine que c'est très peu comparé à ce que vous payez aux États-Unis.
Giorgio
3
De même, si vous étudiez l'ingénierie et que vous appreniez à construire une voiture, personne ne vous apprendrait à conduire une voiture spécifique: c'est simplement quelque chose qu'ils s'attendent à ce que vous sachiez ou que vous appreniez par vous-même.
Giorgio
1
Perdu? Si vous avez les diplômes que vous prétendez avoir, vous devriez savoir mieux. Même si vous n'êtes pas assis là à programmer des mathématiques avancées, les leçons apprises en l'étudiant se traduisent directement par le fait de "voir" une solution élégante et propre.
Rig
0

Échelle et focalisation
D'après mes expériences, dans un contexte académique, l'ampleur de l'application sur laquelle vous travaillez est beaucoup plus petite, et peut être complétée en un jour ou une semaine, ou peut-être aussi longtemps que le semestre comporte un ou deux programmeurs. -typiquement tout ce que vous écrivez sera un code jetable qui sera jeté après le terme. Dans le monde réel, il est possible que vous travailliez sur une application qu’une équipe plus importante a mis plusieurs mois, voire plusieurs années, à développer pleinement. Vous passez plus de temps à déboguer le code des autres et à essayer de comprendre l'infrastructure d'une base de code, sans jongler avec les éléments existants pour ajouter des exigences nouvelles ou modifiées.

Exigences, intégration, clients
De plus, certains aspects de l'élaboration du code, tels que l'analyse des exigences, les tests d'intégration, etc., ont tendance à être moins représentés dans les projets universitaires. Par souci d'équité, les exigences sont généralement définies par l'instructeur et ne sont pas définies de manière collaborative lors de réunions. Vous n'avez pas tendance à "vendre le client" selon une approche particulière qui n'est pas tout à fait ce qu'il souhaitait, mais contrairement à ses désirs, il est en fait réalisable d'un point de vue technique. Dans un contexte académique, votre client (le correcteur ou l'instructeur) a tendance à avoir une idée assez concrète de ce qu'il veut. Dans le monde réel, vous rencontrerez peut-être des clients qui ne savent pas vraiment ce qu'ils veulent et qui doivent choisir leur cerveau pour comprendre ce qu'ils veulent. devrait être construit.

Jessica Brown
la source
0

Maintenance et maintenabilité

Dans les universités (au moins au niveau du premier cycle), les logiciels sont conçus avec des objectifs à court terme, généralement pour compléter un devoir ou un projet à terme. Une fois l’affectation terminée, le code est jeté et jamais revu.

Dans un environnement professionnel, la plupart des logiciels sont conçus pour une utilisation à long terme. Le logiciel est destiné à être utilisé pendant au moins quelques années et doit être conçu pour être facilement maintenu et mis à jour au fil du temps.

Lié à ceci est le travail de maintenance. La majorité des travaux de programmation professionnels impliquent la mise à jour ou la maintenance des logiciels existants. Les projets dits "green-field" sont l'exception plutôt que la norme.

Ken Liu
la source