TheCodestReview #5 - dvoutýdenní džus pro softwarové inženýrství

V minulém díle jsem se chtěl vyjádřit k článku o důležitosti humoru na pracovišti, ale mezitím jsem zjistil, že si zaslouží mnohem větší uznání, takže o něm brzy napíšu celý blogový příspěvek.    

Věci, které mě v posledních týdnech zaměstnaly: 

a) Před Vánoci jsem začal premiérovým dílem seriálu Série webinářů "Neprůstřelný CTO" (v únoru se těšte na 2. díl, který bude obsahovat SaaS CTOs, podrobnosti brzy na mém LinkedIn).

b) Vyladění našeho růstového plánu na rok 2021 s cílem překročit naše cíle. Ruby a JS core business a růst Magento a Produkt Kompetence v oblasti designu interní.

Dost bylo sebepropagace, dovolte mi, abych vás pozval na pátý díl naší série #TheCodestReview. 

Témata moje tým připravil na tuto dobu: 

1. Škálovatelná a udržovatelná architektura front-endu.
2. Konvenční revize.
3. Aktualizace verze Ruby 3.0.0.

Komentáře k frontendovým aplikacím a konvenčním revizím dodá tento týden náš React inženýři zatímco Ruby 3.0.0 od našeho týmu snů o Ruby.

Mnoho vývojářů dnes pro úsporu času používá již vytvořené knihovny uživatelského rozhraní a opakovaně použitelné komponenty. Je to dobrá praxe a pomáhá to nás ušetřit spoustu času, ale když naše projekt se zvětšuje - pochopíte, že nestačí zvládnout s kód.

Existují dva dobré vzory z oblasti back-endového vývoje - Domain Driven Development (DDD) a Separation of Concerns (SoC). Můžeme je použít i v architektuře front-endu.

V DDD se snažíme seskupit podobné funkce a co nejvíce je oddělit od ostatních skupin (modulů).

Zatímco u SoC například oddělujeme logiku, pohledy a datové modely (např. pomocí návrhového vzoru MVC nebo MVVM).

Existuje mnoho osvědčených postupů a vzorů, které lze použít, ale tento způsob je pro mě výhodnější.

Když použijeme tento vzor, získáme tento obrázek:

Na začátku je uživatel přesměrován na správný modul pomocí směrování aplikace. Každý modul je kompletně obsažen. Protože však uživatel očekává, že bude používat jednu aplikaci, a ne několik malých, bude existovat určité propojení. Tato vazba existuje na konkrétní funkce nebo obchodní logiku.

A my máme tuto strukturu:

složka app - aplikační vrstva

assets - složka pro obrázky, písma, ikony atd.

komponenty - zde by měly být komponenty pro opakované použití, které nemají složitou logiku.

config - zde budeme ukládat globální stav

lib - složka pro složité funkce a logické výpočty

moduly - zde jsou naše moduly

pubsub - místo pro ukládání schémat pro popis datové struktury.

styles - pro náš kód css/scss

Tato struktura nám pomůže zvládnout naši rostoucí aplikaci a mít méně chyb. Také nám pomůže vytvořit pohodlnější pracovní části s oddělenými moduly, testovat je a usnadnit refaktorizaci a ladění (díky odděleným modulům).

Pokud se podíváme hlouběji na architekturu modulů a jejich propojení s API, dostaneme něco podobného:

Ve složce 'app' vytvoříme další složku 'api' s kódem pro volání API a data uložíme do složky 'config/store'. Zde uchováváme statická a neměnná data, která používáme v celé aplikaci.

Ve složce "pubsub/schema" také popíšeme konkrétní datové typy pro JavaScript objekty.

Všechny moduly obsahují data, která potřebujeme použít (uživatelé, trasy, tabulky, akce atd.). Každý modul je propojen s aplikační vrstvou a přebírá všechna potřebná data.

Front-end je prvním vstupním bodem pro naše uživatele. S přibývajícími funkcemi našich projektů front-endu se budou objevovat i další chyby. Naši uživatelé však očekávají, že žádné chyby nebudou a nové funkce budou rychle přibývat. To je nemožné. Přesto se pomocí dobré architektury můžeme jen snažit toho co nejvíce dosáhnout.

Konvenční revize od Sathyabodh Mudhol na DZone

Důvod, proč je třeba odevzdat práci lepším způsobem

Představte si, že jste na začátku ve firmě, do které jste právě nastoupili. Všichni lidé jsou na vás milí a všechno se zdá být v pořádku až do okamžiku, kdy se seznámíte s kódovou základnou z doby, kdy JavaScript ještě nebyl jazykem a Netscape načítal stránku, která by se zdála být věkem.

Dědičnost kódu se zdá být obrovským problémem při zavádění nových vývojářů do projektu. Přečíst si kód je jedna věc, ale pochopit, jak byla aplikace vyvinuta, není úplně totéž. Často se ukáže, že revize jsou užitečné a poskytují kontext, proč tyto console.logy nebyly zachyceny linterem nebo proč je tam to ošklivé // TODO pro děti vývojáře, který původně vytvořil anotaci.

Začněme tím, proč jsou konvenční revize lepší než nestandardizovaná pravidla revizí.

Pokud přijmeme nové vývojáře do projektu, ve kterém většina revizí sestává ze zpráv ve smyslu, že by to mělo fungovat nebo Sleepy opravit patičku ASAP, co se vám objeví v hlavě?

Řekl bych, že červené vlajky, protože:

• Nevíme, co přesně by mělo fungovat
• Proč někdo něco tlačil, když byl ospalý a potenciálně chybný?
• Byla oprava uspěchaná, když vidíme anotaci ASAP?

Protože váš tým může mít vlastní pravidla, která se použijí při revizi změn, je zde méně prostoru pro chyby, protože vaše revize musí být spolehlivá. Už to není způsob, jak se jen odhlásit. Je to podpis, který ostatním lidem říká, že jste obsah revize znali. Není třeba zmiňovat, že pokud práce, kterou jste provedli, není správně podepsaná, s největší pravděpodobností to povede k chybě a zobrazí se vám hlášení

Je možné, že váš tým bude chtít nastavit pravidlo zakazující určitá klíčová slova, takže ASAP nebo jakákoli nadávka mohou být na černé listině.

Nástroje

Na začátku projektu je opravdu užitečné seznámit všechny s tím, jak se vaše vývojový tým by chtěli, aby noví vývojáři odevzdávali své změny. Pak nastavte nástroj, který jim pomůže dodržovat to, na čem jste se všichni dohodli.

Jedním z nástrojů, se kterými jsem měl možnost pracovat, byl commitlint a konvenční revize se tak staly mým zvykem, když přicházím do nových projektů, které nemají pravidla a tým je otevřený myšlence jejich zavedení.

Při práci s nastavením a jeho šířením napříč týmem můžete jednoduše vytvořit balíček npm a v každém projektu jej jen mpn i -D. To jistě pomůže všem v projektu, aby byli vždy na stejné vlně a v případě potřeby mohli přecházet z projektu do projektu a chápali, čeho se týkaly poslední změny (a proč byly provedeny).

Přátelé s více výhodami

Po nastavení všeho a pochopení, proč by mohlo být dobré začít CC používat, bude nejlepší programovat podle právě aplikovaných pravidel! Používáme standardizovaný způsob odevzdávání revizí, věnujeme více pozornosti tomu, o čem revize skutečně byla, tak proč nenastavit háčky, které vám umožní rychlé testování na staging, když je příznak přítomen? Nechceme přetěžovat služby a snižovat náklady, když je to potřeba, a existují důvody, proč testovat na serveru podobném produkčnímu místo na localhostu.

Předpokládejme, že pracujete na PWA a k vyzkoušení plného potenciálu je zapotřebí SSL a že máte na své testovací platformě SSL. Vše, co nyní potřebujete, je jen dobře odevzdat. Něco ve stylu feat(PWA): manifest icons workbox setup upload by spustilo celou mašinérii testování a přesouvání ozubených koleček. To nepotřebujeme, když jen nahráváme nějaká statická data, jako je manifest.json, takže přidáme příznak [TEST_SKIP] jako postfix k naší revizi. To umožní našemu CI pouze nahrát nové prostředky do testovacího prostředí a přeskočit testování. Můžete si o tom přečíst více zde

Po nějaké době budete moci vidět další zisky, jako je snadné generování CHANGELOG a lepší verzování pomocí. sémantické verzování. Pokud vás to nepřesvědčí, abyste změnili způsob psaní závazných zpráv, možná by váš názor změnilo, kdybyste si ponořili prsty do čerstvé studené vody a zkusili je na chvíli použít ve svém soukromém úložišti.

Šťastné konvenční spáchání!

Aktualizace verze Ruby 3.0.0 od Ruby Community

Dlouho očekávaná komunitní verze Ruby 3.0.0 spatřila světlo světa o Vánocích, aby ji všichni vývojáři Ruby mohli najít pod vánočním stromečkem, jakmile se ráno probudí. Ve společnosti The Codest pěstujeme kulturu sdílení znalostí pořádáním týdenních dev meetingů, na kterých naši inženýři diskutují o technologických trendech a svých nových objevech, které stojí za pozornost. Níže najdete odkaz na slajdy z ukázkového dne, kde náš senior inženýr Ruby probral pár důležitých změn v Ruby 3.0.0 ze svého subjektivního pohledu:

https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing

Kromě toho náš mentor Ruby přispěl do nové verze svým požadavkem na stažení, který byl úspěšně sloučen. Více o tématu metod kontroly soukromí najdete níže v krátkém článku našeho vedoucího vývoje.

https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods

Moc děkuji za přečtení, a pokud jste došli až sem, vážím si vašeho času a každá zpětná vazba je více než vítána na LinkedIn nebo na můj e-mail.

Vrátíme se k vám s dalším dílem na konci února s recenzí podcastu, ve kterém bude rozhovor s CTO ze společnosti Shopify, mužem, který stojí za inženýrským týmem pracujícím na velkolepé aplikaci Ruby monolith!

Uvidíme se.

Přečtěte si více:

TheCodestReview #4 - týdenní šťáva ze softwarového inženýrství

TheCodestReview #3 - týdenní šťáva ze softwarového inženýrství

TheCodestReview #2 - týdenní šťáva softwarového inženýrství