Scriere tehnică pentru dezvoltatori

HTML, CSS, JavaScript, Python, PHP, C++, Dart - există atât de multe limbaje de programare și s-ar putea chiar să fii fluent în câteva dintre ele! Dar, pe măsură ce ne propunem să scriem cod mai mult și mai bun, modul în care scriem și comunicăm în limbajul de zi cu zi devine din ce în ce mai important... și poate chiar trecut cu vederea.

Modul în care scriem despre și în jurul codului este la fel de important ca și codul în sine. Și, în ciuda faptului că vă aflați pe această linie, putem fi cu toții de acord că cuvintele noastre au potențialul de a ajuta și de a afecta eficiența codului.

În acest articol, vreau să subliniez modul în care aceste două domenii aparent distincte — programarea și scrierea — se pot reuni și pot duce abilitățile noastre de dezvoltator la nivelul următor.

Stai, scris tehnic? Da, exact asta vreau să spun. Cred cu adevărat că suntem cu toții scriitori într-un sens sau altul. Și sunt aici pentru a vă oferi un manual cu sfaturi de scriere, sfaturi și exemple despre cum vă poate face atât un dezvoltator, cât și un comunicator mai bun.

Scrisul tehnic este peste tot

Anul trecut, echipa din spatele popularului client Mac Git, Tower, a chestionat peste 4,000 de dezvoltatori și a constatat că aproape 50% dintre ei au petrecut între 3-6 ore pe zi scriind cod.

Și da, acesta este un sondaj care sonda un grup destul de nișă, dar îmi imaginez că mulți dintre noi se încadrează undeva în acest interval. Oricare ar fi cazul, un dezvoltator nu scrie cod 24/7, deoarece așa cum sugerează acest sondaj, petrecem mult timp făcând alte lucruri.

Aceasta ar putea include:

• demonstrarea unei noi caracteristici,
• documentarea acestei noi caracteristici,
• actualizarea unui bilet de lucru legat de acea nouă caracteristică sau
• munca întârziată pentru a sprijini această nouă caracteristică.

Desigur, există întotdeauna timp pentru pauze de baie și pentru Wordle.

Oricum, majoritatea lucrurilor pe care le facem de obicei implică comunicarea cu oameni precum echipa ta, colegii, clienții, utilizatorii și alți dezvoltatori.

Așa că petrecem o bună parte din timpul nostru comunicând cu oamenii cuvinte pe lângă comunicarea pe care o avem cu calculatoarele prin cod. Cuvintele sunt limbaj scris. Și dacă ne-am scrie mai bine cuvintele, am comunica mai bine. Când comunicăm mai bine, avem mai multe șanse să obținem ceea ce ne dorim.

Aceasta este scrierea tehnică 101.

Și nici măcar nu se termină aici. Unii programatori le place să-și facă propriile produse, ceea ce înseamnă că trebuie să facă din marketing o parte din munca lor. Scrisul tehnic joacă un rol important și în asta. Deci da. Cred că este destul de corect să spun că scrierea tehnică este într-adevăr pretutindeni.

Ce este gramatica bună?

Cu atât de multe limbaje de programare, ultimul lucru pe care ne dorim este să învățăm altul.

Gramatică este o parte integrantă a limbii engleze și deblochează întregul potențial al comunicării. Ne face mai formali, profesionisti si mai coerenti.

Permiteți-mi să vă fac o scurtă prezentare a limbii.

Sintaxa engleză

La fel ca limbajele de programare, engleza are o sintaxă bine definită și începe cu cuvinte.

Cuvintele sunt elementele de bază ale englezei și se încadrează în opt găleți:

Gândiți-vă la acestea ca UI componente: sunt piese modulare pe care le puteți deplasa pentru a construi o propoziție completă și robustă, în același mod în care ați putea pune împreună o propoziție completă și robustă. UI. Toate componentele trebuie să fie acolo tot timpul? Cu siguranta nu! Asamblați o propoziție cu piesele de care aveți nevoie pentru a finaliza experiența, așa cum ați face cu o interfață.

Voce și ton

Vocabular, punctuație, structura propoziției și alegerea cuvintelor. Acestea sunt toate ingredientele englezei. Le folosim pentru a împărtăși idei, pentru a comunica cu prietenii și familia și pentru a trimite e-mailuri colegilor noștri.

Dar este crucial să luăm în considerare sunet a mesajelor noastre. Este uimitor cum un semn de exclamare poate schimba complet tonul unui mesaj:

1. Îmi place programarea.
2. I ca programare! :)

Este ușor să confundi voce cu ton și invers.

Voce este ceea ce privește alegerea noastră de cuvinte, care depinde de context. De exemplu, un tutorial pentru începători este mai probabil să folosească argoul și limbajul informal pentru a transmite o voce prietenoasă, în timp ce documentația poate fi scrisă într-o manieră formală, serioasă și profesională, într-un efort de a ajunge direct la obiect.

Același mesaj, scris cu două voci diferite:

• Distracţie: „Extindeți-vă rețeaua socială și fiți la curent cu ceea ce este în tendințe acum.”
• Serios: „Găsiți locuri de muncă pe una dintre cele mai mari aplicații de rețele sociale și pe piața de locuri de muncă online.”

Nu este neobișnuit să scrieți din greșeală mesaje care par a fi condescendente, ofensatoare și neprofesioniste. Aici e locul ton intră în joc. Citiți-vă mesajele cu voce tare, atrageți alte persoane să le citească pentru dvs. și experimentați cu punctuația și structura propoziției. Așa îți perfecționezi tonul.

Iată un alt mod de a gândi: vocea nu se schimbă niciodată, dar tonul se schimbă. Vocea ta este asemănătoare cu cine ești ca persoană, în timp ce tonul este modul în care reacționezi într-o situație dată.

Voce activă și pasivă

O propoziție conține întotdeauna un actor, un verb și o țintă. Ordinea în care acestea apar determină dacă propoziția este scrisă cu voce activă sau pasivă.

Actorul este primul într-un voce activă. De exemplu: „CSS pictează fundalul”.

Propozițiile care folosesc o voce activă sunt mai simple decât omologii lor. Sunt mai clare, mai scurte și mai ușor de înțeles - perfecte pentru o voce mai profesionistă, care ajunge direct la obiect.

Cu o voce pasivă, actorul vine ultimul. (Vezi ce am făcut acolo?) Asta înseamnă că actorul nostru – CSS în acest caz – vine la sfârșit astfel: „Fondul este pictat de CSS”.

Cititorii convertesc de obicei o voce pasivă într-o voce activă în capul lor, rezultând mai mult timp de procesare. Dacă ați auzit vreodată că a scrie cu o voce activă este mai bine, acesta este de obicei motivul pentru care. Scriitorii de tehnologie preferă vocea activă de cele mai multe ori, cu foarte puține excepții, cum ar fi citarea cercetărilor: „S-a sugerat că...”

Dar asta nu înseamnă că ar trebui să te străduiești întotdeauna pentru o voce activă. Trecerea de la unul la altul – chiar și în același paragraf – poate face ca conținutul să curgă mai perfect de la o propoziție la alta dacă este folosit eficient.

Evitarea greselilor

Gramatica se referă la structura și corectitudinea limbajului și nu există nimic mai bun pentru a realiza asta decât o corectare rapidă a documentului. Este foarte important să scapi din scrierile tale de greșelile de ortografie, problemele gramaticale și imperfecțiunile semantice.

La sfârșitul acestui articol, vă voi arăta instrumentele neprețuite pe care profesioniștii le folosesc pentru a evita greșelile de scris. Evident, există verificatoare ortografice încorporate în aproape orice în zilele noastre; editorii noștri de cod au chiar și pluginuri pentru verificarea ortografică și pentru a preveni greșelile. 

Dar dacă sunteți în căutarea unui instrument unic pentru gramatica tuturor lucrurilor, Grammarly este unul dintre cele mai utilizate instrumente. Nu primesc o respingere pentru asta sau altceva. Este doar un instrument foarte grozav pe care mulți editori și scriitori îl folosesc pentru a scrie conținut curat și clar - similar cu modul în care ați putea folosi Emmet, eslint sau orice alt linter pentru a scrie cod curat și clar.

Scrierea comentarii la cod

Lucrurile pe care le scriem pentru alți dezvoltatori pot avea un impact mare asupra calității generale a muncii noastre, fie că este vorba despre ceea ce scriem în cod, cum explicăm codul sau modul în care dăm feedback cu privire la o bucată de cod.

Este interesant că fiecare limbaj de programare vine cu un set standard de caracteristici pentru a scrie un comentariu. Ar trebui să explice ce face codul. Prin asta, nu mă refer la comentarii vagi de genul acesta:

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

În schimb, utilizați comentarii care oferă mai multe informații:

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

Totul tine de context. „Ce fel de program construiesc?” este exact genul de întrebare pe care ar trebui să ți-o pui.

Comentariile ar trebui să adauge valoare

Înainte de a ne uita la ceea ce face un comentariu de cod „bun”, iată două exemple de comentarii leneșe:

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

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

Amintiți-vă că scopul unui comentariu este de a adăuga valoare unei bucăți de cod, nu de a o repeta. Dacă nu puteți face asta, ar fi mai bine să lăsați codul așa cum este. Ceea ce face ca aceste exemple să fie „leneșe” este că ele doar reia ceea ce face în mod evident codul. În acest caz, comentariile sunt redundante, deoarece ne spun ceea ce știm deja - nu adaugă valoare!

Comentariile ar trebui să reflecte codul actual

Comentariile învechite nu sunt vizibile rare în proiectele mari; îndrăznesc să spun înăuntru cele mai multe proiecte.

Să ne imaginăm pe David, un programator și un tip grozav cu care să stea. David vrea să sorteze o listă de șiruri alfabetic de la A la Z, așa că face ceea ce este evident în JavaScript:

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

David realizează apoi că sortWords() sortează listele de la Z la A. Nu este o problemă, deoarece poate inversa pur și simplu rezultatul:

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

Din păcate, David nu și-a actualizat comentariul la cod.

Acum imaginați-vă că nu v-am spus această poveste și tot ce ați văzut a fost codul de mai sus. Desigur, ai crede că, după rularea acelei a doua linii de cod, „orașele” ar fi sortate de la Z la A! Toată această confuzie fiasco a fost cauzată de un comentariu învechit.

Deși acesta ar putea fi un exemplu exagerat, ceva similar se poate întâmpla (și adesea se întâmplă) dacă vă confruntați cu un termen limită apropiat. Din fericire, acest lucru poate fi prevenit urmând o singură regulă simplă... schimbați-vă comentariile în același timp când schimbați codul.

Aceasta este o regulă simplă care te va salva pe tine și pe echipa ta de multe datorii tehnice.

Acum că știm cum arată comentariile prost scrise, să ne uităm la câteva exemple bune.

Comentariile ar trebui să explice codul unidiomatic

Uneori, natural modul de a face lucrurile nu este corect. Programatorii ar putea fi nevoiți să „încalce” puțin standardele, dar atunci când o fac, este recomandabil să lase un mic comentariu în care să explice rațiunea lor:

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

E de ajutor, nu? Dacă ați fost responsabil pentru revizuirea acestui cod, este posibil să fi fost tentat să-l corectați fără ca acel comentariu să explice ce se întâmplă.

Comentariile pot identifica sarcini viitoare

Un alt lucru util de făcut cu comentariile este să recunoaștem că mai este de lucru.

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

În acest fel, poți rămâne concentrat pe fluxul tău. Și la o dată ulterioară, tu (sau altcineva) poți reveni și remedia.

Comentariile pot trimite înapoi la sursă

Deci, tocmai ați găsit o soluție la problema dvs. pe StackOverflow. După ce ați copiat-lipit codul, uneori este bine să păstrați un link către răspunsul care v-a ajutat, astfel încât să puteți reveni la el pentru referințe viitoare.

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

Acest lucru este important deoarece soluțiile se pot schimba. Este întotdeauna bine să știi de unde provine codul tău în cazul în care se rupe vreodată.

Scrierea cererilor de tragere

Trageți cererile (PRs) reprezintă un aspect fundamental al oricărui proiect. Ele stau în centrul recenziilor de cod. Iar recenziile de cod pot deveni rapid un blocaj în performanța echipei tale fără o formulare bună.

Un bun PR descrierea rezumă ceea ce se face schimbarea şi de ce se face. Proiectele mari au un șablon de cerere de extragere, ca acesta adaptat din a exemplu real:

## 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…

Evita vagi PR titluri

Vă rugăm să evitați titlurile care arată astfel:

• Remediați construcția.
• Remediați eroarea.
• Adăugați plasture.

Acestea nici măcar nu încercare pentru a descrie cu ce versiune, bug sau patch avem de-a face. Un mic detaliu suplimentar cu privire la ce parte a versiunii a fost remediată, ce eroare a fost eliminată sau ce patch a fost adăugat poate contribui în mare măsură la stabilirea unei comunicări și colaborări mai bune cu colegii tăi. Setează niveluri și îi aduce pe oameni pe aceeași pagină.

PR titlurile sunt în mod tradițional scrise în timp imperativ. Sunt un rezumat pe o singură linie a întregului PRși ar trebui să descrie ceea ce este realizat de către PR.

Iată câteva exemple bune:

• Suportă atribute srcset personalizate în NgOptimizedImage
• Configurarea implicită a imaginii la o calitate a imaginii de 75%.
• Adăugați selectoare explicite pentru toate ControlValueAccessors încorporate

Evitati mult timp PRs

O mare PR înseamnă o descriere uriașă și nimeni nu vrea să revizuiască sute sau mii de linii de cod, uneori doar pentru a ajunge să respingă totul!

În schimb, ai putea:

• comunicați cu echipa dvs. prin intermediul Probleme,
• fa un plan,
• descompune problema în bucăți mai mici sau
• lucrați la fiecare piesă separat cu propria sa PR.

Nu e mult mai curat acum?

Furnizați detalii în PR corp

Spre deosebire de PR titlu, corpul este il loc pentru toate detaliile, inclusiv:

• De ce este PR se face?
• De ce este aceasta cea mai bună abordare?
• Orice deficiențe ale abordării și idei pentru a le rezolva dacă este posibil
• Bug-ul sau numărul biletului, rezultatele benchmark-ului etc.

Raportarea erorilor

Rapoartele de erori sunt unul dintre cele mai importante aspecte ale oricărui proiect. Și toate proiectele grozave sunt construite pe feedback-ul utilizatorilor. De obicei, chiar și după nenumărate teste, utilizatorii sunt cei care găsesc cele mai multe erori. Utilizatorii sunt, de asemenea, mari idealiști și, uneori, au idei de caracteristici; te rog asculta-i!

Pentru proiectele tehnice, toate aceste lucruri sunt realizate prin raportarea problemelor. O problemă bine scrisă este ușor de găsit și la care un alt dezvoltator poate răspunde.

De exemplu, majoritatea proiectelor mari vin cu un șablon:

 <!-- 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.

Adunați capturi de ecran

Captați problema folosind dvs utilitarul de capturare a ecranului al sistemului.

Dacă este o captură de ecran a unui CLI program, asigurați-vă că textul este clar. Daca este un UI program, asigurați-vă că captura de ecran surprinde elementele și stările potrivite.

Poate fi necesar să capturați o interacțiune reală pentru a demonstra problema. Dacă este cazul, încercați înregistrați GIF-uri folosind un instrument de înregistrare a ecranului.

Cum se reproduce problema

Este mult mai ușor pentru programatori să rezolve o eroare atunci când este live pe computerul lor. De aceea, un commit bun ar trebui să vină cu pașii pentru a reproduce exact problema.

Iată un exemplu:

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.

Sugerați o cauză

Tu ești cel care a prins bug-ul, așa că poate poți sugera câteva cauze potențiale pentru care există. Poate că bug-ul se întâmplă doar după ce întâlnești un anumit eveniment, sau poate se întâmplă doar pe mobil.

De asemenea, nu poate strica să explorezi baza de cod și poate să identifici ce cauzează problema. Apoi, problema dvs. va fi închisă mult mai repede și este posibil să fiți repartizat celui asociat PR.

Comunicarea cu clienții

Puteți lucra ca freelancer solo sau poate sunteți dezvoltatorul principal într-o echipă mică. În ambele cazuri, să presupunem că sunteți responsabil pentru interfața cu clienții într-un proiect. 

Acum, stereotipul programatorului este că suntem slabi comunicatori. Se știe că folosim un jargon excesiv de tehnic, le spunem altora ce este și ce nu este posibil și chiar ne punem la defensivă atunci când cineva pune la îndoială abordarea noastră.

Deci, cum atenuăm acest stereotip? Întrebați clienții ce își doresc și ascultați întotdeauna feedback-ul lor. Iată cum să faci asta.

Puneți întrebările corecte

Începeți prin a vă asigura că dvs. și clientul sunteți pe aceeași pagină:

• Care este publicul țintă?
• Care este scopul site-ului?
• Cine este cel mai apropiat concurent al tău și ce fac corect?

A pune întrebări este, de asemenea, o modalitate bună de a scrie pozitiv, mai ales în situațiile în care nu ești de acord cu feedback-ul sau cu decizia unui client. A pune întrebări obligă acea persoană să-și susțină propriile afirmații, mai degrabă decât să o ataci apărându-ți propria poziție:

• Sunteți de acord cu asta, chiar dacă vine cu un cost suplimentar de performanță?
• Mutarea componentei ne ajută să ne îndeplinim mai bine obiectivul?
• Grozav, cine este responsabil să mențină asta după lansare? 
• Știți de la îndemână dacă contrastul dintre aceste două culori trece standardele WCAG AA?

Întrebările sunt mult mai inocente și promovează curiozitatea față de animozitate.

Vinde-te

Dacă faci o prezentare unui potențial client, va trebui să-l convingi să te angajeze. De ce ar trebui clientul să te aleagă? Este important să specificați următoarele:

• Cine esti
• Ce faci
• De ce ești potrivit pentru job
• Linkuri către lucrările relevante pe care le-ați făcut

Și odată ce ați primit postul și trebuie să scrieți un contract, amintiți-vă că nu există conținut mai intimidant decât o grămadă de lege. Chiar dacă este scris pentru proiecte de design, Ucigaș de contract poate fi un bun punct de plecare pentru a scrie ceva mult mai prietenos.

Atenția ta pentru detalii ar putea fi diferența dintre tine și alt dezvoltator care încearcă să câștige același proiect. Din experiența mea, clienții vor angaja la fel de ușor un dezvoltator cu care cred că le va plăcea să lucreze decât cel care este cel mai competent sau cu experiență din punct de vedere tehnic pentru job.

Microcopie de scriere

Microcopie este arta de a scrie ușor de utilizat UI mesaje, cum ar fi erori. Pun pariu că au existat momente în care tu, ca dezvoltator, a trebuit să scrii mesaje de eroare, deoarece acestea au fost puse în backburner până la momentul lansării.

Acesta poate fi motivul pentru care vedem uneori erori ca aceasta:

Error: Unexpected input (Code 693)

Erorile sunt ultimul lucru cu care doriți să se ocupe utilizatorii dvs. Dar se întâmplă și nu putem face nimic în privința asta. Iată câteva sfaturi pentru a vă îmbunătăți abilitățile de microcopiere.

Evita jargonul tehnic

Majoritatea oamenilor nu știu ce este un server, în timp ce 100% dintre programatori știu. De aceea, nu este neobișnuit să vedeți termeni neobișnuiți scriși într-un mesaj de eroare, cum ar fi API sau „execuție timeout”.

Cu excepția cazului în care aveți de-a face cu un client tehnic sau cu o bază de utilizatori, este probabil ca majoritatea utilizatorilor dvs. să nu fi urmat un curs de informatică și să nu știe cum funcționează Internetul și de ce un anumit lucru nu funcționează. De aici, eroarea.

Prin urmare, un mesaj de eroare bun nu ar trebui să explice de ce ceva a mers prost, deoarece astfel de explicații ar putea necesita folosirea unor termeni tehnici înfricoșători. De aceea este foarte important să evitați utilizarea jargonului tehnic.

Nu da vina niciodată pe utilizator

Imaginează-ți asta: încerc să mă conectez la platforma ta. Așa că îmi deschid browserul, vă vizitez site-ul web și îmi introduc detaliile. Apoi mi se spune: „Adresa de e-mail/parola dvs. este incorectă”.

Chiar dacă pare dramatic să cred că acest mesaj este ostil, subconștient mă face să mă simt prost. Microcopy spune că nu este niciodată în regulă să dai vina pe utilizator. Încearcă să-ți schimbi mesajul cu ceva mai puțin ascuțit, cum ar fi acest exemplu adaptat din datele de conectare Mailchimp: „Ne pare rău, acea combinație de e-mail-parolă nu este corectă. Vă putem ajuta să vă recuperați contul.”

De asemenea, aș dori să adaug importanța evitării MAJUSCULELOR și a semnelor de exclamare! Sigur, pot fi folosite pentru a transmite entuziasm, dar în microcopie creează un sentiment de ostilitate față de utilizator.

Nu copleși utilizatorul

Folosirea umorului în microcopie este o idee bună! Poate ușura starea de spirit și este o modalitate ușoară de a reduce negativitatea cauzată chiar și de cele mai grave erori.

Dar dacă nu îl folosești perfect, poate părea ca fiind condescendent și insultător pentru utilizator. Asta este doar o mare riscul de asumat.

Mailchimp spune bine:

[D]nu ieși din cale să faci o glumă – umorul forțat poate fi mai rău decât deloc. Dacă nu ești sigur, păstrează o față dreaptă.

(sublinierea mea)

Scrierea unui marcaj accesibil

Am putea petrece cu ușurință un articol întreg despre accesibilitate și despre cum se leagă aceasta cu scrierea tehnică. La naiba, accesibilitatea este adesea inclusă în ghidurile de stil de conținut, inclusiv în cele pentru Microsoft și MailChimp.

Ești dezvoltator și probabil știi deja atât de multe despre accesibilitate. S-ar putea chiar să fiți unul dintre cei mai diligenti dezvoltatori care fac din accesibilitate o parte esențială a fluxului dvs. de lucru. Cu toate acestea, este incredibil cât de des sunt puse considerațiile de accesibilitate pe plan secundar, indiferent cât de important știm că este să facem experiențe online accesibile care să includă toate abilitățile.

Deci, dacă vă treziți să implementați copywritingul altcuiva în codul dvs., să scrieți documentație pentru alți dezvoltatori sau chiar să scrieți UI copiați-vă, fiți atenți la unele bune practici fundamentale de accesibilitate, deoarece acestea completează toate celelalte sfaturi pentru scrierea tehnică.

Lucruri ca:

Andy Bell oferă unele relativ lucruri mici pe care le puteți face pentru a face conținutul mai accesibil, și merită timpul să le verificați. Și, doar pentru lovituri, John Rhea arată câteva trucuri îngrijite de editare care sunt posibile atunci când lucrăm cu elemente HTML semantice.

Concluzie

Acestea au fost șase moduri care demonstrează cum scrierea tehnică și dezvoltarea coincid. Deși exemplele și sfaturile s-ar putea să nu fie științifice rachete, sper că le-ați găsit utile, fie că este vorba de colaborarea cu alți dezvoltatori, de menținerea propriei lucrări, de a fi nevoit să vă scrieți propria copie sau chiar de elaborarea unei propuneri de proiect, printre altele. lucruri.

Concluzia: ascuțirea abilităților de scris și a depune puțin efort suplimentar în scris vă poate face de fapt un dezvoltator mai bun.

Resurse tehnice de scriere

Dacă sunteți interesat de scrierea tehnică:

Dacă ești interesat de copywriting:

Dacă sunteți interesat de microcopie:

Dacă sunteți interesat să utilizați un ghid de stil profesional pentru a vă îmbunătăți scrisul:

Dacă sunteți interesat să scrieți pentru accesibilitate: