Tentations nuisibles dans la programmation

97

Juste curieux, quels genres de tentations dans la programmation se sont avérés vraiment nuisibles dans vos projets?

Par exemple, lorsque vous ressentez le besoin urgent de faire quelque chose et que vous croyez que le projet en bénéficiera ou que vous ferez simplement croire que c'est le cas, et après une semaine, vous réalisez que vous n'avez pas résolu tous les problèmes mais que vous en avez créé de nouveaux ou , dans le meilleur des cas, plaisait à votre bête intérieure sans impact visible.

Personnellement, je trouve très difficile de ne pas refactoriser un mauvais code. Je travaille avec beaucoup de mauvais codes hérités, et il faut de grandes respirations pour ne pas y toucher quand je n'ai aucun test pour prouver que mon refactoring ne casse rien.

Un autre démon pour moi dans l'interface utilisateur, je peux littéralement passer des heures à changer la disposition de l'interface utilisateur simplement parce que j'aime le faire. Parfois, je me dis que je travaille sur la facilité d'utilisation, mais la vérité est que j'aime bouger les boutons.

Quels sont vos démons de la programmation et comment les éviter?

programming-practices language-agnostic Dan
la source
19
Je trouve amusant que personne n’ait été en mesure de répondre à la deuxième partie de votre question: "[et] comment les éviter?".
Craige
3
Quelqu'un a-t-il remarqué que c'était la première question sur SE toute la journée?
msarchet
+1 pour "... passer des heures à changer la disposition de l'interface utilisateur ..." Je tombe trop souvent dans ce piège.
7wp

Réponses:

67

La généralisation prématurée est mon gros bugaboo; au lieu de résoudre le problème à la main d' abord et attendre jusqu'à ce qu'il ya un besoin réel de résoudre le cas général, je vais toujours après le cas général à l' avant et le vent par écrire une tonne de code qui est plus complexe qu'il doit être.

Mise à jour:

Voir " Sin # 1 - Généralisation prématurée " pour une description détaillée.

k3b
la source
6
Je déteste quand les astronautes de l'architecture font ça!
Ozz
13
Oh, la joie de metafactoryfactories :(
+1 "Une étude de grands designers a révélé qu'ils étaient tous bons pour anticiper les changements" (Code Complete 2). Il est bon de pouvoir savoir quels types de changement sont probables. Ensuite, vous pourrez décider s’il ya quelque chose à gagner en résolvant le cas plus général plus tôt - si cela permettrait de gagner du temps plus tard. Parfois, cela ne vaut pas la peine, il serait tout aussi facile de modifier le code ultérieurement.
MarkJ
1
Avez-vous entendu parler du principe YAGNI (vous n'en aurez pas besoin) ?
Oscar Mederos
1
Cette. Je mets le blâme sur le fait que créer un code joli, généralisé et réutilisable est très satisfaisant, surtout si le problème en lui-même n’est pas très difficile et / ou n’est qu’un simple rappel de ce que vous avez fait auparavant. Exemple: opérations de base de données CRUD génériques (interface utilisateur, réponse à une action de l'utilisateur, action avec une base de données, thar).
Cthulhu
197

"Nous reviendrons sur ce problème et le réparerons plus tard. Nous en avons juste besoin maintenant!"

utilisateur18041
la source
16
C'est le diable absolu.
Alesplin
6
Je vous donnerais +100 pour cela si je le pouvais. "Plus tard" ne se passe jamais. Faites les choses bien la première fois ou pas du tout.
Rapidement maintenant
12
N’est-ce pas le complément des heures passées à refactoriser un mauvais code? Nous pouvons diviser le monde en programmeurs qui "le répareront plus tard", mais ce n’est pas le cas, et les programmeurs qui essaient de faire les choses correctement la première fois passent ensuite des heures à "refactoriser le code incorrect".
6
reformulez ceci en "Nous reviendrons et réparerons cette prochaine itération " et cela semble tellement plus structuré
Chris S
4
Tu dois faire ça. Si vous passez tout votre temps à le rendre parfait, il ne sera jamais expédié. Terminez le projet, puis polissez-le.
Zan Lynx
105

La date limite est tellement longue, j'ai assez de temps pour le faire, alors pourquoi ne pas passer un peu de temps à surfer sur le Web?

utilisateur281377
la source
72
remplacer "web" par "programmers.stackexchange.com" :)
davidhaskins
1
Y a-t-il autre chose sur le Web qui mérite d'être lu? J'avais oublié qu'il y avait autre chose!
James McLeod le
3
aka 'Damn you, Minecraft'
johnc
1
@david, ce n'est que le point de départ sur le Web - la question est de savoir jusqu'où vous allez ...
Je dirais que ce n'est plus aussi valable en raison de l'agilité.
vartec
103

"Il ne s'agit que d'un code de preuve de concept à jeter. Une fois qu'ils l'aimeront, je le rendrai vraiment bon."

Davidhaskins
la source
13
C'est ce qu'on appelle le développement rapide d'applications. et cela ne fonctionne jamais dans un environnement professionnel. :)
John Kraft le
12
C'est drôle que pour moi, c'est l'inverse: je ne peux tout simplement pas me faire écrire du code à jeter, même si c'est exactement ce qui est requis.
Dan
6
Je travaille dans la finance et RAD continue de bien fonctionner, en particulier dans les domaines VBA / Excel. Il y a un talent pour cela, RAD ne doit pas nécessairement signifier bâclé.
Ian
5
Et parfois, l'application que vous avez passé deux ans à perfectionner finit par être un code à jeter parce que quelqu'un de plus haut dans l'échelle a décidé "oh, nous ne pouvons pas faire cela" ou une autre version de "ça ne fait rien".
PSU le
12
Cette. Moi: "Ceci est juste ma preuve de concept. Si vous l'aimez, nous allons écrire la version de production." Manager: "Votre version fonctionne, expédions-la!" Moi: "Et bien ça ne couvre pas toute l'utilisation ca ... tu as déjà été envoyé, n'est-ce pas?"
74
  1. Refactoring une partie du code quelques jours avant la publication.
  2. Internet: La plus grande distraction de tous.
  3. Nouvelle technologie : Je ne peux pas garder les mains sur les nouvelles technologies.
  4. Optimiser: Optimiser, Optimiser. .. et plus Optimiser
  5. Perfection : Jamais été satisfait du code.
  6. TODO: Manque de temps pour tout ce qui ne sera jamais fait.
  7. Estimation du temps: Beaucoup de PM ne considèrent pas cela comme une "estimation". Ils prennent comme fait.
  8. Promesses: Donner trop de promesses.
Amir Rezaei
la source
1
Une fois travaillé sur un projet qui avait 100 personnes dans une grande pièce, et seulement 2 ordinateurs partagés avaient Internet. La productivité était très élevée. La direction a donné à tout le monde Internet et s'est demandé pourquoi la production de travail avait été divisée par deux.
Rapidement maintenant
2
En ce qui concerne l' estimation du temps ... tant de gestionnaires le prennent comme point de départ dans la négociation (comme pour la négociation d'un prix). Ceux qui le prennent comme un fait égaré mais au-dessus de la moyenne ...
dbkk
@quickly_now Couper le net fonctionne probablement pour des tâches banales telles que la saisie de données ou des corrections de routine, pour lesquelles vous n'avez pas besoin de chercher quoi que ce soit. Pour de nombreuses choses inhabituelles (par exemple, la recherche de documents / exemple de code d'API), Google est votre ami - il vous faut 5 fois plus de temps pour le résoudre vous-même. De plus, si les gens ne sont pas motivés et veulent être distraits, ils trouveront des moyens.
dbkk
@dbkk - oui jusqu'à un certain point. Tout était à Ada, il n'y avait pas d'API à rechercher, c'était du matériel spécialisé et une classification de sécurité nationale. Mettre des machines connectées à Internet non classifiées dans cet environnement était également un cauchemar pour la sécurité.
Rapidement maintenant
55

En proie à la tentation de tout construire en interne, quand il existe des frameworks et des bibliothèques.

FrustratedWithFormsDesigner
la source
6
Parfois, les frameworks et les bibliothèques existants sont marqués Verboten en grosses lettres rouges par IT legal.
Christopher Mahan
22
Et bien sûr, le tempo opposé: utiliser un framework ou une bibliothèque inconnus et supposer qu’il fera ce qu’il faut et que tout se passera sans heurts.
Carson63000
"mais cela ne prendra qu'une semaine pour écrire et notre framework fera exactement ce que nous voulons, celui en ligne gratuit est probablement plein de bugs"
2
@Christopher: Alors ce serait une bonne raison de réimplémenter (ou de trouver une bibliothèque différente avec une licence acceptable). Mais trop souvent, la raison de la réimplémentation n’est que celle des NIH…
Donal Fellows
@Carson: +1 :-)
Macke
48

Mes démons récurrents: optimisation prématurée et ingénierie excessive.

Et je ne peux toujours pas les éviter à 100% ...

Tomas Narros
la source
10
+1 pour l'ingénierie excessive. Une fois, j’ai écrit tout un "cadre de configuration" avec des "adaptateurs de paramètres de configuration" pour les fichiers .ini, les fichiers XML, les tables de base de données et les sockets réseau (car tout le monde veut héberger un service Web de configuration, non?)
TMN
8
Sur-ingénierie prématurée?
Christopher Mahan le
@Chris "ingénierie prématurée" s'applique aussi. Cela a également été mentionné dans d' autres réponses . Je sais que c'est l'un de mes banes.
Matthew Scharley
Qu'en est-il de la méga-ingénierie prématurée
suroptimisée
4
C'est à moi. Je mets le blâme sur la direction en me laissant des échéances de règne libre / lointain sans me fixer d’échéances pour des composants spécifiques.
Cthulhu
46

Estimations trop optimistes

Lorsque votre responsable vous regarde fixement et que vous avez le sentiment brûlant de donner une estimation inférieure à ce que votre instinct vous dit, ne le faites pas!

Après tout, votre intestin est probablement déjà trop bas!

Nicole
la source
13
Quand ils vous demandent si cela prendra vraiment beaucoup de temps, dites simplement oui, puis assoyez-vous en silence jusqu'à ce qu'ils ressentent la maladresse ...
PeterAllenWebb
4
Mon professeur d'université m'a dit un jour: "Calculez votre meilleure estimation, puis doublez-la." Cela a fonctionné pour moi jusqu'à présent.
zzzzBov
2
Sinon, essayez l' approche SMBC .
Détly
4
Un de mes anciens patrons a triplé les estimations des développeurs, puis négocié pour doubler avec les clients. Les clients pensaient avoir un accord, les développeurs avaient le temps dont ils avaient besoin même s'ils ne le savaient pas. Gagnant-gagnant!
DaveE
2
La planification basée sur des preuves peut aider à résoudre ce problème: joelonsoftware.com/items/2007/10/26.html
Rei Miyasaka le
33

Utiliser une technologie / un outil / un langage dans votre projet uniquement parce que vous venez de l’apprendre.

Pour essayer de prouver à quel point vous êtes un développeur.

Considérer le code que vous avez écrit pour être le vôtre.

biziclop
la source
Si seulement je pouvais y revenir chaque fois que je le faisais. Heureusement, la moitié des solutions se sont révélées plutôt bonnes. La moitié n'a pas.
Dan
Ou un que vous n'avez pas encore appris. N'oubliez pas d'attacher vos éperons, car le trajet sera long.
Evan Plaice
32

Je vais juste faire une pause et regarder stackoverflow.com;)

Richard Miskin
la source
2
J'aime toujours quand stackoverflow est la réponse à l'une de ces questions
Bill Leeper
31

La pire tentation:

Oh, bien .. Je suppose qu'un sale petit tour / hack / fix ne va pas faire mal.

Devinez quoi, ça fait mal. :)

aller à

Goran Jovic
la source
11
"Corrections de la passerelle"
Mark C
4
L'utilisation d'une gotodéclaration entraînera une attaque de rapace.
Maxpm
1
@Maxpm: Bien pensé! Inclus.
Goran Jovic
1
@ Mark C, qu'est-ce qu'un correctif de passerelle? Mon gøøgle-fu n'est pas assez bon.
1
@ Thorbjørn Ravn Andersen: fr.wikipedia.org/wiki/Gateway_drug_theory
Jimmy
23

Caractéristique Creep

Faites un plan, respectez-le et déployez-vous. Et puis revenez en arrière et ajoutez ce que les gens demandent.

J'ai vu cela maintes et maintes fois. Vous vous asseyez, travaillez sur la conception et commencez à coder. Les utilisateurs entendent des sottises confuses au sujet de leur fonctionnalité «manquante» préférée et ils commencent à faire pression pour elle. Votre patron vous demande de l'ajouter à la 11e heure, il bloque le déploiement, introduit des bugs partout, et 3 mois plus tard, une fois que tout le monde est installé, on vous demande de le supprimer, car personne ne peut comprendre pourquoi vous avez mis cette fonctionnalité rétro merdique en premier lieu! Ne pouvez-vous pas dire que le reste de la conception l'a rendu inutile?

Satanicpuppy
la source
Laissant les spécifications dégelées et ouvertes comme une concession parce que le premier Premier ministre (qui venait d'être licencié) ne connaissait rien au développement de logiciels et avait conçu un calendrier de publication complètement irréaliste. Pire idée jamais.
Evan Plaice
20

  1. Ajouter plus de fonctionnalités

  2. La compétition a cette fonctionnalité. Il s’agit donc d’une fonctionnalité indispensable, donc plus de programmation que d’analyser la stratégie, le positionnement, etc.

  3. La compétition n'a pas cette fonctionnalité. Il s’agit donc d’une caractéristique différenciante, donc plus de programmation que d’analyser la stratégie, le positionnement, etc.

  4. Résoudre un problème d’entreprise avec plus de programmation. par exemple, il est impossible d’acquérir une meilleure expertise en matière d’administration du serveur Linux sur lequel votre site Web est hébergé via la programmation de davantage de fonctionnalités. Parfois, vous devez simplement apprendre à résoudre le problème plutôt que de tout coder à nouveau en C # .Net

  5. Résoudre un problème de marketing avec plus de programmation. par exemple, abuser du concept de la vache pourpre de Seth Godin selon lequel vous résolvez indirectement un problème de marketing en programmant plus de fonctionnalités dans votre produit pour en faire une "vache pourpre". Parfois, c'est juste un monstre mutant.

  6. Résoudre un problème de productivité avec plus de programmation en vous disant que le temps passé à écrire ce script sera économisé dans les heures à venir au lieu de programmer réellement des choses vraiment importantes

  7. Planification du codage mais pas encore du codage parce que vous voulez "bien faire les choses"

  8. Coder une version sale et promettre que vous "améliorerez la situation plus tard", mais ne reviendrez jamais à "améliorer"

  9. Ne pas faire de maquette ou de sitemap parce que c'est "très gênant". Je peux simplement capturer les pages des concurrents pour les maquettes et dessiner à la volée le plan du site "plus tard", ce qui n'est jamais. Et puis, allez directement à la programmation de la première page que je visualise dans mon esprit.

Confession: J'ai personnellement commis des erreurs 1, 3, 7, 8. J'ai également fait 2, 4, 5, 6, mais je me suis souvent trompé que je ne l'avais pas fait.

Je suis en train de remédier à 9.

EDIT N'a pas réalisé que la question nous oblige à mettre des solutions.

1) Ajoutez plus de fonctionnalités , mais ne le faites pas. Travaillez avec votre entreprise, votre marketing, vos fondateurs, vos conseillers, etc., et effacez votre candidature en une seule chose.

Allez lire à propos de Twitter, Groupon , etc. sur la façon dont ils éliminent les choses en une seule chose qui a conduit à leur succès.

Si vous pensez que cela ne fonctionne que si vous souhaitez créer de grandes entreprises, détrompez-vous. Ctrl + F pour cette ligne "Plus j'ajoute de fonctionnalités au logiciel, plus le produit se vend mal. (Inutile de dire que cela n'est pas du tout intuitif pour la plupart des développeurs de logiciels.)" Dans ce lien

2) La compétition a cette fonctionnalité. Donc, c'est une fonctionnalité indispensable

Voir la solution 1

3) La compétition n'a pas cette fonctionnalité. Donc, ceci est une caractéristique de différenciation

Voir la solution 1

4) Résoudre un problème d’entreprise avec plus de programmation.

Si vous avez besoin d'embaucher quelqu'un pour vous enseigner, donner des consultations ou le faire pour vous, puis documentez comment il l'a fait pour que vous puissiez le faire vous-même la prochaine fois. SIMPLEMENT FAIS-LE!! Ne réécrivez pas le code, ne passez pas GO, ne collectez pas 200 $.

5) Résoudre un problème de marketing avec plus de programmation.

Si les gens ne comprennent pas ce que vous vendez, C’EST un problème de marketing. Retournez à la solution 1 et faites pivoter.

6) Résoudre un problème de productivité avec plus de programmation

Attendez.

Attendez jusqu'à ce que vous sentiez que votre productivité souffre d'un problème de productivité particulier pour une période supérieure à 2 semaines et que cela se produira raisonnablement pendant 2 semaines supplémentaires.

Maintenant, évaluez le temps passé à programmer un script pour résoudre ce problème. N'oubliez pas de prendre votre pire estimation et de la multiplier par 2.

Multipliez votre estimation par votre taux horaire.

Maintenant, examinez les solutions alternatives: externalisez, achetez une solution sur étagère, ne faites rien à ce sujet, etc.

Choisissez la solution la plus rentable.

S'y tenir.

7) Planification du codage mais pas encore du codage parce que vous voulez "bien faire les choses"

Allez faire de l'exercice. Vous allez ressentir une poussée d'endorphines qui motiveront votre cul et vous inciteront à agir. Je le sais parce que je viens de faire des benchpress 5x5 et des squats 5x5.

8) Coder une version sale et promettre que vous «améliorerez la situation plus tard» sans jamais revenir à «améliorer»

Configurez un système de fichiers tickler dans GTD. et suivi agressif. Suivez toutes les promesses faites à vous-même et aux autres.

9) Ne pas faire de maquette ou de plan du site parce que c'est "très gênant".

Allez dépenser 75 USD sur une édition de bureau de maquettes balsamiq. Je le sais parce que je l'ai acheté il y a 3 semaines. Cela m'a fait refaire mes maquettes parce que je me sens artiste, architecte et visionnaire, même si mon dessin dans le monde réel est nul. La police utilisée dans balsamiq vous rappelle inconsciemment qu'il ne s'agit que d'une maquette, non figée, ce qui vous aide dans RAD.

Fin EDIT

kimsia
la source
J'ai perdu cette réponse, mais j'ai trouvé cela un peu difficile à lire. Je ne comprends pas vraiment le contexte des 9 premiers points. Souhaitez-vous clarifier? Mais bon travail.
@ MattFenwick Bonjour, merci pour votre +1. Les points 1 à 5 sont généralement appliqués dans le scénario de création d'un produit à vendre, mais vous pouvez également l'appliquer à des scénarios dans lesquels votre tendance à trouver la meilleure réponse vous incite à effectuer des recherches approfondies sur l'état de la technique. Par exemple, en recherche.
Kim Stacks
Les points 6 à 9 concernent davantage les tendances névrotiques d’un programmeur. J'ai lu quelque part (je ne le trouve pas) qu'un concepteur aborderait toujours tout problème avec une solution de conception; un agent de commercialisation avec une solution de marketing; et un programmeur avec une solution de code. Oui, le redouté "Quand on a un marteau en or, on ne voit que le syndrome des ongles". Cela est particulièrement évident au point 6). Résolution d'un problème de productivité avec davantage de programmation
Kim Stacks
@ MattFenwick désolé si vous avez confondu avec mon nom. J'ai changé de pseudo après avoir écrit cette réponse. Je vois que votre parcours est davantage dans la recherche. Ma réponse découle en grande partie de mon expérience de développement de solutions de vente. Mais je suis sûr qu'il y a certaines similitudes entre mon travail et le vôtre puisque nous faisons tous les deux de la programmation.
Kim Stacks
17

Un couple de bières m'aidera à travailler mieux et plus longtemps.

Adam Crossland
la source
11
Attends ... tu veux dire que non? ( xkcd.com/323 )
Craige le
4
@Craige: après 21 ans d'expérience dans le domaine de l'alcool et 20 ans en tant qu'ingénieur logiciel professionnel, je travaille toujours sur la partie calibration.
Adam Crossland
4
@adam, cela vous a pris une année de beuverie pour devenir ingénieur?
17
Le codage en buvant de la bière vous aide à créer des réseaux sociaux extrêmement populaires qui valent des milliards de dollars dans quelques années. C'est vrai, j'ai vu ça dans un film.
janosrusiczki
1
@Kitsched: Oui! Surtout si vous avez le design préexistant de quelqu'un d'autre à arnaquer.
Mason Wheeler
16

"Oui, je peux refactoriser ce gigantesque désordre de 2000 lignes de spaghettis en un jour ..."

Hila
la source
13
Alternativement: "le nouveau type [qui ne sait absolument rien du logiciel ou de la structure de son code] ne fait rien, il peut le réparer". Des points bonus lorsque le gars n'a même jamais utilisé la langue dans laquelle le code est écrit.
Langage sauvage
16

"Je peux me débrouiller sans test pour cela. C'est trop difficile à tester."

et c'est mal frère,

"Je dois avoir un test pour ça, peu importe la difficulté du test à écrire ou à comprendre."

Wayne Conrad
la source
2
Si un test est difficile à écrire, il se peut que vous ne le programmiez pas correctement :)
Merlyn Morgan-Graham
2
@ Marylyn Morgan-Graham, tout à fait vrai. Cependant, certains domaines, tels que la concurrence, sont tout simplement plus difficiles à tester.
Wayne Conrad
1
@ Merlyn: Si vous vous trouvez en train d'écrire un simulateur d'instructions pour pouvoir forcer un changement de contexte aux bons endroits, alors vous êtes probablement allé trop loin dans vos tests de concurrence. :)
Zan Lynx
1
@ Zan: Je suis d'accord - au moment requis, je repousserais les développeurs et tenterais de leur demander de refactoriser leur code et de me laisser insérer des simulacres. Bien que je travaille contre les langages de haut niveau où nous examinons Big-O, optimisons les goulots d’étranglement, devons penser à la simultanéité principalement pour l’intégrité des données plutôt que pour la vitesse brute, et expédier (et souvent aucune d’entre elles car elles sont assez rapides boîte).
Merlyn Morgan Graham
15

La procrastination et l' estimation optimiste des tâches sont mes plus gros péchés.

Étirements, tractions ou tractions (ou tout autre exercice physique) pour le premier et humeur pessimiste avant de donner une estimation pour le second.

Nikita Barsukov
la source
Clarification ... Par "estimation optimiste des tâches", vous voulez dire "syndrome facile de la merde", n'est-ce pas? :)
Evan Plaice
@ Evan Plaice - exactement. Comme "oh, c'est tellement trivial" et googler chaque lettre de votre code après avoir commencé à coder.
Nikita Barsukov
13

"Il est beaucoup plus facile de réimplémenter la fonctionnalité à partir de zéro que de comprendre le code existant."

k3b
la source
2
Oui, c2.com/cgi/wiki?RewriteCodeFromScratch affirme qu'il s'agit d'une des "choses à ne jamais faire".
David Cary
Travailler sur l'open source contribue à cette tendance. J'ai personnellement regardé les correctifs avant de croiser les yeux, puis je suis allé de l'avant et j'ai écrit ma propre implémentation pour me rendre compte qu'il était presque identique au correctif (même après l'amélioration / la refactorisation de mon code). C'est drôle comment ça marche.
Evan Plaice
10

Le projet sur lequel je me trouve a subi une tentation extrêmement préjudiciable: l’effet «Inner Platform». C’est une approche que les architectes, qui sont maintenant disparus depuis longtemps, ont adoptée avec une sagesse infinie, ce qui a permis de créer un projet générant environ 20 millions de dollars par an, mais dont la mise à jour et le maintien coûtent 60 millions de dollars (chiffres approximatifs, mais c du problème).

AlexC
la source
10

NIH - pas inventé ici

J'ai beaucoup de mal à donner une chance à des solutions tierces. Tout le monde devrait être naturellement sceptique face aux solutions tierces qui ne sont pas conçues sur mesure pour eux, mais j'ai du mal à être objectif à 100% à ce sujet.

Les gains de temps peuvent être si importants que même si la solution de la tierce partie devait être évitée 9 fois, je dois rester suffisamment objectif pour réaliser celle qui fonctionnera.

Nicole
la source
1
Je vois ce que vous voulez dire et je dois vivre avec tout le temps. Je suis carrément dans l’opinion opposée parfois au point de mériter une réponse à côté de la vôtre. Cependant, j'ai du mal à croire que je peux faire mieux en une semaine qu'un groupe d'experts sur le sujet qui sont au courant depuis des années. Bien sûr, vous devez vous assurer que les personnes derrière cette tierce partie sont bien des experts. Une bonne recherche sur l’environnement du composant a beaucoup aidé à choisir correctement l’adoption ou le codage.
Newtopian
1
@Newtopian, la "bonne" manière est certainement quelque part au milieu. Mon problème avec les bibliothèques tierces ne consiste pas à savoir si je peux faire mieux qu’une équipe d’experts disposant de plusieurs mois ou même de plusieurs semaines, mais que j’ai rarement , peut-être jamais, trouvé une bibliothèque qui corresponde exactement à ce dont nous avons besoin. Il y a toujours des adaptations à faire et, souvent, je trouve souvent que les autres passaient autant de temps à lutter contre cela que de rédiger une solution qui correspond exactement à ce dont nous avons besoin.
Nicole
Moi-même venant de l’autre extrémité du spectre, j'étais simplement curieux de savoir comment vous aviez réussi à essayer d’atteindre ce «juste milieu», voire pas du tout. J'étais également curieux de savoir ce qui vous empêche de faire appel à des tiers pour essayer de comprendre ce qui me motive à les utiliser, car je suis convaincu que les deux sont également néfastes pour la productivité.
Newtopian
@Newtopian Mon explication ci-dessus a-t-elle un sens quant à pourquoi? Ma tentative pour atteindre le milieu est simple: être plus objectif lors de l’évaluation et de la recherche de solutions tierces.
Nicole
9

Conception, codage et / ou tests unitaires par rapport aux "exemples de données" fournis au lieu d'analyser une copie de la base de données réelle du client. La date limite était courte et ils n'arrêtaient pas de dire que ça allait arriver, mais ça ne l'a jamais fait. Lors de son déploiement, l'explosion était spectaculaire. Vraiment, qui aurait pu s'attendre à ce qu'un client ait 3 clients parents.

Je ne recommencerai jamais un projet tant que je n'aurai pas une copie des données réelles .

Dwidel
la source
S'il n'y a pas encore de produit, y aura-t-il des données à copier?
Svish
S'il n'y a pas de données, il y a toujours du papier. Les registres de la société pourraient aider ici aussi.
burnt_hand
9

Le Il doit y avoir une bibliothèque qui fait que quelque part le syndrome.

étroitement liée à

Le plugin fétiche

Newtopien
la source
2
Il semble toujours que je sois capable de trouver la bibliothèque qui «le fait». Mon problème est souvent de les amener à travailler comme annoncé. :(
Ben L
Facile à trouver une bibliothèque - Difficile de trouver une bibliothèque qui a de bons tests unitaires intégrés
burnt_hand
8

Le perfectionnisme tue; probablement la plus grande raison pour laquelle les projets ne réussissent pas.

Naftuli Kay
la source
Je suppose qu'il est possible que cela soit vrai, mais pour cette raison, je n'ai jamais participé à un projet qui a échoué ou qui a même pris du retard.
PeterAllenWebb
Cela dépend de la manière dont vous définissez la perfection et du niveau souhaité.
Svish
7

Parfois, la programmation me conduit à la bouteille.

Mipadi
la source
7

Réécrire au lieu de refactoriser.

Dave O.
la source
Se mettre d'accord. Si vous êtes prêt à vous engager dans la quantité d'effort requis pour une réécriture, il est presque toujours préférable de refactoriser. Cela prendra encore plus de temps que prévu, mais vous effectuez le refactoring progressivement, n'est-ce pas? Vous pouvez vous arrêter avant que ce soit "parfait".
PeterAllenWebb
1
comme corollaire .... écrire à nouveau ailleurs au lieu de refactoriser. Notre base de code a tellement d'implémentations différentes des mêmes choses qu'il est impossible d'obtenir une cohérence quelconque.
Newtopian
6

Penser qu'il doit y avoir une meilleure façon de faire cela. Je ne vais pas me contenter de quelque chose qui pourrait être "assez bon". Je prends rien de moins que la perfection! Cela est généralement évité en parlant à d'autres personnes qui peuvent avoir une perspective différente d'un problème ou en cherchant une solution sous un angle différent.

JB King
la source
5

Automatiser le tout au point, on passe plus de temps à entretenir les outils qu'au travail réel.

Solution: comme pour l'optimisation du code, commencez par identifier les goulots d'étranglement de la productivité, puis remédiez-les avec une bonne automatisation .

Dan
la source
Je suis d'accord avec cela en principe, mais je n'ai jamais vu d'automatisation excessive dans la pratique. Pourtant, cela pourrait juste être mon expérience.
PeterAllenWebb
4

Quels sont vos démons de programmation?

En dehors de ce que d'autres ont mentionné.

Priorisation : Ignorer le travail hautement prioritaire en ce qui concerne le projet et travailler d’abord sur d’autres éléments du projet car ils sont plus intéressants!

Comment les évites-tu?

Avec un peu plus d'autodiscipline. Sérieusement, la discipline personnelle et la motivation personnelle à faire ce qui est juste aident à éviter la plupart de ces "démons".

Mahesh Velaga
la source
3

Nous n'avons pas encore obtenu l'approbation du client, mais la date limite approche, voici donc quelques recommandations préliminaires afin que vous puissiez commencer ...

Plus tard, quand vous aurez fini de construire le projet pour qu'il corresponde à la composition ...

Oh, voici les révisions du client, ils veulent juste changer quelques petites choses *

(* la fonctionnalité principale est entièrement différente)

Ensuite, vous continuez à refactoriser votre code d'origine, en vous basant sur le modèle original défectueux, au lieu de tout recommencer à zéro, car vous êtes sous la pression d'un délai serré et supposez qu'il s'agissait des dernières révisions.

Je me fais mordre par celui-ci tout le temps. Il est difficile d'éviter en tant que développeur web. Le meilleur conseil que je puisse vous donner est de demander plus de temps pour pouvoir apporter les modifications correctement.

travis
la source
2
Adoptez une stratégie dans laquelle vous ne commencez pas le développement tant que vous n'avez pas la signature du client.
Ben L
1
@ Ben: Si seulement c'était sous notre contrôle!
Sevenseacat