TheCodestReview #1 - veckovis juice för mjukvaruutveckling

Varför gör vi det?

1. Att dela kunskap är avgörande för att utveckla tekniska färdigheter och vi bryr oss om det.

2. För att hjälpa tekniska ledare att hitta lösningar som de behöver för att fatta evidensbaserade beslut i sina mjukvaruprojekt.

3. Vi tror starkt på kraften i självutbildning och strävar alltid efter att lära oss nya saker och stärka oss själva, 1% åt gången 

4. Det finns massor av bra teknikinnehåll på nätet som förtjänar mer uppmärksamhet och vi är på väg att ge beröm där det förtjänas

Uppbyggnad av en Färdplan för denna serie har jag genomfört en LinkedIn-enkät för att fråga CTO:er och teknikchefer om deras viktigaste utmaningar i redan svåra nog 2020 och därefter.

Här är vad de sa: 

Utan vidare, låt mig bjuda in dig till det första avsnittet av TheCodestReview med gästbidrag från vår CTO, Head of Development och Frontend Lead som täcker nedan ämnen:

Sex tumregler för skalning av Software Architectures av Ian Gorton

"Ditt system har en flaskhals. Någonstans!" - när vi kämpar för att förbättra applikationens prestanda glömmer vi bort de viktigaste begränsningarna i systemet, kanske är de inte de mest populära elementen i applikationen, men de kan ha en negativ effekt på resten och skalning kanske inte hjälper oss här.

"Övervakning är grundläggande för skalbara system" - vi kan inte vara blinda i vår verksamhet och det är bättre för oss att känna till problemet innan vi blir informerade om det av användare eller vår CEO. Övervakning är nyckeln till tillförlitlighet.

"Datalagret är svårast att skala" - Databasen är hjärtat i vår applikation och precis som med alla hjärtan är det svårt att skära i den utan att påverka vårt venösa system, därför är den ofta vår flaskhals. Å andra sidan, ju längre vi är på marknadJu mer data vi behandlar, desto svårare är det att upprätthålla den förväntade prestandan.

I den nämnda artikeln lyfter författaren fram några specifika aspekter av högpresterande applikationsarkitektur. Under årens lopp har vi lärt oss att använda lösningar som AWS eller Azure, men även de bästa moln skyddar oss inte från oss själva. När vi skapar en applikation fokuserar vi inte på att lösa problem som inte finns och förutse dem på förhand. Därför stöter vi på en hel del problem senare när vår applikation växer. Artikelförfattaren ger oss många värdefulla tips om var vi ska leta efter optimering, vad som är det största problemet och hur det påverkar din applikation. Med min mångåriga erfarenhet av branschen i ryggen håller jag helt med Ian. Jag skulle också vilja tillägga att de råd som ges i artikeln gäller för alla applikationer vi underhåller. Att implementera dessa riktlinjer kommer att ge fördelar för projekt på nivån av dess tillförlitlighet och förutsägbarhet, vilket är en viktig egenskap för företagens tillväxt.

En grundkurs om tekniska leveransmått av Juan Pablo Buritica

- Vanligt förekommande prestationsmått är inte strikt tekniska

- Programvaruleveransens hastighet är mätbar, men de indikatorer som används måste tolkas korrekt för att optimeringen ska få önskad effekt

- Den mest effektiva Team är ett väl samordnat och väl sammanlänkat team - tekniska ledare bör förstå utvecklarnas problem och motiv och vice versa för att uppnå hälsosamma och synergiska effekter.

Juan Pablo Buritica har tagit upp ett ämne som fortfarande verkar vara nischat. Människor som hanterar IT-projekt antar ofta vissa effektivitetsåtgärder (till exempel det grundläggande burndown-diagrammet i JIRA), men de är fortfarande inte nära korrelerade med leveranserna av kod delar för att optimera mjukvaruleveransprocessen baserat på dem. Vanligtvis handlar optimering om fördelningen av uppgifter och kommunikation inom teamet, men det är sällsynt att spåra strikt tekniska indikatorer som författaren nämner, t.ex. "tid till sammanslagning". I en tid med GitHub-webbkrokar och uppgiftshanteringssystem som är öppna för integration blir den här typen av tillvägagångssätt relativt enkelt att tillämpa - data finns till hands, du behöver bara nå dem och bearbeta dem på rätt sätt.

Författaren påpekar med rätta att den statistik han beskriver snabbt kan vända sig mot den utvecklingsteammen detta händer bara när ledningen inte fullt ut förstår detaljerna i programmerarens arbete. Därför är det viktigt att PM eller PO är tekniskt kunnig och kan känna av vad som ligger bakom enskilda uppgifter i systemet.

Modern CTO Podcast - Avsnitt 217 med Dan Conrad - CTO på One Identity

I en tid av pandemi där ett stort antal anställda har bytt till distansarbete måste vi ägna ännu mer uppmärksamhet åt säkerheten för våra data. Ett bra exempel är den situation som Dan nämner, där användare använder samma eller mycket liknande lösenord överallt och inte är medvetna om den fara som är förknippad med det.

Om du använder samma lösenord på många ställen kan det hända att en av webbplatserna får "säkerhetsproblem", att databasen läcker ut på Internet eller att någon ser dig skriva in ett lösenord som av misstag öppnar alla dina dörrar. Enligt min mening borde alla onlinetjänster upplysa dig om riskerna med att ange samma lösenord när du registrerar dig.

Single Sing On (SSO) eller användning av lösenordshanterare som One Identity eller LastPass är mycket användbara för att upprätthålla grundläggande hygien- och säkerhetsstandarder online och skydda våra medarbetare och arbetsplatser från sårbarheter och digitala hot.

Utbildar du dina anställda i hur man hanterar lösenord på ett bra sätt?

Tack för att du läste ända till slutet och håll ögonen öppna för nästa avsnitt som kommer snart!