Jako jedyny programista w startupie miałem luksus podejmowania wielu decyzji dotyczących architektury i frameworku naszej aplikacji.
Przewijam do przodu 4 lata, a później mam przejęcie, mam pięcioosobowy zespół i wiele razy czuję się jak na dzikim zachodzie. Ludzie podejmujący dowolną decyzję dotyczącą projektu podoba im się: liczba całkowita i wyliczenia dla typów DB w jednym miejscu i ciąg znaków w innym, ta struktura dla problemu, a następnie inna struktura dla tego samego problemu w innym miejscu itp.
Jak mogę zacząć egzekwować spójność? Wydaje mi się to ważne, ale członkowie mojego zespołu wydają się popierać metodologię „jeśli to działa, to działa”.
Wydaje mi się, że duża część mojego pytania brzmi: czy nierealne jest, że oczekuję takich standardów? Mam problem z wyobrażeniem sobie, że jestem dyktatorem, który tłumi kreatywność, ale robienie tego, co chcą, wydaje się nie być skalowalne.
Odpowiedzi:
Co czyni cię wyjątkowym?
Mój procesor mówi, że działa i chcę iść do domu. Dlaczego mi przeszkadzasz?
Możesz sobie z tym poradzić, zmuszając wszystkich do wydawania próśb o ściągnięcie. Ale teraz zbliżają się terminy. Zły kod naciska na bramy nieskazitelnego zamku i ostatecznie poddajesz się presji. Albo wygrywasz tylko po to, by wszyscy odeszli i nikt nie używa twojego dziewiczego zamku.
Istnieje wiele narzędzi, które pomagają rozwiązać ten problem. Kontrola źródła, recenzje kodu, standardy kodowania itp., Ale istotą i duszą problemu są Twoje subiektywne opinie na temat tego, co najlepsze, należy uznać za istotne. W tym celu musisz zdobyć i zachować ich szacunek. Zrób to, a to o wiele łatwiejsze. Jeśli tego nie zrobisz, żadne narzędzie ani praktyka cię nie uratują.
Najlepszym sposobem na to jest wczesna komunikacja. Nie mów mi „nie używamy ciągów dla naszych typów DB w tym sklepie” 6 miesięcy po tym, jak zdecydowałem się na ten pomysł. Mówienie mi, że jest pochowany w dokumentacji przez 2 lata, nie jest uzasadnieniem, aby pozwolić mi to zrobić.
Z jakiegokolwiek powodu masz rzeczy, na których Ci zależy. Jeśli troszczysz się o nie i masz rację, spraw, aby te rzeczy były jasno komunikowane przed, podczas i bezpośrednio po kodowaniu każdego modułu.
Prześladowanie kodu jest cudowną praktyką. Zainwestuj w potrzebne narzędzia i praktyki, abyś mógł przejrzeć kod w ciągu kilku minut od napisania. Program parowania i narzędzie to po prostu krzesło dla gości.
Dlaczego? Każda sekunda, która mija po napisaniu kodu wykładniczo, zwiększa koszt jego zmiany. To dlatego, że moja pamięć kodu ma okres półtrwania. Zaczynam o tym zapominać w chwili, gdy mój pęcherz wymaga przerwy.
Ogranicz rzeczy, na których Ci zależy, do ich podstawowych zasad. Zamiast uderzyć mnie listą 101 zasad do naśladowania, podaj mi 10 zasad, które naruszają, abym mógł dowiedzieć się, która reguła 102 powinna być sama.
Pozwól mi narzucić własną wizję, pomagając mi zobaczyć twoją, a my się dogadamy.
Więc nie dyktuj! Spraw, aby było to pozytywne doświadczenie. To nie jest jakiś hippisowski nonsens w nowym wieku. To podstawowa psychologia. Próbujesz zmodyfikować ludzkie zachowanie. Losowe i pozytywne to najbardziej wzmacniające (wystarczy zapytać Las Vegas). Jeśli pójdziesz negatywnie, musisz być konsekwentny ze swoim wzmocnieniem. To nieosiągalny ból. Bądź pozytywny, gdy szerzysz mądrość i możesz być na to swobodny.
Wiem skąd pochodzisz, bo tam byłem. Miałeś kontrolę, a teraz go nie ma. Chcesz to z powrotem. Cóż, przełam to. Teraz masz zespół. Nie trzeba ich kontrolować. Potrzebują przywództwa. Nie potrzebujesz kontroli. To wpływ. Działa lepiej i jest o wiele mniej pracy. Opanuj to i zrelaksuj się. To powinno być zabawne.
Zrób to dobrze, a możesz pojechać na wakacje, a to nadal będzie działać. W jaki sposób? Nie tylko będąc liderem, ale także zmuszając innych do bycia liderami. Po wpojeniu swojej wizji zespołowi mogą pracować, gdy Cię nie ma, po prostu naśladując to, co robiłeś. Wspieraj nowicjuszy i zachęcaj ich, aby podnosili swój wpływ i wywierali wpływ na innych.
Wiem, że to trudne. Nie poszliśmy do tego zawodu, ponieważ jesteśmy dobrzy w kontaktach z ludźmi. Najlepiej komunikujemy się z kodem. W porządku. Po prostu rób to szybko i często. Pokaż mi, dlaczego twój jest lepszy. Słuchaj, jeśli mówię, że nie. Zrób to, dopóki wciąż o tym myślę. Uwielbiam kodować. Na świecie jest niewiele osób, z którymi mogę o tym porozmawiać. Bądź jednym z nich.
źródło
Po pierwsze, zachęć ludzi do zachowania rzeczy, których nie napisali. Deweloperowi łatwo jest przyzwyczaić się do korzystania z ram i technik, do których są przyzwyczajeni. To denerwujące, że trzeba przełączać się między ramami i metodologiami. Jeśli ktoś będzie zmuszony wyprowadzić się poza własny kąt kodu i doświadczyć tego często, spowoduje to narzekanie i, mam nadzieję, produktywną dyskusję, która może doprowadzić do tego, że ludzie będą chcieli coś ujednolicić.
Następnie ściągnij wnioski i recenzje kodu. Nigdy nie zezwalaj na łączenie kodu z głównymi gałęziami bez uprzedniej weryfikacji kodu. Każdy może to zrobić. Ponownie, gdy ktoś zobaczy coś innego niż to, co by zrobił, może skłaniać do dyskusji i pracy zespołowej, aby znaleźć lepsze rozwiązanie. Sprawia również, że każdy staje się opiekunem bazy kodu, co (miejmy nadzieję) zmusza ludzi do dbania o to i stan kodu, który się w nim znajduje.
Na koniec przeprowadzaj dyskusje na temat projektu. Mogą być formalne lub nieformalne, ale je mają. Niech ci, którzy chcą wziąć udział, robią to. Omów, jakie ramy chcesz zastosować, zalety i wady wyliczeń a ints itp. Następnie podejmij decyzję i udokumentuj ją gdzieś (np. Dokument standardu). Wtedy masz coś do wskazania, gdy pojawią się problemy. Nie bój się też ponownie podejmować decyzji w sprawie standardów. Technologia zmienia się (szybko), podobnie jak Twoje potrzeby jako zespół i jako firma.
Pomóż innym zobaczyć to, co widzisz i czuć, że mają wpływ na jakość kodu. Następnie delikatnie zachęcaj dyskusje do znalezienia standardu, gdy pojawią się różnice zdań.
źródło
Wykonuj recenzje kodu za każdym razem, gdy ktoś chce scalić kod z główną gałęzią / pniem i trzymać ludzi według tych standardów podczas przeglądania kodu.
I nie chodzi mi o to, że tylko ty powinieneś wykonywać recenzje kodu. Każdy powinien przejrzeć kod każdego innego. To rozpowszechnia wiedzę o systemie w całym zespole, ale także tworzy sytuację, w której Carol sprawdza kod Boba i mówi: „Widzę, że użyłeś tam liczby całkowitej. Zawsze używam wyliczenia”. Odkrywają rozbieżności, które widziałeś, i zakładając, że im zależy, zdadzą sobie sprawę, że wszyscy muszą znaleźć się na tej samej stronie.
Pojawią się zaakceptowane, uzgodnione standardy, w których to dokumentujesz je i upewniasz się, że ludzie ich przestrzegają. Obejmowałoby to np. „Wyliczenia w DB dla ...” itp. Możesz również dołączyć dokumentację, których ram użyć, itp.
źródło
Tam, gdzie to możliwe, możesz pisać narzędzia / skrypty, aby automatycznie analizować projekty i określać, jakie standardy, narzędzia i podejścia wykorzystuje projekt. Możesz to zrobić, uruchamiając niestandardowe narzędzie w ramach kompilacji CI.
Poproś o zapisanie danych wyjściowych z narzędzi w dokumencie „karty wyników”, np. W arkuszu google z wierszem na jednostkę (np. Na „aplikację”, projekt, interfejs API lub cokolwiek innego), z kolumnami dla różnych zastosowanych wskaźników / standardów. To da ludziom wgląd w to, jakie są standardy, jak dobrze są przyjęte itp. I zapewni porządek chaosowi.
Możesz także ręcznie zaktualizować kolumny, ale powodzenia w ich aktualizacji: D
źródło
Oprócz udzielonych odpowiedzi mówię, że powinieneś edukować swój zespół, czego oczekujesz od nich jako profesjonalistów zajmujących się programowaniem, poczynając od momentu rozmowy kwalifikacyjnej w celu dołączenia do firmy.
1 - Twórz i przestrzegaj konwencji bazy kodu
Jest to jeden z najbardziej podstawowych, ale korzystnych środków, które można zastosować w celu poprawy jakości kodu. W wyniku następujących konwencji kod źródłowy będzie jednolity w całej bazie kodu, co zmniejszy wysiłek poznawczy związany z wyszukiwaniem i odczytywaniem plików kodu.
2 - Wdrożenie przejrzystej architektury oprogramowania
Baza kodu projektu oprogramowania, który nie jest zgodny z wyraźnym stylem architektonicznym, bez względu na to, czym jest, ulega stopniowemu pogorszeniu wraz z dodawaniem do niego nowego, nieustrukturyzowanego kodu, przez co jego modyfikacja staje się trudniejsza. Dlatego ważne jest poświęcenie godzin na zaprojektowanie i zachowanie odpowiedniej architektury oprogramowania.
3 - Mniej znaczy lepiej: języki, frameworki i narzędzia
Z każdym dodatkowym językiem, strukturą i narzędziem wprowadzanym do systemu wiąże się dodatkowy koszt rozwoju i eksploatacji. Zawsze powinieneś ocenić długoterminowe koszty decyzji technologicznej, zanim podejmiesz ją w celu rozwiązania problemu krótkoterminowego. Unikaj zbędnych technologii i wykorzystaj jak najwięcej z bieżącego stosu.
4 - Zaangażuj swój zespół w podejmowanie decyzji dotyczących projektowania systemu
Najbardziej skutecznym sposobem na zbudowanie wspólnego środowiska wiedzy jest zaangażowanie zespołu we wszystkie decyzje dotyczące projektowania systemu. Korzyści są liczne:
5 - Zasada all-in
Uważam, że wysiłki mające na celu refaktoryzację projektu systemu powinny być prowadzone do końca (all-in), a nie być częściowo zakończone. Istnieje duże ryzyko erozji projektu systemu, jeśli programiści mogą stosować lokalnie różne style kodowania i wzorce architektoniczne, kiedy tylko uznają to za stosowne.
Do tego momentu, jeśli pomyślnie wdrożysz poprzednie sugestie, Twój zespół najprawdopodobniej oceni to nieuczciwe zachowanie programistów jako nieprofesjonalne i nieodpowiedzialne.
Niedawno napisałem post na blogu na ten temat, można tam znaleźć szczegółowe informacje na te tematy: https://thomasvilhena.com/2019/11/system-design-coherence
źródło