Co to jest CS-Fixer można poczytać tu. Problematyczne jest jednak wdrożenie go w systemie legacy. Zanim zaczniemy go wdrażać wypada ustalić minimalny zakres poprawek, jakie powinien aplikować fixer. Poniżej podaję minimum, z jakim jest sens zaczynać pracę:

• use’y w plikach – to najpopularniejszy grzech, jaki popełniają programiści, nie dość, że jest mnóstwo nieużywanych referencji, to jeszcze są one nieposortowane lub wręcz aliasowane i podwajane, a to generuje konflikty
• notacja tablic po nowemu – to tylko skrócenie zapisu tablic, mniej czytania i wydaje się być nieinwazyjne
• białe znaki w argumentach funkcji – nie dwie, nie zero ale dokładnie jedna spacja.

Systemy legacy mogą mieć różne zakamarki, rozwiązania chwilowe, epoki kodowania i customowe parsery, których nie widać na pierwszy rzut oka.

Jeśli posiadamy środowisko testowe i bardzo dużą aplikację, to wdrażanie kawałkami może przynieść niespodziewane rezultaty, a wdrożenie całości zabić system.

Wydaje się być racjonalne wdrażać kawałkami, ale przy konfliktach dostajemy w kość.

Kilka zagrożeń:

• kodowanie plików
• końce linii
• domowe parsery plików
• zbieżność kodowania z kodowanie bazy danych
• konflikty pomiędzy developerami

A teraz najważniejsze – jak to wdrażać aby było jak najmniej pracy, jak najwięcej korzyści. Ile czasu to zajmie i dlaczego tak długo?

Potrzebujesz wdrożyć cs-fixera w systemie legacy?

Kliknij tu.