TORNA INDIETRO
È passato un po' di tempo da quando abbiamo messo in pausa la nostra rassegna settimanale di articoli tecnici interessanti, probabilmente a causa del sovraccarico di progetti. Ciononostante, siamo di nuovo qui con la missione di trovare, recensire e distribuire settimanalmente contenuti di grande valore per i responsabili dell'ingegneria e gli sviluppatori di software.
La condivisione delle conoscenze è fondamentale per sviluppare le competenze tecnologiche e noi ci teniamo.
Per aiutare i responsabili dell'ingegneria a trovare le soluzioni di cui hanno bisogno per prendere decisioni basate sulle evidenze scientifiche. progetti software.
Crediamo fermamente nel potere dell'autoformazione, cercando sempre di imparare cose nuove e di rafforzarci, 1% alla volta.
Ci sono tonnellate di ottimi contenuti tecnologici online che meritano maggiore attenzione e noi stiamo per dare credito a ciò che è dovuto.
Costruire un mappa stradale per questa serie, ho fatto un sondaggio su LinkedIn per chiedere CTOs e i responsabili dell'ingegneria sulle loro sfide principali in un 2020 già abbastanza difficile e oltre.
Ecco cosa hanno detto:
"Il vostro sistema ha un collo di bottiglia. Da qualche parte!" - quando lottiamo per migliorare le prestazioni dell'applicazione, ci dimentichiamo delle limitazioni chiave del sistema, che forse non sono gli elementi più popolari dell'applicazione, ma possono avere un effetto negativo sul resto e la scalabilità potrebbe non aiutarci.
"Il monitoraggio è fondamentale per i sistemi scalabili": non possiamo essere ciechi nella nostra attività ed è meglio per noi conoscere il problema prima che ci venga segnalato dagli utenti o dal nostro CEO. Il monitoraggio è la chiave dell'affidabilità.
"Il data tier è il più difficile da scalare" - Il database è il cuore della nostra applicazione e, come ogni cuore, è difficile tagliarlo senza intaccare il sistema venoso, quindi è spesso il nostro collo di bottiglia. D'altra parte, quanto più a lungo siamo sul mercatopiù dati vengono elaborati e più è difficile mantenere le prestazioni previste.
Nell'articolo citato, l'autore evidenzia alcuni aspetti specifici dell'architettura delle applicazioni ad alte prestazioni. Nel corso degli anni, abbiamo imparato a usare soluzioni come AWS o Azure, ma anche le migliori nuvola non ci protegge da noi stessi. Quando creiamo un'applicazione, non ci concentriamo sulla risoluzione di problemi assenti, prevedendoli in anticipo. Pertanto, quando la nostra applicazione cresce, incontriamo molti problemi in seguito. L'autore dell'articolo ci fornisce molti consigli preziosi su dove cercare l'ottimizzazione, su quale sia il problema più grande e su come influisca sulla vostra applicazione. Mettendo in gioco i miei molti anni di esperienza nel settore, sono pienamente d'accordo con Ian. Vorrei anche aggiungere che i consigli forniti nell'articolo si applicano a tutte le applicazioni che gestiamo. L'implementazione di queste linee guida porterà benefici al progetto a livello di affidabilità e prevedibilità, che è una caratteristica importante per la crescita delle imprese.
- Le misure di performance comunemente utilizzate non sono strettamente tecniche
- La velocità di consegna del software è misurabile, ma gli indicatori utilizzati devono essere interpretati correttamente affinché l'ottimizzazione ottenga l'effetto desiderato.
- Il più efficace squadra è un team ben coordinato e ben collegato - i responsabili dell'ingegneria devono comprendere i problemi e le motivazioni degli sviluppatori e viceversa per ottenere effetti sani e sinergici.
Juan Pablo Buritica ha sollevato un argomento che sembra ancora di nicchia. Le persone che gestiscono i progetti IT spesso adottano alcune misure di efficienza (come il grafico di burndown di base in JIRA), ma non sono ancora strettamente correlate con le consegne dei progetti. codice per ottimizzare il processo di consegna del software sulla base di questi indicatori. Di solito, l'ottimizzazione riguarda la distribuzione dei compiti e la comunicazione all'interno del team, ma è raro tracciare indicatori strettamente tecnici che l'autore cita, ad esempio il "tempo di fusione". Nell'era degli agganci web di GitHub e dei sistemi di gestione delle attività aperti all'integrazione, questo tipo di approccio diventa relativamente facile da applicare: i dati sono a portata di mano, basta raggiungerli ed elaborarli nel modo giusto.
L'autore fa giustamente notare che le statistiche che descrive possono rapidamente ritorcersi contro l'autore. team di sviluppoMa questo accade solo quando il personale di gestione non comprende appieno le specificità del lavoro del programmatore. Pertanto, è importante che il PM o il PO siano esperti di tecnica e in grado di capire cosa c'è dietro le singole attività del sistema.
Nell'era di una pandemia, in cui un gran numero di dipendenti è passato alla lavoro a distanza dobbiamo prestare ancora più attenzione alla sicurezza dei nostri dati. Un buon esempio è la situazione citata da Dan, in cui gli utenti utilizzano ovunque le stesse password o password molto simili, senza rendersi conto del pericolo che vi è associato.
Se utilizzate le stesse password in molti posti, può succedere che uno dei siti abbia "problemi di sicurezza", che il database trapeli su Internet o semplicemente che qualcuno vi guardi digitare una password che accidentalmente apre tutte le vostre porte. A mio parere, tutti i servizi online dovrebbero informare l'utente del pericolo associato all'inserimento della stessa password durante il processo di registrazione.
Il Single Sing On (SSO) o l'utilizzo di password manager come One Identity o LastPass sono molto utili per mantenere gli standard di igiene e sicurezza online di base, proteggendo i nostri dipendenti e i luoghi di lavoro da vulnerabilità e minacce digitali.
Educate i vostri dipendenti a una gestione consapevole delle password?
Grazie per aver letto fino alla fine e rimanete sintonizzati per il prossimo episodio in arrivo!
Italian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Japanese 
Korean 
Polish