Jak zapobiec wprowadzaniu przez kolegę ekstremalnej złożoności i abstrakcji?

Mam bardzo trudny czas, ponieważ mój kolega wydaje się wystawiać

Przedwczesne / niepotrzebne prace optymalizacyjne
Przedwczesna deduplikacja z wątpliwymi abstrakcjami
Na przykład używamy zmodyfikowanej architektury VIPER. Wprowadził klasę bazową dla komponentu Routera (używając generics) jako część implementacji pierwszego stosu vipera, nie wiedząc, co dokładnie zostanie powierzone w innych routerach. Teraz utknęliśmy z koniecznością zapewnienia typu UseCasezawierającego przypadki użycia, ale większość routerów nie ma wielu przypadków użycia, tylko jeden.
Wymyślając rozwiązania ogólnego zastosowania dla spekulacyjnych potencjalnych przyszłych funkcji
Na przykład napisał menedżera do wypełniania widoków tabeli statycznych komórek, gdy mieliśmy tylko dwa takie ekrany w aplikacji i nie był świadomy, że projekt odejdzie od nudnych form pionowych do bardziej niestandardowych Interfejsy użytkownika, więc menedżer jest bezużyteczny.
Wybór przypadkowej złożoności

Jak mam z tym walczyć, kiedy wykazuje bariery językowe z kiepskim angielskim?

architecture

— Earl Grey
źródło

Czy próbowałeś obowiązkowych recenzji kodu, aby dać możliwość omówienia, co się dzieje? Czy próbowałeś wspólnie z nim na pokład znaleźć dobre rozwiązanie, zanim usiądzie i zacznie kodować?

— Becuzz,

Czy możesz podać przykład, w którym mogą wystąpić sytuacje takie jak 2 lub 3?

— morbidCode

Czuję twój ból, @EllGrey. Prawdopodobnie nigdy nie widziałem przypadku, w którym super-ogólne „ogólne” kodowanie faktycznie działałoby zgodnie z planem w przyszłości.

— Graham

Znam ludzi, którzy używają szybkiego sortowania zamiast bąbelkowego przedwczesnej optymalizacji. Jaki jest twój próg?

— Pieter B,

Twój kolega wydaje się zapominać / nieświadomy zasady YAGNI .

— Bart van Ingen Schenau

Twój opis brzmi jak kodowanie, które zrobiłem w latach 90. Wykonanie odpowiednio dla współczesnego świata nie jest łatwe. Polecam skupić się na następujących czynnikach:

Łączenie w pary. Dwa zestawy oczu mogą pomóc uchronić się przed jedną wielką, ale skomplikowaną implementacją.
Przegląd kodu. Nowoczesne sklepy sprawdzają 100% wszystkich zmian kodu przez wiele osób
Pokrycie testowe. Upewnij się, że istnieją proste testy. Zbyt skomplikowane testy mogą odzwierciedlać zbyt skomplikowany kod
Dużo dyskusji na temat minimalnego opłacalnego produktu. Podziel funkcje na możliwie najmniejsze komponenty. Można mieć jeden bilet do zmiany bazy danych, drugi do zapełniania tabel referencyjnych, a następnie trzeci do aktualizacji interfejsu użytkownika (część, która faktycznie będzie widoczna dla użytkowników końcowych), ale będzie wydawał się sprzeczny z intuicją, gdy opór jest prawdopodobne.
Częste dyskusje na temat tego, jak mieć mniejsze bilety i zmiany.
Głosowanie nad historią przez cały zespół w celu otwarcia dyskusji na temat złożoności i podejścia.
Edukacja. Upewnij się, że masz lunch i uczysz się, sesje szkoleniowe itp., Aby ludzie mogli poznać dobre praktyki i dlaczego są dobre.

Ze wszystkich powyższych moich dwóch głównych punktów byłyby recenzje kodu i mniejsze historie.

Pod koniec dnia uważam, że najlepszym rozwiązaniem zmiany istniejących zachowań jest oddanie się osobie zaangażowanej. W organizacjach zwinnych (prawdopodobnie dziś większość) potrzeba oddanej osoby, takiej jak scrum-master, aby stale zadawać właściwe pytania i kierować podejściem do rozwoju. W mojej ostatniej organizacji mieliśmy ich kilkanaście, po jednym w każdym zespole, aby pomóc ludziom w przeprowadzeniu tego rodzaju problemów. Eliminuje to potrzebę, by jeden członek zespołu próbował przekonać innych, że „ich droga jest właściwa”, co często może prowadzić do okrutnych wymian i złej krwi.

— Michael Durrant
źródło