Výhodou Thajska je, že je tady takový vedro, že si dobře rozmyslíte skutečný přínos toho, co děláte, než se do toho pustíte.
V Praze bych se třeba upnul na technické řešení, a pustil bych se do nějakého nesmyslného refaktoringu, který by mi zabral 4h a jediný přínos by byl, že bych měl hezčí kód. A jelikož nejsem prase, a kód píšu dostatečně hezký rovnou, tak by to zlepšení bylo asi o 2%.
V Thajsku si řeknu: Vydělá mi to víc peněz? Ne. Přinese to něco uživatelům? To už vůbec ne. Celkový přínos nula-nula nic. Takže úplná zbytečnost. Jak psal John Vanhara v knize Podnikání v USA: „Soustřeďte se na to, co vám první přinese peníze“ a to refactoring prostě nebude nikdy 🙂
Místo toho radši napíšu nějaký článek, připravím tiskovou zprávu, rozkreslím si svůj nový nápad do wireframů… prostě mám mnohem větší focus na věci, které moje podnikání někam posouvají a naopak neřeším věci, které, upřímně, nejsou důležité.
PS: A kdo do komentáře napíše něco o důležitosti refactoringu, tak je akademický teoretik, kterého bych nikdy nezaměstnal 😉
Refaktoring je důležitý. 🙂
A nikdy bych nezaměstnal člověka, který nerefaktoruje.
S tim samozrejme souhlasim. Ale:
1) Nikdy dopredu nevis, kam se tvuj kus kodu (featura) bude rozvijet -> refaktoringu se nevyhnes, protoze ten produkt meni sve pozadavky
2) Vznika ti technicky dluh, pokud jen nabusis kod, ktery si aspon jednou neprojdes znovu. Kdyz se ve skole psali pisemky, myslim, ze bylo vhodnejsi to znovu projit, protoze reseni uz jsi mel vymysleno, jen jsi ho mohl lepe zoptimalizovat, ci prijit na bug 🙂
3) Ono se rika, ze prvni reseni, co te hned napadne je vetsinou to nejlepsi. ANO RESENI. ne postup. Proto si troufam rict, ze kdyz se nabusi prvni kod, a programator si ho znovu projde, tak objevi, ze nektery veci se daji treba zjednodusit ci dokonce vypustit.
4) I kdyz udelas sebelepsi architekturu, tak vzdy narazis na kusy kodu, ktere se treba opakuji a musis je vyclenit. A nemusis byt ani prase bez zkusenosti, co nevi, jak psat kod. -> refaktoring
5) Kdyz vznika nova vec, tak kolikrat ani nevis, ktere featury budes vlastne potrebovat, dokud ti to „tvuj“ trh neukaze. A najednou zjistis, ze to pro co jsi udelal prvnotni architekturu, ti vlastne vubec nestaci a musis to treba cele predelat.
Tot zatim asi vse. Mozna na neco vic prijdu, protoze na soucasnem produktu, ktery se meni rychlosti blesku se refaktoruje ostosest. Duvody? viz bod 5
Mej se a at se v tom thajsku neuvaris 🙂
Jsem zapomnel napsat s cim, ze to souhlasim 🙂
„Soustřeďte se na to, co vám první přinese peníze“
Abych to uvedl na pravou míru: Nejsem proti refactoringu, který bude mít nějaký přínos. Ideálně aby se dalo kladně odpovědět na jednu z výše uvedených otázek.
Bral bych „Kód bude přehlednější a díky tomu se sníží počet chyb na polovinu“ nebo „…a díky tomu se zvýší velocity týmu o 10 story pointů“ a běda jestli ne 🙂
Ale pouze „kód bude hezčí, jednotnější, přehlednější“ mi přijde slabé. To je potom dělání věcí pro věci.
Tak po tomto dodatku již mohu souhlasit :-).