Mes expériences de stage négatives sont-elles représentatives du monde réel? [fermé]

Je suis curieux de savoir si mes expériences actuelles en tant que stagiaire sont représentatives de l'industrie actuelle.

En tant qu'arrière-plan, je vis la majeure partie de deux majeures en informatique et d'une majeure en mathématiques dans une grande université; J'ai suivi tous les cours et les ai tous adorés, alors j'aimerais penser que je ne suis pas mauvais en programmation. J'ai effectué un stage dans l'un des principaux éditeurs de logiciels et, à mi-parcours, j'ai été choqué par la qualité extrêmement 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 un code incorrect, 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 ■ des heures sans fin à essayer de trouver une API non documentée ou à déterminer le comportement d’une autre partie du produit (complètement non documenté). Jusqu'à présent, j'ai quitté le travail en détestant le travail tous les jours et je veux désespérément savoir si c'est ce qui est prévu pour le reste de ma vie.

Ai-je tiré une petite paille sur les stages (les salaires absurdement élevés impliquent que ce n'est pas un poste de faible qualité), ou est-ce ce que c'est que le monde réel?

Ils appellent cela le monde réel pour une raison.

99% de ce que vous rencontrerez dans le monde réel des entreprises 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.

N ° 1 Ecrire Code, N ° 2 ????, N ° 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 codes académiques parfaitement conçus et théoriquement propres, logés dans des référentiels en or de perfection. Pas même proche, pas même ceux qui vendent le code source qu'ils produisent.

Dans le monde des affaires, le code est un moyen d'atteindre un but . Si un code résout un problème métier et génère plus d’argent qu’il en coûte pour le créer et le maintenir, il est souhaitable pour l’entreprise. Vous employer pour écrire du code n’est qu’un moyen pour l’entreprise d’obtenir du code.

Théorie 0 - Pratique ∞

L'idéal serait que l'entretien soit 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 deviennent rapidement obsolètes et réécrits plus souvent.

Les applications métiers sont celles qui sont considérées comme des projets de zombies sans fin pour de nombreuses raisons. Ces projets sont en réalité des succès qu'ils continuent car ils continuent à faire de l'entreprise un profit.

En théorie, il n'y a pas de différence entre théorie et pratique. En pratique, il y en a. - Yogi Berra

En théorie, des bases de code parfaitement propres et parfaitement architecturées avec une couverture à 100% du code devraient permettre aux entreprises de réaliser des économies. En pratique, cela ne permet même pas d'obtenir un retour sur investissement valable.

Physique du cycle de vie du logiciel

Il existe également une force d'entropie super puissante à l'œuvre dans le monde des logiciels. C'est un trou noir d'inévitabilité qui condamne tous les logiciels à dégénérer en Big Ball of Mud .

Plus vous démarrez d'un BBM , mieux c'est, mais chaque système logiciel finira par y arriver avec suffisamment de temps. La rapidité avec laquelle vous approchez de 100% d'entropie dépend de votre point de départ, de la rapidité avec laquelle vous accumulez de la dette technique et du niveau élevé de vos intérêts.

Les systèmes logiciels dégénèrent et pourrissent à cause de la maintenance et non à cause de l'absence de maintenance. Un système en place depuis des années sans modification du code répond par définition à toutes les exigences et objectifs et constitue un succès.

Ce sont les systèmes qui nécessitent des changements constants car ils ont commencé au plus proche de l’entropie maximale. Ce sont ceux qui sont constamment piqués et poussés et c’est la maintenance qui accélère le changement négatif.

Assez bon est assez bon

Les systèmes à cycle de vie court, tels que les sites Web qui changent constamment, ne bénéficient pas d'une couverture initiale coûteuse et de 100% de code lors des tests unitaires, car la durée d'amortissement est trop courte pour permettre de réduire les coûts.

Les systèmes à long cycle de vie, tels que la gamme d’applications professionnelles internes susmentionnée, ne bénéficient pas non plus d’investissements massifs en tests unitaires de couverture de code à 100%, car le taux de changement sur la durée de vie du projet se rapproche d’une constante proche de zéro dans mode non linéaire.

C’est la raison pour laquelle les plans de fin de vie sont plus importants et que les systèmes de remplacement doivent être planifiés au moment de la sortie, et non après quelques années et qu’ils ne sont plus viables. Un nouveau système doit donc être mis en place rapidement.

Autant que je sache, ils n'enseignent rien à propos de BBM. Je n'ai jamais rencontré de jeune diplômé en informatique qui sache ce que c'était et encore moins pourquoi cela se produit.

C’est la raison pour laquelle Assez bon est bon, assez , rien de plus ou moins ne l’est.

Logiciels Slumlords

Il y a des seigneurs de taudis de l'immobilier pour une raison, ils font un profit sur les bidonvilles qu'ils possèdent. Ils font plus de bénéfices qu'ils n'en dépensent pour la maintenance incrémentale de la propriété délabrée. Sinon, ils démoliraient le bâtiment et le remplaceraient. Mais ce n’est pas le cas, car les coûts différentiels sont bien moindres que la rénovation ou le remplacement de l’ensemble du bâtiment. Il y a aussi des clients (locataires) qui sont prêts à payer pour une propriété délabrée.

Aucun propriétaire de bâtiment, maitre de taudis ou pas, ne va dépenser de l'argent sur une propriété simplement à cause d'une notion académique de perfection qui ne se traduit pas par un profit substantiel par rapport au coût associé.

Aucun client ne paiera pour les mises à niveau d'un logiciel qui fonctionne de manière acceptable pour lui. Aucune entreprise ne va dépenser de l'argent uniquement pour écrire et réécrire du code sans générer de bénéfice substantiel tangible.

Microsoft est le plus dominant et le slumlord logiciel qui réussit le mieux. Windows n'a pas commencé à recevoir de nouvelles réécritures fondamentales jusqu'à très récemment. Et ils n'ont toujours pas supprimé tout le code hérité du noyau. Cela n’a aucun sens commercial, les gens sont plus que disposés à accepter les attentes déçues qu’ils ont définies au cours de la dernière décennie.

Pronostic

Cela a été une tendance depuis plus de 20 ans dans le développement de logiciels. Cela ne va pas changer de sitôt. Ce n'est pas la façon dont les gens veulent que ce soit sorti d'un système de croyance, c'est une réalité des forces externes sur une entreprise. Les entreprises sont le moteur de la prise de décision, les profits ne sont pas mauvais, ils paient votre salaire, la vision à court terme ou à long terme n’est pas pertinente, c’est une industrie à court terme en constante évolution par définition. Toute personne qui conteste assez bien pour faire un profit ne comprend pas les affaires.

J'ai passé 15 ans à consulter et j'ai très vite compris que c'était suffisant , que tout me coûtait de l'argent. Oui, je voulais que les choses soient parfaites, mais à moins que vous ne vendiez une base de code, où 99,99999% du temps vous vendez une solution , tout ce code élégant, organisé par un préfet propre est perdu et vous perdez simplement 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 doivent changer, ainsi que les exigences et les technologies.

Ils acceptent l'entropie introduite par le manque de temps ou l'évolution des besoins, le changement de personnel et la vivacité d'un logiciel utilisant le concept de dette technique.

Mais Agile n'est pas une panacée, il ne va pas changer les lois fondamentales de la physique et les bases de code vont pourrir indépendamment. Il appartient à la direction de planifier la gestion de la pourriture avant qu'elle ne devienne incontrôlable et incontrôlable.

Agile quand c'est fait correctement, aide à gérer l'entropie, à la ralentir, à la suivre, à la mesurer et à la gérer de manière planifiée. Ça n'arrêtera pas ça!

Décision de carrière

S'il s'agit d'un véritable 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. Les projets Open Source n’ont pas de meilleurs résultats, et dans de nombreux cas, le code est encore pire que le code de la plupart des entreprises que j’ai vu.

Je suis curieux de savoir si mes expériences actuelles en tant que stagiaire sont représentatives de l'industrie actuelle.

Non ce n'est pas. Il est représentatif de votre niveau de carrière et de votre expérience. Tout cela fait partie de l'apprentissage du fonctionnement des entreprises du point de vue du contrôle qualité interne.

En tant qu'arrière-plan, je vis la majeure partie de deux majeures en informatique et d'une majeure en mathématiques dans une grande université; J'ai suivi tous les cours et les ai tous adorés, alors j'aimerais penser que je ne suis pas mauvais en programmation. J'ai effectué un stage dans l'un des principaux éditeurs de logiciels et, à mi-parcours, j'ai été choqué par la qualité extrêmement faible du code.

Vos compétences, votre expérience, votre formation n’ont aucun impact sur la qualité du travail des autres. Tout simplement parce que vous n'avez pas le pouvoir de changer ces pratiques. Peu importe que vous soyez bon ou mauvais à l'université. Cela ne change pas le fonctionnement actuel de l'entreprise pour laquelle vous travaillez. Alors, même si c'est génial, vous avez tout ce fond. C'est vraiment pour votre propre bénéfice et non le leur. C'est pourquoi il est important d'étudier ce que vous aimez.

J'ai effectué un stage dans l'un des principaux éditeurs de logiciels et, à mi-parcours, j'ai été choqué par la qualité extrêmement 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 un code incorrect, 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 existe une différence entre «qualité du code» et «code acceptable». La vérité est que soit le responsable trouve le code source dans un état acceptable, soit il le juge inacceptable mais nécessaire. Il serait bien que nous puissions tous nettoyer les projets dans lesquels nous sommes impliqués. Ce n’est souvent pas dans l’intérêt des entreprises ou dans le budget 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, ce qui serait une bonne chose à corriger, mais lorsque la direction aura décidé que l'état actuel est "acceptable", il ne reste plus grand chose à faire. Tout est directement lié à qui dirige les choses. Soit ils attachent de la valeur à une bonne qualité interne, soit ils n’en ont pas. Vous le valorisez clairement et donc cet état actuel vous dérange.

Vous trouverez des exemples de ce type de problème dans toute industrie dépendant du contrôle qualité interne. Du développement logiciel à la fabrication. Vous devez apprendre à voir cela non pas comme un problème, mais simplement comme la condition actuelle de leur code source. C'est comme ça, il faut X minutes pour trouver quelque chose, il faut X minutes pour réparer quelque chose.

L’entreprise ne se soucie pas de ce temps supplémentaire ou le trouve acceptable.

Je travaille 10 à 12 heures par jour et je n'ai jamais l'impression d'aller nulle part, car ce sont des heures interminables à essayer de découvrir une API non documentée ou à déterminer le comportement d'une autre partie du produit (complètement non documenté). Jusqu'à présent, j'ai quitté le travail en détestant le travail tous les jours et je veux désespérément savoir si c'est ce qui est prévu pour le reste de ma vie.

Pourquoi était-il acceptable pour vous de passer de longues heures à l'université pour étudier une matière, mais maintenant il n'est pas acceptable de passer de longues heures pour étudier le code source? Je suis sûr que la raison pour laquelle l'employeur vous a embauché était parce qu'ils pensaient que vous pouviez vous en occuper.

Laissez-moi 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 épargné 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 est une réalité de la vie dans de nombreuses industries. Que vous devez résoudre vous-même, mais je peux vous le dire. Détester votre travail n'est jamais bon signe. Vous devriez gérer ce sentiment et aller au fond des choses. Je suis désolé que vous trouviez cette expérience négative.

Ai-je tiré une petite paille sur les stages (les salaires absurdement élevés impliquent que ce n'est pas un poste de faible qualité), ou est-ce ce que c'est que le monde réel?

Tu allais très bien à l'école, mais maintenant tu as un stage et tu ne réussis pas aussi 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, est la seule chose qui compte. Nous ne pouvons pas vous dire quoi faire. Vous devez vous faire votre propre idée.

Je peux vous dire que votre expérience à votre âge était bien meilleure que toutes les autres opportunités que j'avais. 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 diverses entreprises et industries, je peux dire:
oui, c'est assez courant.
C’est la raison pour laquelle les ingénieurs sont généralement payés, ils doivent bien savoir faire face aux désordonnés désordonnés et pouvoir encore apporter des modifications tout en résistant au désir pressant de refactoriser tout ce qui se passe et de savoir ce qu’il est censé être. Faire. J'y ai mis l'émotion - il est normal de ressentir cela à propos du code que vous rencontrez!

Le code que vous voyez aura souvent traversé d'innombrables itérations de différents programmeurs avec des approches et des normes différentes, des conventions de dénomination différentes, etc.

Ce qui se passe cependant, c’est que la pression de $ est toujours active. Il est toujours tentant de décrire en quoi et pourquoi un code de meilleure qualité est la seule solution à long terme, mais dans de nombreux emplois, le temps presse pour trouver une solution rapide à court terme. Il suffit d’un bref délai à un ingénieur pour détruire les normes d’un projet. Il faut un très bon manager qui sait comment éviter 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 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 énumèrent différents éléments et priorités, dont certaines ne sont même pas techniques, qu’ils considèrent importantes, et qui sont donc subjectives.

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 y a des organisations, souvent avec les composantes les plus importantes techniques qui sont faites les bonnes choses.
• Le plus récent de l'entreprise ... et le code ... le plus propre, il a tendance à être. les spaghettis se développent avec le temps et les hommes.
• Certaines personnes font du TDD et du BDD, d'autres pas. La gamme est énorme.
• Après environ 10 ans, l'ensemble de la base technologique change actuellement pour que ceux qui restent dans l'industrie puissent avoir autant de difficulté à suivre que les débutants.

Enfin, comme le souligne Anthony Blake, il existe toujours 3 facteurs: temps, coût et qualité.
J'aime l'expression associée: "pick 2" !

Il y a beaucoup d'opinions à ce sujet parce que les expériences de chacun sont différentes.

Le mien est que la moitié environ 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 bas qui essaient mais qui, au fond, devraient faire autre chose, car ils ne comprennent pas vraiment. Malheureusement, il existe également un autre petit groupe d'imbéciles incompétents qui pensent qu'ils sont beaucoup plus intelligents que tout le monde et qui ne savent généralement pas comment vous devriez les suivre.

En ce qui concerne les projets, j'ai été amené à occuper de nombreux emplois et on m'a immédiatement demandé de "m'occuper" d'un projet déjà établi, généralement celui dont l'entreprise vient de découvrir qu'il a réellement 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 tout-en-un, sans documentation et surdimensionnés. Parfois, je peux le réparer, parfois je recommence tout simplement. Il n'est même pas nécessaire que ce soit du code ancien, j'ai trouvé cela sur de nouveaux projets pour lesquels on m'a demandé d '"aider" également.

Il faut tenir compte du fait que la plupart des entreprises vont donner aux stagiaires des emplois merdiques. Les plus amusantes viennent après que vous ayez fait deux choses: 1 - faites vos preuves et 2 - prenez le temps de travailler sur des choses autres que de réparer les erreurs des autres. En d'autres termes, vous devez faire preuve de capacité et d'initiative.

Le vrai truc pour gérer un code défectueux 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 de cesser de travailler pour des entreprises bien établies et de chercher à travailler dans des startups. Ensuite, il n'y aura plus de code hérité à gérer pour que vous puissiez aider à construire quelque chose de mieux. L'inconvénient est que la pression exercée sur les projets de démarrage pour obtenir des résultats signifie souvent que des raccourcis et des piratages sont utilisés alors qu'ils ne devraient pas l'être.

Les programmeurs sont trop souvent disposés à contracter une dette technologique pour pouvoir livrer rapidement 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 rencontrent des difficultés.

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 mon mot;

Bienvenue dans le monde réel - malheureusement, cela 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 tout à fait indicatif de l'industrie, mais de mon expérience limitée de 5 ans et plus. Je travaillerais sur votre stage et prendrais autant de leçons que possible de l'expérience. Rechercher des poinçons et des indicateurs. Par exemple, pour votre prochain poste, vous devrez sans doute passer par une série d'entretiens. Ce processus est un processus à double sens et vous donne une chance de vous faire une idée de l'entreprise. Ceci est d’une importance vitale et conduira probablement à votre propre bonheur et à votre bien-être.

Pour résumer, repérez les panneaux indicateurs.

• Qui dirige l'entreprise? S'agit-il d'un seul responsable, de l'équipe marketing (le cas échéant, à l'écart), de l'équipe de développement, etc. Cet angle signifie que vous pouvez obtenir plus ou moins de poids pour les projets, le temps consacré à ces 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 participé à une interview au cours de laquelle les responsables ont fait toutes sortes de mouvements de 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 source, vous ne pouviez pas me montrer la porte assez rapidement.
• Objectif commercial? La société vit-elle au jour le jour, comme dans les objectifs financiers quotidiens, ou dispose-t-elle d'un plan à long terme auquel vous appartenez? Le développement de logiciels se fait généralement sur plusieurs mois, de sorte que le fait d’avoir une entreprise de nature schizophrénique mène généralement à des logiciels désordonnés.
• Creusez énormément - lorsque vous posez des questions techniques et voyez si les gens mélangent. Contrôle de source, contrôle de document, processus de publication, rapports de bogue, 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 renseigné sur le monde du travail et des affaires.

Eh bien, je débute ma deuxième décennie dans l’entreprise, et je peux vous dire que le code «clean clean» parfait arrive très rarement, et quand cela se produit, cela ne dure pas longtemps. Globalement, vous vous retrouverez constamment à essayer de réparer les erreurs du passé, tout en étant (malheureusement) contraint par des contraintes de temps et un leadership médiocre de commettre les erreurs du présent.

À moins que vous ne travailliez dans un type de logiciel très spécifique, la pression exercée pour obtenir un produit fonctionnel 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 qu'il ne faut que 5 minutes, personne ne vous laissera quelques semaines pour réduire la durée d'exécution à 2 minutes.

Si, par miracle, vous avez une confluence parfaite entre une direction compétente, un objectif clair, de l'argent, du talent et du temps, et que vous produisez un produit propre et supérieur ... Le seul moyen de le conserver sera de ne pas toucher ça encore . La maintenance et l'extension ont presque toujours une priorité très basse, des modifications sont toujours nécessaires à tout moment, et finissent par être annulées de manière erratique.

Je pensais à ce projet hier. C'était un rêve si évident pour moi, que j'ai renvoyé un morceau de merde vraiment minimaliste à la porte. Je considérais cela comme une perte de temps et de ressources.

Eh bien, surprise, surprise, tout le monde a adoré et cela a bien fonctionné. Alors je suis retourné à la table à dessin et je l'ai bien fait. Et la nouvelle version était incroyable! Mais ensuite, il y a eu 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 à moitié assé dans la société et je n’en ai jamais entendu parler, ce qui est amusant car je sais qu’au moins 10 unités d’affaires l’utilisent encore (le logiciel que nous avons commandé pour faire le travail près de 2 ans de retard) et apparemment cela 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 le connaîtra pas du tout, et quand cela se produira (généralement parce qu’ils ont fait quelque chose de stupide), ils vous maudiront plus mal que leur nom. jamais maudire cet idiot qui a écrit cette chose qui se brise tous les trois mardi.

Il est difficile de dire ce que vous considérez comme un code d'une qualité horriblement basse, mais oui, peu de programmeurs sont très bons (par définition). À mesure que les logiciels évoluent, les gens font des erreurs. Au fil du temps, cela s'accumule et la pression des entreprises (et la programmé paresse / ignorance) rend le refactoring ... peu commun.

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 pour un projet après 20 ans de développement. Cela dit, pendant tout ce temps, beaucoup de gens ont modifié le code et ajouté des choses qui n'étaient pas censées être possibles au début.

Il n’est pas très difficile d’imaginer un 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'avais pas le droit de trop refactoriser mon projet dans la crainte qu'il ne fonctionnerait mieux que le nouveau projet. Je suis à peu près sûr que ce projet ne pourrait jamais fonctionner mieux qu'un nouveau projet. la phrase ressemblait un peu à "Ne le rendez pas meilleur, faites-le simplement fonctionner".

En fin de compte, 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 d'une grande entreprise. Les startups sont très intéressantes et vous pouvez éventuellement aller vite si vous voyez que ça ne se passe pas comme vous le souhaitez aussi.

De plus, vous pouvez faire quelque chose, je ne promets rien, mais si vous estimez que le code est vraiment si mauvais et nécessite une refactorisation. 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 va échouer après un certain temps, les gens passeront plus de temps à comprendre ce qu'il fait au lieu de l'améliorer. Mieux vaut parler et communiquer le problème que le garder pour soi. Si vous êtes assez chanceux, vous pourrez éventuellement refactoriser le projet.

Si vous refacturez le projet, vous risquez de devenir la personne désignée pour les mauvais choix de conception! Et vous comprendrez peut-être pourquoi le refactoring ne se produit pas aussi souvent. Espérons que si toute l’équipe doit refactoriser, personne ne se fera remarquer. Ils vont juste virer tout le monde =)

Je tenterais de résumer la réponse à ces questions avec une citation simple:

All code turns to crap given enough time and hands.

Le reste ne sont que des histoires ...

La qualité du code dépend principalement de deux facteurs.

Le premier est toujours de l'argent. Les entreprises qui subissent une pression élevée sur le survient 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 nécessaires pour tirer parti de leurs développeurs.

Deuxièmement, les gens. Tout d'abord, ceux qui décident des budgets doivent opter pour la qualité du code, puis engager des personnes qui veulent le "vivre". Comme vous pouvez l’imaginer, il peut s'avérer difficile de convertir un programmeur Delphi top-down âgé de cinquante ans, bien rémunéré (aucune intention de stéréotypage, désolé) en un développeur Java à jour, qui réalise des versions CI et les produit. code faiblement couplé. De nombreux développeurs ont une aversion pour les leçons données par des camarades (peut-être plus jeunes), ils n'aiment pas les gens qui pêchent dans leur étang ou qui font trembler leur trône.

Cela dit, et compte tenu du fait que vous avez un code hérité dans chaque entreprise, je dirais que vous en avez beaucoup dans la vie réelle. Ce que vous pourriez faire, c'est vous comporter comme un garçon: allez dans les bois, ramassez des ordures et nettoyez-les. La prochaine fois, vous aurez moins de problèmes à surmonter.

Bienvenue dans le code avec un budget! Il y a une grande différence lorsque la direction pousse le développement 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 à l'université. Pas de documentation! Au fil du temps, j'ai appris beaucoup de temps, rédiger et tenir à jour une documentation formelle n'est qu'une perte de temps. Heureusement pour moi, c'était une équipe formidable. Il était dirigé par un gars qui savait ce qu'il faisait et les autres membres de l'équipe étaient vraiment soucieux d'écrire du code de la bonne façon. Depuis lors, mes expériences ont été similaires aux vôtres. Beaucoup de code horrible, beaucoup de mauvais code, beaucoup de "développeurs" nuls. Il semble y avoir 100 mauvais développeurs pour chaque bon développeur.

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 être disposée à investir un peu à l’avance. J'ai réussi à prouver que faire les choses de la bonne façon au lieu du plus rapide est bénéfique et que je suis devenu très respecté et que l'on fait confiance à ses entreprises. Au fil du temps, le code spaghetti est corrigé ou devient obsolète et votre code prend le relais. Juste être prêt à faire des compromis. Parfois, la manière la plus cool ou la plus robuste de programmer quelque chose est exagérée et il est acceptable de le faire de manière rapide et sale.

J'ai eu un stage dans l'une des plus grandes entreprises de logiciels

Toutes les entreprises ne sont pas identiques. Vous trouverez des équipes de base et des bases de codes de logiciels de base 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 description très bonne et honnête du type de code que vous trouverez dans les grandes entreprises: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

Jusqu'à présent, j'ai quitté le travail en détestant le travail tous les jours et je veux désespérément savoir si c'est ce qui est prévu 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 de la même entreprise, l’équipe A est parfois très différente de l’équipe B. Trouvez celle qui vous convient (par exemple, des projets ambitieux, une culture que vous aimez, un bon salaire, etc.).

Bonne chance!

J'ai vu des choses semblables à toi. J'ai deux expériences de cas où cela se produit.

1. Quand 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 effectué par quelqu'un d'autre, par un autre chef d'équipe / de projet avec un nouveau budget.
2. Lorsqu'un logiciel est entretenu par un petit nombre de personnes sur une longue période, les développeurs ont tendance à être 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, vous y habituer ou changer de société et demander à filtrer du code lors de l'entretien :-)

Cela va être 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 en tenir à l’idéalisme.

Si vous êtes objectif et que vous pouvez regarder votre propre travail dans le futur, ce ne sera pas une expérience très enrichissante. À moins que vous ne vous mentiez 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. Ainsi, si vous regardez le travail du passé, exception faite des exceptions, il apparaîtra inférieur et doit être amélioré. Si vous ne vous sentez pas comme 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 à gérer, de nouveaux développeurs ne seraient pas nécessaires. À mon avis, maintenir certains autres développeurs cruellement est une expérience d'apprentissage utile et devrait constituer un élément de formation obligatoire pour tous les développeurs blue sky.

Votre expérience négative est bien typique des grandes entreprises de marques réputées que beaucoup de développeurs apprennent à aborder avec beaucoup plus de prudence et d’appréhension qu’ils ne l’avaient fait la première fois qu’ils ont eu l’opportunité de travailler dans une entreprise. Fondamentalement, plus vous avez de niveaux 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 fournies dans un délai X et donnent des présentations powerpoint sur la fonctionnalité neato UI qu'ils espèrent travailler suffisamment longtemps pour pouvoir les utiliser. Si tout s'effondre un mois plus tard, c'est généralement le problème de quelqu'un d'autre qui le sait.

Alors oui, les développeurs qui sont 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 que dans Silicon Valley, si vous voulez être paresseux, travaillez pour l'un des grands noms. Si vous voulez un travail passionnant, recherchez un démarrage plus récent qui ne soit pas encore connu. Je travaille à Chicago et peux garantir un phénomène similaire ici.

En règle générale (avec de nombreuses exceptions, j'en suis sûr), vous constaterez une plus grande appréciation 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 moins, mais le travail est souvent beaucoup plus gratifiant à mon avis.

En tant que développeur débutant, vous n’avez probablement pas beaucoup de contrôle sur les personnes pour lesquelles vous travaillez, mais je dirai qu’avoir un grand nom sur votre CV pendant un an ou plus excite définitivement les recruteurs et les ressources humaines. En outre, vous pouvez en apprendre un peu plus que vous ne le feriez autrement en travaillant pour quelqu'un de complètement affreux au cours des six premiers mois environ, ce qui vous permet également de mieux cerner les meilleures pratiques qui importent réellement et pourquoi et lesquelles ne sont que des technologies. les manies.

Et bien sûr, lorsque vous travaillez avec des outils d'entreprise plus répandus et courants, vous aurez tendance à constater que les niveaux de talent médians seront plutôt médiocres. Si vos compétences principales associent Java et C #, élargissez un peu vos horizons. Vous pourriez trouver un créneau plus heureux au niveau intermédiaire en écrivant Erlang ou Python ou: o JavaScript.

Et ne laissez personne vous dire autre chose. Vous n’avez peut-être pas le choix quant à la façon de procéder, mais le code merdique est! @ # $ Ing coûteux.

Votre question portait sur les stages. Je n'ai jamais eu de programme, mais stagiaire dans une station de radio, pas vraiment applicable ici.

Votre question a également mentionné vos expériences au cours de vos stages. Vos expériences de stage et les réponses que vous avez reçues jusqu’à présent résument assez bien mes expériences, après vingt-sept ans d’écriture de logiciels (commencée à la mi-juin 1985).

Je n'y avais jamais vraiment cru à l'école quand nos instructeurs disaient qu'il y avait plus de réflexion que d'écrire du code. Ils avaient raison. Et, si vous essayez de comprendre le code de quelqu'un d'autre, il est pire sans commentaires, et presque aussi mauvais avec des commentaires. Essayez de maintenir un système de collecte de taxes municipales local sans commentaires, sans documentation, sans construction formelle et sans contrôle du code source.

Chaque fois que vous pouvez réussir sans que cela soit une violation directe des ordres habituels, faites-le bien. Rappelez-vous toujours qu'il est plus facile de présenter des excuses pour quelque chose que vous n'avez pas demandé la permission de faire que de ne pas obtenir cette permission et d'aller à l'encontre d'un ordre direct.

N'oubliez pas les normes qui vous ont été enseignées à l'école. Ils ne sont pas inutiles, mais il est plus que probable que ces normes sont les asymptotes dans les limites du calcul. Vous pouvez toujours essayer de les approcher, mais vous pourriez ne jamais atteindre leur valeur.

Bonne chance.