Přejít k navigační liště

Zdroják » Zprávičky » Co byla největší chyba, kterou jste při vývoji webu udělali?

Co byla největší chyba, kterou jste při vývoji webu udělali?

Zprávičky Různé

Nálepky:

Přesně tuto otázku položili svým čtenářům ve Smashing Magazine. Odpovědi svých followerů shrnuli a roztřídili do několika kategorií – „nepozornost“, „nevhodný nástroj“ atd. Je to velmi zajímavé a poučné čtení, při kterém se jen těžko ubráníme vzpomínkám na vlastní chyby.

Schválně – jakou chybu jste udělali vy? Podělte se v komentářích nebo na Twitteru, můžeme je pak porovnat s těmi, co udělali čtenáři Smashing Magazine.

Komentáře

Subscribe
Upozornit na
guest
10 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
v6ak

rm -r templates/* místo rm -r temp/*. Naštěstí to nebylo až tak kritické.
Po předchozím programátorovi jsem jednou nechal v tabulce pár nesmyslných tinyintů. To jsme se divili, když některým uživatelům se nešlo přihlásit do turnaje. Naštěstí jsem si brzy všiml, že zatímco uživatelé s tisícovými id si stěžují, uživatelé se nízkým id se bez problému přihlašují.
Jednou jsem dělal takovou nepříjemnou poloautomatickou procedurou import z docu do DB (převod do „jednoduchého“ HTML, pár regulárů, převod do txt a pak automatika s nějakými parametry). Bohužel, občas jsem se spletl, tak jsem si otevřel konzoli a pak mazal a importoval znovu. Vzhledem k tomu, že některé záznamy v databázi byly trošku divné, chtěl jsem je podle určitých charakteristik vybrat. Nepsal jsem dotaz znovu. Jen jsem párrát stiskl šipku nahoru a upravil dotaz pracující se správnou tabulkou. Bohužel, dotaz nezačínal SELECT * FROM, ale DELETE FROM. Tak jsem to mohl celé smazat a importovat znovu.
Nedávno jsem chtěl ponechat k danému záznamu pouze prvních, řekněme, 16 prvků:

DELETE
    FROM table
    WHERE
        id NOT IN (
            SELECT id
                FROM table
                WHERE foreign_id = ?
                LIMIT 16
        )
---/
Podmínka na foreign_id ve WHERE i DELETE však bohužel chyběla. 
blizzboz

najvačšia chyba bola že som sa vôbec vývoju webu začal venovať

dc

tak pod toto sa tiez podpisujem. Kolko krat si vravim ze zlaty desktop vyvoj, bojovanie s kompilerom a nativnym api.Aj ked clovek si vecsinou pameta to dobre ale aj tak.
Dnes je cely web devel totalny maglajz.

kraag

Zdravim,
moje nejvetsi chyba, kterou jsem zatim stvoril, byla v systemu na rozesilani emailu. Zpusobila ze newsletter se misto jednou asi 2–5 tisicum lidem posilal stale dokola. Nez sem si toho vsiml, tak nekomu prisel i 20× ;)

blaaablaaa

Stalo se mi neco podobneho. Tim, ze jsem neoveroval spravnost emailu, mi phpmailer pri kazdem spusteni vyhazoval vyjimku (spousteno cronem), takze jsem dalsi den zjistil, ze se to nekterym lidem poslalo asi 100krat :D

ITGuru

Tak přesně toto se mi taky stalo :-) naštěstí však na vývojové verzi webu. Šlo o newsletter pro cca 1000 lidí. Rozesílám samozřejmě cyklem a zapomněl jsem volat metodu pro vymazání adres v poli příjemců. Prvnímu tedy přišel mail, do příjemců se PŘIDAL následující mail atd. Takže prvnímu člověku by v ostrém provozu přišel newsletter tolikrát, kolik tam bylo zaregistrovaných lidí – tj. cca 1000× – druhému 999× atp. Jedinému poslednímu by to došlo jednou. Dost dlouho jsem si toho nevšiml – až těsně před spuštěním – doteď mě z toho mrazí :-)

Ale v ostrém provozu jsem kdysi udělal taky pěkný kousek. Vadným SQL dotazem jsem vyrobil nádherný kartézák (kartézský součin) o desítkách milionech záznamů. Spolehlivě to sejmulo celý server, protože to byl velmi frekventovaný web.

Khaz

toto sa nepodarilo priamo mne, ale kolega, programator zmazal nejakym zazrakom cely server :)

Srigi

Pisal som to uz na twitter – nie celkom uplny #fail ale mozno zle rozhodnutie bolo nasadenie NoSQL (MemcacheDB) pri zlom vykone MySQL.
Bol to strom (nested-set), kde kazda noda mala asociacie do asi dalsich troch tabuliech. Render stromu bol neoptimalizovany (cez kniznicu a AR pattern), takze vykreslenie stranky generovalo cca 350–400 SQL dotazov.
Pomerne zbrklo sme rozhodli, ze nasadime NoSQL. Ako vravim, nebol to uplny fail, lebo aplikacia sa zrychlila 65×, ale cca 2 tyzdne som programoval, to co uz existuje v kode MySQL – fetchovanie, asociacie, autogenerovanie ID atd.
Dost zle rozhodnutie bolo pouzit MemcacheDB – IMHO mali sme radsej nasadit dokumentovu DB (Mongo, Couch).

Ladislav Thon

Můžu vědět, proč nešlo ten vyrenderovaný strom (nebo aspoň už načtenou objektovou strukturu) normálně cachovat (memcached by víc než stačilo a in-process cache by byla úplně ideální)?

tiso

Pár rokov dozadu som robil redesign firemného webu a komplet som pomenil url. Do toho sa ešte menila doména (tú mal dovtedy zaregistrovanú špekulant). Na pôvodnú návštevnosť sme sa dostali po roku. Odvtedy už takéto chyby nerobím, už len menšie.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.