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

Proč to děláme?

1. Sdílení znalostí je pro rozvoj technických dovedností klíčové a nám na tom záleží.

2. Pomáhat vedoucím pracovníkům v oblasti inženýrství nalézt řešení, která potřebují k rozhodování založenému na důkazech ve svých softwarové projekty.

3. Pevně věříme v sílu sebevzdělávání, stále se snažíme učit novým věcem a posilovat sami sebe, 1% najednou. 

4. Na internetu je spousta skvělého technického obsahu, který si zaslouží více pozornosti, a my se chystáme ocenit, co se patří.

Budování plán cesty pro tuto sérii jsem provedl průzkum na LinkedIn, abych se zeptal. CTOs a inženýrských manažerů o jejich klíčových výzvách v již tak dost obtížném roce 2020 a dále.

Zde je jejich vyjádření: 

Dovolte mi, abych vás pozval na 1. díl TheCodestReview s příspěvkem našeho hosta CTO, vedoucího vývoje a vedoucího frontendu, který se zabývá níže uvedenými tématy:

Šest pravidel pro škálování Software Architectures od Iana Gortona

"Váš systém má úzké místo. Někde!" - když bojujeme za zvýšení výkonu aplikace, zapomínáme na klíčová omezení systému, možná to nejsou nejoblíbenější prvky aplikace, ale mohou mít negativní vliv na zbytek a škálování nemusí pomoci. nás zde.

"Monitorování je základem škálovatelných systémů" - v našem podnikání nemůžeme být slepí a je pro nás lepší vědět o problému dříve, než nás o něm informují uživatelé nebo náš CEO. Monitorování je klíčem ke spolehlivosti.

"Datová vrstva je nejhůře škálovatelná" - Databáze je srdcem naší aplikace a jako každé srdce je obtížné ji omezit, aniž bychom zasáhli náš žilní systém, proto je často naším úzkým hrdlem. Na druhou stranu, čím déle jsme na trh, tím více dat zpracováváme a tím obtížnější je udržet očekávaný výkon.

Ve zmíněném článku autor upozorňuje na některé specifické aspekty architektury vysoce výkonných aplikací. V průběhu let jsme se naučili používat řešení jako např. AWS nebo Azure, ale i ti nejlepší cloud nás nechrání před námi samými. Při tvorbě aplikace se nezaměřujeme na řešení problémů, které neexistují, a dopředu je předvídáme. Proto se s mnoha problémy setkáváme později, když se naše aplikace rozrůstá. Autor článku nám poskytuje mnoho cenných rad, kde hledat optimalizaci, co je největším problémem a jak ovlivňuje vaši aplikaci. Když dám v sázku své dlouholeté zkušenosti z oboru, plně s Ianem souhlasím. Rád bych také dodal, že rady uvedené v článku platí pro každou aplikaci, kterou spravujeme. Zavedení těchto pokynů přinese výhody projekt na úrovni jeho spolehlivosti a předvídatelnosti, což je důležitá vlastnost pro. růst podnikání.

Základní informace o metrikách dodávek inženýrských služeb od Juana Pabla Buriticy

- Běžně používaná výkonnostní opatření nejsou striktně technická.

- Rychlost dodání softwaru je měřitelná, ale použité ukazatele by měly být správně interpretovány, aby optimalizace přinesla požadovaný efekt.

- Nejúčinnější tým je sehraný a dobře propojený tým - vedoucí inženýři by měli rozumět problémům a motivacím vývojářů a naopak, aby bylo dosaženo zdravého a synergického efektu.

Juan Pablo Buritica nastolil téma, které se zdá být stále nickou. Lidé, kteří řídí IT projekty, často přijímají některá opatření pro zvýšení efektivity (například základní burndown chart v JIRA), ale stále nejsou úzce provázána s dodávkami kód části a na jejich základě optimalizovat proces dodávání softwaru. Obvykle se optimalizace týká rozdělení úkolů a komunikace v rámci týmu, ale jen zřídka se sledují striktně technické ukazatele, které autor zmiňuje, např. "time to merge". V době webových háčků GitHubu a systémů pro správu úkolů otevřených integraci se tento typ přístupu stává poměrně snadno použitelným - data máte na dosah ruky, stačí po nich jen sáhnout a správně je zpracovat.

Autor správně poukazuje na skutečnost, že statistiky, které popisuje, se mohou rychle obrátit proti. vývojový tým, ale to se stává pouze tehdy, když vedoucí pracovníci plně nerozumí specifikům práce programátora. Proto je důležité, aby PM nebo PO byli technicky zdatní a dokázali vycítit, co se za jednotlivými úkoly v systému skrývá.

Moderní CTO Podcast - Episode 217 with Dan Conrad - CTO at One Identity

V době pandemie, kdy velké množství zaměstnanců přešlo na. práce na dálku nastavení, musíme věnovat ještě větší pozornost zabezpečení našich dat. Dobrým příkladem je situace, kterou uvádí Dan, kdy uživatelé používají všude stejná nebo velmi podobná hesla a neuvědomují si nebezpečí, které je s tím spojeno.

Pokud používáte stejná hesla na mnoha místech, může se stát, že některý z webů bude mít "bezpečnostní problémy", databáze unikne na internet nebo vás prostě někdo bude sledovat, jak zadáváte jedno heslo, které omylem otevře všechny vaše dveře. Podle mého názoru by vás všechny online služby měly poučit o nebezpečí spojeném se zadáváním stejného hesla při registraci.

Single Sing On (SSO) nebo používání správců hesel, jako je One Identity nebo LastPass, jsou velmi užitečné pro udržení základní online hygieny a bezpečnostních standardů, které chrání naše zaměstnance a pracoviště před zranitelností a digitálními hrozbami.

Vzděláváte své zaměstnance v oblasti rozumné správy hesel?

Děkujeme, že jste dočetli až do konce, a těšte se na další díl, který vyjde již brzy!