Category Archives: Uncategorized

K čemu je java.lang.Void

Dnes Dagi narazil v mém kódu na použití třídy java.lang.Void. Řekl jsem si, že se pochlubím i svým věrným čtenářům. Kdyby někdo z vás nevěděl, k čemu taková třída je, můžete si přečíst její JavaDoc.

The Void class is an uninstantiable placeholder class to hold a reference to the Class object representing the Java keyword void.

Jasné jako facka. Pravděpodobně se s tímto typem setkáte při reflexi. Ale mnohem důležitější je použití v generikách. Často totiž narazíte v knihovnách na callbacky, které předpokládají, že chcete vrátit nějakou hodnotu. Například Springovský ConnectionCallback, který vypadá takto

public interface ConnectionCallback<T> {
	T doInConnection(Connection con) throws SQLException, DataAccessException;
}

Je ale otázkou jak zvolit typ T, pokud nechcete nic vracet. A zde právě přichází ke slovu java.lang.Void. Můžu napsat například následující kód

template.execute(new ConnectionCallback<Void>() {
	@Override
	public Void doInConnection(Connection con) {
		//your code here
		//...
		return null;
	}
});

Krása nesmírná. Na první pohled je jasné, co se tam děje. Jenom škoda, že musím napsat ten return null.

V rámci objektivity musím přiznat, že to zas není tak důležité. Většinou se s podobným kódem potkáme u anonymních tříd, kde na tom návratovém typu zas tak nezáleží. Ale i tak je to takový pěkný detail, který se hodí znát.

Feature branching

Před chvílí jsem dokoukal povídání Mika Masona a Martina Fowlera o dělání větví pro vlastnosti (feature branching). Do teď jsem si myslel, že to je dobrá věc, ale trochu mé přesvědčení zviklali.

O co jde? Některé týmy postupují tak, že pro každou novou vyvíjenou věc založí novou větev. Ta se začlení do hlavní vývojové větve, až když je daná věc hotová. Má to spoustu výhod a až dodnes mě nedošlo, že to s sebou nese i pár zásadních problémů. Pro nezkreslenou informaci se koukněte na to video, má jen jedenáct minut. Já tu shrnu jen to, co mi přišlo jako nejzásadnější.

Feature branching ohromně komplikuje refaktoring. Když si všimnete zatuchlého kódu, můžete ho refaktorovat, ale dost si tím zkomplikujete merge. Pokud totiž uděláte větší refaktoring, je velká šance, že se dotknete kódu, na kterém dělá někdo jiný. Dostanete se do situace, s kterou vám ani Git nepomůže. Strávíte pěkných pár chvilek ručním mergem a je tu pak dost velká pravděpodobnost, že příště si ten refaktoring dvakrát rozmyslíte. A to je špatně.

Když nad tím tak přemýšlím, potkalo mě to minulý týden. Udělal jsem ve své větvi refaktoring a začlenil jsem ho do hlavní větve. Kolega ale stále žil ve své větvi, mé geniální změny si proto nevšiml a svůj kód udělal o poznání hůře, než by mohl. Vůbec mě napadlo, že by to mohlo být způsobeno nějakou systematickou chybou.

Neříkám, že přestanu feature branching dělat, ale rozhodně se nad ním pořádně zamyslím.

Jak na Git

V posledních pár měsících jsem se pral s verzovacím systémem Git. Teď už mám dojem, že jsem mu přišel na kloub, tak se chci podělit o to, jak se mi to povedlo. Snad to nezakřiknu.

Nakonec u mě zabral následující postup.

Přečíst si knihu ProGit (anglicky nebo česky)
Několik týdnu se pokoušet s Gitem pracovat, rvát si vlasy z hlavy, říkat si, že už jsem asi na ty počítače starý.
Přečíst si knihu znovu a dosáhnout osvícení.

Rozhodně se tu nechystám Git popisovat, přečtěte si tu knihu. Jenom tu popíšu svůj mentální model toho, jak to celé pracuje. Musím vás varovat, že tento model se může lišit od reality, ale mě zatím pomáhá. Schválně budu ignorovat oblast změn (staging, index), budu se věnovat hlavně revizím, kolem kterých se všechno v Gitu točí.

Revize (alias snímek neboli commit) vznikne, když commitneme nějaké změny. Je důležité si uvědomit, že revize obsahuje obraz našeho projektu v okamžiku jejího vzniku. Takže to není popis rozdílů, ale opravdu snímek všech souborů tak jak v čase vytváření revize vypadaly. Interně to je samozřejmě pořešeno tak, aby to bylo rychlé a diskově nenáročné, navenek se ale Git opravdu tváří tak, že má hromadu snímků stavu projektu.

Každá taková revize má navíc jednoznačný identifikátor (hash) a také informaci o tom, které revize jí předcházely.

Toto už stačí, aby to všechno fungovalo. Máme hromadu revizí, které jsou uspořádány v jakémsi orientovaném grafu a my po tom grafu můžeme dle libosti skákat, dělat změny a vytvářet z nich nové revize. Abychom se v tom neztratili, mohou na jednotlivé revize ukazovat pojmenované identifikátory jako jsou větve a tagy. Je tu speciální identifikátor HEAD, který ukazuje na místo v grafu v které se právě nacházím. Všechny tyto identifikátory, ale nejsou nic jiného, než odkazy na revize.

Takže například kouzelný příkaz

git reset --hard <<revize>>

mi převede (téměř) všechny soubory v projektu do stavu v dané revizi a změní hodnotu odkazu HEAD. Tento příkaz si zapamatujte, ohromě se hodí, když se dostanete do potíží. Například když se vám nepovede merge a Git vám automaticky ty nepovedené změny commitne. Nemusíte mazat a naklonovat znovu celé úložištěm jako jsem to jednou v panice udělal já. Stačí se uklidnit, uvědomit si co je Git zač, najít číslo revize v které to bylo ještě v pořádku a vrátit se do ní. Docela bezpečné je vracet se do origin/master, to ukazuje na revizi, kde byl vrchol hlavní větve ve zdrojovém úložišti při poslední synchronizaci. Nepovedené změny sice někde v Gitu zůstanou hnít, ale to zas tak nevadí.

Toliko můj mentální model Gitu. Možná se ještě zmíním o tom, v čem se mi Git líbí. Zajímavé je například vyzobávání třešínek (cherrypick). To je funkce, která mi umožní vyzobnout si změny provedené v jedné revizi a aplikovat je na jinou revizi. Úžasná funkce, pokud potřebuje zároveň aplikovat jednu změnu do víc větví.

Mocná i když trochu nebezpečná zbraň je také přeskládání (rebase), které vám například umožní přehrát změny provedené v jedné větvi nad jinou větví. Dokonce vám to umožní přeházet pořadí revizí, slučovat revize dohromady, rozdělovat jednu revizi na víc atp. Ve skutečnosti se samozřejmě revize nemění, jenom se vytvoří nové, které se jen tváří jako ty původní s příslušnými změnami. Na přeskládání ale pozor, můžete tím naštvat své spolupracovníky, jejichž revize vycházejí z těch původních, nepřeskládaných.

Jinak mohu Git jen doporučit. Výsledek stojí za to, pokud přežijete dvojí přečtení jedné krátké knihy a čtrnáct dnů utrpení.