Que devraient savoir tous les programmeurs sur la programmation?

52

S'il vous plaît, restez sur les questions techniques , les comportements à éviter, les questions culturelles, politiques ou de carrière.

experience self-improvement programming-practices bigown
la source
7
Voyez également ceci stackoverflow.com/questions/132798/…
pramodc84
Ce genre de question m'énerve vraiment. Cela ne peut venir que de l'esprit de quelqu'un qui voit le monde en noir et blanc. Tous les programmeurs n’ont pas le même travail et s’il s’agit du plus petit dénominateur commun que vous recherchez, les réponses ci-dessous montrent que vous vous retrouvez avec une liste de bêtes noires.
Capitaine Sensible

Réponses:

92

  1. Le bogue est dans votre code, pas le compilateur ou les bibliothèques d'exécution.

  2. Si vous voyez un bogue qui ne peut pas arriver, vérifiez que vous avez correctement construit et déployé votre programme. (Surtout si vous utilisez un environnement de développement IDE ou de compilation complexe qui essaie de vous cacher les détails compliqués ... ou si votre compilation implique de nombreuses étapes manuelles.)

  3. Les programmes simultanés / multi-tâches sont difficiles à écrire et à tester correctement. Il est préférable de déléguer autant que possible les librairies et les frameworks d'accès concurrentiel.

  4. La rédaction de la documentation fait partie de votre travail de programmeur. Ne le laissez pas à "quelqu'un d'autre".

MODIFIER

Oui, mon point n ° 1 est surestimé. Même les plates-formes d'applications les mieux conçues ont leur lot de bogues, et certaines des moins bien conçues en sont très répandues. Mais même, vous devriez toujours soupçonner votre code d' abord , et commencer à blâmer seulement compilateur / bugs bibliothèque lorsque vous avez clairement la preuve que votre code est pas en faute.

À l'époque où je développais le C / C ++, je me souviens de cas où de supposés "bogues" d'optimiseur se sont avérés être dus à mon expérience (ou à celle d'un autre programmeur) qui avait déjà fait des choses dont les résultats sont indéfinis. Cela s'applique même aux langages supposés sûrs comme Java; par exemple, examinez de près le modèle de mémoire Java (chapitre 17 de JLS).

Stephen C
la source
17
Je préfère dire "Le bogue est probablement dans votre code", car j'ai rencontré plusieurs fois des bogues dans les bibliothèques d'exécution. Je n'ai pas encore rencontré de bogue de compilation. +1 quand même.
Chinmay Kanchi
29
Si vous n'avez jamais trouvé de véritable bogue dans le compilateur, vous n'êtes pas assez aventureux avec votre codage. ;)
Mason Wheeler le
8
@Chinmay, @ spudd86, @Mason - oui ... et j'ai également trouvé ma part de bugs liés au compilateur et à la bibliothèque au cours de mes 30 ans de programmation. Mais selon mon expérience, plus de 99% des bogues s'avèrent être (du moins en partie) la faute de mon code. Ma réponse exagère volontairement ceci pour faire comprendre que vous devriez toujours suspecter votre code en premier.
Stephen C
5
Je ne comprends pas la peur irrationnelle que les gens ressentent avec la programmation multithread. Je suppose que les personnes qui perpétuent ce point de vue ne programment pas beaucoup de code multithread. C'est juste pas si difficile. +1 pour tout le reste cependant.
Steven Evers le
4
Si vous travaillez sur le compilateur, le bogue est probablement à la fois dans votre code et dans le compilateur;)
Legooolas
84
  • Comment lire le code des autres
  • Le code n'existe pas s'il n'est pas vérifié dans Version Control System.
pramodc84
la source
8
+10000 si je pouvais pour le commentaire de contrôle de version. L’historique et la journalisation des modifications sont absolument indispensables et sont la raison pour laquelle vous devez tout mettre dans le contrôle de version dès le début.
Legooolas
2
... et le référentiel a été synchronisé sur au moins un autre emplacement. Important avec DVCS, mais aussi avec VCS centralisé.
D'ailleurs, le code n'existe pas, sauf s'il existe un élément de travail qui autorise le développeur à l'écrire.
Jesse C. Slicer
2
Je vais plus un pour apprendre à lire le code des autres. C'est plus difficile que la plupart d'entre nous réalisons, mais c'est un élément essentiel d'une programmation réussie.
Bogeymin
plus un pour apprendre à lire le code des autres.
itsaboutcode
76

Les calculs en virgule flottante ne sont pas précis.

Chinmay Kanchi
la source
22
+1: Ce que tout informaticien devrait savoir sur l'arithmétique en
virgule
Si quelqu'un ne sait pas de quoi je parle, lisez le lien de @ Adam. C'est un excellent résumé des pièges du calcul en virgule flottante.
Chinmay Kanchi
1
Et s'ils ne le savent pas, ils peuvent faire partie du groupe de personnes qui posent quotidiennement des questions sur stackoverflow.
Brian R. Bondy
1
@ Brian: Si vrai. J'aimerais qu'il y ait un moyen d'identifier les questions expliquées par l'arithmétique en virgule flottante. Vous pouvez créer une application Stack qui affiche chaque jour une question différente en virgule flottante!
Adam Paynter le
63

N'arrête pas d'apprendre.

systempuntoout
la source
1
Connexes: Ne cessez pas de croire.
Fishtoaster
3
Connexes: Ne cessez pas de penser à demain.
octobre
7
Connexes: n'arrêtez pas la musique.
Adam
1
Connexes: n'arrêtez pas de bouger! C'est ta vie, continue à avancer, bien faire les choses, il faut bien faire les choses!
octobre
44

Réduire la duplication est la première chose que vous puissiez faire pour améliorer la qualité et la maintenabilité de votre code.

Chris Holmes
la source
4
SEC, oui! Comment puis-je oublier? ;-)
Maniero
C’est tellement important que j’y ai répondu à nouveau .
Je dirais plutôt: RÉDUIRE LES CONDITIONNELS. Chaque while / if / for est un bug potentiel.
Zvrba
1
Vous savez, ce qui est drôle avec DRY, c’est que ça se répète partout. :) +1
Billy ONeal le
39

Compétences de dépannage et de débogage

Ils ne consacrent guère de temps à ce sujet dans les cours de programmation que j'ai suivis et, d'après mon expérience, c'est l'un des facteurs les plus déterminants de la productivité d'un programmeur. Qu'on le veuille ou non, vous passez beaucoup plus de temps dans la phase de maintenance de votre application que dans la nouvelle phase de développement.

J'ai travaillé avec tellement de programmeurs qui déboguent en changeant des choses de manière aléatoire, sans stratégie pour trouver le problème. J'ai eu cette conversation des dizaines de fois.

Autre programmeur: Je pense que nous devrions essayer de voir si cela résout le problème.
Moi: D'accord, en supposant que ça règle le problème. Qu'est-ce que cela vous dit sur la source du problème?
Autre programmeur: Je ne sais pas, mais nous devons essayer quelque chose .

JohnFx
la source
2
J'étais sur le point de poster ceci. Une grande partie du travail du programmeur consiste à corriger les bogues et beaucoup de gens ont tendance à être incapables de le faire (en particulier dans le code des autres).
Dov
+1, je suis passé de javascript / php à C # et suis tombé en amour avec le code. Je souhaite que les langages à typage dynamique fassent un bien meilleur travail dans ce domaine.
Evan Plaice
Un autre comportement étrange est que le programmeur insiste sur le fait que chaque partie de son programme est correcte tandis que le résultat est défectueux. "-Vous n'avez pas besoin d'imprimer le tableau sur la console pour vérifier s'il est trié car la ligne ci-dessus est array.sort ()." "-Eh bien ... tu sais, ça ne marche pas. Il doit y avoir quelque chose qui ne va pas quelque part. Tu ne peux pas simplement défendre ton code à ce stade!"
Gawi
2
Je pense qu'il est important de déboguer pour valider vos hypothèses sur l'ensemble de votre programme. Parfois, vous devez aller à la pêche pour trouver des indices. Cela doit être fait systématiquement. C’est parfaitement valable d’essayer quelque chose qui pourrait vous dire quelque chose de nouveau. Je le fais souvent.
Gawi
37
  1. Ne soyez pas intelligent être clair.
  2. Utiliser avant de réutiliser.
  3. Les noms comptent.
  4. Une fonction fait 1 chose et le fait bien.
  5. Petit vaut mieux que grand.
KevBurnsJr
la source
2
Pouvez-vous préciser "Utiliser avant de réutiliser". Je n'ai jamais entendu parler de cela auparavant.
Tjaart
34

Les bases. Actuellement, les programmeurs apprennent des technologies et non des concepts. C'est faux.

vitesse
la source
Oui et non. Vous ressemblez à tous les profs que j'ai jamais eu à l'université ... qui n'ont jamais fait de logiciel dans leur vie. Le savoir sans compétences est inutile dans notre métier.
Steven Evers le
4
+1, si vrai. Oui, c'est quelque chose que les types de tours d'ivoire aiment dire, mais cela ne le rend pas moins vrai pour le reste d'entre nous dans les tranchées.
MAK
2
Des bases comme l'orthographe? Its wrongdevrait être it's wrong, par exemple.
Konerak
2
Non, des notions de base, par exemple, ne s’inquiètent pas des fautes de frappe mais des problèmes de programmation.
Clrod
5
Il est facile d'apprendre les étapes à suivre pour faire quelque chose et souvent difficile de savoir quand vous devez l'utiliser et, plus important encore, quand vous pouvez l'utiliser mais ne le devriez pas. Les manuels scolaires sont particulièrement mauvais pour montrer le comment mais pas le pourquoi (et pourquoi pas).
HLGEM le
27

Chaque programmeur doit savoir qu'il met constamment des hypothèses dans le code, par exemple, "ce nombre sera positif et fini", "ce code sera capable de se connecter au serveur à tout moment en un clin d'œil".

Et il devrait savoir qu'il devrait se préparer à la rupture de ces hypothèses.

LennyProgrammers
la source
6
indiquer spécifiquement ceux avec assert()- partout. assert()vous aidera à documenter vos hypothèses et à vous sauver lorsque vous vous trompez.
Dustin
@Dustin +1 Il est impossible que vous vous souveniez de toutes vos hypothèses - documentez-les par programme et vous serez informé du moment exact où elles se révéleront fausses.
Skilldrick
1
... sauf si compilé avec NDEBUG.
19

Tous les programmeurs devraient être au courant des tests.

Tom Duckering
la source
6
Cela ne fonctionne que si vous l'avez testé.
JD Frias
17

Apprendre des concepts . Vous pouvez Google la syntaxe.

pramodc84
la source
Bon en théorie, sauf que Google est terrible pour trouver une syntaxe spécifique : rechercher des termes tels que "référence d'objet" ou "ceci" étant donné un nombre de résultats équivalent, et rechercher des idiomes tels que "$?" ne donne aucun résultat.
l0b0
16

Pensée critique et logique. vous ne pouvez rien faire de bien sans cela.

Mladen Prajdic
la source
14

Tests unitaires. C'est un excellent moyen de codifier vos hypothèses sur la manière dont le code doit être utilisé.

btlog
la source
13

C'est plus difficile que vous ne le pensez.

Bien qu'il soit facile (ish) de mettre en place quelque chose qui fonctionne normalement, gérer des entrées erronées, tous les cas de bords et de coins, les modes de défaillance possibles, etc. prend beaucoup de temps et sera probablement la partie la plus difficile du travail.

Ensuite, vous devez également donner à votre application une belle apparence.

ChrisF
la source
3
Je pense que ceci est la source du vieil adage «90% du travail prend 90% du temps. les 10%
restants occupent
Je pense que beaucoup de gens ont tendance à toujours sous-estimer la complexité. "À quel point X peut-il être dur?" - Derniers mots célèbres: /
Roman Starkov
@GSto Je ne veux pas travailler 180% du temps, 100% me convient parfaitement!
Adam
13

Connaissance du domaine. La spécification n'est jamais à 100%; connaître le domaine avec lequel vous développez augmentera TOUJOURS la qualité du produit.

Steven Evers
la source
11

Des pointeurs, évidemment. :)

Laurynas Biveinis
la source
3
Les pointeurs ne sont vraiment nécessaires que dans un sous-ensemble de langues pour un petit sous-ensemble de tâches. Pour la plupart des tâches, vous pouvez (et devriez pouvoir) programmer comme si le concept de pointeur n'existait pas.
Chinmay Kanchi
14
@Chinay Kanchi Non. Les pointeurs doivent être compris de tous.
alternative le
5
Cela dépend vraiment de ce que vous entendez par pointeur. Si vous parlez de pointeurs de style C que vous pouvez manipuler (ce que j'ai supposé), je dirais qu'un programmeur Java / C # / Python n'a pas besoin de savoir quoi que ce soit à leur sujet. Si vous parlez de pointeur comme dans les "références" de Java, c’est-à-dire un pointeur qui ne peut pas être manipulé, alors, oui, une certaine connaissance de ces références est nécessaire, ne serait-ce que pour vous éviter de glisser.
Chinmay Kanchi
@mathepic Vous serez bouleversé si vous appreniez combien d'étudiants en CS diplômés chaque année ne comprennent pas la première chose à propos des pointeurs. Si je n'avais pas fait tout mon possible pour effectuer des stages chaque été, on ne m'aurait même pas enseigné les indicateurs de C ou les références à Java ...
Mike B
5
@Chinmay: Un programmeur Python / Java / C # qui ne comprend pas le concept de pointeurs est perdu. L = [[]] * 2; L[0].append(42) Différentes langues utilisent des noms différents, mais l' indirection est essentielle partout.
11

Code Complete 2 - de bout en bout

Kyle Ballard
la source
vous devriez vraiment le savoir avant d'accepter de l'argent pour programmer. Si vous trouvez quelque chose que vous ne saviez pas dedans, envisagez un changement de carrière ou une période intense d’études autogérées pour vous aider à tout comprendre. Et ensuite, excusez-vous auprès de vos collègues. Et cela ne couvre que les bases de la programmation.
Tim Williscroft
11

Les données sont plus importantes que le code.

Si vos données sont intelligentes, le code peut être stupide.

Le code muet est facile à comprendre. Il en va de même pour les données intelligentes.

Presque chaque chagrin algorithmique que j'ai jamais eu est dû au fait que des données se trouvent au mauvais endroit ou ont été maltraitées. Si vos données ont un sens, inscrivez-le dans le système de types .

Gonzales
la source
2
Vous m'avez eu jusqu'à ce que vous disiez "système de type".
10

Quelle langue et quel environnement sont les plus appropriés pour le travail? Et ce n'est pas toujours ton préféré.

Dan Diplo
la source
10

Diviser et conquérir. C'est généralement le meilleur moyen de résoudre tout type de problème pratique, de la planification au débogage.

Rick Minerich
la source
8

Les compétences réelles se reflètent dans la capacité à exécuter correctement une conception simple, et non dans la capacité de réaliser une conception compliquée du tout.

Cette compétence provient d'une plus grande maîtrise des principes fondamentaux, et non de la maîtrise des arcanes. Un programmeur de haut calibre n'est pas défini par sa capacité à coder ce que d'autres ne peuvent pas (utiliser des fonctions de niveau supérieur, la programmation fonctionnelle avancée, que vous avez), mais plutôt par sa capacité à affiner le codage parfaitement banal. Choisir la décomposition appropriée des fonctionnalités entre les classes; construire en robustesse; utiliser des techniques de programmation défensives; et en utilisant des modèles et des noms qui conduisent à une plus grande auto-documentation, ce sont les ingrédients essentiels d'une programmation de haut calibre.

Écrire un bon code auquel vous, ou quelqu'un d'autre, pouvez revenir dans une semaine, un mois ou un an et comprendre comment utiliser, modifier, améliorer ou étendre ce code est crucial. Cela vous épargne du temps et des efforts mentaux. Il améliore la productivité en supprimant les obstacles sur lesquels vous auriez déjà trébuché (en interrompant peut-être votre pensée, en prenant des heures ou des jours d'efforts à d'autres travaux, etc.). Il est ainsi plus facile de se concentrer sur les problèmes difficiles. et parfois cela fait disparaître les problèmes difficiles.

En un mot: élégance. Chaque classe, chaque méthode, chaque condition, chaque bloc, chaque nom de variable: lutte pour l'élégance.

Coin
la source
8

Ne blâmez jamais l'utilisateur de ce qui pourrait être résolu avec une expérience utilisateur plus propre ou une meilleure documentation. Souvent, les programmeurs supposent automatiquement que l'utilisateur est un idiot qui ne peut rien faire de bien, lorsque le problème est une mauvaise expérience générale ou un manque de communication. Les programmes sont destinés à être utilisés, et traiter l’utilisateur avec mépris, c’est perdre le sens de la programmation.

utilisateur8
la source
6

Chaque programmeur doit savoir comment utiliser le débogueur, et savoir comment l'utiliser bien .

Brian R. Bondy
la source
5

Comment utiliser Google

bruno077
la source
4

L'évaluation des courts-circuits, bien que ce soit l'une des premières choses qu'ils apprennent sur les opérateurs booléens.

Federico Klez Culloca
la source
4

Comment évaluer avec précision le temps qu’il faudra à une fonctionnalité pour la mettre en oeuvre. Plus important encore, comment faire passer le message, vous ne faites pas de conneries quand vous soumettez cette estimation.

blés
la source
2
ou apprenez à bien vous servir de l'hôte et à bien faire passer le message que vous n'êtes pas un invité ...;)
Billy Coover
4

Le style de codage compte:

  • questions d'indentation cohérente,
  • utilisation cohérente des espaces blancs (par exemple autour des opérateurs),
  • placement cohérent des sujets de {},
  • les identifiants bien choisis sont importants,
  • etc.

... et le bon design est important.

Idéalement, le programmeur apprend ces choses avant (ou pendant) sa première révision de code. Dans le pire des cas, le programmeur les apprend lorsque le chef lui dit de faire rapidement des modifications non triviales à un code horrible.

Stephen C
la source