TheCodestReview #1 – vikulegur hugbúnaðarverkfræði-safi

Af hverju erum við að gera þetta?

1. Þekkingarskipti eru mikilvæg til að þróa tæknifærni og okkur er annt.

2. Til að hjálpa verkfræðistjórum að finna lausnir sem þeir þurfa til að taka ákvarðanir byggðar á sönnunargögnum í sínum hugbúnaðarverkefni.

3. Við trúum sterklega á mátt sjálfsnáms, og leggjum okkur ætíð fram við að læra nýja hluti og styrkja okkur, 1% í einu. 

4. Það er ógrynni af frábæru tækniefni á netinu sem á skilið meiri athygli og við ætlum að gefa viðurkenningu þar sem hún á skilið.

Að byggja upp a vegakort fyrir þessa seríu hef ég framkvæmt könnun á LinkedIn til að spyrja CTOs og verkfræðistjórar um helstu áskoranir þeirra á þegar nógu erfiðu ári 2020 og framundan.

Þetta sögðu þeir: 

Án frekari ummæla býð ég þér velkominn í fyrsta þátt TheCodestReview með gestainnslagi frá CTO okkar, þróunarstjóra og forystumanns fronthaups, sem fjallar um eftirfarandi efni:

Sex fingurreglur fyrir stærðarútreikninga í Software Architectures eftir Ian Gorton

“Kerfið þitt er með flöskuháls. Einhvers staðar! – þegar við baráttumst við að bæta afköst forritsins gleymum við helstu takmörkunum í kerfinu; kannski eru þessi atriði ekki vinsælustu hlutirnir í forritinu, en þau geta haft neikvæð áhrif á restina og stækkun gæti ekki hjálpað. okkur hér.

“Eftirlit er grundvallaratriði fyrir stækkanleg kerfi – við getum ekki verið blind í rekstri okkar og betra er fyrir okkur að vita af vandamálinu áður en notendur eða okkar CEO. Eftirlit er lykillinn að áreiðanleika.

“The gögn ”lagið er það erfiðasta að stækka" – gagnagrunnurinn er hjarta forritsins okkar og, eins og hvert hjarta, er erfitt að skera hann án þess að hafa áhrif á æðakerfi okkar, og þess vegna er hann oft flöskuháls okkar. Á hinn bóginn, því lengur sem við erum á markaður, því meira gögn sem við vinnslum og því erfiðara er að viðhalda væntanlegri frammistöðu.

Í greininni sem nefnd var dregur höfundur fram nokkra sértæka þætti í arkitektúr hágæða forrita. Í gegnum árin höfum við lært að nota lausnir eins og AWS eða Azure, en jafnvel það besta ský verndar okkur ekki fyrir okkur sjálfum. Þegar við bjóum til forrit einbeitum við okkur ekki að því að leysa vandamál sem eru ekki til staðar, né sjá þau fyrirfram. Þess vegna rekumst við síðar á mörg vandamál þegar forritið okkar vex. Höfundur greinarinnar gefur okkur margar dýrmætar ábendingar um hvar eigi að leita að hagræðingu, hvað sé stærsta vandamálið og hvernig það hefur áhrif á forritið þitt. Með margra ára reynslu minni í greininni í húfi er ég algjörlega sammála Ian. Ég vil einnig bæta við að ráðin sem gefin eru í greininni eiga við um hvert forrit sem við viðhalda. Að innleiða þessar leiðbeiningar mun færa ávinning til verkefni á stigi áreiðanleika og fyrirsjáanleika þess, sem er mikilvægur eiginleiki fyrir Vöxtur fyrirtækja.

Grunnnámskeið í verkfræðilegri skilgreiningu afhendingarmælikvarða eftir Juan Pablo Buritica

Algengur frammistöðuvísar eru ekki eingöngu tæknilegir.

– Hraði hugbúnaðarútgáfu er mælanlegur, en vísbendingarnar sem notaðar eru skulu túlkaðar rétt til að fínstillingin skili tilætluðum áhrifum

– Áhrifaríkastur lið er vel samhæfður og vel tengdur team – verkfræðileiðtogar ættu að skilja vandamál og hvata forritara og öfugt til að ná heilbrigðum og samverkandi áhrifum.

Juan Pablo Buritica hefur vakið upp mál sem virðist enn vera sérsvið. Fólk sem stýrir upplýsingatækniverkefnum tekur oft upp ákveðnar skilvirkniraðgerðir (eins og grunnburndown-grafík í JIRA), en þær tengjast enn ekki nákvæmlega afhendingum kóði þættir til að hagræða hugbúnaðarútgáfuferlinu út frá þeim. Venjulega snýst hagræðing um dreifingu verkefna og samskipti innan team, en sjaldan er fylgst með hinum strikt tæknilegu vísbendingum sem höfundurinn nefnir, t.d. ‘tími til samruna’. Í GitHub-öldinni vefur Með hooks og verkefnastjórnunarkerfum sem eru opin fyrir samþættingu verður þessi nálgun tiltölulega auðveld í framkvæmd – gögnin eru innan seilingar, þú þarft bara að ná í þau og vinna úr þeim á réttan hátt.

Höfundurinn bendir réttilega á að tölfræðin sem hann lýsir geti fljótt snúist gegn þróun team, En þetta gerist aðeins þegar stjórnendateymið skilur ekki til fulls sérstöku atriði vinnu forritarans. Þess vegna er mikilvægt að verkefnisstjóri (PM) eða vörustjóri (PO) sé tæknilega sinnaður og geti skynjað hvað liggur að baki einstökum verkefnum í kerfinu.

Modern CTO hlaðvarp – þáttur 217 með Dan Conrad – CTO hjá One Identity

Í tímum heimsfaraldurs þar sem stór fjöldi starfsmanna hefur skipt yfir til fjarvinna Við uppsetningu verðum við að veita öryggi gagna okkar enn meiri athygli. Gott dæmi er aðstæðan sem Dan nefnir, þar sem notendur nota sömu eða mjög svipuð lykilorð alls staðar og gera sér ekki grein fyrir hættunni sem því fylgir.

Ef þú notar sömu lykilorðin á mörgum stöðum getur gerst að einn af vefunum lendi í öryggisvandamálum, gagnagrunnurinn leki á internetið eða einhver fylgist með þér slá inn eitt lykilorð sem óvart opnar öll dyrnar þínar. Að mínu mati ættu allir netþjónustur að fræða þig um hættuna sem felst í því að nota sama lykilorðið við skráningu.

Single Sign-On (SSO) eða notkun lykilorðastjóra eins og One Identity eða LastPass er afar gagnleg til að viðhalda grunn netheilbrigði og öryggisviðmiðum, og vernda starfsfólk okkar og vinnustaði gegn veikleikum og stafrænum ógnum.

Fræðið starfsfólk ykkar um meðvitaða stjórnun lykilorða?

Takk fyrir að lesa til enda og fylgstu með næsta þætti sem kemur fljótlega!