Les mauvaises pratiques de programmation sont-elles typiques dans l'industrie du logiciel? [fermé]

Je viens de commencer mon premier emploi en tant que développeur de logiciels il y a plus d'un mois. Tout ce que j'ai appris sur la POO, SOLID , DRY , YAGNI, les modèles de conception, les PRS , etc. peut être jeté par la fenêtre.

Ils utilisent des formulaires Web C # .NET et font presque tout dans Code Behind avec très peu de classes externes, certainement pas appelées objets. Ils utilisent des contrôles personnalisés et les réutilisent. À propos des seuls objets utilisés est Entity Framework . Ils réutilisent le code derrière pour chaque client. Ils ont des méthodes de 400 lignes qui font tout type de choses. Pour les nouveaux clients, ils prennent les fichiers aspx et aspx.cs, suppriment le code client et commencent à ajouter le nouveau code spécifique au client.

Leur première excuse serait que cela ajoute de la maintenance supplémentaire, et plus de code signifie plus de maintenance. C'est un petit magasin de trois développeurs, dont moi-même. Un développeur a plus de 30 ans d'expérience et l'autre 20 ans et plus. L'un était un développeur de jeu et l'autre a toujours travaillé en C et C ++.

À quel point est-ce courant dans l'industrie du logiciel? Comment puis-je m'assurer de rester au courant de la POO et des principes associés? Je pratique dans mon temps libre et j’ai l’impression que j’ai vraiment besoin de travailler avec un développeur plus expérimenté pour devenir meilleur à la POO.

1. Les principes que vous avez cités dans votre question ne sont que des ... principes. Ce ne sont pas des mandats, des lois ou des ordres.
2. Bien que les gens qui ont proposé ces principes soient très intelligents, ils ne sont pas des autorités absolues. Ce ne sont que des personnes offrant leurs idées et leurs conseils.
3. Il n'y a pas de "bonne" façon de programmer. Ceci est démontré par le fait que la façon "acceptée" de le faire a changé, et continue de changer, radicalement au fil du temps.
4. L'expédition d'un produit peut souvent avoir la priorité sur le "bon" chemin. C’est une pratique tellement répandue qu’elle a pour nom: Dette technique.

5. Certaines architectures logicielles couramment utilisées ne sont pas idéales. Les meilleures pratiques délaissent les applications monolithiques volumineuses au profit de collections de modules faiblement couplés.

6. Le contexte est important. De nombreux principes architecturaux ne prouvent leur valeur que lorsque vous travaillez avec de grands programmes ou des domaines spécifiques. Par exemple, l'héritage est principalement utile pour les hiérarchies d'interface utilisateur et les autres structures bénéficiant d'arrangements profondément imbriqués et étroitement couplés.

Alors, comment suivez-vous un "droit" chemin, un chemin de principe, afin de pouvoir sortir du désert?

1. Étudiez la pertinence plutôt que la correction. La "bonne" façon de faire n'importe quoi dans le développement logiciel est celle qui répond le plus efficacement à vos besoins spécifiques.
2. Étudiez les compromis. Tout dans le développement de logiciels est un compromis. Voulez-vous plus de vitesse ou moins d’utilisation de la mémoire? Voulez-vous un langage de programmation très expressif avec peu de praticiens ou un langage moins expressif que beaucoup de développeurs connaissent?

3. Étudiez l'intemporalité. Certains principes ont résisté à l'épreuve du temps et seront toujours pertinents. Les systèmes de types sont universels. Les fonctions de première classe sont universelles. Les structures de données sont universelles.

4. Apprendre le pragmatisme. Être pratique est important. La pureté mathématique, les architectures de cathédrale de cristal et les principes de tour d'ivoire sont inutiles si vous ne pouvez pas expédier.

5. Soyez un artisan, pas un zélé. Les meilleurs développeurs de logiciels sont ceux qui connaissent les règles et savent comment les enfreindre lorsqu'il est logique de le faire. Ce sont eux qui savent encore résoudre les problèmes et pensent par eux-mêmes. Ils utilisent des principes pour informer et guider leurs choix, pas pour les dicter.
6. Écrivez le code. Beaucoup. Les principes de conception logicielle sont des optimisations prématurées jusqu'à ce que vous ayez écrit beaucoup de code et développé un instinct pour savoir comment les appliquer correctement.

Ce n'est pas rare. Une chose à réaliser est que l’industrie du logiciel est incroyablement diversifiée. Certaines entreprises sont à la pointe. Des universités de premier plan et des éditeurs de logiciels innovants (même certains laboratoires parmi les plus grands!), Ainsi que des personnes bénies ou des groupes comme le groupe de quatre, analysent les problèmes rencontrés avec les moyens courants de faire les choses et inventent de nouveaux langages, machines, outils et modèles. De nouvelles entreprises, souvent dérivées ou scindées, tentent de les utiliser à des fins commerciales et connaissent parfois un succès incroyable. Pensez Facebook ou Google.

Mais les logiciels sont utilisés presque partout de nos jours, peut-être surtout dans des entreprises qui ne sont pas réellement des éditeurs de logiciels. J'ai principalement travaillé dans l'industrie des transports (automobile et ferroviaire) et les expériences sont variées. Mais aucun d'entre eux n'était à la pointe de la technologie. Parfois, ils ne peuvent pas être; Les logiciels relatifs à la sécurité dépendent d'outils bien validés (nous utilisons actuellement un compilateur C ++ validé des années 1990). Parfois, ils n'ont pas les bonnes personnes. Souvent, le logiciel est développé par des ingénieurs d'autres domaines qui se sont glissés dans le développement de logiciels de leur entreprise lorsque le logiciel est devenu de plus en plus important. On ne peut pas s’attendre à ce qu’ils connaissent ou utilisent les principes du génie logiciel.

Une autre chose à considérer est ce qui est important chez un ingénieur dans le monde réel. Souvent, la tâche à accomplir n’est pas, à proprement parler, une science factice. Les problèmes simples des entreprises non liées aux logiciels peuvent être résolus avec des moyens logiciels modestes. Ce qui fait qu’un bon ingénieur en logiciel est utile, voire même bon, est en partie ce qui en fait un bon ingénieur généraliste: Soyez fiable; organiser et documenter votre travail de manière responsable; être coopératif; faire de bonnes estimations de coûts et de temps (la validité de l'estimation est plus importante que le coût et le temps réels!); comprendre ce que vous pouvez et ne pouvez pas faire. Il manque manifestement ici "de connaître et d'utiliser des outils et des procédures à la pointe de la technologie". Ce que vous décrivez est une entreprise qui a mis en place un ensemble d’outils et un processus qui leur convient. Ils ne produiront probablement jamais rien de sexy ou d'extraordinaire, mais ils répondent assez bien aux demandes des clients pour générer un flux de revenus suffisant et constant. Cela pourrait être la définition de l'ingénierie ;-).

Donc oui: ce que vous apprenez à l’université n’est pas courant dans beaucoup de domaines.

Je veux ajouter un morceau de consolation, ou une note plus optimiste. Ce que vous avez appris ne doit pas être jeté par la fenêtre. Vous pouvez appliquer de meilleurs principes dans votre travail quotidien où cela ne casse pas les choses. Peut-être y aura-t-il une fenêtre d'opportunité pour introduire un nouvel outil ou modèle de conception. Les chances sont meilleures lorsque l'ancienne façon de faire est désagréable pour les collègues, ou s'ils rencontrent des problèmes de gestion de la complexité ou de maintenance (les deux problèmes les plus virulents résolus par les innovations). Soyez prêt à proposer des améliorations lorsqu'il y a une opportunité. Exercer une influence positive et améliorer progressivement les méthodes et les outils; diffuser les connaissances là où elles sont appréciées.

Ils utilisent des formulaires Web .Net C # et font presque tout dans le code caché avec très peu de classes externes

Il y a votre explication juste là. Si vous n'êtes pas au courant, le code Web Forms prêt à l'emploi est à l'opposé de OOP, SOLID, DRY, YAGNI, Design Patterns, SRP , etc. Même les exemples officiels de Microsoft datant de quelques années vous ferait grincer des dents aujourd'hui.

Web Forms s'oriente vers un flux de procédures, avec de faux "événements" déclenchés par des clics de contrôle, etc. Les développeurs qui passaient beaucoup de temps à faire des formulaires Web semblaient également généralement réticents, y compris parce qu’ils passaient tellement de temps à apprendre le cycle de vie des pages et à faire des contrôles de rendu dynamique qu’ils répugnaient à jeter ces connaissances maintenant. face aux méthodes nouvelles / meilleures. Une version inconsciente de l’erreur fallacieuse. Ces développeurs ont passé des années à apprendre à s’affranchir de Web Forms et, à présent, ils ne s’écarteront pas facilement de cette expertise, d’où leur discours sur le temps de "maintenance".

Et cela est assez courant dans l’espace .NET Web Forms, au fait.

À quel point est-ce courant dans l'industrie du logiciel?

Très commun. Vous avez à peu près le même sentiment de commodité que si un plombier détruit votre plomberie, un charpentier livrant de la ferraille ou un tailleur bon marché qui fabrique un costume mal ajusté. C'est tout, humain.

Cela s'explique par une bonne raison: les personnes qui ne sont pas vraiment formées (ou qui ne sont pas enthousiastes) doivent mettre en œuvre quelque chose sous pression.

Ce n’est pas un problème de ces personnes, principalement, mais généralement des structures entourant le développement de logiciels dans cette entreprise. Par exemple, une entreprise peut avoir un groupe de stagiaires développer leurs logiciels internes; même si ces stagiaires sont intelligents et compétents, ils ne resteront là que quelques semaines ou quelques mois, et la propriété changera fréquemment de propriétaire.

Ou bien une personne qui est formidable dans le domaine, mais pas un programmeur, pourrait pirater une application VBA, etc., parce que cela semble être assez facile au début.

Ou bien une application bien faite aboutit à la phase de maintenance, tous les bons développeurs s'en vont, et peu de personnes (le cas le plus défavorable: un seul) continuent à la développer, qui en savent peu, qui n'ont aucune documentation, etc.

Comment puis-je m'assurer de rester au courant de la POO et des principes associés? Je pratique dans mon temps libre et j’ai l’impression que j’ai vraiment besoin de travailler avec un développeur plus expérimenté pour devenir meilleur à la POO.

Il y a deux réponses possible:

• Soit: discutez-en avec votre patron et assurez-vous de participer à des projets propres. Si ce n'est pas possible, trouvez un nouveau patron.
• Ou: assumez vous-même la responsabilité de cela. Cela signifie le faire vous-même - pendant votre temps libre, ou si vous le pouvez, dans l'entreprise, mais conduit par vous-même (peu probable).

Si la deuxième réponse semble trop cynique pour vous, alors laissez-moi vous assurer que ce n'est pas le cas. Un menuisier qui a un atelier de menuiserie à la maison sera très certainement un meilleur menuisier qu'un autre.

Par exemple, il est tout à fait possible et très amusant pour certaines personnes, par exemple, de creuser dans une nouvelle langue telle que Ruby, d’apprendre non seulement la syntaxe, mais également les aspects OO particuliers et approfondis de cette langue et de plonger profondément. Tout cela pendant votre temps libre, sans aucune connexion avec votre travail. Ce sera juste un passe-temps, mais en tant que professionnel qualifié que vous êtes, il peut être aussi efficace (ou même plus) que d'être assis à côté d'un développeur principal et d'essayer de suivre ce qu'il fait. Ce sera alors strictement pour votre développement personnel et votre propre plaisir. Si vous ne vous amusez pas à faire cela ou si vous constatez que vous ne pouvez tout simplement pas parvenir à une compréhension, effacez-le et revenez à la première réponse.

Ce développeur principal qui vous forme a très probablement appris cela exactement de cette façon ...

Je pense qu’en Espagne, c’est une constante, car lorsqu’un développeur passe de nombreuses années dans une entreprise, il (ou elle) est généralement promu dans plus de domaines de gestion comme l’analyse et la gestion de projet. En conséquence, aucune évaluation par les pairs n'est effectuée et le code est généralement écrit par des personnes moins expérimentées.

Les échecs de ces personnes expérimentées ne sont jamais corrigés: au lieu de cela, leur seul objectif est de faire le travail. En conséquence, de plus en plus de mauvaises pratiques sont accumulées dans le code.

En fin de compte, certains experts pensent que la meilleure "solution" consiste à passer à une technologie émergente qui générera un code plus propre et plus facilement maintenable, créant ainsi une nouvelle application. Comme si la technologie seule pouvait le faire.

Encore une fois, des programmeurs inexpérimentés sont mis au travail dans cette nouvelle technologie, personne ne vérifie le code et le cercle est à nouveau fermé ... pour toujours et à jamais ....

Certaines des «meilleures pratiques» que vous apprenez à l'école ne sont ni pratiques ni rentables pour des projets concrets. L'un des plus gros changements que j'ai remarqués concerne le formatage et les commentaires. La plupart de mes professeurs ont insisté sur l'importance de documenter longuement votre code, mais dans le monde réel, un bon code est souvent (pas toujours!) Explicite, et plus important encore, de nombreux chefs ne veulent pas payer pour que vous passiez plus de temps à écrire commentaires.

Vous verrez parfois des programmeurs pressés par le temps qui utilisent des raccourcis et des anti-motifs qui requièrent moins de performances optimales que des solutions de qualité.

Cependant, l'un des plus gros problèmes que j'ai remarqué dans de nombreuses équipes et projets est le manque d'empressement à apprendre de nouvelles choses.. La plupart des programmeurs plus âgés auxquels j'ai parlé ont commencé leur carrière dans une période d'ingénierie logicielle du «Far West», lorsque les qualifications ont commencé et se sont terminées avec la volonté d'écrire du code. Ils se spécialisaient souvent dans des domaines complètement différents et se lançaient dans la programmation avec peu ou pas d'éducation formelle lorsqu'une opportunité se présentait (par exemple, leur employeur n'avait pas de programmeur et avait besoin de quelqu'un pour apprendre afin de construire un logiciel interne). Certains de ces programmeurs autodidactes de la vieille école ne font jamais l'effort d'apprendre les pratiques modernes de codage et continuent à coder dans le style qu'ils ont appris il y a plusieurs décennies. Quand ils finissent par prendre en charge de nouveaux projets en raison de leur ancienneté, ils ont tendance à les retenir et à nuire à la qualité générale du code.

Bien sûr, ce qui précède ne s’applique pas à tous les anciens programmeurs et les codeurs de nouvelle génération peuvent être tout aussi coupables. J'ai travaillé avec de nombreux jeunes programmeurs qui ont acheté quelques outils et bibliothèques tout juste sortis de l'université, puis qui ont complètement arrêté d'apprendre. Ils téléchargent un IDE ou une bibliothèque une fois et ne le mettent jamais à jour à moins que leur entreprise ne l’exige (vous pouvez parfois deviner quelle année un programmeur a obtenu son diplôme en fonction de la date de péremption de ses bibliothèques). Ils ne suivent pas les nouvelles fonctionnalités dans la langue de leur choix et n'apprennent jamais de nouvelles langues. Ils n'apprennent pas de nouvelles stratégies de programmation et peuvent mal utiliser des modèles ou des paradigmes, car ils ne connaissent pas de solutions plus appropriées (oh MVC, à quel point tu as été maltraité). À mesure que le temps passe, leur flux de travail devient de plus en plus obsolète et devient plus un passif qu'un atout.

En résumé, deux des principales causes de problèmes de bases de code sont les délais très brefs et les programmeurs disposant de connaissances obsolètes ou incomplètes. Malheureusement, la responsabilité de ces deux problèmes peut peser lourdement sur le patron ou l'OTC, qui doit veiller à ce que les délais soient réalistes et à ce que le personnel connaisse ses connaissances et ses compétences. Si le patron ne sait rien des bonnes pratiques en matière de programmation, le mieux que vous puissiez faire est d'essayer de suggérer des changements et d'espérer qu'il sera ouvert à toutes suggestions. Malheureusement, ils peuvent être enclins à faire confiance au mot d'un programmeur plus expérimenté qui ne comprend pas la POO et aime écrire 10 000 classes.

Certaines des mauvaises pratiques de programmation résultent de la nécessité de travailler avec des logiciels existants, dont le développement a débuté il y a plusieurs décennies. S'il existe un logiciel très complexe, tout réécrire peut ne pas être une option. Il peut même être extrêmement difficile de comprendre tout ce que le code est en train de faire. La meilleure option serait peut-être simplement de copier ce qui fonctionne tout en essayant d'intégrer de meilleures pratiques de programmation si vous pouvez le faire sans rien casser.

Je pense qu'il est important de ne pas simplement dire le vrai du faux, mais de connaître les raisons qui sous- tendent chaque bon et mauvais. Lorsque vous connaissez des raisons, vous pouvez prédire les conséquences. Pourquoi utiliser tel ou tel principe non pas parce que cela a été décrit dans un livre, mais parce que nous savons en quoi cela aide et ce qui se passe exactement si nous le brisons. Si vous savez ce qui se passe, vous pouvez peser le pour et le contre et prendre une décision. Cela vous aidera également à défendre votre position à chaque fois. SOLID et OOP peuvent également réduire la maintenance s’ils sont bien utilisés.

SOLID, si utilisé trop dogmatiquement, conduit à trop de classes et de méthodes, ce qui n’est pas aussi bon. N'en faites pas trop. Ceci est en partie un gros problème avec nos manuels et tutoriels, car ils essaient souvent de promouvoir des idées sans justification adéquate. OOP a aussi ses inconvénients. De nombreux principes et paradigmes se contredisent. Vous n'avez pas besoin d'être au top, vous devez tout rendre raisonnable, justifié, élégant et simple.

De plus, comme il s’agit de votre premier travail, il est probable que ces programmeurs ne sont pas très compétents. Mais là encore, on leur confie probablement des tâches pas très difficiles qui peuvent être accomplies sans autant de compétences et pour un salaire inférieur par des codeurs moins qualifiés et moins qualifiés. C'est comme ça que l'économie fonctionne. Chaque lieu de travail est différent.

Je comprends ce que tu ressens. Ne paniquez pas . Vous aurez besoin de ce que vous savez, peut-être pas tout de suite, mais cela vous aidera. Peut-être sur un lieu de travail différent, peut-être à certaines occasions. Vous avez le temps devant vous pour aller plus loin.