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

140

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.

Sinistre
la source
J'ai ouvert une discussion sur le titre du chat: chat.stackexchange.com/transcript/message/40126879#40126879 Rejoignez-moi, s'il vous plaît.
dcorking
1
Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
Ingénieur mondial

Réponses:

263
  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.
Robert Harvey
la source
1
Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
Yannis
Où puis-je obtenir systématiquement ces informations sur le fait que je n’ai aucune orientation?
Ooker
4
Ne comprenez pas simplement quelle est la meilleure pratique, mais quels sont les avantages tangibles d’une meilleure pratique. Cela vous permet de relier la meilleure pratique à la pertinence et garantit également l' efficacité de l'application de la pratique pour avoir le meilleur effet. Si vous venez de dire qu'une pratique exemplaire permet de "séparer les préoccupations", vous ne pouvez probablement pas être sûr de choisir la bonne façon de tirer parti des avantages de la pratique.
AaronLS
51

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.

Peter A. Schneider
la source
2
@nocomprende: no entiendo ... Voulez-vous dire que le commun est plus commun et l'extraordinaire est malheureusement extraordinaire? Ou que le commun n'est pas extraordinairement bon? Hé bien oui.
Peter A. Schneider
3
"Ce que vous apprenez à l'université n'est en fait pas courant dans la plupart des domaines" - Cela semble être la clé ...
Brian Knoblauch
1
Je voulais simplement dire que le secteur des logiciels regroupe des personnes dotées de toutes les capacités humaines, de toutes les compétences, des entreprises de tous les types de préparation, de tous les types de problèmes, etc., comme dans le reste du monde. Le logiciel n'est pas différent de ces manières par rapport aux autres domaines. Le problème aurait pu être posé dans n'importe quel site SE.
1
"Les logiciels relatifs à la sécurité dépendent d'outils bien validés (nous utilisons actuellement un compilateur C ++ validé des années 1990)", ça me semble plutôt à la fine pointe!
Hovercouch
1
@ PeterA.Schneider, c'était une blague idiote sur le fait de contrôler de manière novatrice vos outils. ;)
Hovercouch
16

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.

Graham
la source
6
C'est bien de pouvoir aborder la pile technologique avec la question mentionnée
jasonoriordan
5
Qui veut parcourir 20 classes imbriquées et s'appelant simplement pour savoir ce qui se passe lorsque vous cochez ou décochez une case? Seulement les fous, ou les gens qui pensent que les professeurs d'université sont des dieux.
developerwjk
1
En fait, lors de la création de WebForm, les pratiques standard de l'industrie étaient différentes (ou inexistantes) et les applications existantes ne font jamais l'objet d'une refactorisation lorsque "la nouvelle façon géniale de faire les choses" commence à être adoptée. C'est pourquoi vous voyez beaucoup de code WebForm encombré de désordre. Les principes de programmation ne sont pas liés à la pile de technologies que vous utilisez, ils peuvent donc être appliqués même dans WebForms, Cobol, Assembly, peu importe.
BgrWorker
1
Oui c'est vrai. Combien de Mo était votre ViewState? Bizarrement, je pense que les contrôles côté serveur avaient tendance à encourager la logique métier dans l'interface utilisateur. Pourtant, le programmeur était bien responsable d'avoir facilement accepté la merde de programmation culte cultivée par asp.net. Ainsi: il y a tellement d'événements que les objets métier ne peuvent pas atteindre un état correct. Autobus. les objets ne pouvaient pas s'appeler en raison du couplage de l'interface utilisateur. Alors: oh, regarde Mo! Nous pouvons travailler "déconnectés!" nyuck, nyuck, nyuck Le volume de données réel a mis votre application à l'arrêt, les classes asp.net se faisant passer pour un moteur de base de données. Mais nous épargnions les connexions de l’usure!
radarbob
1
Tout ce chahut est vrai ... cœur sincère. J'ai vu tellement de choses décrites dans ce billet concernant les applications WebForms que cela me donne l'impression que ces applications ne sont guère meilleures que certains scripts PHP assemblés par un lycéen branché sur les boissons énergisantes - et c'était considéré comme un logiciel d'entreprise!
Greg Burghardt
12

À 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 ...

AnoE
la source
2
Alors, n'engagez que des personnes bien qualifiées, entièrement formées et enthousiastes pour faire… bon, n'importe quoi Pourquoi ne faisons-nous pas cela? Cela pose la question suivante: comment devraient vivre les personnes peu qualifiées, peu entraînées et peu enthousiastes? Charles Dickens a rapporté la réponse à cette question: pas très bien, voire pas du tout.
@nocomprende, vous projetez votre opinion, je n'ai pas sous-entendu ce que vous avez écrit. J'explique les raisons pour lesquelles le PO a remarqué.
AnoE
Je continue à penser à la question de Kurt Vonnegut de Dieu vous bénisse Monsieur Rosewater : « Que diable sont des gens pour ? »
2
@nocomprende, si je parle d'une "personne non qualifiée", je ne dis pas que les gens sont stupides, je dis que, quelle que soit la raison, une personne a fait un travail qui n'était pas bien formé pour le faire. La faute pourrait bien être à son manager de lui avoir donné le mauvais travail; ou avec des circonstances (p. ex. un collègue tombant malade), ou pour une myriade de raisons que vous pouvez imaginer. Cela n'a rien à voir avec de suggérer que nous devrions seulement embaucher des gens formidables. Si je dois réparer la plomberie de ma maison, vous pouvez être à peu près sûr que je vais faire des dégâts, bien que je sois excellent dans tout ce que je pourrais faire.
AnoE
1
Dans Anthropology, il existe une idée ancienne selon laquelle les sociétés esclavagistes telles que les anciens Égyptiens tiraient beaucoup moins de gens que les sociétés qui les aident à «s'épanouir». C'est pourquoi le capitalisme était meilleur que la culture médiévale. Idéalement, tout le monde serait en mesure de s’épanouir, puis nous tirerions pleinement parti de chacun et chacun tirerait pleinement parti de la société. Le capitalisme n'est pas assez bon pour garantir cela, nous avons donc besoin de quelque chose de plus. La preuve en est que des personnes ne font pas un travail optimal, car si le capitalisme était parfait, cela ne se produirait pas.
11

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 ....

Raul Luna
la source
16
Rien à voir avec l'Espagne. C’est le principe de Peter: les gens sont promus hors des postes où ils réussissent bien jusqu’à atteindre le poste où ils ne le sont pas, et restent bloqués là-bas, car il n’ya rien pour qui les promouvoir.
Jan Hudec
3
Il y a aussi le fait que l'industrie du logiciel continue de croître, de sorte que les personnes relativement peu expérimentées sont plus nombreuses. Et beaucoup d'entreprises n'ont pas du tout de personnel expérimenté, car elles sont nouvelles et trop économiques pour embaucher un ancien combattant, pensant qu'un groupe de nouveaux venus du collège suffiront - ils ne le feront pas.
Jan Hudec le
1
@JanHudec Je ne sais pas mec, je pense que je préférerais beaucoup avoir une jeune fille fraîchement sortie de l'université plutôt que l'une de ces personnes de plus de 20 ans d'expérience dont parle l'affiche originale
Mikey Mouse le
9
@ MikeyMouse, c'est vrai, il y a beaucoup de gens qui n'ont pas 20 ans d'expérience, mais 20 fois plus d'expérience. Et ils épellent très gros problème.
Jan Hudec
".. principe de Pierre .."; en particulier dans un organisme gouvernemental où il s'agit d'un phénomène plus conscient. Je l'appelle leur programme de gestion de consanguinité. Bien qu'il y ait souvent un équilibre entre bons et mauvais codeurs, l'horreur se produit lorsque le MIP renforce l'application de l'incompétence. Des années plus tard, lorsque certains les programmeurs sont maintenant des chefs de division qui, à leur tour, ne feront la promotion de personne meilleure qu’eux-mêmes, les bonnes personnes et les bonnes idées laissent ou sont chassées. Le magasin est devenu un cas d'incompétence; coincé dans la "mentalité restante de rayonnement de fond" de la programmation sur les ordinateurs centraux dans une culture de long terme pour s'entendre.
radarbob
7

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.

utilisateur45623
la source
19
Je n'aime vraiment pas ce mythe selon lequel un bon code est explicite et que les commentaires sont obsolètes. Au mieux, un bon code vous dira exactement ce qui se passe. Cependant, cela ne donne aucune indication sur la raison pour laquelle il fait quelque chose ou même si c'est correct. Commentez votre code pour que son futur responsable n'ait pas à deviner pourquoi vous fabriquez foo, mais pas barre .
user369450
13
Je ne suis pas d'accord avec votre premier paragraphe. La documentation de votre code (avec des commentaires, par exemple) est au moins aussi importante que lorsque vous étiez au collège. La différence est qu'aucun professionnel ne commentera ce qu'une ligne fait - ils documenteront POURQUOI. Ce qui se passe peut être lu à partir du code source. Pourquoi est souvent le résultat de plusieurs minutes à plusieurs heures de réflexion.
Araho
1
Il y a très peu de raisons d'écrire pourquoi le code agit, et la plupart du temps, cela pourrait être expliqué avec un meilleur nom de méthode. Regardons les choses en face, la plupart du code que nous écrivons tous est assez simple pour ne pas mériter de commentaires.
BgrWorker
1
Comment ça va encore? Le code est écrit une fois et lu plusieurs fois. Écrire des commentaires et vous serez économiser du temps à long terme. @ BgrWorker dépend de la personne, je suppose. J'écris régulièrement des algorithmes et je pense qu'ils méritent des commentaires (le plus récent étant un analyseur mathématique symbolique ... il a certainement besoin de commentaires)
person27
1
Je pense que les tests unitaires ont bien plus de valeur que les commentaires. Trop souvent, j'ai vu des situations où le code était mis à jour et où les commentaires ne s'appliquaient plus. Dans ce cas, les commentaires obsolètes compliquent la tâche pour comprendre ce qui se passe. Les tests unitaires documentent l'intention du programmeur d'origine et si votre système CI exécute des tests unitaires lors de l'enregistrement, vous devez les conserver.
bikeman868
2

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.

John Smith
la source
L'échec n'est généralement pas une option non plus.
1

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.

Gherman
la source