Jak refaktoryzować dla Startups 2022: powody i kompromisy

( Przesłane z witryny internetowej Klotho )

Ten wpis na blogu to ogólne omówienie powodów refaktoryzacji kodu i systemów w ustawieniach startowych. Omawiamy ryzyka, podejścia i kompromisy, które należy rozważyć w 2022 r.

Jak ocenić, kiedy koszt jest wart zysków

Bądź ze sobą szczery

Pokusa zawsze będzie polegać na refaktoryzacji: rzeczywisty kod jest chaotyczny, a inżynierowie nie lubią bałaganu. Upewnij się, że refaktoryzacja ma uzasadnienie biznesowe, mierząc, ile czasu zespół spędza na funkcjach bezpośrednio widocznych dla klienta.

Z naszych badań wynika, że ​​firmy średniej wielkości i szybko rozwijające się startupy wydają 39% potencjału inżynieryjnego na niezróżnicowaną pracę, taką jak infrastruktura. Podziel historie na podzadania, takie jak infrastruktura i refaktoryzacja, aby móc mierzyć, dokąd zmierza Twój czas.

Dobrze zbudowany jest dobrze utrzymany

Wyraźne granice między modułami ułatwiają ich testowanie, wdrażanie i monitorowanie. Miej oko na zgłaszane przez klientów błędy, opóźnienia usług i częstotliwość przywracania kodu. Na drugim końcu cyklu życia oprogramowania znajduje się wiele wskaźników wskazujących na tendencję do powstawania wąskich gardeł: czas potrzebny na przejście od projektu do wysyłki, stopień zadowolenia inżynierów i rosnące koszty infrastruktury — to wszystko mogą być główne wskaźniki że narobiłeś długu.

Punkty przegięcia w firmach

Bazy kodu mają tendencję do organizowania się według trzech wymiarów: wielkości zespołu, tempa wprowadzania nowych funkcji i liczby klientów. Kiedy te liczby znacznie się zmienią, być może nadszedł czas, aby przyjrzeć się podziale komponentów.

Jeśli powiększasz zespół lub zwiększasz tempo rozwoju funkcji, czynnikiem ograniczającym będzie czytelność kodu. Zacznij od ukierunkowanej, oportunistycznej refaktoryzacji. Jeśli Twoja baza klientów rośnie, możesz potrzebować bardziej skalowalnych technologii lub przepływów pracy.

Kontroluj, co możesz, zaplanuj resztę

Właściwy wybór nie zapobiegnie ponownej architekturze

Refaktoryzacja i zmiana architektury nie oznacza, że ​​wcześniej dokonałeś złego wyboru. Częściej siły napędowe stojące za przebudową są związane ze zmianami wymagań lub czynnikami zewnętrznymi. Istnieją co najmniej 4 istotne wymiary, które wymuszą zmianę architektury w całym okresie życia produktu: tempo opracowywania nowych funkcji, wielkość zespołu inżynierów, ilość czasu spędzonego na niezróżnicowanej pracy oraz wzrost liczby klientów. Każdy z nich jest coraz trudniej bezpośrednio kontrolować.

Zacznij od łatwych pokręteł…

Jeśli chodzi o cztery wymiary, dwa najłatwiejsze do kontrolowania to tempo nowych funkcji i wielkość zespołu inżynierów. Możesz kontrolować liczbę nowych funkcji, ściślej planując i ustalając priorytety. Skalowanie zespołu jest wolniejszym procesem, ale zwykle można go przynajmniej zaplanować.

Jeśli zarówno zespół, jak i liczba nowych funkcji jest niewielka, jest mało prawdopodobne, aby refaktoryzacja miała znaczący wpływ na biznes. Na drugim końcu spektrum duży zespół pracujący nad wieloma funkcjami może odnieść korzyści z reorganizacji w mniejsze zespoły — i powinieneś rozważyć refaktoryzację lub zmianę architektury kodu, aby pasował. Architektura, która zapewnia czystsze granice organizacyjne i kodowe, umożliwi skalowanie produktu i firmy.

…a następnie przejdź do trudniejszych

Ilość czasu spędzanego przez Twój zespół na niezróżnicowanej pracy może być trudna do opanowania, a wzrost liczby klientów jest najtrudniejszą miarą ze wszystkich, na którą można wpłynąć. Gdyby to było łatwe, każdy ograniczyłby niezróżnicowaną pracę i zmaksymalizowałby wzrost liczby klientów! Mimo to możesz

wyprzedź problemy dzięki ostrożnemu i proaktywnemu podejściu do refaktoryzacji.

Pierwszym krokiem jest wiedza, kiedy nie refaktoryzować. Jeśli wzrost liczby klientów i ilość czasu spędzonego na niezróżnicowanej pracy jest niewielka, nie trać czasu na refaktoryzację: zamiast tego skup się na efektownych, widocznych dla klienta funkcjach. Podobnie, jeśli masz dobry wzrost liczby klientów i niewielką ilość niezróżnicowanej pracy, Twój zespół ma się dobrze. Rozważ refaktoryzację taktyczną, aby uniknąć wzrostu ilości niezróżnicowanej pracy, ale nie poświęcaj jej zbyt wiele czasu.

Jeśli Twój zespół spędza zbyt dużo czasu na niezróżnicowanej pracy, nadszedł czas, aby ponownie przyjrzeć się architekturze, tak aby lepiej skalowała się w miejscu, w którym obecnie znajduje się Twoja firma.

Jeśli przyjęcie przez klientów jest niższe, priorytetem powinna być tańsza architektura, która da ci więcej możliwości.
Jeśli zarówno przyjęcie klientów, jak i ilość czasu, jaką Twój zespół spędza na niezróżnicowanej pracy, są wysokie, być może nadszedł czas, aby skoncentrować się na scentralizowanym, zoptymalizowanym rozwiązaniu. Zwykle przybiera to formę dedykowanego zespołu operacyjnego, który może skutecznie wykonywać zadania związane z infrastrukturą. To wielki problem — poświęć chwilę, aby pogratulować sobie i swojemu zespołowi dotarcia tutaj!

Miej cel, a następnie znajdź skróty, aby się tam dostać

Miej plan, nawet jeśli nie jest idealny

Gdy już zdecydujesz się na zmianę architektury, nie bój się myśleć odważnie. Polegaj na swoich inżynierach, aby wymyślili stan końcowy, który im się spodoba, a następnie zmniejsz go w razie potrzeby. Istnieje duże prawdopodobieństwo, że okazja do gruntownej zmiany architektury pojawi się tylko raz lub dwa razy w cyklu życia produktu, więc bądź przygotowany na wszelkie kompromisy. Ale z tego samego powodu wiedz, że nawet najlepiej opracowane plany pójdą na marne, gdy zaczniesz je wdrażać.

Rób wielkie plany, rób małe kroki

Gdy już wiesz, gdzie chcesz umieścić kod, podejmij taktyczne działania, aby go tam zdobyć. Pracuj po jednym komponencie na raz lub wybieraj komponenty, które są jak najdalej od siebie. Jeśli jeszcze nie zainwestowałeś w solidne testy, zarówno na poziomie jednostki, jak i systemu, nadszedł czas. Testy dadzą Ci pewność, że zmiany nie zepsują istniejących doświadczeń klientów, ale mogą też pomóc Twojemu zespołowi w ustaleniu definicji „ukończone”. Gdy testy przejdą pomyślnie, komponent jest gotowy!

Najlepsza technologia to taka, którą możesz dostosować

Kluczem do ograniczenia wpływu refaktoryzacji i re-architektury na start-upy jest wykorzystanie technologii, którą można dostosować.

W przeszłości firmy wybierały określone technologie, takie jak maszyny wirtualne, bezserwerowe lub kontenery do hostowania swoich aplikacji. Problem polega na tym, że przejście z jednej technologii na drugą jest zbyt drogie, a to, czego potrzebujesz dzisiaj, może nie być tym, czego potrzebujesz jutro.

Architektura adaptacyjna to taka, która umożliwia równie łatwe hostowanie aplikacji w dowolnej technologii. Pozwala to na bieżąco dostosowywać środowisko hostingowe do aktualnych potrzeb. Konkretne opcje technologii, takie jak AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP, stają się wymienne.

Dzięki ponownemu wykorzystaniu istniejących konstrukcji języka programowania, takich jak funkcje i procedury obsługi zdarzeń, a także interfejsów, które są idiomatyczne dla każdego języka, architektury adaptacyjne ułatwiają korzystanie z usług w chmurze.

Szukaj abstrakcji i narzędzi, które są lekkie, ale wystarczająco elastyczne, aby umożliwić zmianę technologii. Uważamy, że adnotacje Klotho pasują do rachunku, ponieważ pozwalają oddzielić znaczenie semantyczne architektury od konfiguracji wdrożenia — ale przy wystarczających inwestycjach w biblioteki wykonawcze i automatyzację infrastruktury można samodzielnie zbudować podobne rozwiązanie.