Jak zachować spójność architektury aplikacji w miarę rozwoju zespołu?

47

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.

Deekor
źródło
8
Czy możesz nam powiedzieć jak najwięcej o swoim obecnym procesie SDLC? Czy jesteś wodospadem, zwinny itp.? Czy korzystasz z TFS lub zarządzania zadaniami? Czy przeprowadzasz recenzje kodu, korzystasz z FxCop lub innych form sprawdzania poprawności kodu? Czy produkujesz dokumentację projektową? Czy masz wyznaczoną rolę architekta?
John Wu
1
@gnat: Nie jest to świetny duplikat, jeśli odpowiedzi są jakikolwiek wskazaniem.
Robert Harvey
2
Aby być uczciwym, standardy te powinny były zostać ustalone bardzo wcześnie i oparte na powszechnie akceptowanym dokumencie „najlepszych praktyk”, aby nikt nie mógł narzekać na faworyzowanie lub elitarność. Jeśli dostajesz ciężką reakcję od osoby, musisz zastanowić się, czy jeden kowboj jest wart zdrowego środowiska dla reszty zespołu i wymienić go, tak czy inaczej, wkrótce to zrobią. Myślę, że wszystkie podane poniżej porady dotyczące ścisłego sprawdzania kodu przed zameldowaniem i dodania komponentu architektury będą działały cuda.
Patrick Hughes
1
To święty graal inżynierii oprogramowania (oprócz drugiego świętego graala, który jest dokładnym wzbudzaniem wymagań).
pmf

Odpowiedzi:

55

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.

czy to nierealne, ż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.

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.

candied_orange
źródło
4
Jest całkiem oczywiste, co masz na myśli przez „prześladowanie kodu” ... Ale Google daje mi tylko prawo karne z całego świata.
Jeremy
3
dodaj do listy „standardy kodowania”
BЈовић
5
Ponieważ wydaje się, że wprowadzam ten termin, podam etymologię „prześladowania kodu”. Sprawdziłem kod wykorzystujący fabrykę abstrakcyjną, aby uzyskać znaczniki czasu. Deweloper rówieśniczy próbował scalić (sprawdzić kod) i przewijał zmiany kodu od czasu jej sprawdzenia. Zauważyła moją fabrykę i pomyślała, że ​​to ciekawe. Nie była pewna, dlaczego to robię. Więc podeszła i zapytała mnie. Kiedy wyglądałam na zdezorientowaną, powiedziała: „Och, ja tylko cię prześladowałem”. Facebook zmienia nasze słownictwo.
candied_orange
1
Prawdziwe! „ Pozwól mi narzucić własną wizję, pomagając mi zobaczyć twoją, a my się dogadamy. Uwielbiam, kiedy poezja, kod i filozofia łączą się!
Pedro Lobito
@candied_orange: Trochę mnie zaskakuje cała sprawa „prześladowania kodu”. Czy po prostu ją robiłeś? W kontekście twojej odpowiedzi wygląda na to, że ona cię prześladuje.
Robert Harvey
23

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ń.

Becuzz
źródło
Zaletą tej metody jest to, że menedżer nie tylko narzuca swoje preferencje, daje zespołowi szansę na podjęcie decyzji i daje mu moc, by go egzekwować.
Robin Bennett
6

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.

Mateusz
źródło
Wydaje mi się, że duża część mojego pytania brzmi: czy nierealistyczne jest oczekiwać ode mnie takich standardów. Mam problem z wyobrażeniem sobie, że jestem dyktatorem, który tłumi kreatywność, ale robienie tego, co chcą, wydaje się niemożliwe do skalowania
Deekor
3
@Mateusz, choć ogólnie się z tobą zgadzam, zrobiłbym to w odwrotnej kolejności. Najpierw przeglądy projektu, a podczas przeglądów projektu pojawiają się wytyczne. Jeśli nałożysz na architekta / szefa ciężar zapisania wszystkiego z góry, przeniesie to ciężar na interwenienta .
Nick Alexeev
@Deekor: Musisz wybrać swoje bitwy. Dowiedz się, na co musisz postawić stopę, i udokumentuj to. Nie musisz dyktować wszystkiego.
Robert Harvey
2
@Deekor, możesz egzekwować standardy i popularne praktyki kodowania bez „tłumienia kreatywności”. To zresztą fałszywy argument. Wspólne standardy kodowania prowadzą do łatwego w utrzymaniu oprogramowania. Bezpłatne kodowanie prowadzi do koszmarów.
Matthew
1
@Nick Aleksiejew, zgadzam się; edytuje.
Matthew
1

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

mcintyre321
źródło
0

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:

  • Osoby czują się cenione i stanowią część zespołu
  • Ważne decyzje są kwestionowane przez cały zespół przed ich podjęciem
  • Mocne i słabe strony projektowania systemu są bardziej zrozumiałe dla wszystkich
  • Tworzy poczucie zbiorowej odpowiedzialności i zaufania

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

Thomas CG de Vilhena
źródło