Mes expériences de stage négatives sont-elles représentatives du monde réel?
Je suis curieux de savoir si mes expériences actuelles en tant que stagiaire sont représentatives de l'industrie réelle.
En arrière-plan, je traverse la majeure partie de deux majors en informatique et une majeure en mathématiques dans une grande université; J'ai suivi toutes les classes et les ai toutes adorées, alors j'aimerais penser que je ne suis pas terrible en programmation. J'ai obtenu un stage dans l'une des principales sociétés de logiciels, et à mi-chemin maintenant, j'ai été choqué par la qualité extraordinairement faible du code. Les commentaires n'existent pas, tout est du code spaghetti, et tout ce qui pourrait être faux est encore pire. J'ai fait une tonne de tutorat/TAing, donc je suis très habitué à lire du mauvais code, mais les principaux produits de l'industrie que j'ai vus l'emportent sur tout cela. Je travaille 10 à 12 heures par jour et je n'ai jamais l'impression d'aller nulle part, car c'est des heures interminables à essayer de trouver une API non documentée ou de déterminer le comportement d'une autre partie du produit (complètement non documenté). J'ai quitté le travail en détestant le travail tous les jours jusqu'à présent, et je veux désespérément savoir si c'est ce qui m'attend pour le reste de ma vie.
Ai-je tiré une courte paille sur les stages (les chèques de paie absurdement grands impliquent que ce n'est pas un poste de mauvaise qualité), ou est-ce à cela que le monde réel ressemble?
Ils l'appellent le Real World ™ pour une raison.
99% de ce que vous rencontrerez dans le monde réel de l'entreprise sera considéré comme de la merde, et pour une bonne raison que je vais expliquer. Le 1% qui n'est pas considéré comme de la merde finira par devenir de la merde.
# 1 Écrivez le code, # 2 ????, # 3 Profit!
Tout d'abord, les entreprises existent pour générer des bénéfices, elles n'existent pas pour générer des montagnes de code académique parfaitement conçu et vierge, théoriquement parfaitement propre, hébergés dans des référentiels dorés de perfection. Pas même proche, pas même ceux qui vendent du code source qu'ils produisent.
Dans le monde des affaires, le code est un moyen à une fin . Si un code résout un problème commercial et fait plus d'argent qu'il n'en coûte pour créer et maintenir, il est souhaitable pour l'entreprise. Vous employer pour écrire du code n'est qu'une façon pour l'entreprise d'obtenir du code.
Théorie 0 - Pratique ∞
Idéalement, l'entretien devrait être plus une préoccupation, mais ce n'est généralement pas le cas, car à court terme, il ne gagne pas financièrement. À long terme, les logiciels ont généralement un cycle de vie relativement court, en particulier les applications Web, ils sont rapidement obsolètes et réécrits plus souvent.
Les applications métier internes sont celles qui sont perçues comme des projets de zombies sans fin pour de nombreuses raisons basées sur l'élan. Ces projets sont en réalité des succès ils se poursuivent car ils continuent à faire de l'entreprise un profit.
En théorie, il n'y a pas de différence entre la théorie et la pratique. En pratique, il y en a. - Yogi Berra
En théorie, des bases de code parfaitement propres et parfaitement conçues avec des couvertures de code à 100% devraient permettre aux entreprises d'économiser de l'argent, dans la pratique, cela ne revient même pas à fournir quelque chose proche d'un retour sur investissement valide.
Physique du cycle de vie du logiciel
Il existe également une force d'entropie super puissante à l'œuvre dans le monde du logiciel. C'est un trou noir inévitable qui condamne tous les logiciels à dégénérer en Big Ball of Mud .
Plus vous partez d'un BBM mieux c'est, mais chaque système logiciel finira par y arriver avec suffisamment de temps. La vitesse à laquelle vous approchez de l'entropie à 100% est déterminée par le point de départ, la vitesse à laquelle vous accumulez la dette technique et le montant des intérêts.
Les systèmes logiciels dégénèrent et pourrissent à cause de la maintenance, pas à cause de son absence. Un système qui est en place depuis des années sans aucun changement de code par définition répond à toutes ses exigences et objectifs et est un succès.
Ce sont les systèmes qui nécessitent un changement constant car ils ont commencé plus près de l'entropie maximale sont ceux qui sont constamment poussés et poussés et c'est le maintenance qui accélère le changement négatif.
Bon assez c'est bon
Les systèmes à cycle de vie court comme les sites Web qui changent constamment ne bénéficient pas d'une énorme conception initiale coûteuse Couverture de 100% du code dans les tests unitaires, car le temps d'amortissement est trop court pour réduire les coûts.
Les systèmes à long cycle de vie comme la gamme d'applications internes mentionnée ci-dessus, ne bénéficient pas vraiment non plus d'investissements massifs de tests unitaires de couverture de code à 100%, car le taux de changement au cours de la vie du projet approche d'une constante proche de zéro dans un mode non linéaire.
C'est pourquoi fin de vie les plans sont plus importants et les systèmes de remplacement doivent être planifiés juste au moment où quelque chose est sorti, pas quand il a dépassé le niveau d'amorçage de quelques années et n'est pas supportable donc un nouveau système doit être précipité en place.
Ils n'enseignent pas BBM pour autant que je sache, je n'ai jamais rencontré un récent diplômé CS qui savait ce que c'était, encore moins pourquoi cela se produit.
C'est pourquoi Good Enough is Good Enough , rien de plus ou de moins ne l'est.
Logiciels Slumlords
Il y a des seigneurs de taudis immobiliers pour une raison, ils font un profit sur les bâtiments de bidonville délabrés qu'ils possèdent. Ils font plus de bénéfices qu'ils n'en dépensent pour l'entretien incrémentiel de la propriété délabrée. S'ils ne le faisaient pas, ils démoliraient le bâtiment et le remplaceraient. Mais ce n'est pas le cas, car les coûts différentiels sont bien inférieurs à la révision ou au remplacement de l'ensemble du bâtiment. Il y a aussi des clients (locataires) qui sont prêts à payer pour des biens délabrés.
Aucun propriétaire d'immeuble, seigneur des bidonvilles ou non ne dépensera d'argent pour une propriété simplement en raison d'une notion académique de la perfection qui ne se traduit pas par un bénéfice substantiel par rapport au coût associé.
Aucun client ne paiera pour les mises à niveau d'un système logiciel qui fonctionne correctement pour lui. Aucune entreprise ne dépensera de l'argent pour écrire et réécrire du code sans aucun bénéfice substantiel tangible.
Microsoft est le slumlord logiciel le plus dominant et le plus performant qui soit. Windows n'a commencé à obtenir des réécritures fondamentales importantes que très récemment. Et ils n'ont toujours pas abandonné tout le code hérité du noyau. Cela n'a aucun sens pour eux, les gens sont plus que disposés à accepter la barre basse des attentes qu'ils ont fixées au cours de la dernière décennie.
Pronostic
C'est un modèle depuis plus de 20 ans que je travaille dans le développement de logiciels. Cela ne changera pas de sitôt. Ce n'est pas la façon dont les gens veulent que ce soit hors d'un système de croyance, c'est une réalité de forces externes sur une entreprise. Les affaires conduisent à la prise de décision, les bénéfices ne sont pas mauvais, ils paient votre salaire, la vision à court ou à long terme est sans importance, c'est une industrie à court terme en constante évolution par définition. Quiconque plaide contre assez bon pour faire du profit ne comprend pas les affaires.
J'ai passé 15 ans à consulter et j'ai appris très rapidement que assez bien était juste cela, tout le reste me coûtait de l'argent. Oui, je voulais que les choses soient parfaites, mais à moins que vous ne vendiez une base de code, 99,99999% du temps vous vendez une solution , tout ce préfet le code élégant et propre est perdu et vous venez de perdre votre temps, vous ne serez jamais remboursé.
Progrès et espoir
Les méthodologies agiles sont un bon pas dans la bonne direction, du moins philosophiquement. Ils abordent le chaos et le changement constant en tant que citoyen de première classe et l'acceptent. Ils rejettent les pratiques dogmatiques, reconnaissant que les méthodologies et les pratiques devraient changer ainsi que les exigences et les technologies.
Ils acceptent l'entropie qui est introduite par le manque de temps ou les exigences changeantes, le changement de personnel et la vivacité d'un système logiciel avec le concept de dette technique.
Mais Agile n'est pas une panacée, cela ne changera pas les lois fondamentales de la physique et les bases de code pourriront malgré tout. Il appartient à la direction de planifier la lutte contre la pourriture avant qu'elle ne devienne complètement incontrôlable et impossible à gérer.
Agile lorsqu'il est fait correctement, aide à gérer l'entropie, à la ralentir, à la suivre, à la mesurer et à la gérer de manière planifiée. Ça ne l'arrêtera pas!
Décision de carrière
Si c'est un vrai problème philosophique pour vous, vous devriez probablement envisager d'autres choix de carrière, car la façon dont les choses fonctionnent a un mérite commercial valable derrière cela. Les projets Open Source n'ont pas de meilleurs antécédents, et dans de nombreux cas, le code est encore pire que la plupart des codes d'entreprise que j'ai vus.
Je suis curieux de savoir si mes expériences actuelles en tant que stagiaire sont représentatives de l'industrie réelle.
Non ça ne l'est pas. Il est représentatif de votre niveau de carrière et de votre expérience. Cela fait partie de l'apprentissage du fonctionnement des entreprises dans une perspective de contrôle qualité interne.
En arrière-plan, je traverse la majeure partie de deux majors en informatique et une majeure en mathématiques dans une grande université; J'ai suivi toutes les classes et les ai toutes adorées, alors j'aimerais penser que je ne suis pas terrible en programmation. J'ai obtenu un stage dans l'une des principales sociétés de logiciels, et à mi-chemin maintenant, j'ai été choqué par la qualité extraordinairement faible du code.
Vos compétences, votre expérience, votre formation n'ont aucun impact sur la qualité du travail effectué par les autres. Tout simplement parce que vous n'avez pas le pouvoir de modifier ces pratiques. Peu importe que vous soyez bon ou mauvais à l'université. Cela ne change rien au fonctionnement actuel de l'entreprise pour laquelle vous travaillez. Donc, même si c'est génial, vous avez tout cet arrière-plan. C'est vraiment pour votre propre avantage et non pour le leur. C'est pourquoi il est important d'étudier ce que vous aimez.
J'ai obtenu un stage dans l'une des principales sociétés de logiciels, et à mi-chemin maintenant, j'ai été choqué par la qualité extraordinairement faible du code. Les commentaires n'existent pas, tout est du code spaghetti, et tout ce qui pourrait être faux est encore pire. J'ai fait une tonne de tutorat/TAing, donc je suis très habitué à lire du mauvais code, mais les principaux produits de l'industrie que j'ai vus l'emportent sur tout cela.
Ce que j'ai appris au cours de mes nombreuses années de programmation, c'est qu'il y a une différence entre la "qualité du code" et le "code acceptable". La vérité est que soit une personne autorisée trouve le code source dans un état acceptable, soit elle le trouve inacceptable mais nécessaire. Ce serait bien si nous pouvions tous nettoyer les projets dans lesquels nous nous impliquons. Il n'est souvent pas dans l'intérêt ou le budget des entreprises d'allouer des ressources pour faire ce travail. Des arguments logiques peuvent être avancés jusqu'à ce que le soleil se lève le lendemain pour expliquer pourquoi ce serait une bonne chose à corriger, mais lorsque la direction a décidé que l'état actuel est "acceptable", alors peu de choses peuvent être faites. Tout est directement lié à qui dirige les choses. Soit ils apprécient la bonne qualité interne, soit ils ne le font pas. Vous l'appréciez clairement et cet état actuel vous dérange donc.
Vous trouverez des exemples de ce type de problème dans toute industrie qui dépend du contrôle qualité interne. Du développement de logiciels à la fabrication. Vous devez apprendre à voir cela non pas comme un problème, mais simplement comme l'état actuel de leur code source. C'est comme ça, il faut X nombre de minutes pour trouver quelque chose, il faut X nombre de minutes pour réparer quelque chose.
L'entreprise ne se soucie pas de ce temps supplémentaire ou la juge acceptable.
Je travaille 10 à 12 heures par jour et je n'ai jamais l'impression d'aller nulle part, car c'est des heures interminables à essayer de trouver une API non documentée ou de déterminer le comportement d'une autre partie du produit (complètement non documenté). J'ai quitté le travail en détestant le travail tous les jours jusqu'à présent, et je veux désespérément savoir si c'est ce qui m'attend pour le reste de ma vie.
Pourquoi était-il acceptable pour vous de consacrer de longues heures à l'université pour étudier un sujet, mais maintenant il n'est pas acceptable de consacrer de longues heures pour étudier le code source? Je suis sûr que l'employeur vous a embauché parce qu'il pensait que vous pouviez le gérer.
Permettez-moi de vous conseiller. Les bons développeurs savent quand demander de l'aide à leurs coéquipiers suivants. Ne pensez pas que les réponses sont toujours dans le code. Je me suis sauvé des heures en posant simplement quelques questions aux gens. On dirait que vous avez besoin d'aide pour vous mettre à niveau.
Deuxièmement, nous ne connaissons pas les conditions de travail. Travailler de longues heures fait partie de la vie de nombreuses industries. Que vous devez résoudre vous-même, mais je peux vous le dire. Détester son travail n'est jamais un bon signe. Vous devez gérer ce sentiment et aller à la racine de celui-ci. Je suis désolé que vous trouviez cette expérience négative.
Ai-je tiré une courte paille sur les stages (les chèques de paie absurdement grands impliquent que ce n'est pas un poste de mauvaise qualité), ou est-ce à cela que le monde réel ressemble?
Tu te débrouillais très bien à l'école, mais maintenant tu as un stage et tu ne vas pas si bien. On dirait que vous êtes déjà dans le monde réel. Cela fait partie de la vie. La question est, qu'allez-vous faire à ce sujet? Que mon ami, c'est la seule chose qui compte. Nous ne pouvons pas vous dire quoi faire. Vous devez vous faire votre propre opinion.
Je peux vous dire qu'il semble que votre expérience à votre âge était bien meilleure que toutes les opportunités que j'ai eues. La vie pour moi dans les années 90 était une lutte pour payer le loyer et trouver mon prochain contrat. Considérez-vous chanceux.
Après 25 ans et une variété d'entreprises et d'industries, je peux dire:
Oui, c'est assez courant.
. c'est vraiment censé faire. J'ai jeté l'émotion pour vous là-bas - il est normal de ressentir cela à propos du code que vous rencontrez!
Le code que vous voyez aura souvent subi des itérations sans fin par différents programmeurs avec différentes approches et normes et différentes conventions de dénomination, etc. etc.
Ce qui se passe cependant, c'est que la pression $ est toujours active. Il est toujours tentant de décrire comment et pourquoi un meilleur code est le seul moyen à long terme, mais dans de nombreux emplois, l'horloge tourne pour une solution rapide à court terme. Un ingénieur ne prend que peu de temps pour détruire les normes d'un projet. Il faut un très bon gestionnaire qui sait empêcher cela et défendre la bonne approche (lorsque cela est raisonnablement possible) pour vraiment y remédier.
Une chose est sûre, le terme "bon code" est tout simplement trop subjectif pour être utile. Ce n'est pas subjectif pour vous bien sûr, vous pouvez lister les raisons/éléments spécifiques. Cependant, d'autres personnes listent différents éléments et priorités, certains même pas techniques, qu'ils jugent importants , et donc subjectifs.
Comme Drekka, cela commence à paraître déprimant, alors laissez-moi essayer de devenir un peu plus positif, car il est certainement vrai que: -
- Il existe des organisations, souvent celles qui ont les plus grandes composantes techniques qui font les bonnes choses.
- Plus l'entreprise est récente ... et le code ... plus elle est propre . les spaghettis poussent à cause du temps et des gens.
- Certaines personnes font du TDD et du BDD, d'autres pas. La gamme est immense.
- Après environ 10 ans, actuellement, l'ensemble de la base technologique change afin que ceux qui restent dans l'industrie aient du mal à suivre le rythme comme les débutants.
Enfin, comme le souligne Anthony Blake, il y a toujours 3 facteurs: le temps, le coût et la qualité.
J'aime l'expression associée: "pick 2"!
Il y a beaucoup d'opinions à ce sujet car les expériences de chacun sont différentes.
Le mien est qu'environ la moitié des développeurs que je rencontre sont bien intentionnés, mais de capacité moyenne. Il y a un petit groupe de personnes brillantes au sommet, et un petit groupe au fond qui essaient, mais devraient essentiellement faire autre chose parce qu'ils ne comprennent pas vraiment. Malheureusement, il existe également un autre petit groupe d'imbéciles incompétents qui pensent qu'ils sont bien plus intelligents que tout le monde et sont généralement très conscients de la façon dont vous devriez les suivre.
En ce qui concerne les projets, je me suis lancé dans de nombreux emplois et on m'a immédiatement demandé de "gérer" un projet établi, généralement celui dont l'entreprise venait de découvrir qu'il avait vraiment besoin après avoir perdu le dernier développeur. Je trouve généralement exactement ce que vous avez décrit ci-dessus - des spaghettis sans papiers, sur-conçus et buggés. Parfois, je peux le réparer, parfois je recommence. Il n'a même pas besoin d'être de l'ancien code, je l'ai trouvé sur de nouveaux projets sur lesquels on m'a demandé de "m'aider".
Vous devez prendre à cœur le fait que la plupart des entreprises vont donner aux stagiaires des emplois de merde. Les plus amusants viennent après que vous ayez fait deux choses: 1 - vous avez fait vos preuves et 2 - vous avez pris le temps de travailler sur autre chose que de corriger les erreurs des autres. En d'autres termes, vous devez faire preuve de capacité et d'initiative.
La véritable astuce pour gérer le mauvais code consiste à déterminer ce qui est récupérable et ce qui ne l'est pas. Cela vient de l'expérience et de la recherche.
L'autre option de carrière que vous avez est d'arrêter de travailler pour des entreprises établies et de chercher à travailler dans des startups. Ensuite, il n'y aura pas de code hérité de merde à maintenir, vous aurez donc la possibilité d'aider à construire quelque chose de mieux. L'inconvénient est que la pression à livrer exercée sur les projets de démarrage signifie souvent que les raccourcis et les hacks sont utilisés alors qu'ils ne devraient pas l'être.
Les programmeurs sont trop souvent disposés à contracter des dettes technologiques afin de livrer tôt ou à temps. Malheureusement, l'impact de cette dette technologique est souvent passé sous silence, minimisé, ignoré ou rejeté par les développeurs et la direction jusqu'à ce qu'il soit trop tard et qu'ils soient en difficulté.
Désolé si cela semble déprimant. Je suis sûr que quelqu'un d'autre peut faire un travail plus positif. :-)
Il y a d'excellentes réponses ici, mais permettez-moi d'ajouter ma part;
Bienvenue dans le monde réel - malheureusement, c'est très courant.
Reportez-vous au schéma ci-dessous;
Avec les logiciels d'entreprise, vous ne pouvez en choisir que 2 ou plus, et vous devez en sacrifier un.
Comme vous semblez l'avoir découvert, la majorité du monde de l'entreprise va avec la vitesse et le prix.
Pas totalement indicatif de l'industrie, mais de mon expérience limitée de 5 ans et plus. Je travaillerais pendant votre stage et prendrais autant de leçons que possible de l'expérience. Recherchez les caractéristiques et les indicateurs. Par exemple, pour votre prochain poste, vous devrez sans aucun doute passer par une série d'entretiens. Ce processus est une voie à double sens et vous donne la possibilité de vous faire une idée de l'entreprise. Ceci est d'une importance vitale et conduira probablement à votre propre bonheur et bien-être.
Pour résumer les choses, repérez les signes révélateurs;
- Qui dirige l'entreprise? Est-ce un gestionnaire unique, l'équipe marketing (si c'est le cas, restez à l'écart), l'équipe de développement, etc. Cet angle signifie que vous pourriez obtenir plus ou moins de levier pour les projets, le temps passé sur les projets, etc.
- Y a-t-il une appréciation technique? Regardez comment la direction, le superviseur et les membres de l'équipe se traitent. J'ai été dans une interview où les managers ont fait toutes sortes de mouvements des sourcils une fois que le responsable technique a commencé à parler. Après cela et après avoir appris qu'ils n'utilisaient pas le contrôle de code source - vous ne pouviez pas me montrer la porte assez rapidement.
- Objectif commercial? L'entreprise vit-elle au jour le jour, comme dans les objectifs financiers quotidiens, ou a-t-elle un plan à long terme dont vous faites partie? Le développement de logiciels se fait généralement sur des mois, donc avoir une entreprise à caractère schizophrène conduit généralement à des logiciels en désordre.
- Creusez beaucoup - lorsque vous posez des questions techniques et voyez si les gens se mélangent. Contrôle des sources, contrôle des documents, processus de publication, rapports de bogues, style de gestion, conditions générales, etc.
Alors vivez et apprenez, et pensez à votre prochain rôle. Avoir une mauvaise expérience n'est pas si mal que ça, car vous serez mieux informé sur le monde du travail et des affaires.
Eh bien, je suis à la veille de ma deuxième décennie dans l'entreprise, et je peux vous dire que le code propre parfait se produit très rarement, et quand cela se produit, il ne reste pas longtemps de cette façon. Dans l'ensemble, vous vous retrouverez constamment à essayer de réparer les erreurs du passé, tout en étant (malheureusement) contraint par des contraintes de temps et un manque de leadership à commettre les erreurs du présent.
À moins que vous ne soyez dans un type de logiciel très spécifique, la pression pour obtenir un produit fonctionnel à la porte l'emporte sur toutes les autres préoccupations, et l'optimisation au-delà d'un certain point est considérée comme inutile. Si le programme s'exécute en 5 minutes et que nous n'en avons besoin que pour l'exécuter en 5 minutes, personne ne vous accordera quelques semaines pour réduire le temps d'exécution à 2 minutes.
Si, par miracle, vous avez cette confluence parfaite de gestion compétente, un objectif clair, de l'argent, du talent et du temps, et vous produisez un produit propre et supérieur ... La seule façon qu'il en sera ainsi si vous - ne le touchez plus jamais. La maintenance et l'extension reçoivent presque toujours une très faible priorité, des modifications sont toujours nécessaires avec un préavis de zéro, et finissent par être surchargées de manière irrégulière.
Je pensais à ce seul projet hier. C'était un rêve de pipe tellement évident pour moi, que j'ai fait rebondir une merde vraiment très peu fonctionnelle. Je l'ai vu comme une perte de temps et de ressources.
Eh bien, surprise, surprise, tout le monde a adoré et cela a bien fonctionné. Je suis donc retourné à la planche à dessin et je l'ai fait correctement. Et la nouvelle version était incroyable! Mais il y a eu ensuite un roulement dans la gestion et le tout a été abandonné au profit d'une "nouvelle direction commerciale".
La deuxième itération a eu un déploiement vraiment à moitié au sein de l'entreprise, et je n'en ai jamais entendu parler, ce qui est amusant car je sais qu'au moins ~ 10 unités commerciales l'utilisent toujours (le logiciel que nous commandons pour faire le travail a près de 2 ans de retard) et il ne casse jamais.
Cela nous amène à mon dernier point. Même si vous produisez quelque chose de miraculeux, le fait que cela fonctionne si bien signifie que PERSONNE ne sera le moins du monde au courant, et quand il se cassera (généralement parce qu'ils ont fait quelque chose de stupide), alors ils maudiront votre nom pire qu'eux jamais maudire cet idiot qui a écrit cette chose qui se brise tous les troisièmes mardi.
J'essaierais de résumer la réponse à ces questions avec une citation simple:
All code turns to crap given enough time and hands.
Le reste n'est que des histoires ...
Bienvenue dans le code avec un budget! Il y a une grande différence lorsque le développement est poussé par la direction à être fait trop tôt, sans planification et avec des raccourcis. J'ai vécu une expérience similaire de choc dans le monde réel lorsque j'ai obtenu mon premier emploi en programmation à la sortie de l'université. Pas de documentation! Au fil du temps, j'ai appris beaucoup de temps, la rédaction et la mise à jour de la documentation officielle ne sont qu'une perte de temps. Heureusement pour moi, c'était une équipe géniale. Il était dirigé par un gars qui savait ce qu'il faisait et les autres membres de l'équipe se souciaient vraiment d'écrire le code de la bonne façon. Depuis lors, mes expériences sont similaires aux vôtres. Beaucoup de code horrible, beaucoup de mauvais code, beaucoup de "développeurs" désemparés. Pour chaque bon développeur, il semble y avoir 100 mauvais.
Vous n'êtes pas condamné à détester votre travail pour toujours. Il suffit de trouver une entreprise suffisamment intelligente pour reconnaître les avantages à long terme et qui est prête à investir un peu au départ. J'ai réussi à prouver que faire les choses de la bonne façon au lieu de la manière la plus rapide est bénéfique et je suis devenu très respecté et fiable pour cela dans les entreprises où j'ai travaillé. Au fil du temps, le code spaghetti est fixe ou devient obsolète et votre code prend le relais. Soyez juste prêt à faire des compromis. Parfois, la façon la plus cool ou la plus robuste de programmer quelque chose est juste exagérée et c'est ok de le faire de manière rapide et sale.
Il est difficile de dire ce que vous considérez comme du code de qualité horriblement faible, mais oui, peu de programmeurs sont très bons (par définition). À mesure que le logiciel évolue, les gens font des erreurs. Au fil du temps, cela s'accumule et la pression commerciale (et la paresse/ignorance des programmeurs) rend le refactoring ... Peu fréquent.
La qualité du code dépend principalement de deux facteurs.
Le premier est toujours l'argent. Les entreprises qui subissent une forte pression de survie paient généralement des salaires bas, engagent des développeurs moins expérimentés, ont des horaires serrés et n'ont ni le temps ni l'argent pour tirer parti de leurs développeurs.
Viennent ensuite les gens. Tout d'abord, ceux qui décident des budgets doivent opter pour des dépenses en qualité de code, ensuite ils doivent engager des gens qui veulent le "vivre". Comme vous pouvez l'imaginer, il peut s'avérer difficile de convertir un programmeur Delphi de haut en bas de cinquante ans bien payé (aucune intention de stéréotypage, désolé) en un développeur Java à jour qui fait CI Builds et produit du code faiblement couplé. De nombreux développeurs ont une aversion pour les leçons des boursiers (peut-être plus jeunes), ils n'aiment pas que quelqu'un pêche dans leur étang - ou secoue leur trône.
Donc, cela étant dit, et compte tenu du fait que vous avez un code hérité à côté de chaque entreprise, je dirais que vous obtenez beaucoup de cela dans la vie réelle. Ce que vous pourriez faire, c'est vous comporter comme un boy-scout: allez dans les bois, ramassez des ordures et nettoyez-les. La prochaine fois, vous aurez moins de dégâts à franchir.
J'ai obtenu un stage dans l'une des principales sociétés de logiciels
Toutes les entreprises ne sont pas identiques. Vous trouverez des équipes de merde et des bases de code de logiciel de merde dans la plupart des entreprises. Mais vous pouvez également trouver d'excellentes équipes et d'excellentes bases de code.
Je pense que les gars de Solaris ont fait une très bonne et honnête description du type de bases de code que vous trouverez dans les grandes entreprises: http://hub.opensolaris.org/bin/view/Community+Group+ sur/dev_solaris
J'ai quitté le travail en détestant le travail tous les jours jusqu'à présent, et je veux désespérément savoir si c'est ce qui m'attend pour le reste de ma vie.
Non, je code depuis plus de 15 ans et je l'aime toujours.
Cela ne veut pas dire que tout a été parfait. J'ai vu des bases de code horribles et aussi d'excellentes. L'astuce consiste à trouver le bon endroit pour vous.
Une grande entreprise est très différente d'une petite. Au sein d'une même entreprise, l'équipe A est parfois très différente de l'équipe B. Trouvez celle qui a le bon équilibre pour vous (par exemple, des projets stimulants, une culture que vous aimez, un bon salaire, etc.)
Bonne chance!
Je ne peux pas vraiment parler pour tout le monde mais voici ce que je peux dire.
Je n'ai pas travaillé plus de 30 ans dans le domaine mais j'en ai vu assez pour dire quelques choses. Un projet a une vie à peu près comme un humain. La conception initiale peut ne pas correspondre aux besoins actuels de, disons, un projet après 20 ans de développement. Cela dit, dans ce laps de temps, beaucoup de gens ont changé le code et ont ajouté des choses qui n'étaient pas censées être possibles au début.
Il n'est pas vraiment difficile d'imaginer du code laid sur des projets hérités ou des projets assez anciens. Nous ne pouvons pas nous attendre à ce que tout le monde comprenne parfaitement les conceptions initiales. C'est triste mais c'est comme ça.
Cela dit, vous devez garder à l'esprit que la refactorisation d'un projet hérité n'est pas toujours possible et parfois même pas souhaitée. J'ai travaillé dans une entreprise où ils développaient le remplacement du projet sur lequel je travaillais. Je n'étais pas autorisé à refactoriser trop mon projet de peur qu'il ne fonctionne mieux que le nouveau projet. Je suis presque sûr qu'il n'y a aucun moyen que ce projet puisse mieux fonctionner qu'un nouveau. la phrase était un peu comme "Ne pas l'améliorer, juste le faire fonctionner".
Finalement, vous n'aurez pas souvent ce genre de projet, car je lis et j'écoute souvent. Vous devriez essayer de trouver du travail avec des startups au lieu de grandes sociétés. Les startups sont assez intéressantes et vous pouvez éventuellement avancer rapidement si vous voyez que cela ne se passe pas comme vous le souhaitez aussi.
Aussi une chose que vous pouvez faire, je ne promets vraiment rien, mais si vous sentez que le code est vraiment mauvais et que vous avez besoin de le refactoring. Partagez-le avec l'équipe. Gardez à l'esprit que les personnes qui ont écrit ce code laid pourraient travailler avec vous. Il ne s'agit pas de blesser les gens, mais si vous voyez que le projet sur lequel vous travaillez s'effondrera après un certain temps et que les gens passeront plus de temps à comprendre ce qu'il fait au lieu de l'améliorer. Il vaut mieux parler et communiquer le problème que de le garder pour vous. Si vous êtes assez chanceux, vous pourriez finir par refactoriser le projet.
Si vous finissez par refactoriser le projet, vous pourriez finir par être la personne désignée pour les mauvais choix de conception! Et vous comprendrez peut-être pourquoi le refactoring ne se produit pas si souvent. Si tout va bien si toute l'équipe doit refactoriser, alors personne ne sera pointé du doigt. Ils vont juste virer tout le monde =)
Ce sera une réponse courte.
L'éducation est très utile pour vous faire sentir qualifié et idéaliste. C'est une bonne chose et vous devriez essayer de vous accrocher à l'idéalisme.
Si vous êtes du tout objectif et que vous pouvez regarder en arrière votre propre travail à l'avenir, ce ne sera pas une expérience très enrichissante. À moins que vous ne vous mentiez à vous-même ou que vous n'appreniez rien, vous verrez de nombreuses façons d'améliorer ce que vous avez fait.
En général, le monde entier fait cela autour de vous. Donc, quand vous regardez le travail du passé, à part les exceptions, il apparaîtra inférieur et a besoin d'amélioration. Si vous ne ressentez pas cela, cela signifie que vous faites le mauvais travail ou que vous payez trop bien.
La bonne nouvelle est que vous pouvez bénéficier des erreurs des autres et de la comparaison avec le passé. Si toutes les applications fonctionnaient bien et étaient faciles à entretenir, de nouveaux développeurs ne seraient pas nécessaires. À mon avis, la maintenance de certains autres développeurs est une expérience d'apprentissage utile et devrait être un élément de formation obligatoire pour tous les développeurs de Blue Sky.
J'ai vu des choses similaires à vous. J'ai deux expériences de cas où cela se produit.
- Lorsque le développement est trop axé sur le projet. La seule chose qui compte est de fournir des fonctionnalités à temps, puis de vous déconnecter. Le prochain changement sera fait par quelqu'un d'autre, par une autre équipe/chef de projet avec un nouveau budget.
- Lorsqu'un logiciel est maintenu par seulement quelques personnes sur une longue période de temps, les développeurs ont tendance à devenir paresseux, car ils connaissent de toute façon leur logiciel. Les principes académiques sont loin.
C'est triste, mais c'est comme ça à certains endroits.
Voyez si vous pouvez faire un petit changement pour le mieux, habituez-vous ou changez de société et demandez à filtrer du code lors de l'entretien :-)
Votre expérience négative est bien trop typique des grandes sociétés de renom que beaucoup de développeurs apprennent à aborder avec beaucoup plus de prudence et d'appréhension qu'ils ne l'ont fait la première fois qu'ils ont eu l'occasion de travailler dans l'une d'entre elles. Fondamentalement, plus vous avez de couches de gestion, plus la médiocrité est défendue. Les cadres intermédiaires ne rendent pas compte aux cadres supérieurs de la qualité du code. Ils rendent compte des fonctionnalités livrées en X temps et donnent des présentations PowerPoint sur la fonctionnalité d'interface utilisateur neato qu'ils espèrent travailler juste assez longtemps pour les faire passer. Si tout s'effondre sur lui-même un mois plus tard, c'est généralement le problème de quelqu'un d'autre et il le sait.
Alors oui, les développeurs qui sont des condamnés à perpétuité dans de tels endroits ont tendance à ne pas trop s'en soucier. Ils ne pourraient pas survivre là-bas s'ils le faisaient. J'ai entendu dire de la Silicon Valley, que si vous voulez être paresseux, travaillez pour l'un des grands noms. Si vous voulez un travail passionnant, recherchez une startup plus récente qui n'est pas encore un nom familier. Je travaille à Chicago et je peux témoigner d'un phénomène similaire ici.
En règle générale (à de nombreuses exceptions près, j'en suis sûr), vous trouverez une appréciation plus élevée du code de qualité dans les entreprises plus petites et gérées ou détenues par des personnes qui continuent également à écrire du code. La compensation est souvent moindre, mais le travail est souvent beaucoup plus gratifiant à mon avis.
En tant que développeur débutant, vous n'êtes pas susceptible d'avoir beaucoup de contrôle sur qui vous travaillez au début, mais je dirai qu'avoir un grand nom sur votre CV pendant un an ou plus excite définitivement les recruteurs et les RH. En outre, vous pouvez apprendre un peu ce que vous n'apprendriez pas sinon travailler pour quelqu'un de complètement affreux au cours des six premiers mois environ et cela vous aide également à mieux comprendre quelles sont les meilleures pratiques qui importent réellement et pourquoi et lesquelles sont simplement techniques. manies.
Et bien sûr, lorsque vous travaillez avec des outils d'entreprise plus courants, vous aurez tendance à trouver que les niveaux de talents médians seront assez minables. Si vos compétences principales sont une combinaison de Java et C #, élargissez un peu vos horizons. Vous pourriez trouver une niche plus heureuse à l'écriture de niveau intermédiaire Erlang ou Python = ou: o JavaScript.
Et ne laissez personne vous dire autre chose. Vous n'avez peut-être pas le choix de procéder, mais le code de la merde coûte! @ # $ Ing cher.