• Pravidlo 30 – kdy jsou metoda, třída nebo subsystém příliš velké

    V code review jsem připomín­koval stořád­kovou metodu, která mi přišla příliš dlouhá. Hranice může být otázkou osobního vkusu, tak jsem hledal zdroje, čím bych svůj názor podpořil. Narazil jsem přitom na článek Rule of 30 – When is a method, class or subsystem too big?, který napsal Jim Bird. S laskavým svolením autora jsem článek přeložil.

    4. prosince 2012

    Lidé, kterým záleží na psaní dobrého kódu, neustále kladou otázku: „Jaká je správná velikost metody, funkce, třídy, balíčku nebo jiného kusu kódu? Od určité chvíle může být kód příliš velký na to pořádně ho pochopit – ale jak velké je příliš velké?“

  • Monitoring

    U zákaz­níka jsme měli nasazené řešení (sestávající se z několika málo desítek kompo­nent), ke kterému jsme posky­to­vali second level support. Selhání byť jediné kompo­nenty mohlo způsobit zasta­vení celé produkce. Identi­fi­kace toho, která kompo­nenta zapříč­i­nila výpadek, bylo zbytečně zdlou­havé. Nehledě k tomu, že jsme nedokázali problémy dosta­tečně předvídat. Zákazník zcela logicky začal požadovat monitoring celého řešení.

    Velkou část minulého roku jsem tak strávil s monitorin­gem. Nepovažuji se v dané proble­ma­tice za odbor­níka (podle kompe­tenční matice bych to viděl tak na n2), ale minimálně si chci napsat pár poznámek pro sebe, abych vše nezapom­něl. Měl jsem zahrnout monito­rování do Joel Test 2.0, protože si dnes už nedokážu předs­tavit provo­zovat komplexní systém bez monitoringu.

    Chci se nejprve obecně věnovat proble­ma­tice monitoringu a pak konkrétní imple­men­taci a to Nagios, respek­tive Eyes of Network, které nad Nagiosem staví.

  • Kódující architekt

    Napsal jsem a přeložil několik článků o stárnutí programátorů a změně jejich pozice. Završím to pohledem na kódujícího archi­tekta. Zatímco v článku Technický lídr si zoufám, že jednou z nejtěžších voleb technické hvězdy, ze které se stává lídr, je ztráta kontaktu s nejnovější technologií, tak kniha Software Archi­tec­ture for Develo­pers (Simon Brown) mi dává určitou naději. Podle autora je softwa­rový archi­tekt technická kariéra.

  • Aby test neselhal na první­ assert (JUnit 5)

    Už jsem psal o tom, jak v JUnit 4 dosáh­nout toho, aby test neselhal na první assert. JUnit 5 již dosáhl miles­tone 2 (podrob­nosti v článku JUnit 5 State Of The Union), tak je potřeba se podívat, jak s novou verzí API dosáh­nout téhož.

    Jsem zastáncem toho, aby jednot­livé testy byly co nejkratší a samozřejmě na sobě nezávislé. Raději napíšu deset testo­vacích metod s jedním asser­tem, než jednu metodu s deseti asserty. Výhodu spatřuji v tom, že při jediném běhu testu vidíte na jediný pohled všechny vadné případy. A ne že opravíte první assert, spustíte test a padne vám hned druhý assert v pořadí.

    Jiné je to v případě integ­rač­ních testů, například Selenium (WebD­ri­ver). Samotná příprava dat je náročná, takže je vhodné asserty sdružovat do větších celků. Ale jak z jediného běhu získat co nejvíce infor­mací, aniž byste museli test znovu a znovu opakovat?

  • Bus faktor v praxi

    Bus faktor je číslo, které říká, kolik lidí by muselo odejít, aby to vážně ohrozilo projekt. Nejhorší číslo je 1. Z pohledu manažerů, by bylo skvělé, kdyby lidé byli snadno zaměni­telní jako součástky stroje. My si někdy můžeme nafou­kaně myslet, že jsme takřka nepostra­da­telní (i když jako manažer, bych se snažil takových lidí zbavit). Pravdou je, že každý je nahra­di­telný. Otázkou je, za jakou cenu.

    Slyšel jsem příběh, u kterého jsem osobně nebyl, ale byla by škoda ho neposlat dál. Nejspíš jde o urban legend, takže jakákoliv podob­nost s vaší firmou je čistě náhodná.

  • Nečitelný příběh Marie Navarové

    Případ Marie Navarové, poslední kniha Arnošta Lustiga, vznikla na základě článku PhDr. Ericha Rennera. Je to příběh hodný Shakes­peara, ale mistr ho psal asi jen tak na okraj. Ostatně to v rozhovoru, jakkoliv žertovně, přiznává (vzal zálohu a neměl, co psát). Chtěl jsem si tedy přečíst původní článek (Neči­telný příběh Marie Navarové), který byl knize předlo­hou. Bohužel vyšel pouze v regionálním tisku. S laskavým svolením autora jsem text převedl do elekt­ro­nické podoby a tímto posky­tuji ve formátech pdf, ePub i mobi. Poděkování patří rovněž Martinu Javorkovi, který po mně sazbu četl.

  • Zpráva o stavu IT trhu

    Po třech letech jsem se rozhodl změnit práci. Oběhal jsem pár firem, máte-li zájem, tak se na násle­dujících řádcích podělím o své zkuše­nosti a podám zprávu o stavu IT trhu. Líčení je to značně subjek­tivní, zúžené na svět Javy, ale dost možná platí i pro vás.

  • Refaktorování nepatří do backlogu

    Z některého kódu se mi dělá fyzicky nevolno a mám chuť ho od začátku přepsat, což by se rozhodně dělat nemělo. Další nápad je, přidat refak­to­rování do backlogu, ale tam nepatří. Ron Jeffries to vysvět­luje v článku Refac­toring – Not on the backlog! Článek jsem s laskavým svolením autora přeložil do češtiny.

    30. července 2014

    V nedávné době se objevilo hodně otázek na konfe­ren­cích a v e-mai­lových diskusích ohledně toho, zda dávat refak­to­ro­vací story do backlogu. I kdyby technický dluh vyrostl, tak to nic nemění na tom, že je to hrozná myšlenka. Vysvět­lení proč:

    Na začátku projektu je kód čistý. Pole je posekané, život krásný a svět náš. Všechno půjde hladce.

  • Mockování a úskalí času v Javě 8

    Adaptace nových verzí Javy jde pomalu. Dodnes vídám, že programátoři neumí či nechtějí používat multi catch, try-with-resources a diamond operátor. Jak chtít složitější posun, který přináší Java 8?

    Ovšem sám nejsem bez viny. Java 8 už je tu víc jak dva roky. Při jejím uvedení jsem psal, jak obstojí v Akumulátor testu, ale na projek­tech ji naplno nevyužíváme. Rozhodl jsem se to napravit tím, že začnu používat java.time.* místo java.util.Date. Jednak kvůli API a taky proto, že jsou nové třídy immutable. Chtěl bych se podělit o to, jak jsem se při tom nachytal.

  • Clean Code

    Jeden z mých nejús­pěšnějších tweetů a přitom taková blbost. Takže asi stojí za rozepsání. Mám totiž za to, že existuje korelace mezi pořád­ku­mi­lov­ností a čistým kódem.

    Občas vídám kód, z kterého je mi fyzicky nevolno. Ale člověk nějak musí zjistit, co je špatné. Abych citoval Ilust­ro­vanou knihu argumen­tač­ních faulů:

    Číst o věcech, které bychom neměli dělat, je často užitečná a poučná zkuše­nost. Ve své knize O psaní píše Stephen King: „Nejlépe se člověk naučí, čeho se vyvaro­vat, při čtení špatné prózy.” Popisuje svou zkuše­nost se čtením obzvlášť špatného románu jako „literární ekviva­lent očkování proti nešto­vicím” [King]. Matematik George Pólya bývá citován, jak ve své přednášce o výuce matema­tiky prohlásil, že člověk musí nejen téma dobře chápat, ale také musí vědět, jak lze téma chápat špatně [Pólya].

    Na pomoc si vezmu knihu Clean Code (Robert C. Martin) a doplním o pár svých postřehů. Měl jsem si ji přečíst na začátku své kariéry, ale na druhou stranu po deseti letech praxe ji dokážu o to víc ocenit. Je smutné, že principy v ní popiso­vané jsou často opomíjené.

subscribe via RSS