Ako rýchlo zistiť kvalitu firmy alebo vývojového tímu? rubrika: Folklór
2
lehotsky
Zdravím,
osobne sa považujem za človeka, ktorému záleží na tom, čo robí. Keď už si nejaký ten modul programujem, tak chcem, aby mal určitú úroveň kvality; dobrý návrh a čistota kódu sú pre mňa veľmi dôležité. Obzvlášť potom v projektoch, kde je nutná nejaká spolupráca viacerých ľudí (väčšina), pretože čítať po niekom (aj po sebe) prasácky kód je horšie ako trieskať hlavou o stenu :).
Žiaľ doteraz všetky moje pracovné skúsenosti boli v tomto ohľade negatívne. Robil som predovšetkým v malých firmičkách, ktoré vyvíjali software na zakázku a prístup k práci bol "nejak to urob, na kvalitu kašli, my už to nejak odprezentujeme". Hlavne, aby to zákazník odkýval, a čo už bolo odkývané nemalo význam zlepšovať (napr. refaktorovať). Samozrejme ako rástol technický dlh, tak vždy s postupom času problémy narastali.
Už som popravde unavený z toho riešiť problémy spôsobené lajdavosťou a laxným prístupom k práci a viem, že do dalšej podobnej firmy už nevleziem.
V blízkej dobe si budem hľadať prácu a preto som sa chcel spýtať, aké otázky na interview by som mal klásť ja firme, aby som čo najlepšie vyradil podobné firmy, kde kvalita hrá druhé (tretie, štrvté?) husle. Našiel som 12 otázok, tzv. Joel Test (http://www.joelonsoftware.com/articles/fog0000000043.html), ktoré ma naviedli správnym smerom, ale zaujímalo by ma, čo by ste mi odporučili aj vy, na základe vašich skúseností :). Aby som to najdôležitejšie proste nezabudol (zaujíma ma všetko od manažmentu, vývoja, až po zdravé medziľudské vzťahy).
Tiež máte pocit, že takéto firmy prevládajú práve v prostredí, kde sa vyrábajú projekty na zakázku? Zdá sa mi, že firmy, ktoré vyvíjajú niečo pre seba k tomu budú pristupovať zodpovednejšie ako, keď sa to vyvíja pre niekoho iného, ale možno sa mýlim.
Díky :).
10
jiri.knesl
Obvykle nejhezčí zdrojáky mívají malé firmy, které dělají produktový vývoj na vlastní službě, kterou nedistribuují k zákazníkům.
Každá firma má nějakou historii a nějaké plány pro budoucnost.
Firmy s historií obvykle s sebou táhnou legacy kód plný překonaných myšlenek, starých knihoven, mrtvého kódu.
Firmy, které dělají zakázky, obvykle plánují dostat peníze co nejdřív a tak se snaží co nejrychleji dostat k cíli za cenu toho, že omezují refaktoring, testování, apod. Takové mají třeba moderní technologie, ale v kódu je nepořádek.
Pouze ty firmy, které dokážou efektivně pracovat se svou codebase (což dokážou spíš menší firmy) a které zároveň chtějí (tzn. buď dělají vlastní produkt, nebo mají osvíceného zákazníka), můžou mít pěkný zdroják.
Komentáře
-
pussy
:
"kód plný překonaných myšlenek" - To i nové firmy a nové projekty. Většina myšlenek, co se používá dnes v praxi, byla zastaralá už před několika lety. Příkladem jsou věci jako MapReduce, NoSQL nebo OOP. Většina firem to totiž začne používat až poté, co se to někomu osvědčí a v té době už často existuje něco lepšího. Navíc většina firem nepoužívá kvalitní věci, ale věci, co mají dobrou reklamu.
—
15.5.2015
-
Taco
:
@pussy: zcela vážně: čím jsou překonány Map/Reduce? co je dle tebe následníkem?
—
15.5.2015
-
pussy
:
MapReduce je velmi nízkoúrovňový. IMO budoucnost je v "deklarativnějších" systémech, kde neřešíte, jak to spočítat, ale co spočítat, a které sami provedou překlad a optimalizaci třeba do MapReduce.
—
15.5.2015
-
voidplace1
:
Úžasně shrnuto, podepisuju :). Zrovna nedávno jsem si říkal, proč vlastně velký firmy často chtějí znalost state of the art technologií, když vás pak zapřáhnou do legacy projektu, který před deseti lety napsali dva Indové a po sérií hrdinných sebevražd se ho podařilo přeportovat z PHP 4 na PHP 5. Dostávám se mimo otázku, nicméně zatím všechny dobře placený joby co jsem dělal byly krajně neuspokojivý technologicky / architektonicky, ale vlastně mi to nakonec dramaticky nevadilo, protože složitost byla většinou v tom dobře porozumět dané byznys doméně, procesům ve firmě a umět participovat tak, aby se plnily byznys cíle. V malý firmě jsem používal příjemný nový věci, ale byl jsem vlastně pořád bez přestání zavalenej prací. Ne, že by vyloženě rutinní, ale že bych si tam kdovíjak trénoval problem solving skilly, to se říct nedalo. Na velkých legacy projektech jsem viděl neskutečné prasárny, ale většinou to bylo ve stavu, kdy už loď byla postavená a plovoucí a zásahy byly mnohem víc o analýze a komunikaci a méně o celodenním bušení po dlouhé týdny a měsíce :).
—
16.5.2015
-
Taco
:
@voidplace1: Já teď dělám na jednom legacy projektu, a přijde mi to i jako docela zábava. Člověk si mentálně odpočine, a může si ověřit, jak se takové ty Kitovi poučky uplatňují na bojišti.
—
16.5.2015
-
voidplace1
:
@Taco: :). Ale úplně vážně. Dělám taky na legacy projektu a je to do do určitý míry úleva. Nevymýšlím složitě architekturu, nějak už je to postavený , jenom dodržuju vymyšlený a snažim se dopochopit co za problémy to vlastně modeluje :). Objem práce mezi jednotlivýma releasama mi příjde podstatně víc v pohodě, než když jsem třeba vykopával projekty sám. Jenom každej zásah teď ze začátku znamená o něco sevřenější půlky, ale většinou se mi daří po 8.5h odejít s relativně čistou hlavou.
—
16.5.2015
-
Anonym
:
Každý kód se stane dřív nebo později legacy, proto je důležité umět s takovým kódem pracovat a dále ho rozvíjet. K tomuto můžu jen doporučit knihu Brownfield Application Development in .NET http://www.amazon.com/Brownfield-Application-Development-Donald-Belcham/...
—
25.5.2015
Pro zobrazení všech 12 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře