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

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

1. Przedwczesne / niepotrzebne prace optymalizacyjne
2. 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.
3. 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.
4. Wybór przypadkowej złożoności

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

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.