Tutoriel

Tutoriel (7)

Suspendisse at libero porttitor nisi aliquet vulputate vitae at velit. Aliquam eget arcu magna, vel congue dui. Nunc auctor mauris tempor leo aliquam vel porta ante sodales. Nulla facilisi. In accumsan mattis odio vel luctus. Fusce egestas, augue in fermentum euismod, quam ante mattis lorem, a tempor ipsum mi sed elit.

Vous cherchez à connaître les meilleurs sites pour télécharger ebooks gratuits illégal en français gratuitement ? Alors vous êtes tombé au bon endroit. Avant de plonger dans le vif du sujet, voyons voir d'abord c'est que signifie Ebook.

Je ne sais pas par vous mais moi perso, si je ne suis pas en train d’écouter de la musique douce, lire un livre sur(l'entrepreneuriat,les clés du succès, etc..), lire certaines ebooks, parler (businesss, entrepreneuriat aux jeunes, je suis fan de ça), ou sortir prendre l’air alors je ne fais que coder et analyser. C’est de cette façon que ma journée fini par se terminer.

La stéganographie est l’art de la dissimulation, son objet est de faire passer inaperçu un message dans un autre message. Elle se distingue de la cryptographie qui est l’art du secret, qui cherche à rendre un message inintelligible à autre que qui-de-droit.

Si vous êtes à la recherche des Meilleurs sites Internet du monde je vous dis qu’il en existe des milliards. Mais parmi ces milliards, il y a ceux qui sont très utiles dans certains cas et d’autres pour certaines personnes.

Si vous avez activé l’affichage de vos fichiers cachés sur votre ordinateur Windows, alors vous avez peut-être déjà observé un fichier appelé « hiberfil.sys » à la racine de votre disque système.

Il est plus facile de créer des installateurs avec Inno setup compiler.

Être un bon programmeur est difficile et noble. La chose la plus difficile pour concrétiser une vision collective d’un projet de logiciel est de traiter avec ses collègues et ses clients. L'écriture de programmes informatiques est importante et requiert beaucoup d'intelligence et de compétences. Mais c’est vraiment un jeu d’enfant comparé à tout ce qu’un bon programmeur doit faire pour créer un système logiciel qui réussisse à la fois pour le client et pour la myriade de collègues dont il est partiellement responsable. Dans cet essai, je tente de résumer le plus succinctement possible les explications que j’aurais aimé recevoir à l'âge de vingt et un ans. Ceci est très subjectif et par conséquent, cet essai est condamné à être personnel et à refléter mes opinions. Je me limite aux problèmes qu’un programmeur risque de rencontrer dans son travail. Bon nombre de ces problèmes et de leurs solutions sont si inhérent à la condition humaine que je semblerai probablement moralisateur. J'espère malgré tout que cette contribution sera utile.

La programmation informatique est enseignée dans des cours. Les excellents livres : The Pragmatic Programmer [Prag99], Code Complete [CodeC93], Rapid Development [RDev96] et Extreme Programming Explained [XP99] enseignent tous la programmation informatique et les plus gros obstacles à surmonter pour être un bon programmeur. Les essais de Paul Graham [PGSite] et Eric Raymond [Hacker] devraient certainement être lus avant ou avec cet article. Cet essai diffère de ces excellents travaux en mettant l'accent sur les problèmes sociaux et en résumant de manière exhaustive l'ensemble des compétences nécessaires telles que je les vois.

Dans cet essai, le terme « patron » est utilisé pour désigner quiconque vous donne des projets à faire. J'utilise les mots « business », « entreprise » et « clan », comme synonymes, à l'exception du fait que « business » signifie « gagner de l'argent », que « entreprise » désigne le lieu de travail et que le « clan » est de façon générale l’ensemble des personnes de votre milieu professionnel.

Bienvenue dans le clan.


Le débogage est la pierre angulaire du programmeur. Le premier sens du verbe « déboguer » est de supprimer les erreurs, mais le sens qui importe vraiment est de voir l'exécution d'un programme en l'examinant. Un programmeur qui ne peut pas déboguer efficacement est aveugle.

Les idéalistes, ceux qui pensent que le design, l'analyse, les théories complexes et autres sont plus fondamentales que le débogage, ne sont pas des programmeurs en activité. Le programmeur qui travaille ne vit pas dans un monde idéal. Même si vous êtes parfait, vous êtes entouré et devez interagir avec le code écrit par des éditeurs de logiciels importants, des organisations comme GNU et vos collègues. L’essentiel de ce code est imparfait et insuffisamment documenté. Sans la possibilité de voir l'exécution de ce code, la moindre imperfection vous bloquera définitivement. Souvent, cette visibilité ne peut être obtenue que par l'expérimentation, c’est cela déboguer.

Le débogage concerne l’exécution des programmes, pas les programmes eux-mêmes. Si vous achetez quelque chose d'un grand éditeur de logiciels, vous ne verrez généralement pas le programme. Mais il restera toujours des endroits où le code ne sera pas conforme à la documentation (le crash de votre ordinateur est un exemple courant et spectaculaire) ou bien où la documentation est muette. Plus généralement, vous créez une erreur, examinez le code que vous avez écrit et n’avez aucune idée de la façon dont l’erreur peut se produire. Inévitablement, cela signifie que certaines des hypothèses que vous faites ne sont pas tout à fait correctes ou que certaines conditions n’ont pas été anticipées. Parfois, le tour de magie qui consiste à regarder dans le code source fonctionne. Quand ce n'est pas le cas, vous devez déboguer.

Pour avoir une visibilité sur l'exécution d'un programme, vous devez être capable d'exécuter le code et de l'observer. Parfois, cela est visible, comme ce qui est affiché sur un écran, ou le délai entre deux événements. Dans de nombreux autres cas, cela implique des éléments qui ne sont pas censés être visibles, tels que l'état de certaines variables dans le code, les lignes de code en cours d'exécution ou le fait que certaines assertions s'appliquent à une structure de données complexe. Ces choses cachées doivent être révélées.

  • Utilisation d’un outil de débogage,
  • Édition de ligne pour apporter une modification temporaire au programme, en ajoutant généralement des lignes imprimant des informations,
  • Journalisation dans une fenêtre permanente montrant l'exécution des programmes sous la forme d'un journal.

Les outils de débogage sont formidables lorsqu'ils sont stables et disponibles, mais l’édition de ligne et la journalisation sont encore plus importants. Les outils de débogage sont souvent en retard sur le développement du langage, ils peuvent donc ne pas être disponibles à tout moment. De plus, comme l'outil de débogage peut modifier subtilement la façon dont le programme s'exécute, il peut ne pas être pratique. Enfin, certains types de débogage, tels que la vérification d'une assertion par rapport à une structure de données volumineuse, nécessitent l'écriture de code et la modification de l'exécution du programme. Il est bon de savoir comment utiliser les outils de débogage quand ils sont stables, mais il est essentiel de pouvoir utiliser les deux autres méthodes.

Certains débutants craignent le débogage lorsqu'il est nécessaire de modifier le code. C'est compréhensible. C'est un peu comme une chirurgie exploratoire. Mais vous devez apprendre à manipuler le code et à le faire sauter ; vous devez apprendre à expérimenter et à comprendre que rien de ce que vous faites temporairement ne fera empirer les choses. Si vous ressentez cette peur, recherchez un mentor. Nous perdons beaucoup de bons programmeurs au délicat moment de leur apprentissage de cette peur.


 

Le débogage est amusant, car il commence par un mystère. Vous pensez que le programme devrait faire quelque chose, mais au lieu de cela, il fait autre chose. Ce n'est pas toujours aussi simple - les exemples que je peux donner seront artificiels par rapport à ce qui se passe parfois dans la pratique. Le débogage nécessite créativité et ingéniosité. S'il n'y a qu'une seule clé pour le débogage, c'est d'utiliser la technique diviser pour mieux régner afin de résoudre le mystère.

Supposons, par exemple, que vous ayez créé un programme devant exécuter dix tâches successives. Lorsque vous l'exécutez, il se bloque. Comme vous ne l'avez pas programmé pour qu’il se bloque, vous avez maintenant un mystère. Lorsque vous examinez la sortie, vous constatez que les sept premières opérations de la séquence ont été exécutées avec succès. Les trois derniers ne sont pas visibles sur la sortie. Votre mystère est donc plus petit: « Il s’est bloqué sur les objets n° 8, n° 9 ou n° 10 ».

Pouvez-vous concevoir une expérience pour voir sur quoi il s'est bloqué? Bien sûr. Vous pouvez utiliser un débogueur ou nous pouvons ajouter des instructions d’édition de ligne (ou l’équivalent dans la langue dans laquelle vous travaillez) après les numéros 8 et 9. Lorsque nous le repasserons à nouveau, notre mystère sera plus petit, comme «C’est bloqué par la chose n ° 9». Je trouve que garder à l’esprit ce qu’est le mystère à tout moment permet de rester concentré. Lorsque plusieurs personnes travaillent ensemble sous la pression pour résoudre un problème, il est facile d’oublier ce qui est le plus important dans le mystère.

La clé de diviser pour mieux régner en tant que technique de débogage est la même que pour la conception d’algorithmes : tant que vous faites du bon travail en décomposant le mystère au milieu, vous n’aurez pas à le diviser trop souvent et vous déboguerez rapidement. Mais quel est le milieu d'un mystère? C'est ici qu'interviennent la vraie créativité et l'expérience.

Pour un vrai débutant, l’espace de toutes les erreurs possibles ressemble à toutes les lignes du code source. Vous n’avez pas la vision que vous développerez plus tard pour voir les autres dimensions du programme, telles que l’espace des lignes exécutées, la structure de données, la gestion de la mémoire, l’interaction avec du code étranger, le code présentant des risques et le code qui est simple. Pour le programmeur expérimenté, ces autres dimensions forment un modèle mental imparfait mais très utile de tout ce qui peut mal se passer. Avoir ce modèle mental est ce qui aide à trouver efficacement le centre du mystère.

Une fois l'espace de travail subdivisé de manière égale pour tout ce qui peut mal tourner, vous devez essayer de décider dans quel espace se trouve l'erreur. Dans le cas simple où le mystère est: « Quelle ligne inconnue bloque mon programme ? », Vous pouvez vous poser la question suivante: « La ligne inconnue est-elle exécutée avant ou après cette ligne que j'estime être exécutée au milieu du programme en cours ? » Habituellement, vous ne serez pas assez chanceux pour savoir que l'erreur existe sur une seule ligne, voire sur un seul bloc. Le mystère ressemble souvent davantage à ceci: « Soit un pointeur dans ce graphique pointe vers le mauvais nœud, soit mon algorithme qui additionne les variables de ce graphique ne fonctionne pas. ». Dans ce cas, vous devrez peut-être écrire un petit programme pour vérifier que les pointeurs du graphique sont tous corrects afin de décider quelle partie peut être éliminée de votre recherche.


J'ai volontairement séparé l'acte consistant à examiner l'exécution d'un programme de l'acte consistant à réparer une erreur. Mais bien sûr, le débogage signifie également l’élimination du bogue. Idéalement, vous aurez une parfaite compréhension du code et atteindrez le moment où vous verrez parfaitement l’erreur et saurez comment la corriger. Mais comme votre programme utilisera souvent des systèmes insuffisamment documentés et dans lesquels vous n’avez aucune visibilité, ce n’est pas toujours possible. Dans d'autres cas, le code est tellement compliqué que votre compréhension ne peut être parfaite.

En corrigeant un bogue, vous voudrez effectuer le changement le plus petit possible pour le réparer. Vous pouvez voir d'autres choses qui ont besoin d'amélioration; mais ne les corrigez pas en même temps. Essayez d'utiliser la méthode scientifique qui consiste à changer une chose et une seule chose à la fois. Pour ce faire, le mieux est de pouvoir facilement reproduire le bogue, puis de mettre en place votre correctif, puis de relancer le programme et d’observer que le bogue n’existe plus. Bien sûr, il est parfois nécessaire de modifier plusieurs lignes, mais vous devez toujours appliquer conceptuellement un seul changement atomique pour corriger le bogue.

Parfois, il y a vraiment plusieurs bogues qui ressemblent à un seul. C'est à vous de définir les bogues et de les corriger un à la fois. Parfois, il est difficile de savoir ce que le programme doit faire ou ce que l’auteur original voulait. Dans ce cas, vous devez utiliser votre expérience et votre jugement et attribuer votre propre idée au code. Décidez ce qu'il doit faire, commentez-le ou clarifiez-le d'une manière quelconque, puis adaptez le code à votre idée. Il s’agit d’une compétence intermédiaire ou avancée parfois plus difficile que d’écrire la fonction d’origine, mais le monde réel est souvent compliqué. Vous devrez peut-être réparer un système que vous ne pouvez pas réécrire.


La journalisation consiste à écrire un système afin qu’il produise une séquence d’enregistrements informatifs, appelée journal. La ligne d'impression ne fait que produire un journal simple, généralement temporaire. Les débutants doivent comprendre et utiliser les journaux, car leur connaissance de la programmation est limitée. Les architectes système doivent comprendre et utiliser les journaux en raison de la complexité du système. La quantité d'informations fournie par le journal doit être configurable, idéalement pendant l'exécution du programme. En règle générale, les journaux offrent trois avantages de base :

  • ils peuvent fournir des informations utiles sur les bogues difficiles à reproduire (tels que ceux qui se produisent dans l'environnement de production mais ne peuvent pas être reproduits dans l'environnement de test) ;
  • ils peuvent également fournir des statistiques et des données relatives aux performances, telles que le temps qui s'écoule entre les instructions ;
  • lorsqu'ils sont configurables, les journaux permettent de capturer des informations générales afin de déboguer des problèmes spécifiques non anticipés sans avoir à modifier et /ou redéployer le code uniquement pour traiter ces problèmes spécifiques.

La quantité d’informations à afficher dans le journal est toujours un compromis entre information et concision. Trop d'informations rendent le journal coûteux et génèrent « un aveuglement du défilement », ce qui rend difficile la recherche des informations dont vous avez besoin. Trop peu d’informations et il se peut qu’elles ne contiennent pas ce dont vous avez besoin. Pour cette raison, il est très utile de rendre la sortie configurable. En règle générale, chaque enregistrement du journal identifie sa position dans le code source, la tâche qui l’a exécuté le cas échéant, le moment précis de l’exécution et, en général, une information utile supplémentaire, telle que la valeur d’une variable, la quantité de mémoire disponible, le nombre d'objets de données, etc. Ces instructions de journal sont dispersées dans tout le code source, en particulier aux points de fonctionnalité majeure et autour du code à risque. Chaque instruction peut être affectée à un niveau et ne produira un enregistrement que si le système est actuellement configuré pour générer ce niveau. Vous devez concevoir les instructions de journal de manière à résoudre les problèmes que vous prévoyez. Anticipez le besoin de mesure de performance.

Si vous avez un journal permanent, vous pouvez désormais effectuer une impression sur la base des enregistrements de celui-ci et certaines instructions de débogage seront probablement ajoutées de manière permanente au système de journalisation.


Vous rencontrerez parfois des boucles ou des fonctions récursives, dont l’exécution prend beaucoup de temps et qui constituent des goulots d’étranglement dans votre produit. Avant d'essayer de rendre la boucle un peu plus rapide, prenez quelques minutes pour déterminer s'il existe un moyen de la supprimer complètement. Un algorithme différent le ferait-il? Pourriez-vous calculer cela en calculant autre chose? Si vous ne trouvez pas de solution, vous pouvez optimiser la boucle. C'est simple : sortez des éléments de celle-ci. En fin de compte, cela nécessitera non seulement de l'ingéniosité, mais également une compréhension des dépenses associées à chaque type de déclaration et d'expression. Voici quelques suggestions:

  • supprimer les opérations en virgule flottante ;
  • n’allouez pas de nouveaux blocs de mémoire inutilement ;
  • placez les constantes ensemble ;
  • déplacez les E/S dans un tampon ;
  • essayez de ne pas diviser ;
  • essayez de ne pas faire de coûteuses conversions de type ;
  • déplacez un pointeur plutôt que de recalculer des index.

Le coût de chacune de ces opérations dépend de votre système. Sur certains , les compilateurs et le matériel font ces choses pour vous. Un code clair et efficace est préférable à un code qui nécessite une compréhension d'une plate-forme en particulier.

Pour apprendre à concevoir un logiciel, étudiez l'action d'un mentor en étant physiquement présent lors de la conception. Puis, étudiez des bouts de logiciels bien écrits. Après cela, vous pourrez lire des livres sur les dernières techniques de design.

Ensuite, vous devez le faire vous-même. Commencez avec un petit projet. Lorsque vous avez enfin terminé, étudiez comment la conception a échoué ou a réussi et comment vous vous êtes écarté de votre conception initiale. Ensuite, passez à des projets plus importants, espérons-le en collaboration avec d'autres personnes. Le design est une question de jugement qui prend des années à acquérir. Un programmeur intelligent peut apprendre les bases de manière adéquate en deux mois et s'améliorer à partir de là.

Il est naturel et utile de développer votre propre style, mais rappelez-vous que le design est un art, pas une science. Les personnes qui écrivent des livres sur le sujet ont tout intérêt à le faire paraître scientifique. Ne devenez pas dogmatique à propos de styles de design particuliers.


Le regretté Edsger Dijkstra a expliqué avec éloquence que la science informatique n’est pas une science expérimentale [ExpCS] et ne dépend pas des ordinateurs électroniques.

...the harm was done: the topic became known as “computer science” - which, actually, is like referring to surgery as “knife science” - and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment.

Comme il le dit se référant aux années 1960 … « le mal était fait : le sujet était devenu « informatique » - ce qui revient à comparer la chirurgie à « science du bistouri» - et il était fermement implanté dans l'esprit des gens que l'informatique concernait les machines et leurs équipements périphériques ».

La programmation ne devrait pas être une science expérimentale, mais la plupart des programmeurs qui travaillent n’ont pas le luxe de s’engager dans ce que Dijkstra entend par informatique. Nous devons travailler dans le domaine de l'expérimentation, comme le font certains physiciens, mais pas tous. Si dans trente ans, la programmation peut être réalisée sans expérimentation, ce sera un grand accomplissement de la science informatique.

Les types d'expériences que vous devrez effectuer incluent les actions suivantes :
     • éprouver des systèmes avec de petits exemples pour vérifier leur conformité à la documentation ou pour comprendre leur réponse en l'absence de documentation ;
     • tester de petits changements de code pour voir s’ils corrigent réellement un bogue ;
     • mesurer la performance d’un système dans deux conditions différentes en raison d’une connaissance imparfaite de ses caractéristiques de performance ;
     • vérifier l’intégrité des données ;
     • collecter des statistiques pouvant laisser penser à la solution aux bogues compliqués ou difficiles à reproduire.

Je ne pense pas que dans cet essai je puisse expliquer la conception des expériences; vous devrez étudier et pratiquer. Cependant, je peux offrir deux conseils.

Tout d’abord, essayez d’être très clair sur votre hypothèse ou sur l’affirmation que vous essayez de tester. Il est également utile d’écrire l’hypothèse, surtout si elle vous semble confuse ou si vous travaillez en équipe.

Vous devrez souvent concevoir une série d'expériences, chacune basée sur les connaissances acquises lors de l’expérience précédente. Par conséquent, vous devez concevoir vos expériences de manière à fournir le plus d’informations possible. Malheureusement, il est difficile de garder chaque expérience simple - vous devrez développer ce jugement par la pratique.


L'estimation demande de la pratique. Cela demande aussi du travail. Cela demande tellement de travail que ce peut être une bonne idée d'estimer le temps qu'il faudra pour faire l'estimation, surtout si vous êtes invité à estimer quelque chose de grand.

Lorsqu'on il est demandé de donner une estimation de quelque chose de grand, la chose la plus honnête à faire est d'esquiver. La plupart des ingénieurs sont enthousiastes et désireux de plaire, et gagner du temps ne va certainement pas déplaire à celui qui en fait les frais. Mais une estimation trop rapide ne sera probablement ni exacte ni honnête.

Tout en gagnant du temps, il peut être possible d’envisager de réaliser ou de prototyper la tâche. Si la pression politique le permet, il s’agit du moyen le plus précis de produire l’estimation et cela fait réellement avancer.

Lorsqu'il n'est pas possible de prendre le temps d'une enquête, vous devez d'abord établir très clairement le périmètre de l'estimation. Répétez ce périmètre en introduction et dans la conclusion de votre estimation écrite. Préparez un devis en décomposant la tâche en sous-tâches de plus en plus petites jusqu'à ce que chaque petite tâche idéalement ne dépasse pas un jour au maximum . Le plus important est de ne rien omettre. Par exemple, la documentation, les tests, le temps nécessaire à la planification, le temps nécessaire pour communiquer avec d'autres groupes et le temps des vacances sont tous très importants. Si vous passez une partie de votre journée à traiter avec des gens stupides, insérez un poste pour cela dans l'estimation. Cela donne à minima à votre patron une visibilité sur l'utilisation de votre temps et pourrait vous en donner plus.

Je connais de bons ingénieurs qui rallongent les estimations systématiquement, mais je vous recommande de ne pas le faire. Un des résultats de ce rallongement est que la confiance en vous peut être perdue. Par exemple, un ingénieur peut prévoir trois jours pour une tâche qui, à son avis, prendra un jour. L’ingénieur peut prévoir de passer deux jours à le documenter ou à travailler sur un autre projet utile. Mais,le fait que la tâche ait été accomplie en un jour seulement sera visible et l'apparition d'un relâchement ou d'une surestimation est née. Il est de loin préférable de donner une visibilité adéquate à ce que vous faites réellement. Si la documentation prend deux fois plus de temps que le codage et si l’estimation le dit, vous gagnerez en crédibilité auprès du responsable.

Si une tâche prend probablement une journée - mais peut prendre dix jours si votre approche ne fonctionne pas - notez ceci d'une manière ou d'une autre dans l'estimation si vous le pouvez; sinon, faites au moins une moyenne pondérée par la probabilité de vos estimations . Tout facteur de risque que vous pouvez identifier et auquel vous pouvez attribuer une estimation doit être inclus dans le calendrier. Il est peu probable qu'une personne soit malade au cours d'une semaine donnée. Mais un grand projet avec de nombreux collaborateurs sera plus exposé aux aléas ; de même pour les vacances. Et quelle est la probabilité d'un séminaire de formation obligatoire à l'échelle de l'entreprise? Si cela peut être estimé, ajoutez-le. Il y a bien sûr des « inconnus inconnus » ou des imprévus. Les imprévus, par définition ne peuvent pas être estimés individuellement. Vous pouvez essayer de créer une ligne supplémentaire globale ou les gérer d'une autre manière que vous communiquerez à votre responsable. Vous ne pouvez toutefois pas laisser votre supérieur oublier qu’ils existent et il est bigrement facile pour une estimation de devenir un emploi du temps sans tenir compte des imprévus.

Pour un travail en équipe, vous devriez essayer de faire en sorte que l'estimation soit faite par les personnes qui feront le travail, et vous devriez essayer d'obtenir un consensus à l'échelle de l'équipe sur les estimations. Les compétences, l'expérience, la préparation et la confiance varient considérablement. La situation est difficile lorsqu'un programmeur expérimenté estime pour lui même et que des programmeurs moins aguerris sont tenus de suivre cette estimation. Le fait de faire en sorte que l’ensemble de l’équipe s’entende ligne par ligne sur l’estimation clarifie la compréhension par l’équipe, tout en offrant la possibilité de réaffecter tactiquement les ressources (par exemple, en reportant la charge de travail des membres les moins capés de l’équipe vers ceux les plus aguerris).

S'il existe de gros risques qui ne peuvent pas être évalués, il est de votre devoir de le dire avec suffisamment de force à votre responsable afin d’éviter qu’il ne s'y engage et soit dans le pétrin si le risque se réalise. Espérons que dans un tel cas, tout ce qui sera nécessaire sera fait pour réduire les impacts.

Si vous parvenez à convaincre votre entreprise d’utiliser la programmation extrême, vous n’aurez plus qu’à estimer des choses relativement petites, ce qui est plus amusant et plus productif.


La vie est trop courte pour écrire des foutaises que personne ne lira; si vous écrivez des foutaises, personne ne les lira. Par conséquent, un peu de bonne documentation est préférable. Les gestionnaires ne comprennent souvent pas cela, car même une mauvaise documentation leur donne un faux sentiment de sécurité, à savoir qu'ils ne dépendent pas de leurs programmeurs. Si quelqu'un insiste absolument pour que vous écriviez une documentation vraiment inutile, acceptez et commencez tranquillement à chercher un meilleur emploi.

Rien de plus efficace que de mettre une estimation précise du temps nécessaire pour produire une bonne documentation dans une estimation ce qui permettra de réduire la demande de documentation. La vérité est froide et difficile : la documentation, comme les tests, peut prendre beaucoup plus de temps que le développement de code.

Rédiger une bonne documentation est avant tout une bonne écriture. Je vous suggère de trouver des livres sur l'écriture, de les étudier et de les pratiquer. Mais même si vous êtes un mauvais écrivain ou que vous maîtrisez mal la langue dans laquelle vous devez documenter, la règle d'or est tout ce dont vous avez réellement besoin: « ne faites pas aux autres ce que vous voudriez pas qu'ils vous fassent ». Prenez le temps de bien réfléchir à qui lira votre documentation, ce dont ils ont besoin pour s’en sortir et comment vous pouvez leur apprendre. Si vous le faites, vous serez un rédacteur de documentation supérieur à la moyenne et un bon programmeur.

Lorsqu'il s'agit de documenter le code lui-même, par opposition à la production de documents pouvant être lus par des non-programmeurs, les meilleurs programmeurs que je connaisse ont une méthode universelle : écrire du code explicite et documenter le code uniquement aux endroits où vous ne pouvez pas le préciser en écrivant le code lui-même. Il y a deux bonnes raisons à cela. Premièrement, quiconque ayant besoin de consulter la documentation au niveau du code sera dans la plupart des cas capable de lire le code et préférera le lire. Certes, cela semble plus facile pour le programmeur expérimenté que pour le débutant. Plus important encore, le code et la documentation ne peuvent pas être incohérents s’il n’y a pas de documentation. Le code source peut au pire être faux et déroutant. La documentation, si elle n’est pas parfaitement écrite, peut mentir, et c’est mille fois pire.

Cela ne facilite pas la tâche du programmeur responsable. Comment écrit-on un code explicite? Qu'est-ce que ça veut dire ? Cela signifie :

  • écrire du code en sachant que quelqu'un va devoir le lire ;
  • appliquer la règle d’or ;
  • choisir une solution simple, même si vous pouviez vous en tirer rapidement avec une autre solution ;
  • sacrifier les petites optimisations qui obscurcissent le code
  • penser au lecteur et consacrer une partie de votre temps précieux à lui faciliter la tâche ;
  • ne jamais utiliser un nom de fonction comme foo, bar ou doIt !

 

La programmation informatique est une activité qui est aussi une culture. Le malheur est que ce n’est pas une culture qui valorise beaucoup la santé physique ou mentale. Pour des raisons à la fois culturelles et historiques (la nécessité de travailler la nuit sur des ordinateurs non chargés, par exemple) et en raison de la pression écrasante de mise sur le marché et de la pénurie de programmeurs, ceux ci sont traditionnellement surmenés. Je ne pense pas que vous puissiez faire confiance à toutes les histoires que vous entendez, mais je pense que 60 heures par semaine, c'est courant, et 50, c'est à peu près un minimum. Cela signifie que souvent beaucoup plus que ce qui est requis. C’est un problème grave pour un bon programmeur, qui est responsable non seulement de lui-même mais aussi de son équipe. Vous devez savoir quand rentrer chez vous et parfois quand suggérer que d’autres personnes rentrent chez elles. Il ne peut y avoir de règle fixe pour résoudre ce problème, pas plus qu'il ne peut en avoir pour élever un enfant, pour la même raison - chaque être humain est différent.

Au-delà de 60 heures par semaine c’est un effort extraordinaire pour moi, que je peux appliquer pendant de courtes périodes (environ une semaine) et que l’on attend parfois de moi. Je ne sais pas s'il est juste d'attendre 60 heures de travail d'une personne; Je ne sais même pas si 40 est juste. Je suis cependant persuadé que c’est stupide de travailler tellement si l’on gagne peu de ce temps supplémentaire. Pour moi , cela ne dépasse pas 60 heures par semaine. Je pense qu'un programmeur devrait être responsable et porter un lourd fardeau. Cependant, le programmeur n'a pas le devoir d'être un souffre douleur. Malheureusement, on demande souvent aux programmeurs de subir pour pouvoir présenter un spectacle à quelqu'un, par exemple un manager qui tente d'impressionner un dirigeant. Les programmeurs succombent souvent à cela parce qu'ils ont envie de faire plaisir et ne savent pas très bien dire non. Il y a trois défenses contre cela:

  • communiquez autant que possible avec tous les membres de l'entreprise afin que personne ne puisse induire en erreur les dirigeants sur ce qui se passe ;
  • apprenez à dire non, et dire non en équipe si nécessaire ;
  • partez si vous le devez.

La plupart des programmeurs sont de bons programmeurs et les bons programmeurs veulent faire beaucoup de choses. Pour ce faire, ils doivent gérer leur temps efficacement. Il existe une certaine inertie mentale associée à la résolution d'un problème et à son implication profonde. De nombreux programmeurs trouvent qu'ils fonctionnent mieux lorsqu'ils disposent de longs blocs de temps ininterrompus pour s’immerger et se concentrer. Cependant, les gens doivent dormir et accomplir d'autres tâches. Chaque personne doit trouver un moyen de satisfaire à la fois son rythme humain et son rythme de travail. Chaque programmeur doit faire le nécessaire pour gagner du temps, par exemple pour réserver certains jours au cours desquels il n'assiste qu'aux réunions les plus critiques.

Depuis que j'ai des enfants, j'essaie de passer des soirées avec eux parfois . Le rythme qui me convient le mieux est de travailler une très longue journée, de dormir au bureau ou près du bureau (le trajet entre chez moi et mon domicile est long), puis de rentrer chez moi suffisamment tôt le lendemain pour passer du temps avec mes enfants avant qu’ils aillent au lit. Je ne suis pas à l'aise avec cela, mais c'est le meilleur compromis que j'ai pu trouver. Rentrez chez vous si vous avez une maladie contagieuse. Vous devriez rentrer chez vous si vous avez des idées suicidaires. Vous devriez faire une pause ou rentrer chez vous si vous avez des envies de meurtre pendant plus de quelques secondes. Vous devriez renvoyer quelqu'un à la maison s'il présente un dysfonctionnement mental grave ou des signes de maladie mentale allant au-delà d'une dépression légère. Si vous êtes tenté d'être malhonnête ou trompeur d'une manière inhabituelle à cause de la fatigue, vous devriez faire une pause. N'utilisez pas de cocaïne ou d'amphétamines pour lutter contre la fatigue. N’abusez pas de la caféine.

Ensemble et unit, nous sommes fort.

Contact

Template Settings

Theme Colors

Cyan Red Green Oranges Teal

Layout

Wide Boxed Framed Rounded
Patterns for Layour: Boxed, Framed, Rounded
Top