TheCodestReview #1 - savaitinės programinės įrangos inžinerijos sultys

Kodėl tai darome?

1. Dalijimasis žiniomis yra labai svarbus ugdant technologinius įgūdžius ir mums tai rūpi.

2. Padėti inžinerijos vadovams rasti sprendimus, reikalingus įrodymais pagrįstiems sprendimams priimti. programinės įrangos projektai.

3. Tvirtai tikime savišvietos galia, visada stengiamės išmokti naujų dalykų ir stiprinti save, 1% 

4. Internete yra daugybė puikaus techninio turinio, kuris nusipelno daugiau dėmesio, ir mes ketiname jį įvertinti.

Sukurti kelių žemėlapis šioje serijoje, aš paleisti LinkedIn apklausą paklausti CTOs ir inžinerijos vadovai apie jų pagrindinius iššūkius jau dabar pakankamai sudėtingu 2020 m. ir vėlesniu laikotarpiu.

Štai ką jie sakė: 

Be tolesnio ado, leiskite man pakviesti jus į 1st epizodas TheCodestReview su svečio įnašą iš mūsų CTO, vadovas plėtros ir Frontend Lead apimantis žemiau temas:

Šešios nykščio taisyklės, kaip padidinti Software Architectures - Ian Gorton

“Jūsų sistemoje yra kliūtis. Kažkur!” - kai kovojame, kad pagerintume taikomosios programos našumą, pamirštame apie pagrindinius sistemos apribojimus, galbūt jie nėra populiariausi taikomosios programos elementai, tačiau jie gali turėti neigiamą poveikį likusiems ir mastelio keitimas gali nepadėti mus čia.

“Stebėsena yra labai svarbi keičiamo mastelio sistemoms” - savo versle negalime būti akli, todėl mums geriau žinoti apie problemą anksčiau, nei mums apie ją praneša naudotojai arba mūsų CEO. Stebėsena yra patikimumo raktas.

“The duomenys Duomenų bazė yra sunkiausiai plečiama” - Duomenų bazė yra mūsų taikomosios programos širdis ir, kaip ir kiekvieną širdį, ją sunku sumažinti nepaveikiant venų sistemos, todėl dažnai ji yra mūsų silpnoji vieta. Kita vertus, kuo ilgiau esame rinka, kuo daugiau duomenų apdorojame, tuo sunkiau išlaikyti numatomą našumą.

Minėtame straipsnyje autorius atkreipia dėmesį į kai kuriuos specifinius didelio našumo taikomųjų programų architektūros aspektus. Bėgant metams išmokome naudoti sprendimus, pvz. AWS arba "Azure", bet net ir geriausi debesis neapsaugo mūsų nuo mūsų pačių. Kurdami taikomąją programą nesusitelkiame į tai, kad spręstume problemas, kurių nėra, iš anksto jas numatydami. Todėl su daugybe problemų susiduriame vėliau, kai mūsų taikomoji programa plečiasi. Straipsnio autorius pateikia mums daug vertingų patarimų, kur ieškoti optimizavimo, kokios yra didžiausios problemos ir kaip jos veikia jūsų taikomąją programą. Atsižvelgdamas į savo ilgametę patirtį šioje srityje, visiškai sutinku su Ianu. Taip pat norėčiau pridurti, kad straipsnyje pateikti patarimai tinka kiekvienai mūsų prižiūrimai programai. Šių rekomendacijų įgyvendinimas duos naudos projektas patikimumo ir nuspėjamumo, kuris yra svarbi savybė verslo augimas.

Juan Pablo Buritica - inžinerinių pristatymo rodiklių pradžiamokslis

- Dažniausiai naudojamos veiklos priemonės nėra griežtai techninės

- Programinės įrangos pristatymo greitį galima išmatuoti, tačiau, kad optimizavimas duotų norimą rezultatą, reikia tinkamai interpretuoti naudojamus rodiklius.

- Veiksmingiausias komanda yra gerai koordinuota ir tarpusavyje susijusi team - inžinerijos vadovai turėtų suprasti kūrėjų problemas ir motyvaciją ir atvirkščiai, kad būtų pasiektas sveikas ir sinerginis poveikis.

Juan Pablo Buritica iškėlė temą, kuri vis dar atrodo nišinė. IT projektus valdantys žmonės dažnai taiko tam tikras efektyvumo priemones (pvz., pagrindinę "Burndown" diagramą JIRA), tačiau jos vis dar nėra glaudžiai susietos su pristatymų kodas dalių, kad pagal jas būtų galima optimizuoti programinės įrangos pristatymo procesą. Paprastai optimizavimas susijęs su užduočių paskirstymu ir bendravimu team viduje, tačiau retai stebimi griežtai techniniai rodikliai, kuriuos mini autorius, pavyzdžiui, ‘laikas iki sujungimo’. GitHub eroje žiniatinklio svetainė kabliukų ir užduočių valdymo sistemų, kurias galima integruoti, tokį požiūrį palyginti lengva taikyti - duomenys yra po ranka, tereikia juos pasiekti ir tinkamai apdoroti.

Autorius pagrįstai atkreipia dėmesį į tai, kad jo aprašyti statistiniai duomenys gali greitai atsigręžti prieš kūrimo komanda, tačiau taip atsitinka tik tada, kai vadovaujantieji darbuotojai nevisiškai supranta programuotojo darbo specifiką. Todėl svarbu, kad PM arba PO būtų techniškai išprusęs ir gebėtų pajusti, kas slypi už atskirų sistemos užduočių.

Šiuolaikinis CTO Podcast - 217 epizodas su Dan Conrad - CTO vienoje tapatybėje

Pandemijos laikais, kai daug darbuotojų perėjo prie nuotolinis darbas nustatymas, turime skirti dar daugiau dėmesio savo duomenų saugumui. Geras pavyzdys - Dano minėta situacija, kai naudotojai visur naudoja tuos pačius arba labai panašius slaptažodžius ir nesuvokia su tuo susijusio pavojaus.

Jei tuos pačius slaptažodžius naudosite daugelyje vietų, gali nutikti taip, kad vienoje iš svetainių kils “saugumo problemų”, duomenų bazė nutekės į internetą arba tiesiog kas nors stebės, kaip įvedate vieną slaptažodį, kuris netyčia atidaro visas duris. Mano nuomone, visos interneto paslaugos turėtų jus informuoti apie pavojų, susijusį su to paties slaptažodžio įvedimu registruojantis.

Vienkartinis prisijungimas (SSO) arba slaptažodžių tvarkyklių, tokių kaip "One Identity" ar "LastPass", naudojimas yra labai naudingas siekiant užtikrinti pagrindinius interneto higienos ir saugumo standartus, apsaugoti darbuotojus ir darbo vietas nuo pažeidžiamumo ir skaitmeninių grėsmių.

Ar mokote darbuotojus, kaip atidžiai valdyti slaptažodžius?

Ačiū, kad skaitėte iki galo, ir laukite kito epizodo, kuris pasirodys netrukus!