TheCodestReview #1 - wekelijks software engineering sap

Waarom doen we het?

1. Het delen van kennis is cruciaal voor het ontwikkelen van technische vaardigheden en dat vinden we belangrijk.

2. Om leiders in engineering te helpen oplossingen te vinden die ze nodig hebben om op feiten gebaseerde beslissingen te nemen in hun softwareprojecten.

3. We geloven sterk in de kracht van zelfstudie, streven er altijd naar om nieuwe dingen te leren en onszelf te versterken, 1% per keer. 

4. Er zijn tonnen aan geweldige technische content online die meer aandacht verdienen en we staan op het punt om de eer te geven die het toekomt

Een routekaart Voor deze serie heb ik een LinkedIn enquête gehouden om te vragen CTOs en engineering managers over hun belangrijkste uitdagingen in het al moeilijk genoeg 2020 en daarna.

Dit is wat ze zeiden: 

Zonder verder oponthoud nodig ik je uit voor de 1e aflevering van TheCodestReview met gastbijdragen van onze CTO, Head of Development en Frontend Lead over de volgende onderwerpen:

Zes vuistregels voor het schalen van Software Architectures door Ian Gorton

"Je systeem heeft een knelpunt. Ergens!" - Wanneer we vechten om de prestaties van de applicatie te verbeteren, vergeten we de belangrijkste beperkingen in het systeem, misschien zijn het niet de meest populaire elementen van de applicatie, maar ze kunnen een negatief effect hebben op de rest en schalen kan ons hier niet helpen.

"Monitoring is fundamenteel voor schaalbare systemen" - we kunnen niet blind zijn in onze business en het is beter voor ons om op de hoogte te zijn van een probleem voordat we er door gebruikers of onze CEO over worden geïnformeerd. Monitoring is de sleutel tot betrouwbaarheid.

"De gegevenslaag is het moeilijkst te schalen" - De database is het hart van onze applicatie en net als elk hart is het moeilijk om erin te snijden zonder ons aderstelsel aan te tasten en daarom is het vaak onze bottleneck. Aan de andere kant, hoe langer we bezig zijn met de marktHoe meer gegevens we verwerken en hoe moeilijker het is om de verwachte prestaties te handhaven.

In het genoemde artikel belicht de auteur enkele specifieke aspecten van een krachtige applicatiearchitectuur. In de loop der jaren hebben we geleerd om oplossingen te gebruiken zoals AWS of Azure, maar zelfs de beste cloud beschermt ons niet tegen onszelf. Bij het maken van een applicatie richten we ons niet op het oplossen van problemen die er niet zijn, we voorzien ze niet van tevoren. Daarom komen we later veel problemen tegen wanneer onze applicatie groeit. De auteur van het artikel geeft ons veel waardevolle tips over waar we moeten zoeken naar optimalisatie, wat het grootste probleem is en hoe dit je applicatie beïnvloedt. Met mijn jarenlange ervaring in de branche ben ik het volledig eens met Ian. Ik wil ook graag toevoegen dat het advies in het artikel van toepassing is op elke applicatie die we onderhouden. Het implementeren van deze richtlijnen zal voordelen opleveren voor de project op het niveau van betrouwbaarheid en voorspelbaarheid, wat een belangrijk kenmerk is voor bedrijfsgroei.

Een inleiding op engineering delivery metrics door Juan Pablo Buritica

- Veelgebruikte prestatiemetingen zijn niet strikt technisch

- De snelheid van softwarelevering is meetbaar, maar de gebruikte indicatoren moeten goed geïnterpreteerd worden om het gewenste effect te bereiken.

- De meest effectieve team is een goed gecoördineerd en goed verbonden team - engineering leiders moeten de problemen en motivaties van ontwikkelaars begrijpen en vice versa om gezonde en synergetische effecten te bereiken.

Juan Pablo Buritica heeft een onderwerp aangesneden dat nog steeds een niche lijkt te zijn. Mensen die IT-projecten managen, nemen vaak een aantal efficiëntiemaatregelen (zoals de basis burndown grafiek in JIRA), maar deze zijn nog steeds niet nauw gecorreleerd met de opleveringen van code onderdelen om op basis daarvan het software delivery proces te optimaliseren. Meestal heeft optimalisatie betrekking op de verdeling van taken en communicatie binnen het team, maar het is zeldzaam om strikt technische indicatoren te volgen die de auteur noemt, bijvoorbeeld 'tijd tot samenvoegen'. In het tijdperk van GitHub web hooks en taakbeheersystemen die openstaan voor integratie, is dit type aanpak relatief eenvoudig toe te passen - gegevens zijn binnen handbereik, je hoeft er alleen maar naar te reiken en ze op de juiste manier te verwerken.

De auteur wijst er terecht op dat de statistieken die hij beschrijft zich snel kunnen keren tegen de ontwikkelingsteamMaar dit gebeurt alleen als het management de details van het werk van de programmeur niet volledig begrijpt. Daarom is het belangrijk dat de PM of PO technisch onderlegd is en kan aanvoelen wat er achter individuele taken in het systeem zit.

Moderne CTO Podcast - Aflevering 217 met Dan Conrad - CTO bij One Identity

In het tijdperk van een pandemie waarbij een groot aantal werknemers is overgestapt op telewerk setup moeten we nog meer aandacht besteden aan de beveiliging van onze gegevens. Een goed voorbeeld is de door Dan aangehaalde situatie waarin gebruikers overal dezelfde of zeer vergelijkbare wachtwoorden gebruiken en zich niet bewust zijn van het gevaar dat daarmee gepaard gaat.

Als je op veel plaatsen dezelfde wachtwoorden gebruikt, kan het gebeuren dat een van de sites "beveiligingsproblemen" heeft, dat de database lekt naar het internet of dat iemand je één wachtwoord ziet intypen dat per ongeluk al je deuren opent. Naar mijn mening zouden alle online diensten je moeten informeren over het gevaar dat gepaard gaat met het invoeren van hetzelfde wachtwoord tijdens het aanmeldingsproces.

Single Sing On (SSO) of het gebruik van wachtwoordmanagers zoals One Identity of LastPass zijn zeer nuttig om de basis online hygiëne en beveiligingsstandaarden te behouden, en onze werknemers en werkplekken te beschermen tegen kwetsbaarheden en digitale bedreigingen.

Geeft u uw werknemers voorlichting over verstandig wachtwoordbeheer?

Bedankt voor het lezen tot het einde en blijf luisteren naar de volgende aflevering!