TheCodestReview #1 - viikoittainen ohjelmistotekniikan mehu

Miksi teemme sen?

1. Tietämyksen jakaminen on ratkaisevan tärkeää teknisten taitojen kehittämisessä, ja me välitämme siitä.

2. Auttaa insinöörityön johtajia löytämään ratkaisuja, joita he tarvitsevat tehdäkseen näyttöön perustuvia päätöksiä heidän ohjelmistohankkeet.

3. Uskomme vahvasti itseopiskelun voimaan, pyrimme aina oppimaan uusia asioita ja vahvistamaan itseämme, 1% kerrallaan. 

4. Verkossa on valtavasti hienoa teknistä sisältöä, joka ansaitsee enemmän huomiota, ja aiomme antaa tunnustusta sille, jolle se kuuluu.

Rakennetaan tiekartta tätä sarjaa varten olen tehnyt LinkedIn-kyselyn, jossa kysyn CTO:t ja insinöörijohtajille heidän keskeisistä haasteistaan vuonna 2020 ja sen jälkeen.

Näin he sanoivat: 

Pidemmittä puheitta, haluan kutsua sinut TheCodestReviewin 1. jaksoon, jossa vieraana on CTO, kehityspäällikkö ja Frontend Lead, joka kattaa alla olevat aiheet:

Kuusi peukalosääntöä Software Architecturesin skaalautumiseen Ian Gortonilta

"Järjestelmässäsi on pullonkaula. Jossain!" - kun taistelemme sovelluksen suorituskyvyn parantamiseksi, unohdamme järjestelmän keskeiset rajoitukset, ehkä ne eivät ole sovelluksen suosituimpia elementtejä, mutta niillä voi olla kielteinen vaikutus muuhun, eikä skaalautuminen välttämättä auta meitä tässä.

"Seuranta on olennaisen tärkeää skaalautuville järjestelmille" - emme voi olla sokeita liiketoiminnassamme, ja meidän on parempi tietää ongelmasta ennen kuin käyttäjät tai CEO ilmoittavat siitä meille. Seuranta on avain luotettavuuteen.

"Datatasoa on vaikein skaalata" - Tietokanta on sovelluksemme sydän, ja kuten jokaista sydäntä, sitä on vaikea leikata ilman, että se vaikuttaa laskimojärjestelmäämme, joten se on usein pullonkaulamme. Toisaalta, mitä pidempään olemme käyttäneet markkinatMitä enemmän tietoja käsittelemme, sitä vaikeampaa on säilyttää odotettu suorituskyky.

Mainitussa artikkelissa kirjoittaja korostaa joitakin suorituskykyisen sovellusarkkitehtuurin erityisnäkökohtia. Vuosien varrella olemme oppineet käyttämään AWS:n tai Azuren kaltaisia ratkaisuja, mutta parhaatkin pilvi ei suojele meitä itseltämme. Sovellusta luodessamme emme keskity ratkaisemaan ongelmia, joita ei ole olemassa, vaan ennakoimme ne etukäteen. Siksi kohtaamme paljon ongelmia myöhemmin, kun sovelluksemme kasvaa. Artikkelin kirjoittaja antaa meille monia arvokkaita vinkkejä siitä, mistä kannattaa etsiä optimointia, mikä on suurin ongelma ja miten se vaikuttaa sovellukseen. Kun laitan monen vuoden kokemukseni alalta peliin, olen täysin samaa mieltä Ianin kanssa. Haluaisin myös lisätä, että artikkelissa annetut neuvot koskevat jokaista ylläpitämäämme sovellusta. Näiden ohjeiden toteuttaminen tuo etuja projekti sen luotettavuuden ja ennustettavuuden tasolla, mikä on tärkeä ominaisuus liiketoiminnan kasvun kannalta.

Juan Pablo Buritican laatima alkuopas teknisten toimitusmittareiden käyttöönotosta.

- Yleisesti käytetyt suorituskykymittarit eivät ole puhtaasti teknisiä

- Ohjelmistojen toimitusnopeus on mitattavissa, mutta käytetyt indikaattorit on tulkittava oikein, jotta optimoinnilla saadaan aikaan haluttu vaikutus.

- Tehokkain joukkue on hyvin koordinoitu ja hyvin verkottunut tiimi - suunnittelujohtajien olisi ymmärrettävä kehittäjien ongelmia ja motiiveja ja päinvastoin terveiden ja synergisten vaikutusten aikaansaamiseksi.

Juan Pablo Buritica on ottanut esiin aiheen, joka näyttää olevan edelleen kapea-alainen. IT-projekteja hallinnoivat ihmiset ottavat usein käyttöön joitakin tehokkuusmittareita (kuten JIRA:n perusluettelo), mutta ne eivät vieläkään korreloi läheisesti toimitusten kanssa. koodi osat, jotta ohjelmistojen toimitusprosessi voidaan optimoida niiden perusteella. Yleensä optimointi koskee tehtävien jakamista ja viestintää tiimin sisällä, mutta harvoin seurataan puhtaasti teknisiä indikaattoreita, jotka kirjoittaja mainitsee, esimerkiksi "time to merge". GitHub-verkkokoukkujen ja integraatiolle avoimien tehtävienhallintajärjestelmien aikakaudella tämäntyyppistä lähestymistapaa on suhteellisen helppo soveltaa - tiedot ovat käden ulottuvilla, niitä on vain tavoiteltava ja käsiteltävä oikealla tavalla.

Kirjoittaja huomauttaa oikeutetusti, että hänen kuvaamansa tilastot voivat nopeasti kääntyä vastoin kehitystiimi, mutta näin tapahtuu vain silloin, kun johtohenkilöstö ei täysin ymmärrä ohjelmoijan työn erityispiirteitä. Siksi on tärkeää, että PM tai PO on teknisesti taitava ja kykenee hahmottamaan, mitä yksittäisten tehtävien taustalla on järjestelmässä.

Moderni CTO Podcast - Jakso 217 Dan Conradin kanssa - CTO at One Identity - CTO at One Identity

Pandemian aikakaudella, jolloin suuri osa työntekijöistä on siirtynyt käyttämään etätyö asennuksen ansiosta meidän on kiinnitettävä entistä enemmän huomiota tietojemme turvallisuuteen. Hyvä esimerkki on Danin mainitsema tilanne, jossa käyttäjät käyttävät kaikkialla samoja tai hyvin samankaltaisia salasanoja eivätkä ole tietoisia niihin liittyvistä vaaroista.

Jos käytät samoja salasanoja monissa paikoissa, voi käydä niin, että jollakin sivustolla on "tietoturvaongelmia", tietokanta vuotaa internetiin tai joku vain katsoo, kun kirjoitat yhden salasanan, joka avaa vahingossa kaikki ovet. Mielestäni kaikkien verkkopalveluiden pitäisi valistaa sinua vaarasta, joka liittyy saman salasanan syöttämiseen rekisteröitymisprosessin aikana.

Single Sing On (SSO) tai One Identityn tai LastPassin kaltaisten salasanahallintajärjestelmien käyttö on erittäin hyödyllistä, kun halutaan pitää yllä perusverkkohygienia- ja turvallisuusstandardeja ja suojella työntekijöitä ja työpaikkoja haavoittuvuuksilta ja digitaalisilta uhkilta.

Koulutatko työntekijöitäsi järkevästä salasanojen hallinnasta?

Kiitos kun luit loppuun asti ja pysy kuulolla, sillä seuraava jakso on tulossa pian!