Que doit savoir chaque programmeur sur la programmation?
S'il vous plaît, restez sur les problèmes techniques, évitez les problèmes de comportement, culturels, professionnels ou politiques.
Le bogue est dans votre code , pas le compilateur ou les bibliothèques d'exécution.
Si vous voyez un bogue qui ne peut pas se produire, vérifiez que vous avez correctement construit et déployé votre programme. (Surtout si vous utilisez un IDE ou framework de build compliqué qui essaie de vous cacher les détails en désordre ... ou si votre build implique de nombreuses étapes manuelles.)
Les programmes simultanés/multithread sont difficiles à écrire et plus difficiles à tester correctement. Il est préférable de déléguer autant que vous le pouvez aux bibliothèques et frameworks concurrents.
La rédaction de la documentation fait partie de votre travail de programmeur. Ne laissez pas cela à "quelqu'un d'autre".
MODIFIER
Oui, mon point n ° 1 est surévalué. Même les meilleures plates-formes d'applications conçues ont leur part de bogues, et certaines des moins bien conçues en sont omniprésentes. Mais même ainsi, vous devez toujours suspecter votre code en premier , et ne commencer à blâmer les bogues du compilateur/bibliothèque que lorsque vous avez une preuve claire que votre code n'est pas en cause.
À l'époque où je faisais du développement C/C++, je me souviens de cas où de supposés "bugs" de l'optimiseur se sont avérés être dus à moi/à un autre programmeur ayant fait des choses qui, selon les spécifications du langage, ont des résultats indéfinis. Cela s'applique même aux langages supposés sûrs comme Java; par exemple. jetons un coup d'œil long au modèle de mémoire Java Java (JLS chapitre 17).
- Comment lire le code des autres.
- Le code n'existe pas s'il n'est pas vérifié dans le système de contrôle de version.
Les calculs en virgule flottante sont pas précis.
N'arrêtez pas d'apprendre.
Que la première chose que vous puissiez faire pour augmenter la qualité et la maintenabilité de votre code est RÉDUIRE LA DUPLICATION.
Dépannage et débogage
Ils ne passent pratiquement pas de temps sur ce sujet dans aucun des cours de programmation que j'ai suivis, et d'après mon expérience, c'est l'un des plus grands 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 les choses au hasard sans aucune 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 le corrige.
Moi: D'accord, en supposant que cela le répare. 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 .
- Ne soyez pas intelligent; être clair.
- Utiliser avant réutilisation.
- Les noms comptent.
- Une fonction fait 1 chose et le fait bien.
- Petit, c'est mieux que grand.
Les bases. Actuellement, les programmeurs apprennent les technologies et non les concepts. C'est faux.
Chaque programmeur doit savoir qu'il met tout le temps des hypothèses dans le code, par exemple "ce nombre sera positif et fini", "ce code pourra se connecter au serveur à tout moment en un clin d'œil".
Et il doit savoir qu'il doit se préparer à la rupture de ces hypothèses.
Chaque programmeur doit connaître les tests.
Apprenez concepts. Vous pouvez Google la syntaxe.
Pensée critique et logique. vous ne pouvez rien faire de bien sans cela.
Tests unitaires. C'est un excellent moyen de codifier vos hypothèses sur la façon dont le code doit être utilisé.
Notation Big O et ses implications.
Quelques références utiles
Connaissance du domaine. La spécification n'est jamais à 100%; connaître le domaine réel avec lequel vous développez augmentera TOUJOURS la qualité du produit.
C'est plus difficile que vous ne le pensez.
Bien qu'il soit facile (ish) de mettre ensemble quelque chose qui fonctionne lorsqu'il est utilisé normalement, faire face à une entrée erronée, tous les cas Edge et Corner, les modes de défaillance possibles, etc. prennent du temps et seront probablement la partie la plus difficile du travail.
Ensuite, vous devez également rendre l'application belle.
Des pointeurs, évidemment. :)
Les données sont plus importantes que le code.
Si vos données sont intelligentes, le code peut être stupide.
Le code stupide est facile à comprendre. Les données intelligentes aussi.
Presque chaque chagrin algorithmique que j'ai jamais eu est dû à des données mal placées ou abusées de leur véritable signification. Si vos données ont un sens mettez ce sens dans le système de type.
Code Complete 2 - couverture à couverture
Quelle langue et quel environnement conviennent le mieux à l'emploi. Et ce n'est pas toujours votre préféré.
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.
La véritable compétence se reflète dans la capacité à bien exécuter une conception simple, pas dans la capacité à faire fonctionner une conception compliquée du tout.
Cette compétence vient d'une plus grande maîtrise des fondamentaux, pas de la maîtrise des arcanes. Un programmeur de haut calibre n'est pas défini par sa capacité à coder ce que les autres ne peuvent pas (en utilisant des fonctions de niveau supérieur, une programmation fonctionnelle avancée, ce que vous avez) mais plutôt par leur capacité à affiner un codage parfaitement banal. Choisir la décomposition appropriée des fonctionnalités entre les classes; bâtir en robustesse; utiliser des techniques de programmation défensive; et en utilisant des modèles et des noms qui mènent à une plus grande auto-documentation, ce sont le pain et le beurre d'une programmation de haut calibre.
Il est essentiel d'écrire un bon code auquel vous ou quelqu'un d'autre pouvez revenir dans une semaine par mois ou un an et comprendre comment utiliser, modifier, améliorer ou étendre ce code. Cela vous fait gagner du temps et de l'effort mental. Il lubrifie les roues de la productivité en supprimant les obstacles sur lesquels vous auriez trébuché auparavant (peut-être interrompre votre cheminement de pensée, ou peut-être prendre des heures ou des jours d'effort loin d'autres travaux, etc.) Il facilite la concentration sur les problèmes difficiles , et parfois cela fait disparaître les problèmes difficiles.
En un mot: l'élégance. Chaque classe, chaque méthode, chaque condition, chaque bloc, chaque nom de variable: recherchez l'élégance.
Ne blâmez jamais l'utilisateur ce qui pourrait être corrigé 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 globale ou un manque de communication. Les programmes sont destinés à être utilisés, et traiter l'utilisateur avec mépris revient à manquer le point de programmation en premier lieu.
Chaque programmeur doit savoir comment utiliser le débogueur et savoir comment l'utiliser enfin.
Comment utiliser Google
Structures de données
L'évaluation des courts-circuits, bien que ce soit l'une des premières choses qu'ils vous apprennent sur les opérateurs booléens.
Les erreurs des utilisateurs ne le sont pas; ce sont des erreurs d'utilisation:
- Les fonctionnalités dangereuses devraient être annulables, pas seulement mises en garde. Voici en regardant
rm, qui toujours ne fonctionne pas avec la poubelle. - Faites le chose la moins nuisible si l'utilisateur casse (ESC, Ctrl-C). Idéalement, le système devrait être dans le même état qu'avant d'exécuter la commande.
rm, encore une fois. - Les options nuisibles devraient être loin des options inoffensives. Un clic droit sur un fichier dans la corbeille GNOME peut afficher "Supprimer définitivement" directement à côté de "Restaurer" :(
Ne pas choisir spécifiquement sur GNU Tools ou GNOME, mais ce sont les exemples les plus faciles à trouver.
Comment estimer avec précision le temps nécessaire à la mise en œuvre d'une fonctionnalité. Plus important encore, comment transmettre que vous n'êtes pas des conneries lorsque vous soumettez cette estimation.
Le style de codage est important:
- questions d'indentation cohérentes,
- l'utilisation cohérente de l'espace blanc (par exemple autour des opérateurs) est importante,
- placement cohérent des affaires de {},
- des identifiants bien choisis comptent,
- 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 patron lui dit de faire des changements non triviaux à un code horrible à la hâte.
En parlant de développement de logiciels commerciaux ici ... Évidemment, cela pourrait ne pas s'appliquer à un système de sécurité DOD ou à un quant hedge fund.
- Concentrez-vous sur ce qui fonctionne, pas sur ce qui est intelligent, KISS.
- Gardez à l'esprit la règle des 80/20 et ne passez pas tout votre temps à essayer de plaire/vendre la minorité.
- Suivez un cours sur les structures/algorithmes de données.
- Test, test, test.
- N'allez pas fouiner dans le code qui est en production et qui fonctionne actuellement. Sauf si vous avez un flux de trésorerie excessif et pas de nouvelles idées. Alors ça va.
- La grande majorité de votre temps sera consacrée à trier la cruauté et à ne pas résoudre de problèmes de programmation intéressants. À moins que vous n'interviewiez, auquel cas les gens veulent seulement voir comment vous résolvez des problèmes de programmation intéressants.
Qu'il y a -
1) Autres paradigmes de programmation au-delà de seulement OO (orientation objet) 2) Autres meilleurs IDE au-delà de Visual Studio (celui-ci est spécialement destiné aux programmeurs qui ont travaillé uniquement sur Windows et uniquement sur les technologies MS)
Fonctionnement de l'ordinateur vraiment, principes fondamentaux du langage, algorithmes/structures de données, analyse d'algorithmes et quelques mesures de la théorie de la complexité.
Je ne peux pas croire que cela n'ait pas été mentionné
Chaque programmeur vaut le sel doit être capable de produire logiciel prêt pour le monde .
J'entends par là le respect des principes de base de l'internationalisation tels que l'externalisation de toutes les chaînes, etc.
Je ne peux pas croire combien de fois j'ai vu des chaînes anglaises codées en dur ou des dialogues avec des chaînes tronquées, etc. lorsque le produit a été traduit.
Les tests unitaires ne sont pas une solution miracle. Vous pouvez toujours introduire des bogues, écrire de mauvais tests et ce ne devrait pas être la seule forme de tests que vous faites.
Les ordinateurs ne comprennent pas la sémantique. Supposons que vous ayez ceci:
var ferrari = new Ferrari();
ferrari.DriveTo(Places.Seattle);
Pour l'ordinateur, vous pouvez également avoir utilisé des noms de types différents et utilisé:
var mxEEcceqs = new safHBBdueWE();
mxEEcceqs.HYBbQAW(n3dNm.pDojeW);
Nommer les choses est très important, mais ne faites pas l'erreur de supposer que l'ordinateur sait ce que vous "voulez dire" simplement parce que vous avez nommé votre type "Ferrari" ou votre méthode "DriveTo".
Ordre d'exécution.
Vous seriez étonné, lorsque vous parlez à des programmeurs contre des gens qui n'ont jamais vu ou touché du code ou des prétendus programmeurs *, la chose qu'ils n'obtiennent pas est l'ordre d'exécution. Si vous rencontrez quelqu'un qui ne peut pas comprendre les structures de contrôle, ayez d'abord cette idée en tête. Vous constaterez qu'ils apprennent plus vite après cela.
* oui, ces gens qui sont capables de trouver du travail en tant que programmeurs, mais quand vous leur posez la question technique la plus simple, ils vont péter les cerveaux .. Je pense que nous en avons tous rencontré un.
Chaque programmeur devrait connaître la "science" en informatique (modèles de conception, algorithmes, objets, etc ...) si vous pouvez maîtriser cela, vous pouvez programmer en utilisant n'importe quel langage, c'est juste une question de s'habituer à la syntaxe.
Ce que lexing et l'analyse sont, juste un aperçu vague est très bien. Mieux encore, en passant la familiarité avec au moins un framework de générateur d'analyseur.
La plupart des WTF les plus horribles que j'ai vus sont les routines d'analyse personnalisée des gens. Horrible à coder initialement, pire à maintenir.
Évaluation.
Un programmeur doit savoir comment les instructions qu'il écrit sont évaluées. a(line.of(code) is aSequenceOf(evaluations)) et si vous ne comprenez pas à quoi ressemble cette ligne après chaque étape de son évaluation, vous allez être extrêmement limité en tant que programmeur dans votre capacité à tirer parti des fonctionnalités du langage.
Je ne parle pas seulement de la base
if (bool == false):
return true
else:
return false
qui bien sûr peut simplement être remplacé par return !bool.
Je fais également référence à la capacité de comprendre votre langue au point où vous pouvez trouver quelque chose comme ceci:
string[] thingsToOutput;
for(int i = 0; i <= thingsToOutput.Length; print(thingsToOutput[i++]));
La première fois que j'ai vu une déclaration comme celle-là, cela m'a un peu fait perdre la tête; il ne m'était pas venu à l'esprit que je pouvais tirer parti de la boucle for de cette manière. La personne qui a écrit cette déclaration a mieux compris les possibilités qui s'offraient à eux - ils ont vu plus de portes ouvertes que moi, ce qui leur a donné plus de liberté et de pouvoir dans leur capacité à concevoir du code.
Maintenant, que ce soit bon le code est un problème - si l'une de ces portes devrait être ouverte - c'est à débattre. Il reste que avec une grande puissance vient une grande responsabilité.
Que connaître la réponse à cette question ne fait pas de vous un programmeur
Notions de base sur les licences logicielles
La différence entre une licence de copyleft "viral" (GPL) par rapport à Apache compatible avec les sources fermées et MS-PL/MS-RL non viral.
Quand faut-il utiliser LGPL et quand ne pas le faire.
Compatibilité des licences. Par exemple, vous pouvez lier une bibliothèque sous licence Apache moderne à un code GPLv3, mais pas GPL 1 ou 2.
Si vous possédez le code source dans son intégralité, vous pouvez le publier sous autant (ou quelques) licences que vous le souhaitez.
Note à S.O. communauté:
N'hésitez pas à modifier cette réponse comme bon vous semble ... principalement pour des informations non adaptées à la section des commentaires ci-dessous.
Cryptographie. Vous n'êtes pas obligé d'écrire votre propre algorithme de chiffrement, mais vous devez avoir une compréhension de base du fonctionnement du chiffrement, de l'authentification des messages et de l'ICP. Je lutte depuis trop longtemps avec des essais et erreurs aveugles dans ce domaine. Récemment, j'ai acheté le livre "Cryptography Engineering" (de Ferguson, Schneier, Kohno) et cela m'a vraiment ouvert les yeux.
Connaissez votre système d'exploitation/plate-forme avant de commencer à coder.
Si vous codez Windows/Linux/Android/iOS, etc. commencez par apprendre le système d'exploitation. Si vous ciblez quelque chose d'autre comme le Web, la même chose va là-bas.
écrire du code pour les gens!
plus de chiffre magique!
n'écrivez pas tout le code sur une seule ligne!
- construire quelque chose que les gens veulent
- construire quelque chose que vous souhaitez utiliser tous les jours
- si vous ne commentez pas votre code, assurez-vous qu'il se lit proprement
- commentez votre code
Il n'y a rien de tel qu'un bug qui ne peut pas se produire.
"Hello world" n'est pas une application complète, car il n'y a aucune affirmation démontrée/programmatique que la sortie est en fait "Hello world". Le code n'est pas complet tant qu'il n'a pas été testé à l'unité.
Certains d'entre eux ont déjà été postés, mais voici ma liste:
- Construisez selon les exigences, n'ajoutez pas ce dont vous n'avez pas besoin, surtout si vous "pensez" que vous le ferez. Si vous en avez besoin plus tard, ajoutez-le ensuite.
- Comment utiliser la recherche Google. Ne dérangez pas votre collègue avant d'avoir regardé.
- Ne sois pas intelligent.
- Ce n'est pas fait jusqu'à ce qu'il réponde à TOUTES les exigences, testé, documenté et vérifié dans SVN.
- Normes de codage appropriées, par exemple: conventions de dénomination
Apprenez à déployer correctement votre code, vos tests et votre progiciel.
L'une des pires habitudes des développeurs que j'ai vues dans l'industrie est une ignorance courante de la façon de mettre votre logiciel entre les mains d'autres personnes, voici quelques mauvais signes:
Nouvel environnement de développement-itus:
- Je voulais apprendre Ruby donc nous avons écrit nos trucs dedans, le client et la version principale devront prendre un environnement Ruby maintenant
Version-itus:
- Notre équipe est passée à la version X + 1 du compilateur car c'est la dernière, n'en avons-nous parlé à personne?
- Nous avons besoin de la version de bibliothèque Y, oh, vos trucs ne fonctionnent pas avec ça?
- Nous avons testé sur une version très ancienne, cela ne fonctionne pas avec la dernière version?
- Nous avons piraté une version spéciale du noyau pour faire fonctionner la version
Itus binaire uniquement:
- Notre environnement de construction est vraiment compliqué, nous allons juste vous donner des binaires
Itus multicœur:
- Désactiver SMP, nos trucs ne fonctionnent que sur un environnement monoprocesseur
Fonctionnalité codée en dur:
- Décommentez ce #define pour activer la fonctionnalité X, que voulez-vous dire que vous voulez à l'exécution?
Simplicité, clarté, généralité. http://www.math.harvard.edu/computing/programming/rules.html
- construire des systèmes comme des réseaux de processus simples connectés par des sockets/tuyaux
- échanger des données dans un format texte simple: ensembles d'enregistrements de paires "clé: valeur", ou TSV
"L'outil de débogage le plus efficace reste une réflexion approfondie, associée à des déclarations imprimées judicieusement placées." BWK
Plus vous en savez sur le fonctionnement de la sécurité sur la plate-forme de votre choix, mieux c'est.
Utilisez le bon outil pour le travail.
Le programmeur est l'élément important, et le langage et les outils doivent être choisis en fonction du problème. N'ayez pas peur des nouvelles langues et des nouveaux projets.
On ne pleure pas dans la programmation!
- une compréhension approfondie des concepts de fondation, par ex. types de données, interfaces
- une compréhension de niveau moyen à élevé de l'outil qu'ils utilisent, par ex. connaissances spécifiques .net/Java
- une idée raisonnable des `` autres technologies avec lesquelles votre truc s'interface '', par exemple comment fonctionnent les bases de données
- à peu près où se dirige leur base technologique, par exemple qu'est-ce que le cloud computing et quel impact cela aura-t-il sur leurs compétences actuelles
Comment écrire un programme FizzBuzz.
Lorsque vous devez distribuer une application ou mettre un site Web en production en dehors des limites de votre entreprise, tout ce que vous pensiez n'a pas d'importance, est important.
Le code n'est beau que s'il fait ce qu'il est censé faire.
- Binaire avec une compréhension de base de signé et non signé.
- Comprendre comment fonctionne n'importe quel système numérique positionnel.
- Comprenez comment les structures de données de base sont stockées en mémoire.
La correction du code nécessite plus d'intelligence que l'écriture initiale du même code.
Par conséquent, si vous écrivez du code à la limite de votre intelligence, vous n'êtes, par définition, pas assez intelligent pour le réparer lorsqu'il se casse.
Écrivez d'abord vos structures de données - cela signifie tout, des schémas de base de données aux mécanismes de transfert/sérialisation.
La plupart des projets concernent le stockage et le déplacement de données d'un point A à un point B au format C.
En fin de compte, environ 90% de votre code sera logique pour faire le formatage, mais le vrai tueur a juste un format pour accéder et écrire vos données. Une fois que vous avez une API pour l'accès aux données, vous pouvez jouer avec le formatage comme vous le souhaitez, mais une fois que vous démarrez la production avec une API de stockage, il peut vraiment être difficile de réaliser que vous l'avez foiré.
Dans les 5 questions essentielles de Steve Yegge sur l'écran du téléphone, il essaie de s'assurer que les personnes interrogées ont une connaissance de base de:
- Codage. Le candidat doit écrire du code simple, avec une syntaxe correcte, en C, C++ ou Java.
- Conception OO. Le candidat doit définir les concepts de base OO, et proposer des classes pour modéliser un problème simple.
- Scripting et regexes. Le candidat doit décrire comment trouver les numéros de téléphone dans 50 000 pages HTML.
- Structures de données. Le candidat doit démontrer une connaissance de base des structures de données les plus courantes.
- Bits et octets. Le candidat doit répondre à des questions simples sur les bits, les octets et les nombres binaires.
http://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions
Au moment où il a écrit cela, il était sur Amazon, mais travaille (et mène probablement des interviews) chez Google maintenant. Cela vous fait juste passer l'écran. Voici comment il a décrit ce qu'il cherchait:
ce que je recherche ici, c'est un vide total dans l'un de ces domaines. Ce n'est pas grave s'ils luttent un peu et découvrent ensuite. Ce n'est pas grave s'ils ont besoin de quelques conseils ou invites mineurs. Cela ne me dérange pas s'ils sont rouillés ou lents. Ce que vous recherchez, ce sont des candidats totalement désemparés ou horriblement confus dans le domaine en question.
La documentation est très importante. Plus encore si vous construisez quelque chose à partir de zéro. Cela aide à documenter vos idées avant d'écrire un code.
Je l'ai appris à la dure.
Je ne peux pas encore commenter, mais sur le thème "Tester et déboguer les compétences", ce petit bijo par Ned Batchelder est une lecture incontournable. (Ensuite, une grande partie de ce qu'il a à dire sur le débogage et les assertions mérite d'être prise en considération.)
Chaque programmeur doit savoir que la seule chose qu'il sait, c'est qu'il ne sait rien. Il y a beaucoup à apprendre.
Chaque programmeur doit lier les actions FindNextSelected et FindPreviousSelected (Visual Studio) aux touches du clavier (de préférence F4 et F2). Vous en tirez deux choses:
- Manière plus rapide de naviguer entre différents points d'utilisation de variable/fonction/sous-chaîne (plus rapide qu'avec "Rechercher toutes les références")
- Possibilité de différencier les choses à l'intérieur d'un document. En sautant d'avant en arrière tout en recherchant une sous-chaîne, vous pouvez voir les différences entre les différents emplacements. Pas besoin d'utiliser Winmerge pour comparer des parties du même document.
Connaître la syntaxe de base des expressions régulières, y compris le regroupement conditionnel. Évitez d'utiliser des addons de commande regex spécifiques à la bibliothèque ou au moins commentez/factorisez ces parties.
Comment faire.
... Que voulez-vous dire que j'ai besoin de 15 caractères?
Programme avec la maintenabilité à l'esprit.
Je ne peux pas dire combien de fois de simples expressions régulières ont converti des données que les gens pensaient que cela prendrait des jours à manipuler. Il doit être présent dans chaque boîte à outils du programmeur.
Bien sûr, nous ne pouvons pas oublier xkcd: 
Chaque programmeur doit savoir comment fonctionne un processeur.
Soyez Maître de Quelque chose, mais Soyez Conscient de Tout !!!!
Il y a de très bonnes suggestions ici, mais je suis surpris que personne n'ait mentionné l'excellente série d'articles d'Ulrich Drepper: Ce que chaque programmeur devrait savoir sur la mémoire .
Tous les problèmes en informatique peut être résolu par un autre niveau d'indirection.
Concevez votre code et si votre gestionnaire souhaite utiliser une approche de style RAD essayez d'obtenir autant de détails que possible. Ensuite, lorsque plus de fonctionnalités sont ajoutées, essayez de penser si le code existant peut être réécrit avant il suffit d'accumuler plus de code et vous vous retrouvez avec un gratte-ciel au lieu d'une maison.
chaque programmeur doit avoir une base solide en génie logiciel, ainsi qu'en analyse/conception de systèmes et en concepts de systèmes d'information. De cette façon, s'ils sont appelés à contribuer de manière substantielle à l'analyse/conception des systèmes et/ou à l'architecture de l'information, ils seront dans une position de connaissance + d'opinion. de la meilleure solution au problème. Le génie logiciel est un peu plus difficile à mesurer, mais les connaissances préalables sont disponibles sur le marché et dans des cours universitaires appropriés où ils enseignent plus que simplement comment bricoler un peu de code ensemble. de toute façon, cela n'est pas censé être négatif parce que l'esprit principal n'est que l'amélioration, mais j'ai travaillé avec des gens qui n'ont aucune connaissance informatique ou il y a les "script kiddies" à l'esprit unique qui codent et recodent (et seulement dans leur langue de choix) et ne voient chaque problème que comme une répétition des solutions précédemment appliquées (par ce codeur). faire mieux pour le client.
Exécutez d'abord le code ou la logique dans votre tête ou votre papier. Ne vous précipitez pas pour frapper la commande de compilation et d'exécution pour la tester.
Il se trouve en quelques lettres, vraiment:
Ok, je simplifie trop, mais fondamentalement, si vous êtes assez autodidacte, n'arrêtez jamais d'apprendre et êtes un peu perfectionniste, vous devriez avoir la base pour devenir un bon programmeur.
Au-delà, ce serait plus spécifique à des rôles et technologies particuliers.
Si quelque chose peut mal tourner, alors ce sera le cas. Supposons le pire des cas
N'oubliez pas la personne qui va utiliser le logiciel que vous créez.
Reconnaissez que tout ce qui peut mal tourner va mal. Passez très peu de temps à écrire du code - mais reconnaissez et réutilisez les modèles courants. Refactorisez le code en permanence pour atteindre le design idéal.
Toutes les données doivent vivre quelque part. Vous pouvez le trouver si vous regardez assez fort.
Ils doivent connaître le pouvoir des fermetures et commencer à les utiliser.
Notation hexadécimale. Champs de bits également - AND, OR (inclus et exclusif), complément (1 et 2), décalage de bits.
Mon premier vote serait pour les conventions de dénomination.
Lorsque quelqu'un vous demande de construire quelque chose, souvenez-vous: il vous demande également de le maintenir. Peut-être, pour toujours.
Que quels que soient les programmes, plus que de dire à une machine comment faire un travail, ils sont le moyen le plus clair de montrer aux autres êtres humains comment faire un travail.