La décision de conception ou de programmation la plus regrettable que vous ayez prise? [fermé]

J'aimerais savoir quel genre de décisions de conception vous avez prises et comment elles se sont retournées contre vous. A cause d'une mauvaise décision de conception, j'ai fini par devoir supporter cette mauvaise décision pour toujours (j'y ai également pris part). Cela m'a fait comprendre qu'une seule erreur de conception peut vous hanter pour toujours. Je veux apprendre des gens plus expérimentés quel genre de gaffes ont-ils vécu et qu'ont-ils appris d'eux?

Je suis sûr que cela aidera beaucoup les autres programmeurs en leur évitant de répéter ces décisions.

Merci d'avoir partagé votre expérience.

Ignorant YAGNI , encore et encore ...

"Je le ferai plus tard"
"Plus tard" ne vient jamais.

C ++, héritage virtuel multiple en forme de losange . Vous avez eu l'idée.

La configurabilité dans une application est agréable. Trop de configurabilité est un cauchemar à utiliser et à maintenir.

Une de mes erreurs m'a appris que la normalisation de la base de données ne devrait pas être suivie aveuglément. Vous pouvez, et dans certaines situations, vous DEVEZ aplatir vos tables.

J'ai fini par gérer des charges de tables (via des modèles) et les performances n'étaient pas aussi bonnes que possible avec un peu d'aplatissement des tables.

Utiliser un seul caractère dans les bases de données pour les statuts, etc. Cela ne sert à rien, la surcharge liée à l'utilisation d'un caractère plus long () ou de nvarchar2 () est minuscule par rapport au réseau et à l'analyse effectuée par tout appel SQL, mais les caractères finissent toujours plutôt obscurci, ou à court (pas pour les statuts, mais d'autres choses). Mieux vaut mettre simplement la version lisible par l’homme et avoir également dans votre modèle Java (dans mon cas) une énumération avec des valeurs correspondantes.

J'imagine qu'il s'agit d'une forme d'optimisation prématurée inutile et aveugle. Comme si l’utilisation d’un seul personnage sauverait le monde de nos jours. Mis à part les booléens Y / N dans les bases de données qui ne prennent pas en charge les booléens / bits.

Ne pas développer une couche d'accès aux données appropriée , et avoir SQL partout dans mon code, juste pour obtenir quelque chose de "rapide" et opérationnel. Plus tard, lorsque le projet a commencé à se développer et que les exigences ont changé, il est devenu un cauchemar. Je ne savais pas ce qu'est un DAL à l'époque.

Je suis heureux d'avoir dépassé cela, même si je vois encore des programmeurs ayant plus de 20 ans d'expérience dans ce domaine.

Penser que je pourrais être architecte, développeur et PM sur le même projet.

2 mois de sommeil 3 heures par nuit m'a appris que vous ne pouvez pas le faire.

Choix de Microsoft Foundation Classes (MFC) pour l'écriture d'un IDE Java.

Ce n’était pas ma décision (j’ai rejoint la société un peu plus tard), mais quelque part, j’ai pris un peu trop de chemin, y compris la traduction de tous leurs messages de journal.

Résultats:

• Plus difficile d'ajouter une nouvelle journalisation
• Plus de coût pour la traduction
• Les journaux sont plus difficiles à lire après

Oops.

Réinventer la roue

Faire trop de design . Créer de nombreux diagrammes UML, en particulier des diagrammes de séquence pour chaque opération, dont une grande partie s'est finalement révélée inutile. À la fin, il s'est avéré qu'un gain de temps considérable aurait pu être gagné en omettant une conception / des diagrammes inutilement détaillés et en commençant à coder directement.

Les clients qui croient savent ce qu'ils veulent et en font trop avant de vérifier avec eux.

Mon pire décision de conception? Dans les années 80, je travaillais sur un projet dans lequel nous avons eu l’idée géniale de créer une sorte de modèle pour nos écrans de saisie de données, qui serait interprété au moment de l’exécution. Ce n'est pas une mauvaise décision: cela rendait la conception des écrans de saisie facile. Fondamentalement, il suffit de créer un fichier qui ressemble à l’écran de saisie, avec des codes spéciaux pour identifier ce qui était une étiquette, c’est ce qui était un champ de saisie, et pour déterminer si les champs de saisie étaient alphanumériques ou numériques. Ensuite, j'ai décidé d'ajouter quelques codes spéciaux à ces fichiers pour identifier les validations à effectuer. Ensuite, j'ai ajouté plus de codes pour permettre la construction conditionnelle de l'écran, le champ X inclus uniquement lorsqu'une condition était vraie, etc. Ensuite, j'ai ajouté plus de codes pour effectuer un traitement simple des entrées. Etc. Finalement, nous avons transformé notre modèle d’écran en un nouveau langage de programmation complet avec des expressions, des structures de contrôle et une bibliothèque d’e / s. Et pour quoi faire? Nous avons fait une tonne de travail pour réinventer FORTRAN. Nous avions une étagère pleine de compilateurs pour des langages mieux conçus et mieux testés. Si nous avions consacré autant d’efforts à la fabrication de produits pour lesquels nous possédions une certaine expertise, cette société pourrait toujours être en activité aujourd’hui.

Application trop zélée de YAGNI (désignée Conception par énumération dans les pièges du développement orienté objet ) dans un environnement où toute personne sensée pourrait dire que les exigences allaient définitivement changer. Et changer à plusieurs reprises.

Si vous avez tout codé (en dur) exactement selon les exigences actuelles, en écrasant tous ceux qui disent: "est-ce que cela ne pourrait pas être plus générique?" avec votre maillet YAGNI - et les exigences changent radicalement (mais d’une manière qui aurait pu être raisonnablement anticipée), alors cela peut être la différence entre prendre deux semaines pour s’adapter et prendre 20 minutes.

UPDATE: Pour clarifier, voici un exemple fictif qui n'est pas très éloigné de ce qui s'est passé. Stack Overflow a été conçu pour prendre en charge les badges, mais supposons qu’ils ne puissent penser qu’à quatre badges au début. Seulement quatre, un si petit nombre, ils ont donc codé en dur la prise en charge de quatre badges exactement dans toute la logique du site. Dans la base de données, dans les informations utilisateur, dans tout le code d'affichage. Parce que "tu n'auras pas besoin" de badges auxquels tu ne penses pas, n'est-ce pas? Supposons ensuite que le site soit mis en ligne et que les gens suggèrent de nouveaux badges. Chaque badgeCela prend jusqu'à deux semaines à ajouter, car il y a tellement de codage difficile à modifier un peu partout. Néanmoins, "vous n’aurez pas besoin de" plus de badges que la liste actuelle, il n’ya donc jamais de refactoring pour prendre en charge une collection générique de badges. Une telle collection générique aurait-elle pris plus de temps à l’avance? Pas beaucoup, le cas échéant.

YAGNI est un principe précieux, mais il ne doit pas être utilisé pour excuser une conception médiocre et un codage dur inapproprié. Il y a un équilibre et avec l'expérience, je crois que je m'en approche.

Ressources humaines incompétentes

Essayer de faire quelque chose de bien avec les mauvaises personnes!
Même s’ils jouent le rôle d’un Premier ministre superflu de l’ego (ce qui est plutôt courant, en particulier dans les grandes entreprises où leur incompétence peut perdurer plus longtemps).

À chaque fois, je crée une dette technique, rédige un code de procédure, passe des tests, etc. parce que je me dépêche. Presque inévitablement, je trouve que cela me fait souffrir plus tard.

Utilisation des services d’intégration SQL Server (SSIS).

Je ne le souhaite pas à mon pire ennemi.

Après avoir construit plusieurs packages SSIS au cours des deux derniers mois, il ne reste plus qu'à découvrir que les packages que j'ai développés ne sont ni distribuables, ni non déployables. Spécifiquement dans un environnement non Web, sous licence non SQL Server.

C'est une très mauvaise situation, quand vous avez moins de 48 heures pour réécrire vos packages SSIS dans du code POCO .NET pur ou que vous manquez votre échéance cible.

Je suis étonné de pouvoir réécrire trois packages SSIS (cela m'a pris deux mois pour tester et développer), en 12 heures en code .NET pur, avec les adaptateurs OLEDB et les adaptateurs SQL.

SSIS n'est pas distribuable et n'exécutera pas de packages à partir d'un ordinateur client si aucune licence SQL Server n'y est installée (en particulier le fichier DTSPipeline.dll). Ce serait formidable de savoir à l'avance. Je vois maintenant l'avertissement (en petits caractères) sur MSDN. Cela ne sert à rien si vous avez des exemples de code sur Internet avec du code machine uniquement sous licence SQL. En gros, vous devez créer un service Web qui communiquera avec votre serveur SQL pour exécuter vos packages SSIS par programme. Vous ne pouvez pas les exécuter à partir de code .NET pur, sauf si une licence SQL est installée sur la machine en cours d'exécution. Comment irréaliste est-ce? Microsoft s'attend-il vraiment à ce que SSIS soit utilisé à partir de machines nécessitant l'installation d'un serveur SQL? Quel gaspillage complet de deux mois.

Mon entreprise n'utilisera plus jamais SSIS à cause de cette petite impression "gotcha".

Ne pas définir le mécanisme / modèle de déploiement le plus tôt possible.

Jeter des œufs de Pâques «drôles» dans un code que j'ai écrit avant de partir en vacances pendant deux semaines. Je pensais que je serais la seule personne à le lire à mon retour, cela me ferait rire et me préparer à le recoder.

Inutile de dire que mon patron n’a pas été impressionné lorsqu’il a relu le texte en mon absence et qu’il était encore moins impressionné lorsque l’un des «œufs de Pâques» touchait son visage avec un drôle de dessin dans ASCII.

Mmmmmm ...

Utiliser des thèmes ASP.Net alors qu’un simple dossier classique aurait bien fonctionné.

Prendre le chemin rapide pour faire fonctionner un code plutôt que le bon chemin (un peu général, mais nous l'appellerons une abstraction et donc une réponse «juste»).

Mon entreprise a un modèle de développement semblable à une cascade, dans lequel nos utilisateurs et nos analystes définissent les exigences des projets. Sur l’un de nos «gros» projets, nous avons reçu une pile d’exigences et j’ai remarqué que certaines exigences contenaient des détails d’implémentation , en particulier des informations relatives au schéma de base de données utilisé par notre système de comptabilité.

J'ai fait remarquer aux utilisateurs professionnels que la mise en œuvre était mon domaine, elle ne devrait pas être contenue dans les exigences. Ils n'étaient pas disposés à modifier leurs exigences car, après tout, ils sont THE BUSINESS, et il est donc logique que les comptables conçoivent un logiciel de comptabilité. En tant que modeste développeur qui est trop éloigné du sondage totem, je suis payé pour le faire au lieu de penser . Même si je me suis battu, je ne pouvais pas les persuader de réécrire les exigences - il y a trop de paperasserie et de paperasserie autour des changements, ce qui est trop compliqué.

Alors, je leur ai donné ce qu'ils ont demandé. Au moins, ça fonctionne , mais la base de données est étrangement conçue:

• Beaucoup de normalisation inutile. Un seul enregistrement contenant 5 ou 10 champs est divisé en 3 ou 4 tables. Je peux m'occuper de cela, mais j'aimerais personnellement que tous les champs 1: 1 soient placés dans une seule table.

• Beaucoup de dénormalisation inappropriée. Nous avons une table qui stocke les données de facturation qui stocke plus que les données de facturation. Nous stockons un certain nombre de drapeaux divers dans la table InvoiceData, même si l'indicateur n'est pas lié logiquement à la table InvoiceData, de sorte que chaque indicateur a une valeur de clé primaire magique et codée en dur et que tous les autres champs sont annulés dans la table InvoiceData. Comme le drapeau est représenté comme un enregistrement dans la table, j'ai suggéré de tirer le drapeau dans sa propre table.

• Beaucoup plus de dénormalisation inappropriée. Certains indicateurs à l'échelle de l'application sont stockés sous forme de colonnes dans des tables inappropriées, de sorte que la modification de l'indicateur d'une application nécessite la mise à jour de tous les enregistrements de la table.

• Les clés primaires contiennent des métadonnées. Ainsi, si une clé primaire varchar se termine par "D", nous calculons les factures en utilisant un ensemble de valeurs, sinon, nous le calculons avec un autre ensemble. Il serait plus judicieux d'extraire ces métadonnées dans une colonne distincte ou d'extraire l'ensemble de valeurs à calculer dans une autre table.

• Les clés étrangères accèdent souvent à plusieurs tables, de sorte qu'une clé étrangère se terminant par "M" peut être liée à notre table de comptes de crédit, alors qu'une clé étrangère se terminant par "A" peut être liée à notre table de comptes automatiques. Il serait plus facile de scinder les données en deux tables, MortageData et AutoInsuranceData.

Toutes mes suggestions ont été abattues avec beaucoup de pleurs et de grincements de dents. L'application fonctionne comme prévu, et bien que ce soit une grosse boule de boue, tous les programmes malveillants, les cas particuliers et les règles commerciales étranges sont documentés de manière sarcastique et humoristique dans le code source.

S'en tenir à une technologie plus ancienne, car il semble trop fastidieux de laisser vos clients passer à une nouvelle version du framework .NET, mais la création du logiciel prendra plus de temps, car vous ne pouvez pas utiliser certains composants (qui permettent de gagner du temps). version plus récente du framework.

De retour à l'université, je travaillais sur mon projet de design senior. Un autre gars et moi écrivions un système de suivi des bogues basé sur le Web. (Rien de révolutionnaire, mais nous voulions tous les deux avoir une expérience Web.) Nous avons fait la même chose avec les servlets Java, et cela a fonctionné assez bien, mais pour une raison idiote, au lieu d’opter pour Exceptions comme mécanisme de traitement des erreurs, nous avons choisi utiliser des codes d'erreur.

Lorsque nous avons présenté notre projet de grade et qu'un membre du corps enseignant a demandé l'inévitable: "Si vous deviez le refaire, que feriez-vous différemment?" J'ai instantanément su la réponse: "J'utiliserais des exceptions, c'est pour cela qu'elles sont là."

Ce n’était pas mon choix de méthode, mais un XSLT a été créé pour convertir un fichier XML basé sur des lignes en un rapport HTML basé sur des colonnes.

Cela ne fonctionnait que dans IE, il était complètement impossible de décoder comment cela fonctionnait. Chaque fois que nous avions besoin de l'étendre, c'était incroyablement difficile et cela a pris des siècles.

À la fin, j'ai remplacé par un minuscule script C # qui faisait la même chose.

essayer d'utiliser toutes les nouvelles technologies (pour apprendre de nouvelles technologies) même si cela n'a même pas besoin.

Je n'ai pas pris assez de temps pour évaluer le modèle d'entreprise. J'ai fait ce que le client a demandé, mais 6 à 12 mois plus tard, nous sommes tous deux arrivés à la conclusion que nous aurions dû faire autrement.

Concevoir sans spécification.

J'ai implémenté une sous-section d'une application en fonction des besoins.

Il s’avère que les exigences étaient gonflées et plaquées or, et mon code était sur-conçu. J'aurais dû concevoir ma sous-section pour fonctionner uniquement avec ce que j'avais ajouté à ce moment-là, mais prévoir d'ajouter tous les autres éléments sans inclure de support générique dès le départ.