Tehnično pisanje za razvijalce

HTML, CSS, JavaScript, Python, PHP, C++, Dart — na voljo je toliko programskih jezikov in morda celo popolnoma tekoče govorite več njih! Ker pa si prizadevamo napisati več in boljšo kodo, postaja način pisanja in komuniciranja v vsakdanjem jeziku vedno bolj pomemben ... in morda celo spregledan.

Način, kako pišemo o kodi in okoli nje, je nedvomno enako pomemben kot koda sama. In ne glede na to, kje ste na tej črti, se lahko vsi strinjamo, da lahko naše besede pomagajo in škodijo učinkovitosti kode.

V tem članku želim orisati, kako se lahko ti dve na videz različni področji – programiranje in pisanje – združita in poneseta naše razvijalske veščine na višjo raven.

Čakaj, tehnično pisanje? Da, točno to mislim. Resnično verjamem, da smo vsi pisatelji v enem ali drugem smislu. In tukaj sem, da vam ponudim začetnico z nasveti za pisanje, nasveti in primeri, kako lahko postanete boljši razvijalec in komunikator.

Tehnično pisanje je povsod

Lansko leto je ekipa, ki stoji za priljubljenim odjemalcem Mac Git, Tower, anketirali več kot 4,000 razvijalcev in ugotovil, da jih je skoraj 50 % porabilo med 3-6 ur na dan za pisanje kode.

In ja, to je ena raziskava, ki anketira precej nišno skupino, vendar si predstavljam, da mnogi od nas sodimo nekje v ta razpon. Ne glede na to, razvijalec ne piše kode 24 ur na dan, 7 dni v tednu, ker kot kaže ta anketa, porabimo veliko časa za druge stvari.

To lahko vključuje:

• predstavitev nove funkcije,
• dokumentiranje te nove funkcije,
• posodobitev delovne karte, povezane s to novo funkcijo, ali
• zaostalo delo za podporo te nove funkcije.

Seveda se vedno najde čas za oddih v kopalnici in Wordle.

Kakor koli že, večina stvari, ki jih običajno počnemo, vključuje komunikacijo z ljudmi, kot je vaša ekipa, sodelavci, stranke, uporabniki in drugi razvijalci.

Torej porabimo dober kos svojega časa za komunikacijo z ljudmi besede poleg komunikacije, ki jo imamo z računalniki prek Koda. Besede so pisni jezik. In če bi svoje besede bolje zapisali, bi bolje komunicirali. Ko bolje komuniciramo, je večja verjetnost, da bomo dobili, kar želimo.

To je tehnično pisanje 101.

In to se niti ne konča tukaj.. Nekateri programerji radi izdelujejo tudi lastne produkte, kar pomeni, da mora marketing postati del njihovega dela. Tudi tehnično pisanje igra pri tem veliko vlogo. Torej, ja. Mislim, da je precej pošteno reči, da je tehnično pisanje prav zares povsod.

Kaj je dobra slovnica?

Ker je na voljo toliko programskih jezikov, je zadnja stvar, ki si jo želimo, naučiti se še enega.

Grammar je sestavni del angleščine in odklene ves potencial komunikacije. To nas naredi bolj formalne, profesionalne in koherentne.

Naj vam na kratko predstavim jezik.

Angleška sintaksa

Tako kot programski jeziki ima tudi angleščina dobro definirano sintakso in se začne z besedami.

Besede so gradniki angleščine in spadajo v osem veder:

Pomislite na te kot UI komponente: so modularni kosi, ki jih lahko premikate, da sestavite popoln in robusten stavek, na enak način, kot bi lahko sestavili popoln in robusten UI. Ali morajo biti vse komponente ves čas tam? Zagotovo ne! Sestavite stavek s koščki, ki jih potrebujete za dokončanje izkušnje, tako kot bi to storili z vmesnikom.

Glas in ton

Besedišče, ločila, stavčna struktura in izbira besed. Vse to so sestavine angleščine. Uporabljamo jih za izmenjavo idej, komuniciranje s prijatelji in družino ter pošiljanje e-pošte svojim sodelavcem.

Vendar je pomembno upoštevati zvok naših sporočil. Neverjetno je, kako lahko en klicaj popolnoma spremeni ton sporočila:

1. Rad programiram.
2. I kot programming! :)

Glas je enostavno zamenjati za ton in obratno.

Voice je tisto, kar zadeva našo izbiro besed, ki je odvisna od konteksta. Na primer, vadnica za začetnike bo bolj verjetno uporabljala sleng in neuraden jezik za izražanje prijaznega glasu, medtem ko je dokumentacija lahko napisana na formalen, resen in profesionalen način, da bi prišli naravnost do bistva.

Isto sporočilo, napisano v dveh različnih glasovih:

• Zabava: "Razširite svoje družabno omrežje in bodite na tekočem o tem, kaj je trenutno v trendu."
• Resno: "Poiščite zaposlitev na eni največjih aplikacij za družabna omrežja in spletnega trga dela."

Nič nenavadnega ni, če pomotoma napišete sporočila, ki se zdijo prizanesljiva, žaljiva in neprofesionalna. Tukaj je Ton stopi v igro. Preberite svoja sporočila na glas, povabite druge ljudi, da jih preberejo namesto vas, ter eksperimentirajte s svojimi ločili in strukturo stavkov. Tako izpiliš svoj ton.

Tukaj je še en način razmišljanja: vaš glas se nikoli ne spremeni, vaš ton pa se. Vaš glas je podoben temu, kdo ste kot oseba, medtem ko je ton vaš odziv v dani situaciji.

Aktivni in pasivni glas

Stavek vedno vsebuje igralca, glagol in cilj. Vrstni red, v katerem so ti, določa, ali je stavek napisan v aktivu ali pasivu.

Igralec je na prvem mestu v aktivni glas. Na primer: "CSS pobarva ozadje."

Stavki, ki uporabljajo aktivni glas, so enostavnejši od svojih ustreznikov. So jasnejši, krajši in bolj razumljivi — kot nalašč za bolj profesionalen glas, ki preide naravnost k bistvu.

Z pasivni glas, igralec pride zadnji. (Vidite, kaj sem tam naredil?) To pomeni, da je naš igralec – v tem primeru CSS – na koncu takole: »Ozadje naslika CSS.«

Bralci običajno pretvorijo pasivni glas v aktivni glas v svojih glavah, kar povzroči več časa za obdelavo. Če ste kdaj slišali, da je pisanje z aktivnim glasom boljše, je to običajno razlog. Tehnični pisci imajo večino časa raje aktivni glas, z zelo redkimi izjemami, kot je na primer navajanje raziskav: "Predlagano je bilo, da ..."

Vendar to ne pomeni, da si morate vedno prizadevati za aktiven glas. Če preklapljate z enega na drugega – tudi v istem odstavku – lahko vaša vsebina bolj nemoteno teče iz enega stavka v drugega, če ga uporabljate učinkovito.

Izogibanje napakam

Pri slovnici gre predvsem za strukturo in pravilnost jezika in nič ni boljšega za doseganje tega kot hitro lektoriranje vašega dokumenta. Zelo pomembno je, da se znebite svojih spisov črkovalnih napak, slovničnih težav in pomenskih nepopolnosti.

Na koncu tega članka vam bom pokazal neprecenljiva orodja, ki jih strokovnjaki uporabljajo za izogibanje pisnim napakam. Očitno je, da so dandanes vgrajeni črkovalniki skoraj v vsem; naši urejevalniki kode imajo celo vtičnike za preverjanje črkovanja in linting, ki pomagajo preprečiti napake. 

Če pa iščete orodje na enem mestu za vse slovnice, Grammarly je eno najbolj razširjenih orodij. Ne dobim povračila za to ali kaj podobnega. Je res odlično orodje, ki ga mnogi uredniki in pisci uporabljajo za pisanje čiste in jasne vsebine — podobno kot bi lahko uporabili Emmet, eslint ali kateri koli drug linter za pisanje čiste in jasne kode.

Pisanje komentarjev kode

Stvari, ki jih pišemo za druge razvijalce, imajo lahko velik vpliv na splošno kakovost našega dela, ne glede na to, kaj pišemo v kodi, kako kodo razlagamo ali kako podajamo povratne informacije o delu kode.

Zanimivo je, da ima vsak programski jezik standardni nabor funkcij za pisanje komentarjev. Morali bi pojasniti, kaj koda počne. S tem ne mislim na nejasne komentarje, kot je ta:

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

Namesto tega uporabite komentarje, ki ponujajo več informacij:

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

Vse je odvisno od konteksta. "Kakšen program gradim?" je točno takšno vprašanje, kot bi si ga morali zastaviti.

Komentarji naj dodajo vrednost

Preden pogledamo, kaj pomeni "dober" komentar kode, sta tukaj dva primera lenih komentarjev:

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

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

Ne pozabite, da je namen komentarja dodati vrednost delu kode in ne ponoviti. Če tega ne morete storiti, je bolje, da pustite kodo takšno, kot je. Zaradi česar so ti primeri "leni", je to, da zgolj ponovno navajajo, kaj koda očitno počne. V tem primeru so komentarji odveč, saj nam povedo tisto, kar že vemo – ne dodajajo vrednosti!

Komentarji morajo odražati trenutno kodo

Zastareli komentarji niso redkost pri velikih projektih; upam si reči noter Najbolj projektov.

Predstavljajmo si Davida, programerja in vsestransko kul tipa, s katerim se lahko družimo. David želi razvrstiti seznam nizov po abecedi od A do Ž, zato naredi očitno v JavaScriptu:

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

David nato spozna, da sortWords() dejansko razvršča sezname od Z do A. To ni problem, saj lahko preprosto obrne izhod:

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

Na žalost David ni posodobil svojega komentarja kode.

Zdaj pa si predstavljajte, da vam nisem povedal te zgodbe in da ste videli le zgornjo kodo. Seveda bi pomislili, da bodo po zagonu te druge vrstice kode `mesta` razvrščena od Z do A! Celoten fiasko zmede je povzročil zastarel komentar.

Čeprav je to morda pretiran primer, se lahko (in pogosto tudi zgodi) nekaj podobnega, če tekmujete s tesnim rokom. K sreči je to mogoče preprečiti z upoštevanjem enega preprostega pravila ... spremenite svoje komentarje hkrati, ko spremenite kodo.

To je eno preprosto pravilo, ki bo vas in vašo ekipo rešilo pred marsičim tehnični dolg.

Zdaj, ko vemo, kako izgledajo slabo napisani komentarji, si poglejmo nekaj dobrih primerov.

Komentarji morajo pojasnjevati enodiomatično kodo

Včasih, the naravna način dela ni pravi. Programerji bodo morda morali nekoliko "kršiti" standarde, a ko to storijo, je priporočljivo, da pustijo majhen komentar, ki pojasnjuje njihovo utemeljitev:

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

To je koristno, kajne? Če ste bili odgovorni za pregled te kode, vas je morda zamikalo, da bi jo popravili brez tistega komentarja, ki bi pojasnil, kaj se dogaja.

Komentarji lahko prepoznajo prihodnje naloge

Še ena koristna stvar pri komentarjih je priznati, da je treba opraviti še več dela.

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

Tako lahko ostanete osredotočeni na svoj tok. Pozneje se lahko vi (ali kdo drug) vrnete in to popravite.

Komentarji se lahko vrnejo na vir

Torej, pravkar ste našli rešitev za svojo težavo na StackOverflow. Ko kopirate in prilepite to kodo, je včasih dobro obdržati povezavo do odgovora, ki vam je pomagal, da se lahko nanj vrnete za prihodnjo uporabo.

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

To je pomembno, ker se rešitve lahko spremenijo. Vedno je dobro vedeti, od kod prihaja vaša koda, če se kdaj pokvari.

Pisanje vlečnih zahtev

Zahteve za vlečenje (PRs) so temeljni vidik vsakega projekta. Sedijo v središču pregledov kode. In pregledi kode lahko brez dobrega besedila hitro postanejo ozko grlo pri uspešnosti vaše ekipe.

Dober PR opis povzema kaj se spreminja in zakaj se izdeluje. Veliki projekti imajo predlogo za zahtevo po vleki, kot je ta, prilagojena iz a pravi primer:

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

Izogibajte se nejasnosti PR naslove

Izogibajte se naslovom, ki izgledajo takole:

• Popravi zgradbo.
• Odpravite napako.
• Dodajte obliž.

Te niti ne poskus da opišemo, s katero gradnjo, hroščem ali popravkom imamo opravka. Nekaj ​​dodatnih podrobnosti o tem, kateri del zgradbe je bil popravljen, kateri hrošč je bil odpravljen ali kateri popravek je bil dodan, lahko veliko pripomore k vzpostavitvi boljše komunikacije in sodelovanja s sodelavci. Postavlja ravni in spravlja ljudi na isto stran.

PR naslovi so tradicionalno napisani v velelni čas. So enovrstični povzetek vsega PR, in bi morali opisati kaj izvaja PR.

Tukaj je nekaj dobrih primerov:

• Podprite atribute srcset po meri v NgOptimizedImage
• Privzeta konfiguracija slike na 75-odstotno kakovost slike
• Dodajte eksplicitne izbirnike za vse vgrajene ControlValueAccessors

Izogibajte se dolgim PRs

Velika PR pomeni ogromen opis in nihče noče pregledati na stotine ali tisoče vrstic kode, včasih samo zato, da na koncu opusti celotno stvar!

Namesto tega lahko:

• komunicirajte s svojo ekipo prek Vprašanja,
• narediti načrt,
• problem razdelite na manjše koščke, oz
• delajte na vsakem delu posebej s svojim PR.

Ali ni zdaj veliko čistejše?

Navedite podrobnosti v PR telo

Za razliko od PR naslov, telo je o mesto za vse podrobnosti, vključno z:

• Zakaj je PR končano?
• Zakaj je to najboljši pristop?
• Morebitne pomanjkljivosti v pristopu in ideje za njihovo rešitev, če je to mogoče
• Številka napake ali vstopnice, rezultati primerjalnih testov itd.

Prijava napak

Poročila o napakah so eden najpomembnejših vidikov vsakega projekta. In vsi veliki projekti temeljijo na povratnih informacijah uporabnikov. Običajno, tudi po neštetih preizkusih, uporabniki najdejo največ napak. Uporabniki so tudi veliki idealisti in včasih imajo ideje o funkcijah; prosim, poslušajte jih!

Pri tehničnih projektih se vse te stvari naredijo s poročanjem o težavah. Drug razvijalec zlahka najde dobro napisano težavo in nanjo odgovori.

Na primer, večina velikih projektov prihaja z predlogo:

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

Zberite posnetke zaslona

Zajemite težavo s svojim sistemski pripomoček za snemanje zaslona.

Če gre za posnetek zaslona a CLI programa, se prepričajte, da je besedilo jasno. Če je a UI poskrbite, da posnetek zaslona zajame prave elemente in stanja.

Morda boste morali zajeti dejansko interakcijo, da prikažete težavo. Če je temu tako, poskusite posnemite GIF z orodjem za snemanje zaslona.

Kako ponoviti težavo

Programerjem je veliko lažje rešiti napako, ko je v živo v njihovem računalniku. Zato mora dobra potrditev vsebovati korake za natančno reprodukcijo težave.

Tukaj je primer:

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.

Predlagajte vzrok

Vi ste tisti, ki ste ujeli hrošča, zato morda lahko predlagate nekaj možnih vzrokov, zakaj je tam. Morda se napaka pojavi šele po tem, ko naletite na določen dogodek, ali pa se zgodi le na mobilni napravi.

Prav tako ne more škoditi, če raziščete kodno zbirko in morda ugotovite, kaj povzroča težavo. Potem bo vaša težava veliko hitreje zaključena in verjetno boste dodeljeni sorodnemu PR.

Komuniciranje s strankami

Morda delate kot samostojni svobodnjak ali pa ste glavni razvijalec v majhni ekipi. V obeh primerih recimo, da ste odgovorni za sodelovanje s strankami pri projektu. 

Programerski stereotip je, da smo slabi komunikatorji. Znani smo po tem, da uporabljamo preveč tehnični žargon, drugim govorimo, kaj je in kaj ni mogoče, in se celo branimo, ko nekdo dvomi v naš pristop.

Kako torej omiliti ta stereotip? Vprašajte stranke, kaj si želijo, in vedno poslušajte njihove povratne informacije. Tukaj je opisano, kako to storiti.

Postavite prava vprašanja

Začnite tako, da se prepričate, da ste vi in ​​stranka na isti strani:

• Kdo je vaše ciljno občinstvo?
• Kaj je cilj strani?
• Kdo je vaš najbližji tekmec in kaj počne prav?

Postavljanje vprašanj je tudi dober način za pozitivno pisanje, zlasti v situacijah, ko se ne strinjate s povratnimi informacijami ali odločitvijo stranke. Postavljanje vprašanj to osebo prisili, da podpre svoje lastne trditve, namesto da bi jo napadli z zagovarjanjem svojega stališča:

• Se strinjate s tem, tudi če vključuje dodatne stroške delovanja?
• Ali nam premikanje komponente pomaga bolje doseči naš cilj?
• Super, kdo je odgovoren za vzdrževanje tega po lansiranju? 
• Ali na hitro veste, ali kontrast med tema dvema barvama ustreza standardom WCAG AA?

Vprašanja so veliko bolj nedolžna in spodbujajo radovednost namesto sovraštva.

Prodajte se

Če se boste predstavili bodoči stranki, jo boste morali prepričati, da vas najame. Zakaj naj stranka izbere vas? Pomembno je navesti naslednje:

• Kdo ste
• Kaj delaš
• Zakaj ste primerni za to delo
• Povezave do ustreznega dela, ki ste ga opravili

In ko enkrat dobite službo in morate napisati pogodbo, ne pozabite, da ni vsebine, ki bi bila bolj zastrašujoča kot kopica legalizma. Čeprav je napisan za oblikovalske projekte, je Pogodbeni morilec je lahko lepo izhodišče za pisanje nečesa veliko bolj prijaznega.

Vaša pozornost do podrobnosti je lahko razlika med vami in drugim razvijalcem, ki poskuša pridobiti isti projekt. Po mojih izkušnjah bodo stranke prav tako zlahka najele razvijalca, za katerega mislijo, da bodo uživale pri delu, kot tistega, ki je tehnično najbolj kompetenten ali izkušen za to delo.

Pisanje mikrokopije

Mikrokopija je umetnost pisanja uporabniku prijaznega UI sporočila, kot so napake. Stavim, da ste včasih kot razvijalec morali pisati sporočila o napakah, ker so bila v zadnjem času vse do zagona.

Morda zato včasih opazimo takšne napake:

Error: Unexpected input (Code 693)

Napake so zadnja stvar, s katero želite, da se vaši uporabniki ukvarjajo. Vendar se zgodijo in glede tega ne moremo storiti ničesar. Tukaj je nekaj nasvetov za izboljšanje vaših sposobnosti mikrokopiranja.

Izogibajte se tehničnemu žargonu

Večina ljudi ne ve, kaj je strežnik, medtem ko 100% programerjev ve. Zato ni nenavadno videti neobičajne izraze, zapisane v sporočilu o napaki, kot je API ali »časovna omejitev izvedbe«.

Razen če imate opravka s tehnično stranko ali uporabniško bazo, je verjetno, da večina vaših uporabnikov ni opravila tečaja računalništva in ne ve, kako deluje internet in zakaj določena stvar ne deluje. Zato napaka.

Zato dobro sporočilo o napaki ne bi smelo pojasnjevati zakaj nekaj je šlo narobe, saj bi takšne razlage morda zahtevale uporabo strašnih strokovnih izrazov. Zato je zelo pomembno, da se izogibate uporabi tehničnega žargona.

Nikoli ne krivite uporabnika

Predstavljajte si to: poskušam se prijaviti na vašo platformo. Zato odprem brskalnik, obiščem vaše spletno mesto in vnesem svoje podatke. Nato mi rečejo: "Vaš e-poštni naslov/geslo ni pravilen."

Čeprav se mi zdi dramatično, da je to sporočilo sovražno, se zaradi tega podzavestno počutim neumno. Microcopy pravi, da nikoli ni v redu kriviti uporabnika. Poskusite spremeniti svoje sporočilo v nekaj manj oprijemljivega, kot je ta primer, prirejen iz Mailchimpove prijave: »Oprostite, ta kombinacija e-pošte in gesla ni prava. Pomagamo vam lahko obnoviti račun.«

Rad bi dodal tudi pomembnost izogibanja VSEH VELIKIH ČRK in klicajev! Seveda jih je mogoče uporabiti za izražanje navdušenja, vendar v mikrokopiji ustvarijo občutek sovražnosti do uporabnika.

Ne preobremenite uporabnika

Uporaba humorja v vaši mikrokopiji je dobra ideja! Lahko izboljša razpoloženje in je preprost način za zajezitev negativnosti, ki jo povzročajo tudi najhujše napake.

Če pa ga ne uporabljate popolnoma, se lahko uporabniku zdi prizanesljiv in žaljiv. To je samo a velika tvegati.

Mailchimp dobro pravi:

[N]ak se ne šalite – vsiljeni humor je lahko hujši kot noben. Če niste prepričani, bodite mirni.

(poudarek moj)

Pisanje dostopnih oznak

Z lahkoto bi porabili cel članek o dostopnosti in njeni povezavi s tehničnim pisanjem. Hudiča, dostopnost je pogosto vključena v vodnike po slogu vsebine, vključno s tistimi za Microsoft in MailChimp.

Ste razvijalec in verjetno že veste toliko o dostopnosti. Morda ste celo eden bolj marljivih razvijalcev, ki naredi dostopnost ključni del vašega delovnega toka. Kljub temu je neverjetno, kako pogosto so vidiki dostopnosti postavljeni na stranski tir, ne glede na to, kako pomembno vsi vemo, da je narediti dostopne spletne izkušnje, ki vključujejo vse zmožnosti.

Torej, če ugotovite, da v svojo kodo izvajate pisanje nekoga drugega, pišete dokumentacijo za druge razvijalce ali celo pišete UI kopirajte sami, bodite pozorni na nekatere temeljne najboljše prakse dostopnosti, saj zaokrožujejo vse druge nasvete za tehnično pisanje.

Stvari, kot so:

Andy Bell ponuja nekaj relativno majhne stvari, ki jih lahko naredite, da bo vsebina bolj dostopna, in vredno je vašega časa, da jih preverite. In samo za zabavo, John Rhea pokaže nekaj lepih trikov za urejanje ki so možni, ko delamo s semantičnimi elementi HTML.

zaključek

To je bilo šest načinov, ki dokazujejo, kako tehnično pisanje in razvoj sovpadata. Čeprav primeri in nasveti morda niso znanstveni, upam, da so se vam zdeli koristni, ne glede na to, ali gre med drugim za sodelovanje z drugimi razvijalci, vzdrževanje lastnega dela, pisanje lastne kopije ali celo pripravo predloga projekta. stvari.

Zaključek: če izostrite svoje pisne sposobnosti in vložite malo dodatnega truda v svoje pisanje, lahko dejansko postanete boljši razvijalec.

Sredstva za tehnično pisanje

Če vas zanima tehnično pisanje:

Če vas zanima pisanje besedil:

Če vas zanima mikrokopiranje:

Če vas zanima uporaba profesionalnega slogovnega vodnika za izboljšanje vašega pisanja:

Če vas zanima pisanje o dostopnosti: