Différences entre la programmation à l'école et la programmation dans l'industrie?
Beaucoup d'étudiants, lorsqu'ils obtiennent leur diplôme et obtiennent leur premier emploi, ont l'impression de ne pas vraiment savoir comment programmer, même s'ils ont pu être de bons programmeurs à l'université.
Quelles sont certaines des différences entre la programmation en milieu universitaire et la programmation dans le "monde réel"?
Dans un programme informatique de premier cycle traditionnel, vous apprenez la programmation juste. Mais le monde réel ne veut pas de gens qui sont juste programmeurs. Le monde réel veut de vrais ingénieurs logiciels. Je sais que de nombreuses descriptions de poste ne semblent pas exprimer cette distinction, ce qui ne fait que confondre la question. Dans le monde réel, vous devez pouvoir:
- Rassemblez et analysez les exigences quand elles ne vous sont pas directement transmises
- Concevoir et analyser l'architecture avec des possibilités presque infinies
- Créer des plans de test et agir sur eux pour évaluer et améliorer la qualité d'un système
- Travailler en collaboration sur une équipe de personnes avec des antécédents et des niveaux d'expérience différents
- Estimer et planifier le travail même si vous ne savez pas exactement quoi construire
- Communiquer efficacement avec les parties prenantes 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 parties prenantes
Oh oui, et vous devez également être en mesure d'écrire du code, même si cela ne prend, en moyenne, que 40 à 60% du temps d'un ingénieur logiciel.
Donc, ce n'est pas que les étudiants de premier cycle 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.
À 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 éliminé par la suite)
- Un ensemble d'outils bien défini auquel vous avez été présenté avant la mission
- 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é dans le contexte. Il s'agit d'un ensemble d'exigences contradictoires qui changent au fil du temps et votre solution doit être suffisamment flexible et robuste pour que vous puissiez réagir à ces changements dans un délai acceptable.
- Les outils doivent être choisis par vous. Peut-être qu'il y a déjà quelque chose utilisable dans la base de code de votre équipe vieille de 10 ans, peut-être qu'il y a un projet open source, ou peut-être une bibliothèque commerciale ou peut-être devrez-vous l'écrire vous-même.
- Pour déterminer si l'itération actuelle de votre logiciel est une amélioration (car vous n'êtes presque jamais réellement terminé avec un projet logiciel), vous devez effectuer des tests de régression et des tests d'utilisabilité, ce qui signifie généralement que les exigences floues, complexes, contradictoires et intégrées au contexte changent à nouveau.
Conclusion
La programmation à l'école et la programmation dans le monde réel sont si intrinsèquement différentes au point où il y a en fait très peu de chevauchement. CS vous préparera au développement de logiciels "du monde réel" comme l'entraînement d'athlétisme préparerait une armée au combat.
Ils font face à un aspect différent du problème:
Le milieu universitaire est principalement axé sur la "science de la programmation", étudiant ainsi la façon de rendre efficace un algorithme particulier ou de développer des langages adaptés pour rendre certains paradigmes plus expressifs. L'industrie se concentre principalement sur la production de choses qui doivent être vendues. 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 "concentration" est ce qui rend un maître académique en C pratiquement incapable d'écrire une application Windows (puisque nous les API Windows ne sont pas dans la norme C99!), Se sentant ainsi "incapable de programmer". Mais, en fait, il a toutes les capacités pour apprendre par lui-même ce qui lui manque. Quelque chose qui - sans études académiques appropriées (pas nécessairement faites dans le milieu universitaire) - est assez difficile à trouver.
Bonnes réponses. Permettez-moi d'ajouter que la programmation académique a tendance à être presque à l'échelle du jouet. C'est bon pour l'enseignement. 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.
Un domaine de différence réside dans l'analyse des performances. 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 de langage spécifique au 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é.
Mise à jour: comme si quelqu'un lisait dans mes pensées: attentes des diplômés contre réalité ...
Ma prise, deux autres facteurs:
Taille du problème : Dans le milieu universitaire, je devais principalement développer des logiciels "à partir de zéro", ce qui signifiait que la plupart du temps, le plus gros programme que j'avais rencontré était le plus grand que j'ai écrit. Cela met l'accent sur la capacité nécessaire pour gérer et faire face à la complexité qui émerge de différents logiciels interagissant ensemble. Si j'étais conscient de l'effort nécessaire pour comprendre avec complexité, j'aurais peut-être choisi de ne pas être du tout dans l'industrie.
Lecture VS écriture : 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, soit à des fins de maintenance (je n'ai effectué aucune maintenance dans le monde universitaire), soit pour une extension, soit simplement pour une division du travail. Par conséquent, la lecture du code devient beaucoup plus importante que son écriture.
Une proposition pour une meilleure éducation à la programmation: Le milieu universitaire devrait nous exposer davantage aux situations du monde réel sans régresser vers 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 des histoires de personnes abandonnant le cours après cette expérience). Si j'avais vu au début de la vingtaine un projet LOC de 20K comprenant différents styles de programmation, que je devais comprendre en un jour et corriger un bug en trois, j'aurais peut-être envisagé d'autres options de carrière - mais probablement pas.
Dans le monde universitaire, la plupart des gens étudient l'informatique ou des cours connexes. Dijkstra a un jour observé que "l'informatique ne concerne pas plus les ordinateurs que l'astronomie ne concerne les télescopes". Une personne qui étudie l'informatique apprend d'abord et avant tout à devenir un scientifique et non un programmeur. En tant que programmeur, il restera un amateur et la transition vers un programmeur professionnel est donc difficile.
La plus grande différence que j'ai trouvée entre la programmation académique et la programmation industrielle concerne la robustesse. Presque tout le monde a connu le paradoxe "ça marche pour moi" dans sa carrière, et c'est une extension de cette condition. Dans le monde universitaire, l'accent est mis sur les algorithmes et les fonctions et peu d'attention est accordée à l'utilisabilité et à la stabilité du logiciel dans des conditions quotidiennes.
Par exemple, à mon bureau, nous avons un ingénieur qui prendra le logiciel et est un maître dans les accidents dus aux conditions des coins. Il cliquera sur un bouton aussi vite que possible jusqu'à ce que quelque chose plante ... si une opération prend trop de temps, il commencera simplement à cliquer au hasard sur l'écran (par frustration? IDK ....)
Changer nos philosophies de programmation pour que nous rendions les choses "à l'épreuve de Steve" a en général amélioré la stabilité de notre application.
Je n'ai aucune expérience personnelle avec la formation en programmation à l'école - j'étais une majeure en anglais. Posez-moi des questions sur Keats et Byron! - mais j'ai reçu plusieurs nouveaux diplômés et les ai élevés et encadrés dans le monde du développement logiciel professionnel. Je peux donc parler de ce point de vue.
D'après mon expérience, vraiment tout ce qu'ils ont obtenu de leur scolarité était un intérêt pour la programmation. Leurs compétences variaient 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 en fait en miniature. Un système comprenant plus d'une vingtaine de lignes de code les a fait 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 est beaucoup. Je peux travailler avec quelqu'un qui est intéressé. Je peux les transformer en un développeur, à condition qu'ils viennent à moi avec un intérêt à en être un. Enfer, c'est tout I a commencé avec. Cela et une appréciation pour les romanciers américains post-modernes.
Dans le milieu universitaire,
DÉSAVANTAGES
- Nous avons des délais qui consistent principalement à marquer des points.
- Les bogues ne causent pas vraiment de problèmes, car la plupart des projets ne sont jamais utilisés dans des applications réelles.
PLUS
- Nous avons amplement le temps pour la recherche.
- Se balancer par rapport aux 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 des exigences des clients en constante évolution.
- 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
La programmation académique concerne davantage le codage vous-même. Ceci est important pour apprendre comment cela fonctionne. La qualité du code et le contrôle des révisions ne comptent pas beaucoup. À des exceptions notables, le code n'a pas de durée de vie au-delà de l'affectation. La portée des projets a tendance à être assez limitée et à ne pas se glisser.
Dans le monde réel, vous devriez avoir le moins de code original possible. Beaucoup de code est développé par les équipes. Il vaut mieux utiliser des routines de bibliothèque que de le coder vous-même. La qualité du code et le contrôle des révisions deviennent plus importants. Le code a généralement une durée de vie bien au-delà de ce qui était initialement prévu. La portée du projet est généralement assez large et a tendance à fluer de manière significative si elle n'est pas gérée.
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 pourrait être la suivante: dans la programmation du monde réel - vous devez en savoir plus que la programmation et vous devez pouvoir vous adapter rapidement.
Selon le secteur dans lequel vous travaillez, vous devez vous conformer à ses lois.
Michael n'a touché que la pointe de l'iceberg en déclarant des tâches liées à la programmation, que je qualifierais de faciles (si vous valez la pâte que vous êtes payé).
En général, vous rencontrerez au moins quelques défis par sujet dans une industrie:
- Lois applicables (par 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 manquantes ou inexistantes ou différentes des normes de l'industrie/lois applicables
Si vous comparez un projet de programmation de doctorat de recherche à un projet réel, il est probable qu'ils soient très similaires en termes de difficulté, de savoir-faire de niveau d'entrée, etc.
La seule vraie différence est 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 fait les règles :)
Échelle et mise au point
D'après mes expériences, dans un milieu universitaire, l'échelle de la demande sur laquelle vous travaillez est généralement beaucoup plus petite, quelque chose qui peut être complété en une journée ou une semaine, ou peut-être aussi longtemps que le semestre par un ou deux. progammeurs - généralement tout ce que vous écrivez sera du code à jeter qui sera jeté après le terme. Dans le monde réel, vous pouvez vous retrouver à travailler sur une application qu'une équipe plus importante a mis des mois, voire des années, à développer pleinement. Vous passez beaucoup plus de temps à déboguer le code des autres et à essayer de comprendre l'infrastructure d'une base de code, jongler sans casser les parties existantes pour ajouter des exigences nouvelles ou modifiées.
Exigences, intégration, clients
De plus, certains aspects du développement du code, tels que l'analyse des exigences, les tests d'intégration, etc., ont tendance à être moins représentés dans les projets académiques. Par souci d'équité, les exigences sont généralement déjà établies pour vous par l'instructeur, et ce n'est pas décidé en collaboration lors des réunions. Vous n'avez pas tendance à "vendre le client" selon une approche particulière qui n'est pas tout à fait ce qu'ils voulaient, mais contrairement à leurs désirs, c'est réalisable d'un point de vue technique. Dans un environnement académique, votre client (le correcteur ou l'instructeur) a généralement une idée assez concrète de ce qu'il veut, dans le monde réel, vous pouvez rencontrer 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.
Maintenance et maintenabilité
Dans le milieu universitaire (au moins au niveau du premier cycle), le logiciel est construit avec des objectifs à court terme à l'esprit, généralement pour terminer une tâche à domicile ou un projet de trimestre. Une fois l'affectation terminée, le code est jeté et jamais revu.
Dans un cadre professionnel, la plupart des logiciels sont écrits avec une utilisation à long terme à l'esprit; le logiciel est destiné à être utilisé pendant au moins quelques années et doit être construit pour être facilement entretenu et mis à jour au fil du temps.
Lié à cela est le travail de maintenance. La majorité du travail de programmation professionnelle implique la mise à jour ou la maintenance des logiciels existants. Les projets dits "verts" sont l'exception plutôt que la norme.
Si vous regardez les sujets étudiés en informatique dans les universités, vous trouverez environ la moitié du temps perdu en mathématiques, en sciences, au choix, etc. et l'autre moitié sur des sujets académiques tels que: conception de compilateurs, théorie des algorithmes, architecture informatique, 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 directement une solide expérience de ce qui est requis dans l'informatique quotidienne.
Prenez les exigences de programmation Web de Microsoft (c'est-à-dire les zones requises par quelqu'un pour être un membre d'équipe productif 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- OO programmation et conception d'application
6- Java Script
7- Framework MVC
8- Une certaine exposition aux outils de contrôle des sources
9- Une certaine exposition aux outils de test automatisés
Outil de suivi des 10 bogues
11-Concepts du commerce électronique (facultatif)
12-ORM
13-Quelques compétences en analyse commerciale
14-Quelques compétences en communication
15-Probablement, quelques principes fondamentaux du cloud computing
Comme vous pouvez le constater, la plupart des exigences ci-dessus sont rarement axées sur (vous pouvez obtenir 1 cours dans certains au plus) pendant les études collégiales/universitaires.
On ne peut pas entièrement blâmer les institutions car il existe de nombreuses piles de technologies de ce type et elles continuent de changer.
La plupart des éléments ci-dessus de Microsoft n'aideront pas quelqu'un qui souhaite développer des applications en Java.
Le vrai problème est qu'aucune des piles technologiques dont l'entreprise a 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 à des emplois en entreprise comme la programmation en environnement des affaires. Les besoins des laboratoires de recherche, etc. ne sont pas couverts par cette réponse. D'autres domaines nécessitent également plus 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.