Quel est le mythe le plus absurde sur les problèmes de programmation?
En d'autres termes ... Quel est le malentendu le plus répandu et le plus frustrant à propos de la programmation, que vous avez rencontré?
Quels mythes/idées fausses répandus et anciens trouvez-vous difficile pour les programmeurs de dissiper/corriger.
Veuillez expliquer pourquoi c'est un mythe.
Parce que vous êtes programmeur, vous savez comment réparer la machine virale de [personne].
Une chose commune des RH qui me rend fou lorsque je suis à la recherche d'un emploi: l'hypothèse implicite que toutes les compétences de codage sont spécifiques au langage, qu'il n'y a aucune expertise en génie logiciel qui transcende les jeux de commandes. Ces dix années d'expérience en Java et cinq autres en Perl signifient que vous seriez complètement inutile sur un projet qui utilise, disons, C #.
"Oui, il y a une courbe d'apprentissage. Mais j'ai fait des transitions plus difficiles que cela. Je vais vous faire un marché, payez-moi 80% pour le premier mois et à la fin de ce temps si je ne suis pas ... oh , attendez, nous n'avons pas réellement cette conversation, car votre singe RH a simplement supprimé mon application. "
Si vous ne tapez pas, vous ne travaillez pas.
Je crois que les regards vides de zombies et les promenades de café sont essentiels pour que les programmeurs organisent des choses dans leur tête.
que vous pouvez accélérer un projet en retard, simplement en y envoyant plus de personnes.
Ce logiciel d'écriture est facile.
Sinon, comment expliquez-vous tous ces projets qui se déroulent dans le temps et sur le budget et les gens (politiciens, médias, etc.) sont toujours surpris, et les clients se plaignent lorsque vous leur dites que leur "petit site Web" (ou autre) prendra en fait 6 mois pour développer et coûter plusieurs milliers de dollars (livres, euros, [insérer la devise de votre choix])
Avec des exigences floues et en constante évolution, je pense parfois qu'il est étonnant qu'un logiciel soit jamais fini!
Je sais que c'est un peu plus compliqué que ça;)
La complexité de l'application est directement proportionnelle à la complexité de l'interface utilisateur. Par ce raisonnement, vous devriez pouvoir créer Google ou Twitter sur un week-end.
Tous les programmeurs sont bons en mathématiques. :-)
Tout adolescent qui pirate des ordinateurs a des compétences équivalentes (ou supérieures) à celles d'un programmeur expérimenté.
Mon neveu de 14 ans est bon en informatique et je lui paie 10 $/heure pour tondre ma pelouse. Pourquoi devrais-je vous payer six chiffres pour écrire le prochain FaceBook?
Cela en temps réel signifie rapide.
Dire "Les paquets doivent être traités en temps réel." est sans valeur et le jumeau maléfique ... répondre "À quelle vitesse X doit-il arriver?" avec "En temps réel" est peut-être moins que nul. ..bordering sur stupide plutôt qu'ignorant.
temps réel signifie que, simplement, cette fonction Y prendra toujours X temps et que tout écart indique une erreur grave. La durée de X ne définit pas "en temps réel", elle pourrait être de six microsecondes ou de six jours. Que vous puissiez déterminer la fonction Y prendra du temps X définit le "temps réel". Les systèmes en temps réel sont déterministes par cette définition.
Alors faites tomber ..
Pourquoi ne l'écrivez-vous pas simplement la première fois, plutôt que de passer autant de temps à taper du code bogué, puis à le lire plus tard en essayant de trouver les bogues?
:-) :-) :-) :-)
Si vous n'êtes pas allé à l'université, vous n'êtes pas apte à l'emploi
Cette optimisation prématurée signifie que vous ne devriez pas optimiser du tout. J'ai vu des bases de données plus horriblement mauvaises parce que personne ne voulait considérer les performances (essentielles à tout système de base de données) dans la conception car c'était une optimisation prématurée que tout autre problème de conception de base de données. Déchets, il existe des tueurs de performances connus, arrêtez de les utiliser comme premier choix.
Autre mythe, il est trop difficile de refactoriser la base de données. Non, mais vous devez réfléchir à la façon de refactoriser dans la phase de conception pour le faire efficacement. Et BTW, plus vous attendez pour résoudre ce problème de performances basé sur la conception ennuyeux, plus il sera difficile à résoudre.
Un autre mauvais mythe, la conception de la base de données devrait refléter les principes OOP. Non, les bases de données sont conçues pour fonctionner avec des ensembles non OOP principes. Certains OOP les choses causeront d'horribles problèmes de performances et d'autres sont tout simplement stupides en termes de base de données.
Enfin, vous devez appliquer l'intégrité des données dans l'application. Les bases de données vont durer au-delà de l'application et perdraient les règles lorsque l'application est remplacée, plusieurs applications vont y accéder et il sera souvent nécessaire d'exécuter des requêtes directes pour corriger les choses qui ne passent pas par l'application. Je n'ai jamais vu une base de données qui refuse d'appliquer l'intégrité des données dans la base de données qui contient de bonnes données.
Qu'il existe une source mythique de meilleures pratiques absolues.
Aucune déviation ne peut jamais être justifiée.
Aucun document prétendant définir quelque chose comme une meilleure pratique ne peut être remis en question.
Le fait que le marketing semble penser que l'ajout d'une tonne de petites fonctionnalités est moins de travail que l'ajout d'une seule fonctionnalité, mais plutôt lourde. Ce qui est probablement un cas plus spécifique de l'idée fausse selon laquelle "le changement de tâche n'a pas de surcharge".
Ce code de commentaire n'est pas nécessaire, ou ce "bon code n'a pas besoin de commentaires". Parfois, vous devez expliquer ce qu'un code complexe fait. De plus, commenter des sections de code vous aide à parcourir plus efficacement la lecture.
Le pire mythe: si vous programmez depuis longtemps, vous pouvez facilement être chef de projet.
Et que vous deveniez chef de projet si vous programmez depuis longtemps.
Si nous utilisons autre chose que Java, C # et C++ dans notre projet, nous ne trouverons aucun programmeur pour le supporter.
Java est juste C++ avec différentes classes.
Le plus dangereux que j'ai vu, car il est accepté si facilement, c'est que pouvoir écrire du code rapidement est bon, et donc plus vous pouvez coder [insérer la fonction ici] dans une langue donnée, meilleure est la langue est.
Il s'agit d'un exemple sérieux d'optimisation prématurée, car beaucoup plus de travail est consacré au code maintien qu'à sa création. Cela signifie qu'il est beaucoup plus important d'écrire du code facile à lire, à comprendre et à déboguer que du code facile à écrire rapidement, et faciliter un code facile à lire est une mesure beaucoup plus utile de la qualité du langage.
qu'en tant que programmeur, vous savez tout sur les dernières tendances matérielles, l'overclocking, le mod de boîtier, etc. les amis et les parents vous consultent lorsqu'ils achètent leurs engrenages.
Les leçons de fabrication peuvent être appliquées au processus de développement logiciel.
Que lorsque les programmeurs disent que c'est très difficile à faire/tout simplement impossible, les RH pensent qu'ils sont paresseux et démotivés
Il doit y avoir un programme open source pour mon entreprise. Ne pouvez-vous pas simplement le télécharger et Tweak à mes besoins.
Plus d'une personne m'a demandé ce que c'est que de programmer uniquement pour réaliser à mi-chemin de la conversation qu'ils pensent que nous programmons directement en binaire ou en utilisant des symboles mathématiques.
Je ne sais pas si je veux dissiper ce mythe, ça me donne l'air vraiment intelligent!
Je pense que la plus grande idée fausse est qu'il est plus important de pouvoir écrire le code facilement que de pouvoir lire et comprendre le code.
La programmation est tout comme le travail à la chaîne d'assemblage. Vous travaillez sur un produit pendant un certain temps (peut-être avec des collègues) et enfin vous l'expédiez. Tout comme la construction d'une maison en briques.
Contra: La programmation contient beaucoup de créativité et de planification. C'est de l'art. Comme le maçon, un programmeur sait également la différence entre façonner une brique et planifier une cathédrale entière.
Le portage d'un programme vers C++ accélérera automatiquement son exécution.
Tout environnement de programmation avec un concepteur visuel quelconque fera en sorte que les utilisateurs professionnels puissent "écrire" le programme et les programmeurs réels ne sont pas nécessaires.
Réutilisation de la POO. C'est le plus grand sophisme commercialisé dans la programmation.
L'apprentissage de la syntaxe est la partie difficile.
2 mythes que je veux révéler. Beaucoup de mes amis ne comprennent pas que Java et JavaScript sont complètement différents, et beaucoup de non-programmeurs que je connais ne comprennent pas qu'il existe plus d'une langue. Un de mes amis commençait à peine à programmer et avait besoin de mon aide ", bien sûr, il ne savait même pas dans quelle langue il travaillait.
Ces deux choses me reviennent beaucoup.
Que l'attribution d'une priorité autre que "1" signifie que la tâche ne sera jamais effectuée.
Un responsable m'a demandé de personnaliser l'outil de suivi des bogues avec les priorités 1a, 1b, 1c, 1d et 1e afin qu'il puisse tout attribuer en tant que variation de priorité 1, mais nous pourrions toujours organiser le travail.
Et oui, j'ai réussi à résoudre tous les problèmes de "priorité 1". Mais avant de pouvoir aborder les problèmes qui étaient encore dans la priorité 2-5, le gestionnaire m'a fait réaffecter les priorités de ces problèmes dans les cinq niveaux de priorité 1.
(Je réalise que ce mythe n'est pas spécifique à la programmation, mais c'est vrai pour plusieurs autres réponses sur ce fil.)
Tant que l'ordinateur comprend le code que vous saisissez, c'est tout ce qui compte. Par conséquent, taper des commentaires et utiliser des noms de variables de plus de deux lettres est une perte de temps. :-(
La forme de saisie est liée à la capacité de programmation. Sérieusement, l'un des professeurs de mon lycée m'a dit: "Vous ne pouvez pas coder rapidement si vous ne pouvez pas taper rapidement." Ma réponse a été: "C'est comme dire que je ne peux écrire le grand roman américain que si je le fais en cursif."
Que le programmeur prototypique:
- arrive au travail après 11h
- ne boit que du Mountain Dew
- aime la cuisine indienne ou les sushis
- vit seul par choix (avec les parents et/ou au sous-sol)
- reste jusqu'à 3h du matin en jouant à des jeux vidéo
Cette notation hongroise signifie seulement que vous préfixez les noms de variable avec un type (comme int iArraylength = 5;) au lieu du type de données qu'elle contient (comme int xcTextfield = getTextfield (). Coord.x;)
"Systèmes notation hongroise"! = "Applications notation hongroise"
Logiciel sans bug. Plus tard, j'ai appris que chaque programme fonctionnerait toujours avec des bogues et que le jeu entier consistait à satisfaire les exigences des clients.
Que tout code écrit dans un langage OOP (C #, C++, Java) par n'importe qui est automatiquement orienté objet et "réutilisable".
Ce n'est pas seulement une fois que l'on m'a demandé de réutiliser un bloc de code de mille lignes ou une classe dans une architecture qui n'avait aucun modèle sauf l'héritage (qui ne compte même pas). Apparemment, le copier-coller compte également comme une bonne réutilisation de code pour quiconque ne connaît pas la différence entre un langage OO et OOP lui-même.
Un TDWTF préféré qui arrive de temps en temps: Code-Refuse
Ces applications Web peuvent être "7x24".
Demandez à n'importe quel homme d'affaires quel temps d'arrêt est autorisé et il insiste toujours sur une disponibilité à 100%. Peu importe que le temps d'arrêt d'une minute par semaine est toujours de 99,99% et est presque irréalisable pour une organisation plus petite qu'un service public majeur.
Tous les programmes écrits en C/C++ s'exécuteront plus rapidement que les programmes équivalents Java/C #.
Qu'il existe un "meilleur" outil/solution/réponse unique à tout problème/question
Le plus grand mythe est que c'est facile.
Des programmeurs devenus managers disant:
"Trois semaines?! J'ai codé dans le passé, comment difficile cela peut-il être?"
Que toute M.Sc. avec un cours de programmation suffit pour être embauché en tant que développeur de logiciels.
Parce que vous êtes programmeur, vous savez réparer le copieur.
Quelles idées fausses sont répandues depuis longtemps
Il existe une croyance très répandue parmi les programmeurs sur la façon de trouver des problèmes de performances. C'est que pour les trouver, vous devez les mesurer.
Le contre-exemple le plus simple est une boucle infinie (indésirable). Cela prend 100% du temps, faire des choses qui sont complètement inutiles.
Comment trouvez-vous le problème? Vous l'obtenez sous un débogueur et l'interrompez, l'arrêtez ou l'interrompez. Ensuite, vous regardez la pile, car vous savez que la boucle se trouve quelque part dessus. Vous l'avez attrapé dans l'acte. L'avez-vous mesuré? ou juste le trouver?
Supposons que ce ne soit pas une boucle infinie, cela prend juste plus de temps que vous ne le pensez. Supposons que le travail inutile soit inférieur à 100%, comme 90%, 50% ou 20%. C'est la même idée. Si vous le mettez en pause, ce pourcentage est la chance que vous l'attrapiez dans l'acte. (Vous n'avez pas besoin de savoir quel est le pourcentage pour l'attraper.)
Pour être sûr, vous pouvez l'interrompre plusieurs fois. Dès que vous le voyez faire quelque chose, sur aussi peu que deux échantillons, que vous pouvez remplacer par quelque chose de plus rapide, vous pouvez le réparer pour une accélération de Nice. Non seulement cela, vous venez de rendre d'autres problèmes plus faciles à trouver, car le temps est plus court et ils prennent un pourcentage plus élevé. Cela peut "Snowball" jusqu'à ce que le code soit très proche de l'optimal.
Bien sûr, si vous voulez mesurer le problème, prenez simplement plus d'échantillons, mais ce n'est pas une condition préalable pour le trouver.
Les gens me disent, je l'espère, que c'est ce que font les profileurs d'échantillonnage mais le font mieux. Beaucoup préfèrent débattre de la question plutôt que de voir par eux-mêmes.
Qu'être un gestionnaire vaut mieux qu'être un codeur. Être manager, c'est ennuyeux. Quiconque s'est lancé dans la gestion pure n'a jamais aimé la programmation.
Les ordinateurs et les logiciels améliorent le processus de travail par lui-même.
Parmi les programmeurs: que Delphi est mort, mourant ou sous assistance respiratoire.
Qu'un manager connaisse le jack-squat sur le code que ses développeurs écrivent.
Il existe un langage appelé C/C++
Ou que les langues sont si proches que les compétences sont interchangeables.
Ce logiciel d'écriture consiste en fait à écrire du code.
Beaucoup de gens ont tendance à penser que JavaScript est similaire à C++ et ne comprennent pas qu'il utilise réellement l'héritage de prototype.
Que les langages de programmation changent tout le temps.
C'était peut-être il y a longtemps dans le passé ...
Mais de nos jours, les changements sont principalement des fonctionnalités supplémentaires qui essaient de ne pas casser le code existant.
Pourquoi les programmeurs insistent-ils pour écrire des bogues? (Venant d'une personne de marketing + testeur qui ne peut jamais faire un rapport de bogue correctement).
- Cela OO signifie qualité.
- Que l'approche OO est la bonne approche.
- Que le travail d'un programmeur est d'écrire du code.
- Cette langue est importante.
L'ensemble mentalité hollywoodienne (faute d'un meilleur nom) que chaque fois qu'un programmeur d'une série de films/séries prend la parole, il doit articuler toutes les technologies dont il a besoin ( I besoin d'un PHP front-end et un back-end MySQL !!! 11 ) ... Et puis un peu plus qui n'a aucun sens à bien sûr.
Si je parlais comme ça, je serais probablement frappé dans les noix.
Utiliser l'anglais (ou votre langue maternelle) pour décrire un problème:
est plus utile que de fournir un exemple compilable du code qui illustre le problème.