Les développeurs de logiciels qui ignorent la qualité / les normes sont-ils meilleurs pour l'entreprise? [fermé]

Les développeurs de logiciels qui choisissent de ne pas faire de l'optimisation du code, des normes et des meilleures pratiques une priorité absolue, créent-ils un code plus utile que les développeurs qui souhaitent se soucier de l'optimisation, de la mise en œuvre des normes et des pratiques de codage au-dessus de l'exécution des tâches à temps?

Comment ces différentes méthodologies se comparent-elles en ce qui concerne les évaluations de performances individuelles?

Comment ces styles se comparent-ils dans les évaluations par les pairs?

Quelle est la meilleure façon d'influencer votre équipe pour implémenter davantage de meilleures pratiques pendant le SDLC?

Non, ils ne seront respectés que par le propriétaire du projet du moment.

Ils seront saccagés pendant des années par:

• futurs mainteneurs,
• futurs testeurs,
• futurs maîtres d'ouvrage,
• futurs managers,
• et à peu près toute personne impliquée dans la base de code à l'avenir.

Ils pourraient même recevoir le même traitement de:

• les testeurs actuels,
• les rédacteurs actuels de la documentation technique.

Fausse dichotomie: les qualités sont orthogonales.

                Haute qualité Basse qualité

Rentable IMPRESSIONNANT Sketchy

Iffy FIRE FIRST non rentable

Non. Les meilleures pratiques sont les meilleures parce que, par définition , elles aident à réaliser les projets plus correctement, en moins de temps, avec une modification plus rapide en cours de route, donc les ignorer est garanti pour diminuer les bénéfices. Bien sûr, vos gestionnaires peuvent prescrire des pratiques qu'ils pensent être les meilleures, mais qui ne le sont pas réellement, ou ils peuvent mal évaluer ce que les clients paieront et ce qui ne le sera pas - alors tous les paris sont annulés.

Les normes de codage sont plus délicates; il est possible de prescrire trop de détails à vos codeurs, ce qui entraîne une baisse d'efficacité. Mais avec l'expérience, il devient assez facile de dire des lignes directrices utiles de la microgestion anale-rétentive, donc la même chose s'applique: les meilleures pratiques réelles valent toujours la peine, les pseudo-meilleures pratiques généralement pas.

L'optimisation de code ne vaut généralement pas la peine d'être effectuée à moins que vous n'ayez mesuré vos goulots d'étranglement, confirmé que la réalisation d'une optimisation est nécessaire et mesuré que votre astuce astucieuse répond réellement à l'exigence de performance. Sinon (ce qui est le plus souvent), cela ne vaut pas la peine, et donc pas optimal.

Suis-je d'accord avec les développeurs qui ne se soucient pas de l'optimisation du code et des pratiques? Non.

Font-ils le travail dont ils ont besoin? Oui.

Une entreprise consiste à gagner de l'argent, et la seule façon de gagner de l'argent est de lancer des produits. Cela signifie généralement que les projets ont des calendriers stricts, ce qui signifie que ce qui peut être la meilleure façon de faire quelque chose n'est peut-être pas le moyen le plus rapide de faire quelque chose.

Bien que je ne sois pas d'accord avec ce style de développement, l'entreprise peut être considérée comme respectable si des produits sont lancés.

Non, et je trouverais le chemin le plus rapide loin de cette entreprise qui apprécie ces vices.

Oui et non, ce qui est un peu délicat mais c'est une meilleure pratique et pas une pratique parfaite. Idéalement, vous devez les suivre en permanence, mais il y aura toujours une situation où l'entreprise veut mettre ses besoins avant les besoins de vos produits.

Vous serez détesté par les responsables mais aimé par votre patron.

Les meilleures pratiques sont un peu comme le bon sens, tout le monde convient que tout le monde devrait le savoir jusqu'à ce que deux personnes commencent à en discuter en détail. Il n'y a pas deux personnes complètement d'accord sur la définition et il n'y a pas de source logique de vérité qui s'applique à toutes les situations.

Ecrivez-vous le système de guidage d'un satellite spatial (vous ne l'êtes probablement pas)? Alors l'enfer Aucun code de mauvaise qualité / performant n'est jamais acceptable dans ce genre de travail.

Êtes-vous en train d'écrire un site Web jetable pour une poussée marketing unique (vous ne le faites probablement pas non plus ou vous n'auriez pas posé la question, mais c'est plus probable que le satellite)? Alors enfer Oui, faites sortir ce morceau de papier par tous les moyens nécessaires pour respecter le délai, le prochain directeur marketing va probablement faire autre chose avec une autre entreprise de toute façon. CE QUE VOUS FAITES N'EST PAS DE L'ART OU DES SCIENCES - PAYEZ.

Tout le reste entre les deux: négociable, surtout tant que le développeur est accroché au support initial.

Jusqu'à ce que la seconde venue de l'être sacré que vous préférez se produise et qu'il / elle définisse les pratiques de développement de manière miraculeuse, il y aura une place importante pour le débat sur tout projet non directement responsable des décisions de vie ou de mort qui ne l'est pas. si insignifiant pour être jetable.

Tout ce qui est en dehors des meilleures pratiques labellisées vitales est généralement plus comme la politique de l'entreprise, les spécifications du client ou l'opinion personnelle. Beaucoup d'entre eux sont une opinion personnelle sur laquelle de nombreuses personnes s'entendent actuellement, mais cela ne fait pas d'elle un guide immuable pour toutes les situations.

Combien d'argent ils gagnent pour l'entreprise est discutable. S'il y a un niveau de révision du code en question, les coûts de maintenance augmenteront et quelqu'un ne sera pas content. Les coûts élevés de maintenance à long terme sont plus chers que de le faire correctement à l'avance.

Le degré de respect qu'ils obtiennent est probablement propre à chaque cas. À un certain moment, cependant, quelqu'un le remarquera.

Ne pas se soucier de ces choses peut faire gagner plus d'argent à court terme à l'entreprise, mais pourrait lui coûter plus d'argent à long terme pour plus de corrections de bogues et de codage de maintenance.

Parfois, un travail rapide et sale peut être nécessaire s'il y a une ruée vers des entreprises concurrentes pour obtenir des produits similaires sur le marché en même temps, mais les coûts futurs de telles actions doivent être soigneusement examinés.

Tout dépend du client.

Un client qui aime rapide et sale (et généralement moins cher) ne se soucie pas que cela posera des problèmes à l'avenir.

Pensez à la construction d'armoires.

Certains paieront et apprécieront des armoires construites sur mesure de bonne qualité. Ils ne se soucient pas des frais supplémentaires des tiroirs en bois dur et de la quincaillerie de premier ordre. Cela ne les dérange pas, cela prendra une semaine ou même un mois supplémentaire pour construire et installer les choses.

Beaucoup ne le feront pas. Beaucoup opteront pour les produits de masse en panneaux de particules bon marché que vous obtenez dans un magasin à grande surface. Ils veulent qu'ils soient installés en 2 jours. Un petit écart ici et là est parfaitement acceptable. Ils ne se soucient pas qu'ils s'effondreront dans 10 ans.

Donc, si vos gestionnaires font l'éloge du développeur qui le fait rapidement et sale, soit vos clients ne veulent pas de haute qualité, soit les gestionnaires mentent aux clients.

Seul le temps nous le dira. Faites ce que les managers veulent ou trouvez un autre emploi.

Non jamais. Optimisation du code de l' OMI, les meilleures pratiques, véritable savoir -faire sont la PLUPART chose importante à avoir dans une base de code; sans elle, le tout se transforme en boue et est maintenu avec du ruban adhésif. C'est une conception non durable. C'est comme ignorer une tumeur parce qu'elle est petite et que vous êtes en bonne santé maintenant; vous êtes en bonne santé maintenant mais quelques années plus tard, il devient terminal parce que vous l'avez ignoré pendant si longtemps.

Non seulement je ne suis pas d' accord avec les développeurs qui ne se soucient pas de ces choses, mais je n'ai aucun respect pour eux au démarrage. Un moyen infaillible de me faire envisager de quitter une organisation, peu importe la durée de mon séjour, est d'être entouré d'une équipe dans laquelle je suis la seule personne (sinon la seule personne dans toute l'entreprise) qui se soucie sur les concepts de génie logiciel appropriés.

Une bonne lecture: http://www.joelonsoftware.com/items/2009/09/23.html

Mais à mon humble avis, les meilleures pratiques d'un homme sont un autre cauchemar pour l'homme. Et chaque base de code non triviale sera un cauchemar pour un étranger.

Quoi que vous en pensiez, ne vous en faites pas.

EDIT: Je ne défends aucune des positions, selon la tâche que je pourrais me pencher de chaque côté.

Mieux pour l'entreprise? Ça dépend.

Pour une startup avec des fonds limités, faites-le et sortez-le - peu importe si c'est désordonné, cela peut être corrigé plus tard quand il y a plus de ressources.

Pour un produit mature où de nombreux utilisateurs comptent sur la qualité du logiciel, tout doit être fait "correctement".

Mieux pour le développeur individuel? En fait, ce n'est pas pertinent. Faites simplement la même chose que ce que font vos collègues et laissez la direction gérer les retombées - ce n'est pas votre travail. Si vous réparez la merde des autres tout le temps, vous serez considéré comme lent, et vous serez celui qui est toujours là tandis que les autres ont été promus au-dessus de vous. Obtenez avec le programme, ou sortez pendant que vous le pouvez si c'est si mauvais.

Dépend du développeur et du projet / situation.

Des temps extraordinaires nécessitent des mesures extraordinaires.

Donc, si j'ai besoin de quelque chose maintenant, et que quelqu'un est en train de sur-concevoir une application java de niveau entreprise qui exploite pas moins de 14 des derniers cadres de mots à la mode tandis qu'un simple script python fera le travail est aussi pire que le développeur qui coupe les coins et pense le code buggy fera l'affaire en temps normal.

Être développeur est en partie flexible. Vous ne devez pas être esclave de vos outils et suivre aveuglément les pratiques - il y aura toujours un cas où ils vous feront défaut. Savoir quand briser et plier les règles est l'une des choses qui viennent avec beaucoup d'expérience et qui sont précieuses.

Dans votre cas - s'il fournit plus de valeur que vous parce que la vitesse est critique, même après avoir pris en compte l'augmentation des coûts de maintenance, il mérite la meilleure compensation. De l'autre côté - si vous êtes coincé avec le nettoyage de son gâchis - vous avez un problème de communication avec la direction.

C'est au cas par cas. Sauf le style de codage - il n'y a aucune excuse.

Je suis désolé, mais je serais en désaccord avec la plupart des réponses à cette question, à l'exception de la première.

La principale valeur d'un logiciel est qu'il est flexible.

Je ne pense pas que vous devriez réécrire le code des autres sans juste motif. Si vous devez changer un module pour une raison quelconque pour implémenter votre fonctionnalité, vous êtes maintenant, pour le meilleur ou pour le pire, le propriétaire de ce module. Changez-le, réécrivez une partie, réécrivez tout.

Ne produisez jamais une qualité médiocre en termes de flexibilité. Il n'y a rien de tel que de jeter quoi que ce soit dans un logiciel. Si le client dit que c'est temporaire et qu'il n'en aura plus besoin après une certaine date, et qu'il ne se soucie pas de la qualité, dites "mauvais" ou écrivez que le code ne sera pas modifié par vous ou par un autre programmeur une fois il est déployé en production, ou vous avez le droit de les poursuivre.

L'hypothèse la plus mauvaise que je vois dans certaines de ces réponses est qu'un code propre réduit en quelque sorte la vitesse de développement. Pour tout projet de n'importe quelle substance (plus de 6 heures de travail), un code propre accélère le développement à long terme (plus d'une semaine). Je l'ai vu maintes et maintes fois.

Un code de mauvaise qualité est tout simplement irrespectueux envers la profession et vos collègues. Désolé mais vrai.

Donc pas de mauvaise qualité, en termes de flexibilité, jamais!