TheCodestReview #1 - cotygodniowy sok z inżynierii oprogramowania

Dlaczego to robimy?

1. Dzielenie się wiedzą jest kluczowe w rozwijaniu umiejętności technicznych i zależy nam na tym.

2. Aby pomóc liderom inżynierii znaleźć rozwiązania potrzebne do podejmowania decyzji opartych na dowodach w ich projekty oprogramowania.

3. Mocno wierzymy w siłę samokształcenia, zawsze starając się uczyć nowych rzeczy i wzmacniać siebie, 1% na raz 

4. Istnieje mnóstwo świetnych treści technicznych online, które zasługują na więcej uwagi, a my zamierzamy wyrazić uznanie tam, gdzie jest to należne

Budowanie mapa drogowa Na potrzeby tej serii przeprowadziłem ankietę na LinkedIn, aby zapytać CTOs i menedżerów ds. inżynierii na temat ich kluczowych wyzwań w wystarczająco trudnym 2020 r. i później.

Oto, co powiedzieli: 

Bez zbędnych ceregieli, zapraszam na 1. odcinek TheCodestReview z gościnnym udziałem naszego CTO, Head of Development i Frontend Lead, który omówi poniższe tematy:

Sześć praktycznych zasad skalowania Software Architectures autorstwa Iana Gortona

"Twój system ma wąskie gardło. Gdzieś!" - walcząc o poprawę wydajności aplikacji zapominamy o kluczowych ograniczeniach w systemie, może nie są to najpopularniejsze elementy aplikacji, ale mogą mieć negatywny wpływ na resztę i skalowanie może nam tu nie pomóc.

"Monitorowanie jest podstawą skalowalnych systemów" - nie możemy być ślepi w naszej działalności i lepiej dla nas wiedzieć o problemie, zanim zostaniemy o nim poinformowani przez użytkowników lub nasz CEO. Monitorowanie jest kluczem do niezawodności.

"Warstwa danych jest najtrudniejsza do skalowania" - Baza danych jest sercem naszej aplikacji i, jak każde serce, trudno jest ją wyciąć bez wpływu na nasz układ żylny, dlatego często jest naszym wąskim gardłem. Z drugiej strony, im dłużej jesteśmy na rynekIm więcej danych przetwarzamy, tym trudniej jest utrzymać oczekiwaną wydajność.

We wspomnianym artykule autor zwraca uwagę na niektóre specyficzne aspekty wysokowydajnej architektury aplikacji. Przez lata nauczyliśmy się korzystać z takich rozwiązań jak AWS lub Azure, ale nawet najlepsze chmura nie chroni nas przed nami samymi. Tworząc aplikację, nie skupiamy się na rozwiązywaniu problemów, których nie ma, przewidując je z góry. Przez to wiele problemów napotykamy później, gdy nasza aplikacja się rozrasta. Autor artykułu daje nam wiele cennych wskazówek gdzie szukać optymalizacji, co jest największym problemem i jak to wpływa na aplikację. Stawiając na szali moje wieloletnie doświadczenie w branży, w pełni zgadzam się z Ianem. Chciałbym również dodać, że rady zawarte w artykule odnoszą się do każdej utrzymywanej przez nas aplikacji. Wdrożenie tych wskazówek przyniesie korzyści projekt na poziomie jego niezawodności i przewidywalności, co jest ważną cechą dla rozwoju biznesu.

Elementarz dotyczący inżynieryjnych wskaźników dostarczania autorstwa Juana Pablo Buritica

- Powszechnie stosowane miary wydajności nie są ściśle techniczne

- Szybkość dostarczania oprogramowania jest mierzalna, ale użyte wskaźniki powinny być odpowiednio zinterpretowane, aby optymalizacja przyniosła pożądany efekt

- Najbardziej skuteczny zespół to dobrze skoordynowany i zgrany zespół - liderzy inżynierii powinni rozumieć problemy i motywacje deweloperów i vice versa, aby osiągnąć zdrowe i synergiczne efekty.

Juan Pablo Buritica poruszył temat, który wciąż wydaje się niszowy. Osoby zarządzające projektami IT często przyjmują pewne miary wydajności (takie jak podstawowy wykres burndown w JIRA), ale nadal nie są one ściśle skorelowane z dostawami. kod części, aby na ich podstawie zoptymalizować proces dostarczania oprogramowania. Zazwyczaj optymalizacja dotyczy podziału zadań i komunikacji w zespole, ale rzadko kiedy śledzi się wskaźniki stricte techniczne, o których wspomina autor, np. "time to merge". W dobie web hooków GitHuba i otwartych na integrację systemów zarządzania zadaniami, tego typu podejście staje się stosunkowo łatwe do zastosowania - dane są na wyciągnięcie ręki, wystarczy po nie sięgnąć i przetworzyć we właściwy sposób.

Autor słusznie zwraca uwagę na fakt, że opisane przez niego statystyki mogą szybko obrócić się przeciwko zespół programistówale dzieje się tak tylko wtedy, gdy kadra zarządzająca nie rozumie w pełni specyfiki pracy programisty. Dlatego ważne jest, aby PM lub PO byli technicznie obeznani i potrafili wyczuć, co kryje się za poszczególnymi zadaniami w systemie.

Modern CTO Podcast - Odcinek 217 z Danem Conradem - CTO w One Identity

W dobie pandemii, gdy duża liczba pracowników przeszła na praca zdalna musimy zwracać jeszcze większą uwagę na bezpieczeństwo naszych danych. Dobrym przykładem jest sytuacja przytoczona przez Dana, w której użytkownicy używają wszędzie tych samych lub bardzo podobnych haseł i nie są świadomi związanego z tym niebezpieczeństwa.

Jeśli używasz tych samych haseł w wielu miejscach, może się zdarzyć, że jedna z witryn będzie miała "problemy z bezpieczeństwem", baza danych wycieknie do Internetu lub po prostu ktoś będzie obserwował, jak wpisujesz jedno hasło, które przypadkowo otwiera wszystkie drzwi. Moim zdaniem wszystkie serwisy internetowe powinny informować o niebezpieczeństwie związanym z wpisywaniem tego samego hasła podczas rejestracji.

Single Sing On (SSO) lub korzystanie z menedżerów haseł, takich jak One Identity lub LastPass, są bardzo przydatne do utrzymania podstawowej higieny online i standardów bezpieczeństwa, chroniąc naszych pracowników i miejsca pracy przed lukami w zabezpieczeniach i zagrożeniami cyfrowymi.

Czy edukujesz swoich pracowników w zakresie świadomego zarządzania hasłami?

Dziękujemy za przeczytanie do końca i czekamy na kolejny odcinek już wkrótce!