TAGASI
Oleme juba mõnda aega pannud pausi meie iganädalasele ülevaatlikule tehnikaartiklite ülevaatele, ilmselt projektitööde ülekoormuse tõttu. Sellegipoolest läheme taas missioonile, et leida, üle vaadata ja pakkuda teile iganädalaselt väga väärtuslikku sisu insenerijuhtidele ja tarkvaraarendajatele.
Teadmiste jagamine on tehniliste oskuste arendamisel väga oluline ja me hoolime sellest.
Selleks, et aidata inseneride juhtidel leida lahendusi, mida nad vajavad tõenduspõhiste otsuste tegemiseks oma tarkvaraprojektid.
Me usume kindlalt enesehariduse jõusse, püüdes alati õppida uusi asju ja tugevdada ennast, 1% korraga.
Internetis on hulgaliselt suurepärast tehnilist sisu, mis väärivad rohkem tähelepanu ja me tahame anda tunnustust, kui see on vajalik.
Ehitades üles teekaart selle seeria jaoks olen käivitanud LinkedIni küsitluse, et küsida CTOs ja inseneride juhid oma peamistest väljakutsetest juba piisavalt keerulises 2020. aastal ja kaugemalgi.
Siin on see, mida nad ütlesid:
"Teie süsteemis on kitsaskoht. Kusagil!" - kui me võitleme rakenduse jõudluse parandamise nimel, unustame ära süsteemi peamised piirangud, võib-olla ei ole need rakenduse kõige populaarsemad elemendid, kuid need võivad avaldada negatiivset mõju ülejäänud elementidele ja skaalamine ei pruugi meid siinkohal aidata.
"Seire on oluline skaleeritavate süsteemide jaoks" - me ei saa olla oma tegevuses pimedad ja on parem, kui me teame probleemist enne, kui meid teavitavad sellest kasutajad või meie CEO. Seire on töökindluse võti.
"Andmetasand on kõige raskemini skaleeritav" - Andmebaas on meie rakenduse süda ja nagu iga südant, on ka seda raske kärpida, ilma et see mõjutaks meie veenisüsteemi, mistõttu on see sageli meie kitsaskoht. Teisest küljest, mida kauem me oleme turg, mida rohkem andmeid me töötleme ja mida raskem on säilitada eeldatavat jõudlust.
Nimetatud artiklis toob autor välja mõned kõrgtehnoloogilise rakendusarhitektuuri spetsiifilised aspektid. Aastate jooksul oleme õppinud kasutama selliseid lahendusi nagu AWS või Azure, kuid isegi parimad pilv ei kaitse meid iseenda eest. Rakenduse loomisel ei keskendu me probleemide lahendamisele, mis puuduvad, neid ette nähes. Seetõttu puutume hiljem, kui meie rakendus kasvab, kokku paljude probleemidega. Artikli autor annab meile palju väärtuslikke näpunäiteid, kust otsida optimeerimist, mis on suurim probleem ja kuidas see mõjutab teie rakendust. Pannes oma aastatepikkuse kogemuse tööstuses maksma, nõustun Iaaniga täielikult. Samuti tahaksin lisada, et artiklis esitatud nõuanded kehtivad iga rakenduse kohta, mida me hooldame. Nende suuniste rakendamine toob kasu projekt selle usaldusväärsuse ja prognoositavuse tasandil, mis on ettevõtte kasvu jaoks oluline omadus.
- Tavaliselt kasutatavad tulemusnäitajad ei ole rangelt tehnilised
- Tarkvara tarnimise kiirus on mõõdetav, kuid optimeerimiseks tuleks kasutatud näitajaid õigesti tõlgendada, et saavutada soovitud mõju.
- Kõige tõhusamad meeskond on hästi koordineeritud ja hästi seotud meeskond - inseneride juhid peaksid mõistma arendajate probleeme ja motivatsiooni ning vastupidi, et saavutada terve ja sünergiline mõju.
Juan Pablo Buritica on tõstatanud teema, mis näib olevat endiselt nišš. IT-projekte haldavad inimesed võtavad sageli kasutusele mõned tõhususe meetmed (nagu näiteks JIRA põhiline burndown-diagramm), kuid need ei ole ikka veel tihedalt seotud tarnetega. kood osad, et optimeerida nende põhjal tarkvara tarnimise protsessi. Tavaliselt puudutab optimeerimine ülesannete jaotust ja suhtlemist meeskonnas, kuid harva jälgitakse ka rangelt tehnilisi näitajaid, mida autor mainib, nt "aeg ühinemiseks". GitHubi veebikonksude ja integratsioonile avatud ülesannete haldamise süsteemide ajastul muutub seda tüüpi lähenemine suhteliselt lihtsasti rakendatavaks - andmed on käeulatuses, tuleb vaid nende järele haarata ja neid õigesti töödelda.
Autor juhib õigesti tähelepanu sellele, et tema kirjeldatud statistika võib kiiresti pöörduda vastu arendusmeeskond, kuid see juhtub ainult siis, kui juhtkond ei mõista täielikult programmeerija töö spetsiifikat. Seetõttu on oluline, et PM või PO oleks tehniliselt taibukas ja suudaks tajuda, mis on süsteemi üksikute ülesannete taga.
Pandeemia ajastul, mil suur hulk töötajaid on üle läinud kaugtöö seadistamisel peame pöörama veelgi rohkem tähelepanu oma andmete turvalisusele. Hea näide on Dani poolt viidatud olukord, kus kasutajad kasutavad kõikjal samu või väga sarnaseid paroole ega ole teadlikud sellega seotud ohust.
Kui kasutate samu paroole paljudes kohtades, võib juhtuda, et ühel saitidel on "turvaprobleemid", andmebaas lekib internetti või lihtsalt keegi vaatab, kuidas te sisestate ühe parooli, mis avab kogemata kõik teie uksed. Minu arvates peaksid kõik veebiteenused teid teavitama ohust, mis on seotud sama salasõna sisestamisega registreerimise ajal.
Single Sing On (SSO) või paroolihaldurite nagu One Identity või LastPass kasutamine on väga kasulik, et hoida põhilisi veebihügieeni- ja turvastandardeid, kaitstes meie töötajaid ja töökohti haavatavuste ja digitaalsete ohtude eest.
Kas te õpetate oma töötajatele teadlikku paroolihaldust?
Aitäh, et lugesite lõpuni ja jääge ootama järgmist episoodi, mis on peagi tulemas!
Estonian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Greek