Proč se projekty s vlastním týmem zasekávají?

Neignorujte chybová hlášení. Podrobná chybová zpráva z databáze prozradí názvy tabulek, sloupců i typy dat a útočníkovi výrazně usnadní další postup. V produkčním prostředí proto zapněte obecné chybové stránky a podrobnosti logujte pouze na server. Totéž platí pro ladící nástroje, které nesmí být veřejně dostupné.

Parametrizované dotazy místo slepování řetězc

Praktický krok: zaveďte krátký týdenní stav, kde každý řekne, co dokončil, co ho blokuje a co potřebuje. Ne délku, ale konkrétní překážku. Pokud se stejná překážka objeví dvakrát, řešte ji jako systémový problém, ne jako osobní selhání. Dále je nutné ohlídat, aby se interní tým nerozpadl do příliš mnoha malých úkolů. Méně větších celků se dokončuje lépe než hromada drobností.

U dávkového vkládání a hromadných aktualizací se často objevuje jiná chyba: aplikace spojí více hodnot do jednoho dotazu a zapomene, že počet parametrů musí odpovídat počtu zástupných symbolů. Pokud se počet neshoduje, vývojář sáhne po ručním skládání a tím vrátí injektáž zpět do hry. Bezpečnější je zpracovat dávku po menších částech nebo použít jeden připravený dotaz v cyklu, i za cenu mírně vyšší režie.

Nakonec myslete na zálohu a sdílení. Lokální repozitář je fajn, ale poškozený disk znamená konec. Nastavte si vzdálený repozitář, kam budete pravidelně nahrávat změny. I když pracujete sólo, získáte tím klid a možnost pracovat z jiného počítače. Před každým nahráním si projděte, co přesně odesíláte, ať neposíláte rozdělanou práci nebo citlivá data. Verzování není jednorázový úkol, ale návyk. Čím dřív ho přijmete za vlastní, tím méně času strávíte hašením požárů a tím víc prostoru zbyde na skutečné programování.

První commit by měl obsahovat základní kostru projektu. Pak už postupujte po malých krocích. Každá změna, která dává smysl sama o sobě, si zaslouží vlastní commit s výstižnou zprávou. Vyhněte se hromadným commitům typu „oprava" nebo „úpravy". Zprávy pište v rozkazovacím způsobu a snažte se do první řádky vejít do padesáti znaků. Větší celek pak popište v delším textu. Díky tomu se v historii vyznáte i po měsících a snadno dohledáte, kdy a proč se něco změnilo.

Jak uspořádat první repository, aby se v něm dalo vyznat Než začnete verzovat, rozhodněte se, co všechno má být součástí repozitáře. Do něj patří zdrojové kódy, konfigurační soubory bez citlivých údajů a dokumentace. Naopak nikdy necommitujte hesla, přístupové klíče, složku s nainstalovanými závislostmi ani vygenerované soubory. Vytvořte soubor .gitignore a vypište do něj všechny cesty, které mají zůstat stranou. Tím předejdete tomu, že se do historie dostane něco, co budete muset složitě mazat. Pokud už se citlivý údaj do repozitáře dostal, nestačí ho přepsat novým commitem – musíte historii přepsat nebo klíč okamžitě zneplatnit.

Většina vývojářů dnes ví, že se mají vyhýbat skládání SQL dotazů pomocí řetězců. Přesto se SQL injection drží na předních příčkách chyb v bezpečnosti webových aplikací. Důvod není neznalost základního pravidla, ale to, že se injektáž často schová tam, kde ji nikdo nečeká: v dynamicky sestavovaných klauzulích ORDER BY, v názvech tabulek nebo v dávkovém zpracování. Tam parametrizace v tom nejběžnějším slova smyslu nefunguje, protože databázový engine nedovolí předat identifikátor jako parametr.

Další častá chyba je absence rozhodčího. Když se tým nedohodne, projekt stojí. Někdo musí mít poslední slovo a musí být jasné, kdo to je. Není to o hierarchii, ale o tom, že bez rozhodnutí se práce hromadí. Zároveň je dobré předem určit, co se stane, když se něco nestihne. Bez plánu B se každé zpoždění mění v krizi.

Projekty s vlastním týmem nepadají na nedostatku schopností, ale na nedostatku hranic, rozhodnutí a průběžné kontroly. Kdo si tyto tři věci nastaví předem, mívá projekt hotový v rozumném čase i bez externí pomoci.

Verzování není jen nástroj pro velké týmy. Pokud píšete webový kód, ať už jde o statickou stránku, PHP skript nebo jednoduchou aplikaci v JavaScriptu, sledování změn vám dřív nebo později ušetří hodiny práce. Představte si, že jste včera přepsali funkci pro nahrávání obrázků a dnes zjistíte, že rozbila přihlašování. Bez verzování nemáte jak zjistit, co přesně se změnilo, ani jak se vrátit k funkční verzi. Systém správy verzí je záchranná brzda, která se vyplatí i pro jednotlivce.

První věc, kterou je potřeba udělat ještě před startem, je oddělit projekt od rutiny. Znamená to pojmenovat, kdo je za co odpovědný, a hlavně kolik času na to skutečně má. Pokud člověk dělá na projektu vedle své každodenní agendy, musí být tento čas explicitně vyčleněný. Bez toho se projekt posouvá vždy až na druhé místo. Typická chyba je spoléhat na to, že to lidé nějak zvládnou. Nezvládnou.