API-të më të mira duken të vetëkuptueshme kur i shikon prapa. Thërret një metodë, ajo bën të vetmen gjë që premton emri i saj dhe vazhdon të sillet ashtu përgjatë një duzine versionesh. Ai besueshmëri nuk është fat. Është rezultat i një grushti vendimesh të marra herët dhe të mbrojtura me kalimin e kohës.

## Emërto gjërat për thirrësin, jo për implementimin

Një API është një premtim i shkruar në emrat e metodave. Kur e emërton një funksion sipas mënyrës se si punon nga brenda, çdo ristrukturim rrezikon ta thyejë atë premtim. Emërto sipas asaj që dëshiron thirrësi, dhe implementimi mbetet i lirë të ndryshojë poshtë tij.

Testi është i thjeshtë: lexoje me zë vendin ku bëhet thirrja. Nëse një koleg i ri mund të hamendësojë çfarë ndodh pa e hapur kodin burimor, emri po e bën punën e vet.

## Bëje rastin e zakonshëm pa mundim

Shumica e thirrësve duan të njëjtën gjë pjesën më të madhe të kohës. Dizajnoje rrugën e paracaktuar që të mos kërkojë asnjë konfigurim, pastaj shto opsione sipër për rastet e rralla. Një API që kërkon pesë parametra për një detyrë rutinë do të mbështillet në një ndihmës nga ekipi i parë që e përdor, dhe tani mban dy ndërfaqe në vend të njërës.

> Çdo argument i detyrueshëm është një taksë e vogël që ngarkon në çdo thirrje të vetme. Ngarkoje vetëm kur vlera vërtet nuk mund të nënkuptohet.

## Versiono kontratën, jo kodin

Ndryshimet që prishin përputhshmërinë nuk janë armiku. Surpriza është. Kur duhet të prishësh diçka, jepi një emër të ri ose një version të ri dhe lëre rrugën e vjetër të vazhdojë të punojë përgjatë një dritareje të qartë vjetërsimi. Thirrësit do ta falin një migrim që mund ta planifikojnë. Nuk do ta falin një ndryshim të heshtur që prish prodhimin një të martë.

Një API që plaket bukur është ai për të cilin mund të pushosh së menduari. Ndërtoje ashtu që edhe njerëzit që varen prej tij të munden po ashtu.

Dizajnimi i API-ve që Plaken Bukur

Askush nuk cakton një takim për kohën e ndërtimit. Ajo rritet ngadalë, një varësi pas tjetrës, derisa një rindërtim i plotë të jetë aq i gjatë sa të justifikojë shikimin e telefonit. Ajo pauzë duket e padëmshme. Nuk është.

## Konteksti është ajo që në të vërtetë humbet

Kur një ndërtim zgjat tridhjetë sekonda, ti qëndron brenda problemit. Kur zgjat tre minuta, ti largohesh. Ndron skedat, lexon një mesazh, ndjek një lidhje, dhe kur ndërtimi mbaron duhet të rindërtosh modelin mendor që sapo e le. Kostoja në orë muri është minuta. Kostoja e vërtetë është ringarkimi.

## Ndërtimet e ngadalta ndryshojnë sjelljen

Ekipet përshtaten me reagimin e ngadaltë në mënyra që e bëjnë kodin më të keq. Ata grumbullojnë së bashku ndryshime të patestuara sepse ekzekutimi i ciklit është i kushtueshëm. Ata anashkalojnë ristrukturimin e vogël sepse nuk ia vlen edhe një pritje tjetër. Ata pushojnë së shkruari eksperimentin e shpejtë që do t'i kishte dhënë përgjigje një pyetjeje me kod në vend të një debati.

> Shpejtësia e ciklit tënd të reagimit përcakton madhësinë e ndryshimit më të vogël që dikush është i gatshëm të bëjë.

## Trajtoje si një metrikë të klasit të parë

Mate kohën e ndërtimit dhe testimit ashtu si mat kohën e disponueshmërisë. Vendose në një panel. Vendos një buxhet dhe mbroje gjatë rishikimit. Kur një ndryshim e shtyn ndërtimin përtej buxhetit, ajo është një kosto e vërtetë për t'u peshuar, jo një gabim rrumbullakimi për t'u shpërfillur.

Ndërtimet e shpejta nuk janë luks për ekipet e mëdha. Ato janë themeli që i lejon një ekipi të vogël të vazhdojë të lëvizë si një ekip i vogël.

Kostoja e Vërtetë e një Ndërtimi të Ngadaltë

Pyet një inxhinier se si përmirësohet dhe do të flasë për shkrimin e më shumë kodit, ndërtimin e projekteve anësore, mësimin e një gjuhe të re. Pothuajse askush nuk thotë se ushtron leximin. E megjithatë, në çdo ekip real, leximi është puna. Ti lexon për të rishikuar, për të gjetur gabime, për të kuptuar atë që je gati të ndryshosh.

## Fillo me formën para detajeve

Kur hap një skedar të panjohur, përmbaju dëshirës për ta lexuar nga lart poshtë. Së pari shfleto për strukturën. Cilat janë eksportet kryesore? Ku hyjnë të dhënat dhe ku dalin? Një hartë e shpejtë e formës bën që detajet të gjejnë vend në vend që të grumbullohen.

## Ndiq një rrugë deri në fund

Zgjidh një skenar të vetëm realist dhe gjurmoje nga fillimi në fund. Një kërkesë, një klikim, një hyrje. Ndjekja e një rruge konkrete të mëson më shumë sesa leximi i çdo dege, sepse të tregon çfarë ndodh në të vërtetë në vend të gjithçkaje që mund të ndodhë.

> Nuk e kupton një sistem derisa të mund të parashikosh çfarë do të bëjë me një hyrje që nuk e ke parë kurrë.

## Lexo me qëllim kod që admiron

Lër mënjanë kohë për të lexuar një bibliotekë të ndërtuar mirë ashtu si do të studioje një shkrim të mirë. Vër re si i emërton gjërat, ku vendos kufijtë, çfarë zgjodhi të mos bënte. Do të thithësh modele që mund t'i përdorsh më vonë pa qenë nevoja t'i rishpikësh nën presion.

Leximi nuk është pjesa pasive e inxhinierisë. Është aty ku në të vërtetë ndodh pjesa më e madhe e të kuptuarit. Jepi të njëjtin ushtrim të qëllimshëm që i jep çdo gjëje tjetër, dhe edhe shkrimi bëhet më i lehtë.

Inxhinieri

Dizajnimi i API-ve që Plaken Bukur

Kostoja e Vërtetë e një Ndërtimi të Ngadaltë

Leximi i Kodit Është një Aftësi që Mund ta Ushtrosh