Rédaction technique pour les développeurs

HTML, CSS, JavaScript, Python, PHP, C++, Dart — il existe de nombreux langages de programmation et vous maîtrisez peut-être même parfaitement plusieurs d'entre eux ! Mais alors que nous visons à écrire du code plus nombreux et de meilleure qualité, la façon dont nous écrivons et communiquons dans le langage de tous les jours devient de plus en plus importante… et peut-être même négligée.

La façon dont nous écrivons sur le code est sans doute aussi importante que le code lui-même. Et quelle que soit votre position sur cette ligne, nous pouvons tous convenir que nos paroles ont le potentiel à la fois d’aider et de nuire à l’efficacité du code.

Dans cet article, je souhaite décrire comment ces deux domaines apparemment distincts – la programmation et l'écriture – peuvent se réunir et faire passer nos compétences de développeur au niveau supérieur.

Attendez, rédaction technique ? Oui, c'est exactement ce que je veux dire. Je crois sincèrement que nous sommes tous des écrivains dans un sens ou dans un autre. Et je suis ici pour vous donner une introduction avec des astuces de rédaction, des conseils et des exemples sur la façon dont cela peut faire de vous à la fois un meilleur développeur et un meilleur communicateur.

La rédaction technique est partout

L'année dernière, l'équipe derrière le populaire client Mac Git, Tower, a interrogé plus de 4,000 XNUMX développeurs et a constaté que près de 50 % d’entre eux passaient entre 3 et 6 heures par jour à écrire du code.

Et oui, il s’agit d’une enquête menée auprès d’un groupe assez spécialisé, mais j’imagine que beaucoup d’entre nous se situent quelque part dans cette fourchette. Quoi qu’il en soit, un développeur n’écrit pas de code 24 heures sur 7, XNUMX jours sur XNUMX, car, comme le suggère ce sondage, nous passons beaucoup de temps à faire autre chose.

Cela pourrait inclure :

• faire une démonstration d'une nouvelle fonctionnalité,
• documenter cette nouvelle fonctionnalité,
• mettre à jour un ticket de travail lié à cette nouvelle fonctionnalité, ou
• travail de backlogging pour prendre en charge cette nouvelle fonctionnalité.

Bien sûr, il y a toujours du temps pour les pauses toilettes et Wordle aussi.

Quoi qu'il en soit, la plupart des choses que nous faisons généralement impliquent de communiquer avec des personnes telles que votre équipe, vos collègues, vos clients, vos utilisateurs et d'autres développeurs.

Nous passons donc une bonne partie de notre temps à communiquer avec les humains via des mots en plus de la communication que nous avons avec les ordinateurs via code. Les mots sont un langage écrit. Et si nous écrivions mieux nos mots, nous communiquerions mieux. Lorsque nous communiquons mieux, nous avons plus de chances d’obtenir ce que nous voulons.

C'est la rédaction technique 101.

Et cela ne s'arrête même pas là. Certains programmeurs aiment également créer leurs propres produits, ce qui signifie qu'ils doivent intégrer le marketing dans leur travail. La rédaction technique joue également un rôle important à cet égard. Donc voilà. Je pense qu'il est assez juste de dire que la rédaction technique est en effet partout.

Qu’est-ce qu’une bonne grammaire ?

Avec autant de langages de programmation, la dernière chose que nous voulons est d’en apprendre un autre.

Grammaire fait partie intégrante de l’anglais et libère tout le potentiel de la communication. Cela nous rend plus formels, professionnels et cohérents.

Laissez-moi vous donner un bref aperçu de la langue.

La syntaxe anglaise

Tout comme les langages de programmation, l’anglais a une syntaxe bien définie et commence par des mots.

Les mots sont les éléments constitutifs de l’anglais et ils se répartissent en huit catégories :

Pensez-y comme UI composants : ce sont des éléments modulaires que vous pouvez déplacer pour construire une phrase complète et robuste, de la même manière que vous pourriez reconstituer une phrase complète et robuste. UI. Tous les composants doivent-ils être là à tout moment ? Certainement pas! Assemblez une phrase avec les éléments dont vous avez besoin pour compléter l’expérience, comme vous le feriez avec une interface.

Voix et ton

Vocabulaire, ponctuation, structure des phrases et choix des mots. Ce sont tous les ingrédients de l’anglais. Nous les utilisons pour partager des idées, communiquer avec nos amis et notre famille et envoyer des e-mails à nos collègues.

Mais il est crucial de considérer sonner de nos messages. C’est incroyable à quel point un point d’exclamation peut complètement changer le ton d’un message :

1. J'aime la programmation.
2. I comme la programmation! :)

Il est facile de confondre voix et ton, et vice versa.

Voix C'est ce qui concerne notre choix de mots, qui dépend du contexte. Par exemple, un didacticiel destiné aux débutants est plus susceptible d'utiliser l'argot et un langage informel pour transmettre une voix amicale, tandis que la documentation peut être rédigée de manière formelle, sérieuse et professionnelle dans le but d'aller droit au but.

Le même message, écrit de deux voix différentes :

• Fun: "Développez votre réseau social et restez informé des tendances actuelles."
• Sérieuse: "Trouvez un emploi sur l'un des plus grands réseaux sociaux et marché de l'emploi en ligne."

Il n’est pas rare d’écrire accidentellement des messages qui semblent condescendants, offensants et non professionnels. C'est ici que tonifier entre en scène. Lisez vos messages à voix haute, demandez à d'autres personnes de les lire pour vous et expérimentez votre ponctuation et votre structure de phrase. C’est ainsi que vous affinez votre ton.

Voici une autre façon de voir les choses : votre voix ne change jamais, mais votre ton change. Votre voix s'apparente à qui vous êtes en tant que personne, tandis que le ton correspond à la façon dont vous réagissez dans une situation donnée.

Voix active et passive

Une phrase contient toujours un acteur, un verbe et une cible. L'ordre dans lequel ceux-ci arrivent détermine si la phrase est écrite à une voix active ou passive.

L'acteur arrive en premier dans un voix active. Par exemple : « CSS peint l’arrière-plan ».

Les phrases utilisant une voix active sont plus simples que leurs homologues. Ils sont plus clairs, plus courts et plus compréhensibles, parfaits pour une voix plus professionnelle qui va droit au but.

Avec son voix passive, l'acteur arrive en dernier. (Vous voyez ce que j'ai fait là-bas ?) Cela signifie que notre acteur – CSS dans ce cas – arrive à la fin comme ceci : « L'arrière-plan est peint par CSS. »

Les lecteurs convertissent généralement une voix passive en voix active dans leur tête, ce qui entraîne un temps de traitement plus long. Si vous avez déjà entendu dire qu’il est préférable d’écrire d’une voix active, c’est généralement pour cette raison. Les rédacteurs techniques préfèrent la voix active la plupart du temps, à quelques exceptions près, comme en citant des recherches : « Il a été suggéré que… »

Mais cela ne signifie pas que vous devez toujours vous efforcer d’avoir une voix active. Passer de l’un à l’autre – même dans le même paragraphe – peut rendre votre contenu plus fluide d’une phrase à l’autre s’il est utilisé efficacement.

Éviter les erreurs

La grammaire concerne la structure et l’exactitude du langage, et il n’y a rien de mieux pour y parvenir qu’une relecture rapide de votre document. Il est très important de débarrasser vos écrits des fautes d’orthographe, des problèmes de grammaire et des imperfections sémantiques.

À la fin de cet article, je vous montrerai les outils précieux que les professionnels utilisent pour éviter les erreurs d’écriture. De toute évidence, de nos jours, il existe des correcteurs orthographiques intégrés dans presque tout ; nos éditeurs de code disposent même de plugins de vérification orthographique et de peluchage pour éviter les erreurs. 

Mais si vous recherchez un outil unique pour tout ce qui concerne la grammaire, gramaticalmente est l’un des outils les plus utilisés. Je ne reçois pas de pot-de-vin pour ça ou quoi que ce soit. C'est simplement un très bon outil que de nombreux éditeurs et rédacteurs utilisent pour écrire du contenu propre et clair – de la même manière que vous pourriez utiliser Emmet, Eslint ou tout autre linter pour écrire du code propre et clair.

Écrire des commentaires de code

Les choses que nous écrivons pour d’autres développeurs peuvent avoir un impact important sur la qualité globale de notre travail, qu’il s’agisse de ce que nous écrivons dans le code, de la manière dont nous expliquons le code ou de la manière dont nous donnons notre avis sur un morceau de code.

Il est intéressant de noter que chaque langage de programmation est livré avec un ensemble standard de fonctionnalités pour rédiger un commentaire. Ils devraient expliquer ce que fait le code. Je ne veux pas dire par là des commentaires vagues comme celui-ci :

red *= 1.2 // Multiply `red` by 1.2 and re-assign it

Utilisez plutôt des commentaires qui fournissent plus d’informations :

red *= 1.2 // Apply a 'reddish' effect to the image

Tout est question de contexte. « Quel genre de programme est-ce que je construis ? » C'est exactement le genre de question que vous devriez vous poser.

Les commentaires doivent ajouter de la valeur

Avant d'examiner ce qui constitue un « bon » commentaire de code, voici deux exemples de commentaires paresseux :

const age = 32 // Initialize `age` to 32

filter: blur(32px); /* Create a blur effect with a 32px radius */

N'oubliez pas que le but d'un commentaire est d'ajouter de la valeur à un morceau de code, pas de le répéter. Si vous ne pouvez pas faire cela, il vaut mieux laisser le code tel quel. Ce qui rend ces exemples « paresseux », c’est qu’ils ne font que reformuler ce que fait évidemment le code. Dans ce cas, les commentaires sont redondants car ils nous disent ce que nous savons déjà : ils n’ajoutent aucune valeur !

Les commentaires doivent refléter le code actuel

Les commentaires obsolètes ne sont pas rares dans les grands projets ; oserais-je dire dans (en fait, presque toutes) projets.

Imaginons David, un programmeur et un gars sympa avec qui sortir. David souhaite trier une liste de chaînes par ordre alphabétique de A à Z, il fait donc l'évidence en JavaScript :

cities = sortWords(cities) // sort cities from A to Z

David se rend alors compte que sortWords() trie en fait les listes de Z à A. Ce n'est pas un problème, car il peut simplement inverser le résultat :

cities = sortWords(cities) // sort cities from A to Z
cities = reverse(cities)

Malheureusement, David n'a pas mis à jour son commentaire de code.

Imaginez maintenant que je ne vous ai pas raconté cette histoire et que tout ce que vous avez vu était le code ci-dessus. On pourrait naturellement penser qu’après avoir exécuté cette deuxième ligne de code, les « villes » seraient triées de Z à A ! Tout ce fiasco de confusion a été provoqué par un commentaire obsolète.

Bien que cela puisse être un exemple exagéré, quelque chose de similaire peut (et se produit souvent) si vous courez dans un délai serré. Heureusement, cela peut être évité en suivant une règle simple… changez vos commentaires en même temps que vous changez le code.

C'est une règle simple qui vous évitera, à vous et à votre équipe, bien des problèmes. dette technique.

Maintenant que nous savons à quoi ressemblent des commentaires mal rédigés, regardons quelques bons exemples.

Les commentaires doivent expliquer le code unidiomatique

Parfois l sciences naturelles la façon de faire les choses n’est pas bonne. Les programmeurs devront peut-être « enfreindre » un peu les normes, mais lorsqu’ils le font, il est conseillé de laisser un petit commentaire expliquant leur justification :

 function addSetEntry(set, value) {    
  /* Don't return `set.add` because it's not chainable in IE 11. */  
  set.add(value);
  return set;
}

C'est utile, non ? Si vous étiez responsable de la révision de ce code, vous avez peut-être été tenté de le corriger sans que ce commentaire explique ce qui se passe.

Les commentaires peuvent identifier les tâches futures

Une autre chose utile à faire avec les commentaires est d’admettre qu’il y a encore du travail à faire.

// TODO: use a more efficient algorithm
linearSort(ids)

De cette façon, vous pouvez rester concentré sur votre flux. Et plus tard, vous (ou quelqu'un d'autre) pourrez revenir et réparer le problème.

Les commentaires peuvent renvoyer à la source

Vous venez donc de trouver une solution à votre problème sur StackOverflow. Après avoir copié ce code, il est parfois judicieux de conserver un lien vers la réponse qui vous a aidé afin de pouvoir y revenir pour référence future.

// Adds handling for legacy browsers
// https://stackoverflow.com/a/XXXXXXX

C’est important car les solutions peuvent changer. Il est toujours bon de savoir d’où vient votre code au cas où il tomberait en panne.

Rédaction de pull request

Pull demandes (PRs) sont un aspect fondamental de tout projet. Ils sont au cœur des révisions de code. Et les révisions de code peuvent rapidement devenir un goulot d’étranglement dans les performances de votre équipe sans une bonne formulation.

Le bon PR la description résume est ce que nous faisons un changement est en train de se produire et why c’est en train d’être fait. Les grands projets ont un modèle de pull request, comme celui-ci adapté d'un exemple réel:

## Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.

## Types of changes
What types of changes does your code introduce to Appium?
 - [ ] Bugfix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
 - ...

## Checklist
 - [ ] I have read the CONTRIBUTING doc
 - [ ] I have signed the CLA
 - [ ] Lint and unit tests pass locally with my changes

## Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc…

Évitez les vagues PR titres

Veuillez éviter les titres qui ressemblent à ceci :

• Correction de la construction.
• Réparer le bug.
• Ajoutez un correctif.

Ceux-ci ne le font même pas tentative pour décrire de quelle version, bogue ou correctif nous avons affaire. Un petit détail supplémentaire sur quelle partie de la version a été corrigée, quel bug a été corrigé ou quel correctif a été ajouté peut grandement contribuer à établir une meilleure communication et collaboration avec vos collègues. Il établit les niveaux et met les gens sur la même longueur d'onde.

PR les titres sont traditionnellement écrits en temps impératif. Il s’agit d’un résumé d’une seule ligne de l’ensemble PR, et ils devraient décrire est ce que nous faisons est réalisé par le PR.

Voici quelques bons exemples :

• Prise en charge des attributs srcset personnalisés dans NgOptimizedImage
• Configuration d'image par défaut avec une qualité d'image de 75 %
• Ajouter des sélecteurs explicites pour tous les ControlValueAccessors intégrés

Évitez longtemps PRs

Un grand PR signifie une description énorme, et personne ne veut réviser des centaines ou des milliers de lignes de code, parfois juste pour finir par tout rejeter !

Au lieu de cela, vous pourriez :

• communiquer avec votre équipe via Questions,
• faire un plan,
• décomposer le problème en morceaux plus petits, ou
• travailler chaque pièce séparément avec la sienne PR.

N'est-ce pas beaucoup plus propre maintenant ?

Fournir des détails dans le PR corps

Contrairement au PR titre, le corps est le place pour tous les détails, y compris :

• Pourquoi est-ce que PR en train d'être fait ?
• Pourquoi est-ce la meilleure approche ?
• Toute lacune de l’approche et idées pour les résoudre si possible
• Le numéro de bug ou de ticket, les résultats du benchmark, etc.

Signaler des bogues

Les rapports de bugs sont l’un des aspects les plus importants de tout projet. Et tous les grands projets reposent sur les commentaires des utilisateurs. Habituellement, même après d’innombrables tests, ce sont les utilisateurs qui trouvent le plus de bugs. Les utilisateurs sont également de grands idéalistes, et ils ont parfois des idées de fonctionnalités ; s'il vous plaît, écoutez-les !

Pour les projets techniques, tout cela se fait en signalant les problèmes. Un problème bien rédigé est facile à trouver et à résoudre pour un autre développeur.

Par exemple, la plupart des grands projets s'accompagnent un modèle:

 <!-- Modified from angular-translate/angular-translate -->
 ### Subject of the issue
 Describe your issue here.

 ### Your environment
 * version of angular-translate
 * version of angular
 * which browser and its version

 ### Steps to reproduce
 Tell us how to reproduce this issue.

 ### Expected behavior
 Tell us what should happen.

 ### Actual behavior
 Tell us what happens instead.

Rassemblez des captures d'écran

Capturez le problème à l'aide de votre utilitaire de capture d'écran du système.

S'il s'agit d'une capture d'écran d'un CLI programme, assurez-vous que le texte est clair. Si c'est un UI programme, assurez-vous que la capture d’écran capture les bons éléments et états.

Vous devrez peut-être capturer une interaction réelle pour démontrer le problème. Si tel est le cas, essayez de enregistrer des GIF à l'aide d'un outil d'enregistrement d'écran.

Comment reproduire le problème

Il est beaucoup plus facile pour les programmeurs de résoudre un bug lorsqu’il est présent sur leur ordinateur. C'est pourquoi un bon commit doit être accompagné des étapes permettant de reproduire précisément le problème.

Voici un exemple :

Update: you can actually reproduce this error with objects:

 ```html
 <div *ngFor="let value of objs; let i = index">
   <input [ngModel]="objs[i].v" (ngModelChange)="setObj(i, $event)" />
 </div>
 ```

 ```js
 export class OneComponent {
   obj = {v: '0'};
   objs = [this.obj, this.obj, this.obj, this.obj];
 ​
  setObj(i: number, value: string) {
     this.objs[i] = {v: value};
  }
 }
 ```

 The bug is reproducible as long as the trackBy function returns the same value for any two entries in the array. So weird behavior can occur with any duplicate values.

Suggérer une cause

C’est vous qui avez attrapé le bug, alors peut-être pouvez-vous suggérer des causes potentielles expliquant pourquoi il est là. Peut-être que le bug ne se produit qu'après avoir rencontré un certain événement, ou peut-être qu'il ne se produit que sur mobile.

Cela ne peut pas non plus faire de mal d’explorer la base de code et peut-être d’identifier la cause du problème. Ensuite, votre problème sera résolu beaucoup plus rapidement et vous serez probablement affecté au problème correspondant. PR.

Communiquer avec les clients

Vous pouvez travailler en tant que pigiste solo ou peut-être êtes-vous le développeur principal d’une petite équipe. Dans les deux cas, disons que vous êtes responsable de l’interface avec les clients sur un projet. 

Le stéréotype des programmeurs est que nous sommes de mauvais communicateurs. Nous sommes connus pour utiliser un jargon trop technique, dire aux autres ce qui est possible et ce qui n’est pas possible, et même être sur la défensive lorsque quelqu’un remet en question notre approche.

Alors, comment atténuer ce stéréotype ? Demandez aux clients ce qu’ils veulent et écoutez toujours leurs commentaires. Voici comment procéder.

Posez les bonnes questions

Commencez par vous assurer que vous et le client êtes sur la même longueur d’onde :

• Qui est votre public cible?
• Quel est le but du site ?
• Qui est votre concurrent le plus proche et que font-ils correctement ?

Poser des questions est également un bon moyen d’écrire de manière positive, en particulier dans les situations où vous n’êtes pas d’accord avec les commentaires ou la décision d’un client. Poser des questions oblige cette personne à soutenir ses propres affirmations plutôt que de l’attaquer en défendant sa propre position :

• Êtes-vous d’accord avec cela même si cela entraîne un coût de performance supplémentaire ?
• Le déplacement du composant nous aide-t-il à mieux atteindre notre objectif ?
• Génial, qui est responsable de maintenir cela après le lancement ? 
• Savez-vous d’emblée si le contraste entre ces deux couleurs répond aux normes WCAG AA ?

Les questions sont beaucoup plus innocentes et favorisent la curiosité plutôt que l’animosité.

Vends toi

Si vous faites une présentation à un client potentiel, vous devrez le convaincre de vous embaucher. Pourquoi le client devrait-il vous choisir ? Il est important de préciser les éléments suivants :

• Qui tu es
• Ce que vous faites
• Pourquoi vous êtes un bon candidat pour le poste
• Liens vers le travail pertinent que vous avez effectué

Et une fois que vous avez obtenu le poste et que vous devez rédiger un contrat, n’oubliez pas qu’il n’y a pas de contenu plus intimidant qu’un tas de jargon juridique. Même s'il est écrit pour des projets de conception, le tueur contrat peut être un bon point de départ pour écrire quelque chose de beaucoup plus convivial.

Votre souci du détail pourrait faire la différence entre vous et un autre développeur essayant de remporter le même projet. D'après mon expérience, les clients embaucheront tout aussi facilement un développeur avec lequel ils pensent aimer travailler que celui qui est techniquement le plus compétent ou expérimenté pour le poste.

Écriture de microcopie

Microcopie l'art d'écrire est-il convivial UI messages, tels que des erreurs. Je parie qu'il y a eu des moments où vous, en tant que développeur, avez dû écrire des messages d'erreur parce qu'ils étaient mis en veilleuse jusqu'au moment du lancement.

C'est peut-être pour cela que nous voyons parfois des erreurs comme celle-ci :

Error: Unexpected input (Code 693)

Les erreurs sont la dernière chose à laquelle vous souhaitez que vos utilisateurs soient confrontés. Mais cela arrive, et nous ne pouvons rien y faire. Voici quelques conseils pour améliorer vos compétences en microcopie.

Évitez le jargon technique

La plupart des gens ne savent pas ce qu’est un serveur, alors que 100 % des programmeurs le savent. C'est pourquoi il n'est pas rare de voir des termes inhabituels écrits dans un message d'erreur, comme API ou « exécution du délai d’attente ».

À moins que vous n’ayez affaire à un client technique ou à une base d’utilisateurs, il est probable que la plupart de vos utilisateurs n’ont pas suivi de cours d’informatique et ne savent pas comment fonctionne Internet ni pourquoi une chose particulière ne fonctionne pas. D'où l'erreur.

Par conséquent, un bon message d’erreur ne devrait pas expliquer why quelque chose s’est mal passé, car de telles explications pourraient nécessiter l’utilisation de termes techniques effrayants. C’est pourquoi il est très important d’éviter d’utiliser du jargon technique.

Ne blâmez jamais l'utilisateur

Imaginez ceci : j'essaie de me connecter à votre plateforme. J'ouvre donc mon navigateur, visite votre site Web et saisis mes coordonnées. Ensuite, on me dit : « Votre email/mot de passe est incorrect. »

Même si cela semble dramatique de penser que ce message est hostile, cela me fait inconsciemment me sentir stupide. Microcopy dit qu’il n’est jamais acceptable de blâmer l’utilisateur. Essayez de changer votre message en quelque chose de moins pointu, comme cet exemple adapté de la connexion de Mailchimp : « Désolé, cette combinaison e-mail-mot de passe n'est pas correcte. Nous pouvons vous aider à récupérer votre compte.

J'aimerais également ajouter l'importance d'éviter TOUTES LES MAJUSCULES et les points d'exclamation ! Bien sûr, ils peuvent être utilisés pour transmettre de l’enthousiasme, mais en microcopie, ils créent un sentiment d’hostilité envers l’utilisateur.

Ne submergez pas l'utilisateur

Utiliser l’humour dans votre microcopie est une bonne idée ! Cela peut détendre l’ambiance et c’est un moyen simple de freiner la négativité causée par même les pires erreurs.

Mais si tu ne l'utilises pas à la perfection, cela peut paraître condescendant et insultant pour l’utilisateur. C'est juste un big risque à prendre.

Mailchimp le dit bien :

Ne faites pas tout votre possible pour faire une blague – l’humour forcé peut être pire que rien du tout. Si vous n'êtes pas sûr, gardez un visage impassible.

(Souligner le mien)

Écrire un balisage accessible

Nous pourrions facilement consacrer un article entier à l’accessibilité et à son lien avec la rédaction technique. Bon sang, l'accessibilité est souvent incluse dans les guides de style de contenu, y compris ceux pour Microsoft ainsi que Mailchimp.

Vous êtes développeur et vous en savez probablement déjà beaucoup sur l’accessibilité. Vous êtes peut-être même l'un des développeurs les plus assidus qui font de l'accessibilité un élément essentiel de votre flux de travail. Pourtant, il est incroyable de constater combien de fois les considérations d’accessibilité sont mises de côté, même si nous savons tous qu’il est important de rendre les expériences en ligne accessibles qui incluent toutes les capacités.

Ainsi, si vous vous retrouvez à implémenter la rédaction de quelqu'un d'autre dans votre code, à rédiger de la documentation pour d'autres développeurs, ou même à écrire UI copiez-vous, tenez compte de certaines bonnes pratiques fondamentales en matière d'accessibilité, car elles complètent tous les autres conseils en matière de rédaction technique.

Des choses comme:

Andy Bell en propose relativement petites choses que vous pouvez faire pour rendre le contenu plus accessible, et cela vaut la peine de les consulter. Et, juste pour le plaisir, John Rhea montre quelques astuces de montage intéressantes cela est possible lorsque nous travaillons avec des éléments HTML sémantiques.

Conclusion

Ce sont six façons de démontrer comment la rédaction technique et le développement coïncident. Même si les exemples et les conseils ne sont peut-être pas sorcier, j'espère que vous les avez trouvés utiles, qu'il s'agisse de collaborer avec d'autres développeurs, de maintenir votre propre travail, de devoir rédiger votre propre copie à la rigueur, ou même de rédiger une proposition de projet, entre autres. des choses.

L’essentiel : perfectionner vos compétences rédactionnelles et consacrer un peu d’effort supplémentaire à votre écriture peut en fait faire de vous un meilleur développeur.

Ressources de rédaction technique

Si la rédaction technique vous intéresse :

Si vous êtes intéressé par la rédaction :

Si vous êtes intéressé par la microcopie :

Si vous souhaitez utiliser un guide de style professionnel pour améliorer votre écriture :

Si vous souhaitez écrire pour l’accessibilité :