Společnost ThoughWorks, známá např. jako autor nástrojů CruiseControl nebo Selenium, publikuje dva krát za rok Technology Radar – přehled aktuálních trendů a technologií pro vývoj software. Dnes bych se chtěl podělit o body, které mě zaujaly v říjnovém čísle. Na radaru jich je celkem 107!
Rozhodně používat (Adopt)
- Jasmine paired with Node.js umožňuje robustní testování JavaScriptového kódu bez nutnosti pouštět browser.
- Clojure and Scala jsou dva jazyky postavené nad JVM, Clojure je čistě funkcionální (podobný Lispu), Scala je spíš hybrid mezi. Překvapuje mně doporučení pro Scalu, protože jednu dobu procházela zpětně nekopatibilními změnami API/syntaxe mezi verzemi kompilátoru, a navíc trpěla výkonnostními problémy.
- SASS, SCSS, LESS, and Stylus. Je příjemným zjištěním, že nadstavby nad CSS už dozrály pro širší nasazení (na rozdíl od transpilátorů JavaScriptu, které jsou pořád v plenkách).
Vyzkoušet na menším projektu (Trial)
- Gradle a Rake jsou nástroje pro build (alternativy k Ant, Maven a MSBuild), které na rozdíl od nástrojů založených na XML netrpí nadměrným množstvím špičatých závorek a zároveň umožňují rozšiřitelnost na úrovni jemnější než jenom externí pluginy. Pocházejí ze světa Ruby, ale měly by umět sestavit i Java a .NET aplikace.
- NuGet je balíčkovací nástroj pro .NET, inspirovaný populárním gem pro Ruby. Zajímalo by mě, proč zatím není doporučován pro všeobecné použití?
- SaaS performance testing tools zjednodušují zátěžové testování, protože odpadne potřeba konfigurovat HW a instalovat SW prostředí.
- Continuous integration in the cloud zjednodušuje zavedení CI, už není potřeba instalovat a provozovat vlastní CI server.
- Logs as data. Díky nástrojům schopným zpracovat obrovské množství dat z logů je dnes možné používat logy nejenom jako diagnostický nástroj, ale taky jako zdroj informací o chování našich uživatelů.
- Dependency Structure Matrices (DSM) je nástroj pro vizualizaci kódu, který podporuje evolutionary architecture and emergent design.
Používat s opatrností (Hold)
- Feature Branching je technika, kdy pro každou fíčuru vytvoříme samostatnou větev v SVN/GIT. Po dokončení implementace provedeme merge do hlavní větvě. Jako hlavní nevýhodu vidím pozdní integraci s hlavní větví, tím pádem i pozdní otestování na CI serveru.
- Exhaustive browser-based testing. Testovat JavaScript integračně v browseru nad DOM-em už není cool. Testy jsou pomalé a křehké, jako řešení se nabízí Jasmine + node.js
- Maven, o kterém vím jenom tolik, že je poměrně populární ve světě Javy.
- WS-* je nástupce OAuth, zaměřený víc na enterprise. Před pár měsíci jsem četl knížku od Microsoftu, kde ukazovali použití v .NET. Programování bylo sice jednoduché, ale konfigurace a nasazení složité. Hodnocení ThoughWorks se proto ani nedivím. Zajímalo by mě však, jakou máme jinou alternativu pro single-sign-on uživatelů z různých enterprise domén?
- Google Dart vypadal vloni jako jazyk, který brzo nahradí JavaScript. Zdá se, že to nebude tak jednoduché.
Co zaujalo nebo překvapilo Vás?
K Mavenu by se slušelo dodat, proč je v Hold. V minulém Radaru totiž psali: Maven has long been a staple of build automation in the Java space. However, given its lack of flexibility and support for automation best practices, especially in the Continuous Delivery domain, the use of alternatives such as Gradle should be considered.
@banter Děkuji za doplnění, mě samému ta informace přišla neúplná.
Feature branching bych zařadil do Adopt, není se čeho bát a v distribuovaných VCS je to maximálně pohodlné.
V CI to řešíme tak, že vedle projektu na build masteru máme ještě testovací, kde si každý vývojář může zkoušet své feature branche.
Hou, hou, hou! Feature branching ne, viz http://martinfowler.com/bliki/FeatureBranch.html
Hezký den, nerozumím té poznámce o problémech feature branchů (“Jako hlavní nevýhodu vidím pozdní integraci s hlavní větví, tím pádem i pozdní otestování na CI serveru.”) — proč by měl být problém CI říct, ať testuje stav po každém commitu v každé větvi? Resp. co dělám špatně, když mi to takhle funguje? :-)
Co se týče pozdní integrace s hlavní větví, tak se domnívám, že je good practice se o tu integraci starat přimergováváním masteru do feature branche v okamžicích, které uznám za vhodné (podle rychlosti vývoje v té části kódu, na které pracuji) — tj. tak, aby závěrečný merge do masteru nebyl nijak konfliktní.
Banter: Názor Fowlera rozhodně není jediný správný. Countinuous integration (commitování do mainline, bez feature branchí) lze úspěšně používat jen pokud zároveň používáš feature toggling (což imho skoro nikdo nedělá) a pokud máš velmi zodpovědné vývojáře, kteří nedělají skoro žádné chybné commity.
Fowler se navíc vůbec nezmiňuje o rebasování, které řadu těch problémů branchování (big scary merge) dost minimalizuje.
Vypadá to, že Fowler je asi hodně zvyklý používat SVN a feature toggling a filozofii feature branchí a flexibilní historie ještě nepřišel úplně na chuť.
Btw docela bych chtěl vidět, jak se u historie vzniklé kontinuální integrací, jak jí Fowler popisuje, délá code review nad nějakou featurou…
Daniel: Fowler nepoužívá přímo pojem “rebase”, ale uvádí příklad, kdy si do své feature-branch taháš změny z “head” (případně i z dalších feature-branches – pak tomu říka Promiscuous Integration). I při takovém postupu však mají feature-branches další problémy, kvůli kterým se nevyplatí používat (jak tvrdí ve svém článku).
Co se týka code-review nad fíčurou: podle mě dělat CR až na konci, kdy je celá fíčura hotová, je pozdě. Takové CR zabere neúměrně mnoho času, nebo proběhne jenom povrchně. Navíc opravovat zásadnější problémy v návrhu až na konci znamená následný přepis velkého množství kódu, takže většinou se to už neopraví (není chuť a často ani čas).
Pokud potřebuješ propojit commity s fíčurou, tak stačí do commit-logu přidávat ID fíčury. Například tak, jak to dělá GitHub (viz sekci “Commits + Issues” https://github.com/blog/831-issues-2-0-the-next-generation)
Ještě k tomu Code Review – doporučuji přečíst Best Kept Secrets for Peer Code Review (zkrácená verze: http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-Review.pdf).
The Cisco code review study shows that for optimal effectiveness, developers should review
fewer than 200-400 lines of code (LOC) at a time. Beyond that, the ability to find defects diminishes.
Miroslav: Nepoužívání feature branchí vede z mého pohledu k tomu, že člověk přestane verzovat svůj postup na úkolu, protože cokoliv, co commituju do masteru, musí být už funkční a odladěné, jinak tím rozbiju ostatním práci. Naproti tomu když vyvíjíš ve větvích, tak si můžeš dělat u sebe hromadu pokusných commitů a větví, ty pak různě upravovat, squashovat a když jsi se svou prací spokojen, tak teprve výslednou větev zvěřejnit, nebo dokonce rovnou mergnout do masteru (třeba i fast-forward).
Menší code review a feature branche se nijak nevylučují. Můžes si nechat udělat code review jen na jeden commit ve své branchi a pak teprve pokračovat dál v práci. Výhodou je opět to, že pokud by review odhalilo zásadní chyby, můžeš kód úplně předělat a nikomu tím nic pod rukama nezničíš.
A co se týče spolupráce více vývojářů na jedné části kódu, tak není problém odvětvovat feature větve jednu ze druhé nebo je rebasovat kamkoliv je potřeba.
Git je, co se týče větví, neuvěřitelně mocný a efektivní, je velká škoda se téhle síly dobrovolně vzdát.
To, že je něco snadné, neznamená, že to musím dělat. ;)