Při poslechu podcastu o Middlemanovi mě zaujala zmínka o článku My Weird Ruby o kódu psaném dnes a v minulosti. Je to zajímává forma retrospektivy, což se může hodit při hledání nové práce. Dříve je stav hlavně při bakalářském studiu na UPCE, poté už jsem se postupně propracovával ke dnešnímu přístupu.
Z počátku hlavně Mercurial, od práce v Edgedesignu hlavně Git. Nedělám vše přes CLI, základní operace chci dělat rychle a nechci si moc věcí pamatovat, takže používám Sourcetree, Gitkraken a TortoiseHG. GUI používám hlavně při diffech a kvůli pohledu do historie.
Commituji hodněkrát za den a snažím se psát srozumitelné commity, abych mohl snadno skenovat historii (nejdřív kategorie) a věděl jsem, co jsem dělal i bez pohledu do diffu (popis úkolu za pomlčkou).
Dříve jsem verze aplikací neřešil, prostě jsem nakopíroval soubory přes ftp a konzoli jsem se vyhýbal
Z Windows jsem měl z konzole otřesné zkušenosti, takže po příchodu do Edgedesignu, MacOS a Symfony, jsem si musel začít zvykat na práci v konzoli. Postupně byl návrat do “Windows módu” čím dál protivnější, takže jsem nakonec i nový notebook pořídil bez OS a přešel jsem na Linux. Spustit jeden příkaz, co vymaže cache, je návykové. Oproti otevření průzkumníka, najetí do složky a odstranění do koše. Stejně jako třeba zálohování disku, nasazování aplikací... Možná zrovna deployment mám stále více manuálnější oproti dnešním trendům, ale pro aktuální účely mi to postačuje a nechci dělat něco, co zrovna nepotřebuji (viz architektura).
Dřív jsem psal kód, jak jsem to zrovna naklapal a psal jsem relativně dost komentářů a pojmenování jsem extra neřešil
Více dbám na formu, jména, strukturu, ... Než napíšu komentář, tak přemýšlím, jestli by nešel kód zrefaktorovat tak, aby komentář nebyla potřeba. Dříve tohle ani nešlo, když jsem neměl historii, testy, tak je tam vždy strach ze sebemenší změny. Coding standards v PHP kontroluje integrační server, u JAVY a Pythonu jsem zatím spoléhal hlavně na inspectora standardů v IDEA.
Dříve jsem testy moc nepsal a spíše jsem klikal v aplikaci, prohlížeči... a čekal na hlášení problémů
I když už jsem testy začal psát, tak chvíli trvalo než jsem se dopracoval k tomu, jak psát “užitečné” testy. Z počátku jsem tedy psal podle metod a moc hodnotné nebyly, ale pořád to bylo lepší než nic :)
Dostat TDD pod kůži chvíli trvalo. Pamatuji si, jak mi to nejdřív přišlo divné. Jak lze psát test, když nemám kód? Ale teď už si nedokážu si představit práci v novém jazyku/nástroji, upgrade např. frameworku, reorganizaci balíčků v rozsáhlém projektu bez testů. Nasazovat novou verzi s klidem? Bez testů těžko, co když jsem zapomněl proklikat jednu stránku a teď nebude hlavní poslání aplikace fungovat?
O formě testů už jsem psal v části “dříve”, ale forma nikdy nebude ideální. Třeba teď se snažím odstraňovat should z názvů metod. Hodně pomáhá TestDox (díky GOOS), který upozorní na špatně a nepřesně pojmenované metody.
Přivedla mě k tomu UPCE, protože se to tak dělá v praxi. Možná při vodopádu, ale pro vývoj užitečného SW se mi to zatím neosvědčilo. Nezapomenu, jak jsem měl kompletní schéma databáze, všechny normální formy dodržené, ERD a UML diagramy nakreslené, ale aplikace byla nepoužitelná pro uživatele. Ale měla diagramy...
ERD diagram pouze k zápasům, dalším X tabulek je ještě k soutěžím (lze je najít v příloze BP)
YAGNI, KISS, 4 rules of simple design... mnoho názvů pro stejnou myšlenku. Nepsat kód, nedělat diagramy, když je nepotřebuji. Speciálně u DB schéma mi přijde lepší přístup v nastavení procesu migrací. Stačí mi teď jedna tabulka, tak proč jich dělat 40? Nikdy na první dobrou neudělám správný kód, schéma DB, diagram čehokoliv, ale je tam postupné zjišťování nových a nových poznatků. Změna je nevyhnutelná a BDUF ji nijak neusnadňuje.
"Wouldn't it be easier just to do it right in the first place?" Of course it would, except for three things: We may not know how to do it "right". Doing everything "right" today might take so long that changing circumstances tomorrow invalidate today's solution before it is even finished.
Software development has a long tradition of people so busy thinking about software development they don't have time to develop software. They would sit for hours, talking about each of their ideas in turn. By the time they were tired of talking, they could have implemented all the alternatives twice. They didn't want to waste programming time, though, so they wasted talking time instead.
Kent Beck - Extreme Programming Explained - Embrace Change (2nd Edition)
Stejně tak při psaní kódu moc nedbám na původní představy. Jsou tu různé principy jako SOLID, design patterns, ..., ale raději se nechávám testy k designu, který aktuálně potřebuji. Raději mám jednoduchý kód dostatečný pro aktuální stav než komplexní kód s odporem naroubovaným Visitor patternem. V 3.kroku TDD je refactoring a když v něm vidím, že by to pattern zjednodušil, tak proč ne. Ale psát kód s myšlenkou na určitý pattern se mi neosvědčilo.
I’ve been saying for years that if you simply follow Kent Beck’s rules of simple design, then you’ll see how every good design principle you’ve ever heard of reduces to some combination of “remove duplication” and “improve names”.
J.B.Rainsberger - Foreword in 4 rules of simple design
Žít, odpočívat a vzdělávat se moc nejde, když den za dnem, hodinu za hodinou člověk buší kód. Krátkodobě možná, ale živit se takto celý život jako programátor? Díky, nechci. I když někomu řeknu odhad, tak to není závazek, že to tak stihnu a budu to po nocích kódovat. Obzvlášť po nástupu do práce se snažím minimalizovat počet vlastních projektů a spíše použiju existující řešení, i když není třeba ideální.
If you want to be a better developer, you must always keep this inevitably in mind: The client will always extend the deadline. They will always want more features. They will always want change—LATE.
You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.
In the real world, your bad code doesn’t vanish when the semester’s over, you don’t get an A for marathon coding the night before an assignment’s due, and, worst of all, you have to deal with people. So, coding gurus are not necessarily professionals.
The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)
Dříve jsem se vyhýbal zveřejnění článků a issue jsem párkrát psal raději anonymně než bych si vytvořil účet na githubu
Chvíli mi trvalo než jsem tu stránku našel :) Myslím, že se ten účet jmenoval nějak jako BugsAndNewsReporter, ale už je asi zablokovaný.
Po nástupu do týmu v Edgedesignu už na schovávání, skrývání chyb a překrucování skutečnosti není čas. Zákazník hlásí chybu, kód jsem napsal já, takže to je moje odpovědnost. Podrobné detaily vzniku jsou sice pro okolí nepodstatné, ale pro další vývoj je důležité vědět, proč vznikla a jak tomu příště předejít.
Those who cannot remember the past are condemned to repeat it.
- George Santayana
Také jsem začal jsem používat Symfony. Z toho občas vyplynuly zkušenosti, které se můžou hodit i někomu jinému, takže jsem je sepsal. Někdy třeba smysl není úplně pochopen a dojde k překroucení, ale pořád je to příležitost pro zlepšení, abych se příště vyjádřil jasněji. Netýká se to jen článků, ale obecně veškeré odpovědnosti za svoje “výplody”, ať už v kódu, v komunikaci...
In fact, Thomas Edison is often quoted as saying, “If I find 10,000 ways something won’t work, I haven’t failed. I am not discouraged, because every wrong attempt discarded is another step forward.”. The key to learning from your mistakes is to document your failures. Write up “postmortems,” as they’re often called in our business. Take extra care to make sure the postmortem document isn’t just a useless list of apologies or excuses—that’s not its purpose. A proper postmortem should always contain an explanation of what was learned and what is going to change as a result of the learning experience.
Team Geek: A Software Developer's Guide to Working Well with Others
Přijde, že jsem postupně dopracoval k používání většiny XP praktik a hodnot. Požaduje to sice disciplínu a cesta to není občas jednoduchá, ale myslím, že se vyplatí. Aby byly všechny strany spokojené, zákazník, zaměstnavatel i já, tak to bez disciplíny nepůjde. Pro někoho to třeba nejsou XP praktiky, ani nic co jsem popsal já, ale mně pomohly k profesionalismu, odpovědnosti a radosti ze svoji práce.
Professionals are often heroes, but not because they try to be. Professionals become heroes when they get a job done well, on time, and on budget. By trying to become the man of the hour, the savior of the day, John was not acting like a professional. John should have said no to his own internal decision that the only way to get this job done on time was to make a big mess.
The temptation to be a hero and “solve the problem” is huge. What we all have to realize is that saying yes to dropping our professional disciplines is not the way to solve problems. Dropping those disciplines is the way you create problems.
The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)