Les mauvaises pratiques de programmation sont-elles typiques dans l'industrie du logiciel?
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, SOLIDE , SEC , YAGNI, modèles de conception, SRP , etc. peut être jeté par la fenêtre.
Ils utilisent des formulaires Web C # .NET et font presque tout dans le code derrière avec très peu de classes externes, certainement pas appelées objets. Ils utilisent des contrôles personnalisés et les réutilisent. Les seuls objets utilisés sont par Entity Framework . Ils réutilisent les codes derrière pour chaque client. Ils ont des méthodes qui font 400 lignes et qui font tous les types de choses. Pour les nouveaux clients, ils prennent l'aspx et l'aspx.cs et enlèvent le code client et commencent à ajouter le nouveau code spécifique au client.
Leur première excuse serait d'ajouter une maintenance supplémentaire, et plus de code est plus de maintenance. C'est une petite boutique de trois développeurs dont moi. Un développeur a plus de 30 ans d'expérience et l'autre a plus de 20 ans d'expérience. L'un était développeur de jeux et l'autre a toujours fonctionné en C et C++.
Est-ce courant dans l'industrie du logiciel? Comment puis-je m'assurer que je reste au-dessus de OOP et les principes associés? Je pratique pendant mon temps libre et je sens que j'ai vraiment besoin de travailler avec un développeur plus expérimenté pour améliorer OOP.
- 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.
- Bien que les personnes qui ont élaboré ces principes soient très intelligentes, ce ne sont pas des autorités absolues. Ce ne sont que des gens qui offrent leurs idées et conseils.
- Il n'y a pas de façon "correcte" 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.
- L'expédition d'un produit peut souvent primer sur le fait de le faire "correctement". C'est une pratique tellement répandue qu'elle a un nom: Dette technique.
Certaines architectures logicielles couramment utilisées ne sont pas idéales. Les meilleures pratiques évoluent loin des grandes applications monolithiques vers des collections de modules à couplage lâche.
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 d'autres structures qui bénéficient d'arrangements étroitement imbriqués et étroitement couplés.
Alors, comment suivez-vous un "bon" chemin, un chemin de principe, afin de pouvoir sortir du désert?
- Étudiez la pertinence, plutôt que l'exactitude. La "bonne" façon de faire quoi que ce soit dans le développement de logiciels est celle qui répond le mieux à vos besoins spécifiques.
- Étude des compromis. Tout dans le développement de logiciels est un compromis. Voulez-vous plus de vitesse ou moins de mémoire? Voulez-vous un langage de programmation très expressif avec peu de praticiens, ou un langage moins expressif que de nombreux développeurs connaissent?
Étudier 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.
Apprenez le pragmatisme. Être pratique est important. La pureté mathématique, les architectures de la cathédrale de cristal et les principes de la tour d'ivoire sont inutiles si vous ne pouvez pas expédier.
- Soyez un artisan, pas un fanatique. Les meilleurs développeurs de logiciels sont ceux qui connaissent les règles, puis savent comment les briser quand cela a du sens 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.
- Écrivez le code. Beaucoup. Les principes de conception de logiciels sont des optimisations prématurées jusqu'à ce que vous ayez écrit beaucoup de code et développé un instinct pour 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. Les grandes universités et les sociétés de logiciels innovantes (même certains laboratoires dans les grands!) Ainsi que des personnes ou des groupes bénis comme le gang des quatre analysent les problèmes rencontrés avec les façons courantes de faire les choses et inventent de nouveaux langages, machines, outils et modèles. De nouvelles entreprises, souvent des spin-offs ou des scissions, essaient de les utiliser commercialement et connaissent parfois un succès étonnant. 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 en fait des sociétés de logiciels. J'ai travaillé principalement dans l'industrie du transport (automobile et ferroviaire), et il y a un mélange d'expériences. Mais aucun d'entre eux n'était proche du "tranchant". Parfois, ils ne peuvent pas l'être; les logiciels pertinents pour la sécurité dépendent d'outils bien contrôlé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 dans d'autres domaines qui se sont avérés justement se glisser dans le développement de logiciels dans 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 pour un ingénieur dans le monde réel. Souvent, la tâche à accomplir n'est pas, littéralement, la science des fusées. Les problèmes de pain et de beurre dans les sociétés non logicielles peuvent être résolus avec des moyens logiciels modestes. Ce qui fait un ingénieur logiciel utile, peut-être même bon, est en partie ce qui fait un bon ingénieur général: soyez fiable; organiser et documenter votre travail de manière responsable; être coopératif; faire de bonnes estimations de coût 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. Manifestement, il manque "connaître et utiliser des outils et des procédures de pointe". Ce que vous décrivez est une entreprise qui a mis en place un ensemble d'outils et un processus qui fonctionnent pour eux. Ils ne produiront probablement jamais rien de sexy ou d'extraordinaire, mais ils répondent suffisamment aux demandes des clients pour générer un flux régulier de revenus suffisants. Cela pourrait être la définition de l'ingénierie ;-).
Alors oui: ce que vous apprenez à l'université n'est pas courant dans la plupart des 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. Il y aura peut-être 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 les choses est désagréable pour les collègues, ou s'ils rencontrent des problèmes de gestion de la complexité ou de la maintenance (les deux problèmes les plus virulents traités par les innovations). Soyez prêt à apporter des améliorations lorsque l'occasion se présente. Être 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 C # .Net et font presque tout dans le code derrière avec très peu de classes externes
Voilà votre explication. Si vous n'êtes pas au courant, le code Web Forms prêt à l'emploi est à peu près l'opposé polaire de OOP, SOLID, DRY, YAGNI, Design Patterns, SRP, etc. Même les exemples officiels de Microsoft il y a quelques années vous ferait grincer des dents aujourd'hui.
Les formulaires Web se poussent vers un flux procédural, avec de faux "événements" déclenchés par des clics de contrôle et autres. Les développeurs qui ont passé beaucoup de temps à faire des formulaires Web semblent également réticents à s'en écarter également, probablement parce qu'ils ont consacré tellement de temps à apprendre le cycle de vie des pages et à faire des contrôles rendus dynamiquement qu'ils répugnent à jeter ces connaissances maintenant face à des méthodes plus récentes/meilleures. Une version inconsciente de l'erreur fallacieuse. Ces développeurs ont passé des années à apprendre à gérer les formulaires Web et ne s'écarteront plus facilement de cette expertise, d'où leur discours sur le temps de "maintenance".
Et cela est assez courant dans l'espace .NET Web Forms, btw.
Est-ce courant dans l'industrie du logiciel?
Très commun. À peu près la même chose que d'avoir un plombier détruire votre plomberie, un charpentier livrant de la malbouffe ou un tailleur bon marché faisant un costume mal ajusté. C'est-à-dire que tout est humain.
Il y a une bonne raison à cela: des gens qui ne sont pas vraiment formés (ou 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 demander à un groupe de stagiaires de développer son logiciel interne; même si ces stagiaires sont brillants et bien informés, ils ne seront là que pour quelques semaines ou mois, et la propriété changera fréquemment.
Ou une personne qui est excellente dans le domaine, mais pas un programmeur, pourrait pirater une application VBA, etc., car cela semble assez facile au début.
Ou une application bien faite se retrouve dans la phase de maintenance, tous les bons développeurs avancent, et elle continue ensuite d'être développée par peu de gens (pire des cas: un) qui en savent peu, qui n'ont pas de documentation, etc.
Comment puis-je m'assurer que je reste au top de OOP et les principes associés? Je pratique pendant mon temps libre et je sens que j'ai vraiment besoin de travailler avec un développeur plus expérimenté pour améliorer OOP .
Il y a deux réponses possible:
- Soit: discutez-en avec votre patron et assurez-vous de vous lancer dans 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 par 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 vous semble trop cynique, laissez-moi vous assurer que ce n'est pas le cas. Un charpentier qui a un atelier de menuiserie à la maison la plupart sera certainement un meilleur charpentier que celui qui n'en a pas.
Par exemple, il est tout à fait possible et un beaucoup de plaisir pour certaines personnes, par exemple, de creuser dans un nouveau langage comme Ruby, d'apprendre non seulement la syntaxe, mais aussi une profondeur spéciale OO aspects de cette langue, et plongez vraiment profondément. Tout dans votre temps libre, sans avoir aucun lien avec votre travail. Ce sera juste un passe-temps, mais étant le professionnel qualifié que vous êtes, il peut être aussi efficace ( ou plus) comme assis à côté d'un développeur principal et essayant 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 à le faire, ou si vous trouvez que vous ne parviens à aucune compréhension, puis grattez-le et revenez à la première réponse.
Le développeur principal qui vous forme a tout à fait probablement appris ces choses exactement de cette façon ...
Je pense qu'en Espagne, c'est une constante parce que 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, aucun examen par les pairs n'est effectué 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 s'accumulent dans le code.
Finalement, un cul intelligent dit que la meilleure "solution" est de passer à une technologie émergente qui générera un code plus propre et plus maintenable, créant une nouvelle application. Comme si la technologie pouvait à elle seule le faire.
Encore une fois, des programmeurs inexpérimentés sont mis au travail dans cette nouvelle technologie, personne ne passe en revue le code et le cercle est à nouveau fermé ... pour toujours et à jamais ....
Certaines des "meilleures pratiques" que vous apprenez à l'école ne sont pas pratiques ou rentables sur des projets du monde réel. L'un des plus grands changements que j'ai remarqués concerne la mise en forme et les commentaires. La plupart de mes professeurs ont souligné l'importance de documenter en détail votre code, mais dans le monde réel, un bon code est souvent (pas toujours!) Explicite, et plus important encore, de nombreux patrons ne veulent pas payer pour que vous passiez plus de temps à écrire commentaires.
Vous verrez parfois des programmeurs pressés par le temps utiliser des raccourcis et des anti-modèles qui nécessitent moins de plaques chauffantes que des solutions de qualité.
Cependant, l'un des plus gros problèmes que j'ai remarqués dans de nombreuses équipes et projets est ne réticence à apprendre de nouvelles choses. Beaucoup de programmeurs plus âgés avec qui j'ai parlé ont commencé leur carrière dans une période de génie logiciel du "Far West" lorsque les qualifications ont commencé et se sont terminées par la volonté d'écrire du code. Ils se sont souvent spécialisés dans des domaines complètement différents et se sont lancés 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 créer un logiciel interne). Certains de ces programmeurs autodidactes de la vieille école ne font jamais l'effort d'apprendre les pratiques de codage modernes et continuent de coder à peu près le style qu'ils ont appris il y a des décennies. Lorsqu'ils se retrouvent en charge de nouveaux projets en raison de l'ancienneté, ils ont tendance à freiner les projets et à nuire à la qualité globale du code.
Bien sûr, ce qui précède ne s'applique pas à tous les programmeurs plus anciens, et les codeurs de nouvelle génération peuvent être tout aussi coupables. J'ai travaillé avec de nombreux programmeurs plus jeunes qui ont acheté quelques outils et bibliothèques fraîchement sortis de l'université, puis ont complètement cessé d'apprendre. Ils téléchargeront une IDE ou bibliothèque une fois et ne la mettront 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 mise à jour de ses bibliothèques). Ils ne suivent pas les nouvelles fonctionnalités dans la ou les langues de leur choix et n'apprennent jamais de nouvelles langues. Ils n'apprennent pas de nouvelles stratégies de programmation et peuvent mal utiliser les modèles ou les paradigmes parce qu'ils ne connaissent pas d'alternatives plus appropriées (oh MVC, à quel point tu es abusé.) Avec le temps, leur flux de travail devient de plus en plus obsolète, et ils deviennent plus un passif qu'un actif.
En résumé, deux des plus grandes causes de bases de code en désordre sont les délais précipités et les programmeurs avec des connaissances obsolètes ou incomplètes. Malheureusement, la responsabilité des deux problèmes peut incomber fortement au patron ou au CTO, qui doit s'assurer que les délais sont réalistes et que le personnel est à jour sur ses connaissances et ses compétences. Si le patron ne sait rien des bonnes pratiques de programmation, le mieux que vous puissiez faire est d'essayer de suggérer des changements et d'espérer qu'ils soient ouverts aux suggestions. Malheureusement, ils peuvent être enclins à faire confiance à la Parole d'un programmeur plus expérimenté qui ne comprend pas OOP et aime écrire 10 000 classes de ligne.
Certaines des mauvaises pratiques de programmation résultent du fait de devoir travailler avec des logiciels hérités qui ont commencé leur développement il y a des décennies. S'il existe un énorme logiciel complexe, tout réécrire pourrait ne pas être une option. Il peut même être extrêmement difficile de comprendre tout ce que le code fait réellement. La meilleure option pourrait être de simplement 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 bien du mal mais de savoir raisons derrière chaque bien et mal. Lorsque vous connaissez les raisons, vous pouvez prédire les conséquences. Pourquoi utiliser tel ou tel principe non pas parce qu'il a été décrit dans un livre, mais parce que nous savons comment cela aide et ce qui se passe exactement si nous le cassons. Si vous savez ce qui se passe, vous pouvez peser le pour et le contre et prendre une décision. Cela vous aidera également à faire valoir votre position à chaque fois. SOLID et OOP peut également réduire la maintenance s'il est bien utilisé.
SOLIDE s'il est utilisé trop dogmatiquement conduit à trop de classes et de méthodes, ce qui n'est pas aussi bon que ça. N'en faites pas trop. C'est en partie un gros problème avec nos manuels et tutoriels car ils essaient souvent de promouvoir des idées sans justification appropriée. OOP a aussi ses inconvénients. De nombreux principes et paradigmes se contredisent. Vous n'avez pas besoin d'être au sommet, vous devez faire tout ce qui est raisonnable, justifié, élégant et simple.
De plus, comme c'est votre premier travail, il est probable que ces programmeurs ne soient pas très qualifiés. Mais là encore, on leur fait probablement confiance pour des tâches pas très difficiles qui peuvent être effectuées sans autant de compétences et pour un salaire inférieur par des codeurs moins qualifiés et moins chers. Voilà comment fonctionne l'économie. Chaque lieu de travail est différent.
Je comprends ce que tu ressens. Pas de panique. Vous aurez besoin de ce que vous savez, peut-être pas immédiatement, mais cela vous aidera. Peut-être sur un lieu de travail différent, peut-être à certaines occasions. Vous avez du temps devant vous pour aller plus loin.