Cowboy coding - ďábel mezi českými programátory

Web vyrostl na PHP... - Špatně. Jenom je PHP jazyk nejjednodušší na naučení, proto se do něj pouští tolik lidí. Na malé projekty padne slušně, ale cokoliv většího je pak boj (viz. proč se používá tolik různých frameworků a knihoven).

I pokud dostane programátor projekt vypracovat sám, měl by vždy používat nějaký systém na verzování kódu (SVN nebo GIT). K tomu si pak přibalit nějaký systém na psaní ticketů o chybách nebo něco podobného a máte slušný základ.

Jako dokumentace, by u malých projektů mělo stačit podrobné zadání s požadavky.
Možná pokud máte hodně času a nevíte co s ním, můžete začít psát UNIT testy na nejdůležitější součásti programu.

Ve zkratce - dá se, ale musíte se naučit s dalšími nástroji. Na malý projekt o jediném člověku se to spíš nevyplácí, ale je nutné si ve věcech "držet pořádek".

Jestli má cenu v takové firmě pracovat záleží na každém; obecně se nedá říct.
Ne každý šéf má IT vzdělání a nemůže všechno vědět. Je tedy na programátorovi, aby ho informoval o možných technologiích a co implementace přinese a bude stát.
Taky je možný, že šéf o problému neví a měl by sis s nim o tom popovídat. Pokud ti i nadále bude jeho postup vadit, tak můžeš jít jinam.

FilipProgramator:
„má ale cenu v takové firmě pracovat?“
Nemá. Evidentně máš zkušenosti, které nepoužíváš - např. tu analýzu kódu.

„Neměla by to sama vynucovat?“
Měla. Ale na druhou stranu sám programátor se musí stále ptát, co a jak má fungovat, atd. atd. - nelze programovat něco dle své vlastní libovůle. Pokud ti šéf není schopen dodat požadavky, co a jak má fungovat, tak to je špatné...

Vždycky si řekni - dostal jsem za projekt takovou sumu, kterou jsem chtěl a která byla úměrná ke strávené práci? Jestli ne (např. že strávená práce byla vyšší), tak jdi pryč...

FilipProgramator:
„má ale cenu v takové firmě pracovat?“
To záleží na povaze každého, někomu takový styl práce může i vyhovovat. Možná důležitý faktor by byl, nakolik se šéf nechá poučit o tom, jak by měl proces vývoje softwaru vypadat.
Druhá věc je, že úplně dokonalý proces podle učebnic nefunguje snad nikde, takže v jiné práci to může být podobné. Ani to, že vývoj probíhá nahodile a žádný definovaný proces neexistuje, ještě nemusí být to nejhorší s čím se lze setkat, viz Capability Immaturity Model.
(Třeba CIMM -1 asi není těžké si představit: Existuje definovaný proces, ovšem nevhodně a neefektivně navržený, přičemž zaměstnanci nejsou hodnocení podle výsledků své práce, ale podle toho, jestli se striktně drží procesu)

„ve firmě dostanu vlastní projekt, o kterém rozhoduje šéf, který kontroluje až klient (není čas udělat testování a když to dělám - "jak to že to trvá tak dlouho?!")“
Předpokládám, že někde na začátku máte odhadnout, jak dlouho to bude trvat.
Neříkáte tedy moc optimistické časy? Pokud to máte dělat celé sám, prostě započítejte čas na analýzu a testování do odhadu.

„Po dokončení projektu se ozve klient, že to chtěl vlastně jinak“
Tak to je celkem normálka :-)
Pro takový případ je klíčová existence nějaké smlouvy či objednávky, kde by bylo napsané, co zákazník dostane. Do projektu s nejasným vágně definovaným zadáním bych šel leda kdybych dostal zaplacené i případné dodatečné práce.
Když takové zadání existuje, jsou zhruba tyto varianty:
• V zadání to nebylo → Požadavek nad rámec zadání, uděláme, když si to zákazník zaplatí.
• V zadání to bylo, ale v předané aplikaci to není → Chyba programátora, nesplnil zadání.
• Zadání je formulované nejasně a klient to pochopil jinak než programátor → Chyba analytika, resp. toho, kdo připravoval to zadání. Programátor to může zmírnit tím, že se během vývoje bude na sporné body ptát.