TheCodestReview #1 - ugentlig software engineering juice

Hvorfor gør vi det?

1. Deling af viden er afgørende for at udvikle tekniske færdigheder, og vi er ikke ligeglade.

2. At hjælpe tekniske ledere med at finde de løsninger, de har brug for til at træffe evidensbaserede beslutninger i deres softwareprojekter.

3. Vi tror stærkt på kraften i selvuddannelse og stræber altid efter at lære nye ting og styrke os selv, 1% ad gangen. 

4. Der er masser af godt tech-indhold online, som fortjener mere opmærksomhed, og vi er ved at give kredit, hvor det er på sin plads

Opbygning af en køreplan Til denne serie har jeg lavet en LinkedIn-undersøgelse for at spørge CTO'er og tekniske ledere om deres vigtigste udfordringer i det allerede vanskelige 2020 og fremover.

Her er, hvad de sagde: 

Lad mig uden videre invitere dig til 1. episode af TheCodestReview med gæstebidrag fra vores CTO, Head of Development and Frontend Lead, der dækker nedenstående emner:

Seks tommelfingerregler for skalering af Software Architectures af Ian Gorton

"Dit system har en flaskehals. Et eller andet sted!" - Når vi kæmper for at forbedre applikationens ydeevne, glemmer vi de vigtigste begrænsninger i systemet, måske er de ikke de mest populære elementer i applikationen, men de kan have en negativ effekt på resten, og skalering hjælper os måske ikke her.

"Overvågning er grundlæggende for skalerbare systemer" - vi kan ikke være blinde i vores forretning, og det er bedre for os at kende til problemet, før vi bliver informeret om det af brugerne eller vores CEO. Overvågning er nøglen til pålidelighed.

"Dataniveauet er det sværeste at skalere" - Databasen er hjertet i vores applikation, og som ethvert hjerte er det svært at skære i den uden at påvirke vores venesystem, og derfor er den ofte vores flaskehals. På den anden side, jo længere vi er på markedjo flere data vi behandler, og jo sværere er det at opretholde den forventede ydeevne.

I den nævnte artikel fremhæver forfatteren nogle specifikke aspekter af højtydende applikationsarkitektur. I årenes løb har vi lært at bruge løsninger som f.eks. AWS eller Azure, men selv den bedste sky beskytter os ikke mod os selv. Når vi skaber en applikation, fokuserer vi ikke på at løse problemer, der ikke findes, og forudse dem på forhånd. Derfor støder vi på en masse problemer senere, når vores applikation vokser. Artiklens forfatter giver os mange værdifulde tips til, hvor vi skal lede efter optimering, hvad der er det største problem, og hvordan det påvirker din applikation. Med mine mange års erfaring i branchen er jeg helt enig med Ian. Jeg vil også gerne tilføje, at de råd, der gives i artiklen, gælder for alle de applikationer, vi vedligeholder. Implementering af disse retningslinjer vil give fordele for projekt på niveauet for dens pålidelighed og forudsigelighed, som er en vigtig funktion for forretningsvækst.

En grundbog om tekniske leveringsmålinger af Juan Pablo Buritica

- Almindeligt anvendte præstationsmål er ikke strengt tekniske

- Hastigheden af softwarelevering er målbar, men de anvendte indikatorer skal fortolkes korrekt, for at optimeringen får den ønskede effekt.

- Den mest effektive hold er et velkoordineret og velforbundet team - tekniske ledere bør forstå udviklernes problemer og motivation og omvendt for at opnå sunde og synergiske effekter.

Juan Pablo Buritica har taget et emne op, som stadig synes at være en niche. Folk, der leder IT-projekter, anvender ofte nogle effektivitetsforanstaltninger (som f.eks. det grundlæggende burndown-diagram i JIRA), men de er stadig ikke tæt forbundet med leverancerne af Kode dele for at optimere softwareleveringsprocessen baseret på dem. Normalt handler optimering om fordeling af opgaver og kommunikation i teamet, men det er sjældent, at man sporer rent tekniske indikatorer, som forfatteren nævner, f.eks. "tid til fusion". I en tid med GitHub-webhooks og task management-systemer, der er åbne for integration, bliver denne type tilgang relativt let at anvende - data er lige ved hånden, du skal bare række ud efter dem og behandle dem på den rigtige måde.

Forfatteren peger med rette på, at de statistikker, han beskriver, hurtigt kan vende sig mod den udviklingsteammen det sker kun, når ledelsen ikke helt forstår detaljerne i programmørens arbejde. Derfor er det vigtigt, at PM eller PO er teknisk kyndige og i stand til at fornemme, hvad der ligger bag de enkelte opgaver i systemet.

Moderne CTO Podcast - Afsnit 217 med Dan Conrad - CTO at One Identity

I en tid med en pandemi, hvor et stort antal medarbejdere har skiftet til fjernarbejde opsætning skal vi være endnu mere opmærksomme på sikkerheden af vores data. Et godt eksempel er den situation, som Dan nævner, hvor brugere bruger de samme eller meget lignende adgangskoder overalt og ikke er klar over den fare, der er forbundet med det.

Hvis du bruger de samme adgangskoder mange steder, kan det ske, at en af siderne får "sikkerhedsproblemer", at databasen bliver lækket til internettet, eller at nogen ser dig skrive en adgangskode, der ved et uheld åbner alle dine døre. Efter min mening bør alle onlinetjenester oplyse dig om den fare, der er forbundet med at indtaste den samme adgangskode under tilmeldingsprocessen.

Single Sing On (SSO) eller brug af adgangskodeadministratorer som One Identity eller LastPass er meget nyttige til at opretholde den grundlæggende onlinehygiejne og sikkerhedsstandarder og beskytte vores medarbejdere og arbejdspladser mod sårbarheder og digitale trusler.

Uddanner du dine medarbejdere i bevidst password management?

Tak, fordi du læste med til sidst, og hold øje med næste afsnit, der kommer snart!