Když data přicházejí od uživatelů, ověřte meze dřív než logiku

Hranice nejsou jen minimum a maximum Klasická chyba je otestovat hodnoty uvnitř rozsahu a pak až hodnoty výrazně mimo. Skutečné chyby se schovávají přesně na hranici: hodnota o jedna nižší než minimum, přesně minimum, přesně maximum, o jedna vyšší než maximum. U pole s pěti znaky zkuste čtyři, pět a šest znaků. U čísla od 1 do 100 zkuste 0, 1, 100 a 101. Přidejte nulu, prázdný řetězec, samé mezery a hodnotu null, protože každá z nich se v kódu chová jinak.

Základem je rozklad. Místo „nastuduji a napojím platební bránu" vytvoř dílčí kroky: projít dokumentaci, připravit testovací prostředí, napsat adaptér, ošetřit chybové stavy, otestovat scénáře. Každý krok by měl být tak malý, aby se dal odhadnout v řádu hodin, ne dní. Pak sečti optimistický a pesimistický odhad a vezmi vážený průměr. Tento postup nutí přemýšlet o tom, co všechno se může pokazit, a odhalí skrytou práci, kterou bys jinak přehlédl.

Poslední věc, kterou začátečníci podceňují, je velikost a pořadí vrstev. Každý příkaz v souboru pro sestavení obrazu vytváří novou vrstvu. Když nejdřív zkopírujete celý projekt a teprve potom nainstalujete závislosti, při každé změně jediného souboru se závislosti instalují znovu. Stačí nejdřív zkopírovat jen seznam závislostí, nainstalovat je a teprve potom zkopírovat zbytek. Ušetříte čas i místo na disku.

U čísel nezapomínejte na dělení nulou, přetečení a podtečení, u desetinných čísel na zaokrouhlování. U datumů na přestupný rok, konec měsíce a přechod letního času. U souborů na prázdný soubor, příliš velký soubor a soubor se špatným kódováním. Testujte i to, co na první pohled nemá smysl: znaky s diakritikou, emoji, vložené uvozovky a středníky, protože právě ty odhalí chybějící escapování nebo neošetřenou injektáž.

Odhad času v softwarovém projektu není věštění. Je to rozhodnutí učiněné s neúplnými informacemi a jeho kvalita závisí hlavně na tom, jak dobře rozložíš práci a jak poctivě přiznáš nejistotu. Většina týmů neodhaduje špatně proto, že by byla neschopná, ale protože odhaduje velké celky najednou a do výsledku započítává jen „čistý" čas programování.

Častá chyba je záměna typu. Prohlížeč tiše převede řetězec na číslo nebo naopak, a výsledek vypadá skoro správně. Porovnávejte přesně a kontrolujte, zda funkce vrací to, co skutečně očekáváte. U pole ověřte, zda nejde o prázdnou hodnotu, než zavoláte metodu — jinak dostanete chybu, která ukazuje na jiné místo, než kde vznikl problém.
Nakonec testy zautomatizujte. Ruční ověřování hranic se při každé změně zapomene. Napište sadu případů, která se spouští opakovaně, a doplňte ji pokaždé, když najdete novou chybu. Tím se z jednorázového testování stane trvalá ochrana a vy přestanete řešit stejné vstupy znovu.

Začni vztažnými body. Nastav si základní škálu odstupů, typicky násobky čtyř nebo osmi pixelů, a drž se jich všude — osvětlení v obýváku paddingu, marginech, mezerách mezi prvky. Náhodné hodnoty jako 13 px nebo 27 px vytvářejí chaos, který oko zachytí, i když si ho nikdo neumí pojmenovat. Stejně tak si definuj tři až čtyři velikosti písma pro nadpisy, tělo textu a popisky. Víc úrovní znamená, že se hierarchie rozpadne a uživatel nepozná, co je důležité.

Rezervy nejsou slabost, úložné prostory v malém bytě ale pojistka Do každého úkolu přidej rezervu na komunikaci, čekání na odpovědi, code review a opravy po testech. Realisticky to bývá 30 až 50 procent hrubého času. Pokud má tým více projektů nebo podporu, připočti i přepínání kontextu. Vyhni se tomu, že rezervu schováš do jednoho velkého úkolu na konci; rozlož ji rovnoměrně, aby byla vidět a dala se kontrolovat.

Po dokončení etapy porovnej skutečný čas s odhadem a zapiš, kde vznikl rozdíl. Z těchto poznámek vzniká kalibrace: příště víš, že integrace třetí strany obvykle trvá dvakrát déle, než se zdá. Odhady se nikdy netrefí přesně, ale s každou iterací se zmenšuje prostor pro nepříjemná překvapení.

Před každým větším refaktoringem mějte uložený stav v systému správy verzí. IDE sice obsahuje lokální historii, ale ta není náhradou za commit. Pracujte po malých krocích a po každém spusťte testy nebo alespoň kompilaci. Zabráníte tomu, abyste po hodině zjistili, že jste rozbili něco, co jste vůbec neměnili.
Nejčastější chyby: odhadovat podle nejlepšího možného scénáře, zapomínat na schůzky a administrativu, slibovat termín před analýzou a tlačit na zkrácení odhadu, aby projekt „prošel". Další pastí je srovnávání s jiným projektem, který byl jiný rozsahem i týmem. Pokud odhad měníš, dělej to na základě nových zjištění, ne na základě přání.
If you have any concerns pertaining to where and how to use http://crativ.co.Kr/, you can contact us at our own web-site.