@Wibowit: Wiem, że w teorii tak właśnie to wygląda.
W praktyce jednak bliżej prawdy jest @Krolik .
@Krolik napisał głównie o tym, że Rust jest magiczny i że nie masz w nim data-races i wycieków zasobów w takiej ilości jak np. w Javie czy C#.
Przy przerabianiu pierwszych, z około 20 systemów (właściwie jest to monolit o 20 możliwych do wyodrębnienia funkcjach) wyglądało to następująco:
- Czas tworzenia systemu 20 godzin zespołu
- Czas integracji z istniejącymi systemami 400 godzin zespołu.
(...)
Wniosek - napisanie wszystkich systemów od nowa zajmie tyle czasu, co zintegrowanie jednego, bo przebijanie się przez gkod poprzedników jest niewiarygodnie czasochłonne.
Jeżeli twierdzisz, że przepisanie całego systemu ma zająć 400 godzin zespołu to daje to jakieś 3 miesiące pracy (wliczając choroby, urlopy, piłkarzyki itd). 3 miesiące przestoju raczej nie byłoby katastrofą w typowym projekcie biznesowym. Nawet, gdybyś rozciągnął to do np 6 miesięcy żelaznego deadline'u. Tyle, że musiałby to być naprawdę żelazny deadline, bez okazywania żalu jeśli po tych 6 miesiącach nowy system nadal nie nadaje się na produkcję, ale ma dużo (lepiej napisanego) kodu, z którym trzeba się rozstać. Życie pokazuje, że to tak nie działa (jest psychologiczny problem z wyrzucaniem kodu). W agile'u jest coś takiego jak spike, gdzie tworzy się program, po to by zbadać trudność tematu, a potem ten program wyrzucić. Takie jest założenie wprost - program ma być wyrzucony po spełnieniu oryginalnego zadania jakim jest eksploracja problemu. W praktyce jest tak, że tak to może działać co najwyżej jeśli spike to robota na kilka dni (w sumie taka jest chyba teoria za spike'ami - eksperyment na kilka dni, by lepiej oszacować zadanie, które trudno oszacować). Jak rozciąga się do tygodni to już jest dylemat: kierownik zespołu nie chce tego ciągnąć, bo wyrzucanie kilkutygodniowej pracy nie wygląda (przynajmniej z pozoru) na opłacalny ruch, a jeśli już ma być ciągnięte to tak, żeby to dowieźć na produkcję, a więc pomysł traci status eksperymentu i staje się wymaganiem, tak jak każde inne normalne zadanie.
Kolejną sprawą jest to, że trawa u sąsiada jest zawsze bardziej zielona. Teraz się wam wydaje, że przepisywanie od zera byłoby lepsze, ale bardzo możliwe, że gdybyście przepisywali od zera to obecna strategia wydawałaby się lepsza. Podstawowy powód już podałem - rozciągnięcie się eksperymentu w czasie i presja ze strony kierownictwa, by to jak najszybciej dowieźć na produkcję (bo nowe funkcjonalności są potrzebne szybko), a nie wywalać tak kosztownego eksperymentu. Teraz macie tak, że jeden moduł już macie za sobą, a więc macie już pewne doświadczenie w oraniu starego kodu. To powinno przyspieszyć wymianę pozostałych części systemu - im więcej doświadczenia tym bardziej płynna praca. Kolejna sprawa to to, że przepisując możesz od razu dodawać nowe rzeczy. Jeśli dodajesz nowe rzeczy przepisując cały system naraz to mocno zwiększasz napięcie między zespołem, a kierownictwem, bo co z tego, że nowy system będzie fajny, skoro termin oddania go już dawno przekroczył granicę cierpliwości kierownictwa? Jeśli dodajesz nowe rzeczy przepisując system po kawałku to ograniczona przestrzeń zmian zmniejszy owo napięcie. Kierownictwo zobaczy nowy bajer dostarczony w granicach cierpliwości, a więc będzie zadowolone.
