Reużywalnyność elementów - refactor aplikacji.

Podczas to gdy zespół pisze moduły zauważyłem że istnieje pewna część Wspólna dla wielu modułów, pragnąłbym wyciągnąć ją do jednego modułu. Tak by stworzyć wspólny abstrakt.
Metodologiczne można to nazwać próba stworzenia wewnętrznego API dla mojej aplikacji w celu reużywania już istniejącego kodu, elastyczność podejścia będzie zapewniać fabryka i strategia wewnatrz mojego API.

Czekałem trochę aż moduły dojrzeją, by można było zbierać z nich wykształcone części wspólne i nie popełniać błędu zbyt szybkiego zbioru, gdyż później konczy się to ifologią.

Macie jakieś swoje patenty, narzędzia czy ogólnie porady lub na to co warto uważać podczas takiego refaktoringu aplikacji? Nie da się ukryć, ze tym sposobem wprowadzam dodatkowe sprzężenie do modułu.
Można powiedzieć, ze dość duży ciężar zostanie przeniesione na moje wewnętrze API.

W dużej mierze sam już doszedłeś do dobrego wniosku- poczekać aż system będzie bardziej dojrzały i dopiero wyodrębniać jakieś faktyczne części wspólne.

Dodam tylko żeby przede wszystkim nie próbować wyodrębniać kodu na siłę- jeśli widzisz że dany fragment kodu będzie wymagał nadmiernej logiki żeby obsłużyć różne wymagania wywodzące się z konkretnych modułów, to lepiej to odpuścić i zostawić tak jak jest. Trochę więcej autonomii kosztem częściowo powtarzającego się kodu. Moim zdaniem to nic złego jeśli jest uzasadnione.

Ponadto jeszcze jedna kwestia- konfiguracja. Wspólne API piszę tak że pozwala na skonfigurowanie wedle potrzeb konkretnego modułu. Jak to zrobić to zależy od języka. Dla przykładu w .Net pozwalam robić to na etapie rejestracji kontenera IoC oraz za pomocą extension methods:

// AddLogging to metoda rozszerzająca kontener IoC, przyjmująca metodę anonimową pozwalającą konfigurować wedle potrzeb
services.AddLogging(config => config.SetSomething = true) 

Przed refaktorem zrób sobie dokument opisujący co dokładnie ma się znaleźć w tym wyciągniętym module, jaka ma być jego odpowiedzialność. Zaprojektuj tez API modułu.

Gdy myślę o reużywalności to myślę w dwóch kategoriach:

1. Małych technicznych konstrukcjach, często niezależnych od domeny, jeśli robią efekty uboczne to tylko w jednym kierunku (tzn albo odczyty, albo zapisy). Te konstrukcje są łatwe w ponowym użyciu i kompozycji. Mam nad nimi praktycznie 100% kontroli, ponieważ jak coś się zmienia w aplikacji to nie pociąga modyfikowania tych konstrukcji.

2. Komponentach, które sprawiają, że aplikacja robi coś użytecznego z perspektywy końcowego usera. Na ogół takie komponenty zawierają w sobie jakiś kontekst (potrafią coś opakować, same potrafią być opakowane), potafią coś pokazywać, zarządzać stanem, mają wpływ na interakcję z userem.

Ciężko jest pisać reużywalny kod, jeśli są przecięcia (a będą jesli próbujesz opakować coś biznesowego). Nawet jak masz wrażenie, że to dobry moment aby opakować pracę, nadać jej ogólny charakter to wystarczy tylko drobna zmiana założeń, aby to szybko pękło. Reużywalne komponenty są bardzo kruche i wstrzymałbym się dopóki apka jest nadal utrzymywana oraz dopóki nie zdobyłbym większego obycia nad dziedziną jakiej ona dotyczy (czyli gdzieś tak po 4-5 podobnej aplikacji można rzeczywiście mieć jakiś sensowny pomysł na podziały, inaczej zgaduje).

Zamiast uogólniać, piszę procedury, stosuje transaction script, cieszę się gdy z kontekstu wynika jaki problem aplikacja próbuje rozwiązać oraz przyjmuję nastawienie, że w razie zmian zamiast polegać na rozszerzeniach zmodyfikuje co trzeba.

Ddd i rozmowa z biznesem + roadmap produktu oraz projektu