TheCodestReview #1 - iknedēļas programmatūras inženierijas sula

Kāpēc mēs to darām?

1. Dalīšanās ar zināšanām ir ļoti svarīga, lai attīstītu tehniskās prasmes, un mums tas rūp.

2. Lai palīdzētu inženierzinātņu jomas vadītājiem atrast risinājumus, kas nepieciešami, lai pieņemtu uz pierādījumiem balstītus lēmumus savā programmatūras projekti.

3. Mēs stingri ticam pašizglītības spēkam, vienmēr cenšamies apgūt jaunas lietas un stiprināt sevi, 1% pēc kārtas. 

4. Tīmeklī ir daudz lieliska tehnoloģiju satura, kas ir pelnījis vairāk uzmanības, un mēs gatavojamies dot kredītu, kur tas pienākas.

Izveidot ceļa karte šai sērijai es esmu veicis LinkedIn aptauju, lai jautātu. CTOs un inženiertehnisko darbu vadītāji par viņu galvenajiem izaicinājumiem jau tā pietiekami sarežģītajā 2020. gadā un turpmāk.

Lūk, ko viņi teica: 

Bez papildu ado, Ļaujiet man jūs uzaicināt uz 1. epizode TheCodestReview ar viesu ieguldījumu no mūsu CTO, Attīstības vadītājs un Frontend Lead aptver zemāk tēmas:

Seši īkšķa noteikumi Software Architectures mērogošanai - Ian Gorton

“Jūsu sistēmā ir vāja vieta. Kaut kur!” - kad mēs cīnāmies, lai uzlabotu lietojumprogrammas veiktspēju, mēs aizmirstam par galvenajiem sistēmas ierobežojumiem, varbūt tie nav vispopulārākie lietojumprogrammas elementi, bet tie var negatīvi ietekmēt pārējos, un mērogošana var nepalīdzēt. mums šeit.

“Uzraudzība ir būtiska mērogojamām sistēmām” - mēs nevaram būt akli savā biznesā, un mums ir labāk zināt par problēmu, pirms mūs par to informē lietotāji vai mūsu. CEO. Uzraudzība ir uzticamības atslēga.

“The dati līmenis ir visgrūtāk mērogojamais” - Datu bāze ir mūsu lietojumprogrammas sirds, un, tāpat kā jebkuru sirdi, to ir grūti sagriezt, neietekmējot mūsu venozo sistēmu, tāpēc bieži vien tā ir mūsu vājākais posms. No otras puses, jo ilgāk mēs esam uz tirgus, jo vairāk datu apstrādājam un jo grūtāk ir saglabāt gaidīto veiktspēju.

Minētajā rakstā autors izceļ dažus specifiskus augstas veiktspējas lietojumprogrammu arhitektūras aspektus. Gadu gaitā esam iemācījušies izmantot tādus risinājumus kā, piem. AWS vai Azure, bet pat vislabākais mākonis neaizsargā mūs no mums pašiem. Veidojot lietojumprogrammu, mēs nekoncentrējamies uz neesošu problēmu risināšanu, iepriekš tās paredzot. Tāpēc mēs saskaramies ar daudzām problēmām vēlāk, kad mūsu lietojumprogramma aug. Raksta autors sniedz mums daudz vērtīgu padomu par to, kur meklēt optimizāciju, kas ir lielākā problēma un kā tā ietekmē lietojumprogrammu. Ņemot vērā savu ilggadējo pieredzi šajā nozarē, es pilnībā piekrītu Ianam. Vēlos arī piebilst, ka rakstā sniegtie padomi attiecas uz katru lietojumprogrammu, ko mēs uzturam. Šo vadlīniju īstenošana dos labumu projekts uzticamības un prognozējamības līmenī, kas ir svarīga iezīme, lai uzņēmējdarbības izaugsme.

Juan Pablo Buritica (Juan Pablo Buritica) - inženierzinātņu piegādes metriku praimeris

- Bieži izmantotie darbības rādītāji nav stingri tehniski.

- Programmatūras piegādes ātrums ir izmērāms, taču, lai optimizācija dotu vēlamo rezultātu, izmantotie rādītāji ir pareizi jāinterpretē.

- Visefektīvākais komanda ir labi koordinēta un labi saistīta team - inženierzinātņu vadītājiem jāizprot izstrādātāju problēmas un motivācija un otrādi, lai panāktu veselīgu un sinerģisku efektu.

Juan Pablo Buritica ir aktualizējis tēmu, kas joprojām šķiet nišas jautājums. Cilvēki, kas pārvalda IT projektus, bieži vien pieņem dažus efektivitātes pasākumus (piemēram, pamata burndown diagrammu JIRA), bet tie joprojām nav cieši saistīti ar piegādēm. kods daļas, lai optimizētu programmatūras piegādes procesu, pamatojoties uz tām. Parasti optimizācija attiecas uz uzdevumu sadalījumu un komunikāciju team ietvaros, bet reti tiek sekots līdzi stingri tehniskiem rādītājiem, ko min autors, piemēram, ‘laiks līdz apvienošanai’. GitHub laikmetā tīmekļa vietne āķi un uzdevumu pārvaldības sistēmas ir atvērtas integrācijai, šāda veida pieeja kļūst salīdzinoši viegli piemērojama - dati ir rokas stiepiena attālumā, tikai tie ir jāsasniedz un jāapstrādā pareizā veidā.

Autors pamatoti norāda uz to, ka viņa aprakstītā statistika var ātri vērsties pret. izstrādes komanda, bet tas notiek tikai tad, ja vadības darbinieki pilnībā neizprot programmētāja darba specifiku. Tāpēc ir svarīgi, lai PM vai PO būtu tehniski zinošs un spētu sajust, kas slēpjas aiz atsevišķiem uzdevumiem sistēmā.

Mūsdienu CTO podkāsts - 217. epizode ar Danu Konrādu - CTO pie vienas identitātes

Pandēmijas laikmetā, kad liels skaits darbinieku ir pārgājuši uz attālinātais darbs iestatījumu, mums ir jāpievērš vēl lielāka uzmanība mūsu datu drošībai. Labs piemērs ir Dana minētā situācija, kad lietotāji visur izmanto vienas un tās pašas vai ļoti līdzīgas paroles un neapzinās ar to saistīto bīstamību.

Ja daudzās vietās izmantojat vienas un tās pašas paroles, var gadīties, ka kādā no vietnēm radīsies “drošības problēmas”, datubāze noplūdīs internetā vai vienkārši kāds skatīsies, kā ievadāt vienu paroli, kas nejauši atvērs visas jūsu durvis. Manuprāt, visiem tiešsaistes pakalpojumiem vajadzētu jūs izglītot par briesmām, kas saistītas ar vienas un tās pašas paroles ievadīšanu reģistrēšanās procesā.

Viena vienota piekļuve (SSO) vai paroļu pārvaldnieku, piemēram, One Identity vai LastPass, izmantošana ir ļoti noderīga, lai uzturētu pamata tiešsaistes higiēnas un drošības standartus, pasargājot darbiniekus un darbavietas no ievainojamības un digitālajiem draudiem.

Vai izglītojat darbiniekus par apzinīgu paroļu pārvaldību?

Paldies, ka izlasījāt līdz beigām, un gaidiet nākamo epizodi, kas drīzumā gaidāma!