Migracja systemów informatycznych. O biznesie i technologii

Jakiś czas temu na łamach Just Geek IT opisałem migracje systemów informatycznych opartych o .NET z czysto technicznego punktu widzenia. Dzisiaj opiszę ten sam proces z punktu widzenia biznesu oraz technologii. Mam nadzieję, że będzie to dla Was ciekawe!

13. Eksperymentuj

Tak naprawdę cały system, który pokazałem u klienta był moim autorskim rozwiązaniem – poza testami na swoich systemach nigdy go produkcyjnie nie wprowadziłem. Patrząc przez pryzmat 6 tygodni pracy z nim i ponad 20-stoma systemami dalej, mogę powiedzieć, że był to udany eksperyment.

14. Nie bądź wąskim gardłem

Dlaczego tylko trochę ponad 20 systemów? Nie byłem w stanie przekazać wystarczająco szybko całej potrzebnej wiedzy wszystkim zespołom. Szybciej było mi napisać artykuł niż tłumaczyć każdemu z osobna. Innym aspektem jest to czy ktoś go przeczytał.

15. Pain Driven Development

Nie lubię wykonywać monotonnej pracy, więc ją automatyzuje, jednak czasami specyfika zadania wymaga grzebania się w szambie. Im bardziej coś na Ciebie wywiera wpływ tym bardziej wracasz do korzeni, podstaw programowania, dobrych praktyk. Zaciskasz zęby i pchasz wózek przed siebie do momentu, aż przestaniesz czuć ból, a tylko błogi spokój i ukojenie. Staram się wykonywać pracę, której nikt nie chce zrobić, bo wiem, że to przyniesie największy wkład w rozwój firmy i każdej osoby, która w niej pracuje.

16. Nie przywiązuj się do swojej roli i obowiązków

Osobiście uważam za idiotyzm przywiązywanie się do swojej roli i obowiązków – oznaczałoby to, że się ograniczam. Kiedy trzeba być kimś innym, niż programistą to przejmuję zadania lidera naszego zespołu, testerów czy analityków. Zespół działa jako całość i bez różnicy, że kogoś brakuje, reszta zespołu przejmuje jego obowiązki. Dlatego nierzadko u nas zdarza się, że analitycy przyjmują rolę testerów, programiści i analitycy rolę lidera, a testerzy wspomagają analityków w swojej pracy.

17. Wykonuj egzekucje

Maklerzy na Wall Street każdą inwestycje nazywają egzekucją, w prawie natomiast można nazwać to sprawiedliwością Pizona. Oznacza to tyle, że nie ma odwrotu od podjętej decyzji. Kiedy decyzja została podjęta nie ma sensu się nad tym rozwodzić i martwić co się stanie, tylko iść do przodu. Czas pokaże jak dana decyzja wpłynie na sytuację. 99% czarnych scenariuszy nie wydarzy się, więc po co się nimi przejmować?

18. Atakuj problem a nie ludzi

Deadliny powodują nerwy, a nerwy powodują, że wyżywamy się na innych, bo wyobrażamy sobie te 99% sytuacji, które prawdopodobnie się nie wydarzą. Paradoksalnie, im więcej stresu tym bardziej jesteśmy na niego odporniejsi i z czasem wygrana czy przegrana nie robi już większej różnicy – jest to jedynie kolejny epizod w naszym w życiu. Dlatego też nie warto wyżywać się na współpracownikach z powodu narastających problemów – problemy wkrótce znikną, a z ludźmi będziesz widywać się codziennie.

19. Jasno ustalaj podział prac i poinformuj o fakcie

Zmieniasz część systemu, która nie przynależy do Twojego zespołu? Pobieżnie coś nie działa? Poinformuj właścicieli o fakcie lub zostaw im kod, aby zaakceptowali go. Ich odpowiedzialnością jest wprowadzenie poprawki nawet jak blokuje to Twój proces przy integracji z ich usługą. Zdarzyła się sytuacja, że zespół korzystający z naszego rozwiązania nie poinformował nas o nie wykonaniu pełnej migracji i dowiedzieliśmy się o tym na dwa dni przed końcem ostatniego, szóstego sprintu (moment oddania systemów do testów UAT). 

Migracja tego wycinka systemu była przypisana do tamtego zespołu ze względu na to, że odpowiedzialność za system należała do dwóch zespołów, a system był uznawany jako całość mimo podzielenia go na dwie części. Migracja tego systemu była wykonana dwa sprinty wcześniej.

20. Uśmiechaj się i zawsze szukaj pozytywów

ZOBACZ TEŻ:  Zasady czystego kodu C# w pigułce

Patrząc przez pryzmat całego życia, po co się przejmować, nieważne jak nisko upadniesz zawsze warto się zreflektować i poszukać, co dana sytuacja nas nauczyła. Jak nie drzwiami to oknem, a jak nie oknem to wykorzystaj buldożer.

Moje subiektywne spostrzeżenia, jeśli chodzi o środowisko .NET i samą w sobie migrację

1. Stwórz listę używanych technologii i paczek NuGet’owych

Rozwiązanie Microsoft.Build.CentralPackageVersions pozwala na zdefiniowanie listy paczek, które wykorzystujemy w projektach, zmiana pliku packages.props podmienia wersje we wszystkich projektach z niego korzystających.

2. Tak buduj współdzielone biblioteki, aby zmiany były jak najmniej inwazyjne i nie wprowadzały piekła “DLL’ek”

Chodzi o to, aby budować współdzielone biblioteki wraz ze wsteczną kompatybilnością oraz najlepiej utrzymywać niezmienioną wartość AssemblyVersion. Eliminuje to potrzebę przekierowywania paczek na inne wersje biblioteki w plikach app.config czy web.config oraz powoduje mniej nerwów przy zmianach w projektach.

3. Jak migrujesz aplikacje Winforms, WPF, XBAP na nowy format to przygotuj się na napisanie własnego systemu do wdrażania takich aplikacji

Co tu dużo mówić, na obecną chwilę nie wszystkie rozwiązania wspiera w pełni silnik .NET Core, więc jeśli chcesz migrować coś poza zwykłymi bibliotekami przygotuj się na napisanie swoich własnych rozwiązania do wdrożenia takiej aplikacji.

4. Ostrożnie z redukowaniem długu technologicznego i upiększaniem kodu

Wszystkiego rodzaju automaty do upiększania kodu są fajną rzeczą, jednak z umiarem. Osobiście zdarza mi się, że się zagalopuje i zmienię za dużo przez co inni cierpią.

5. NuGet’owe repozytoria oparte o foldery zamiast serwerów i zbyt duże uprawnienia to zło w czystej postaci

Pewnego dnia podczas zwykłej pracy jeden z deweloperów zgłasza, że nie działa mu nuget.org. Oho, znowu Azure padł – myślę. Zaraz zgłasza się drugi z tym samym problemem. No to klapa z pracą na dzisiaj – myślę. Okazało się, że jeden z deweloperów wszedł na dysk, na którym znajdują się paczki NuGet’owe i otworzył jedną z nich. Windows uznał, że zablokuje paczkę i wszystkie jej podległe. Co na to NuGet? Zablokował procesy budujące i maszyny developerskie.

6. Skrypty budujące z dopiskiem “All” to system z odroczoną karą

Czekasz dwie godziny na opublikowanie się całego systemu, aby przetestować mały wycinek rozwiązania, gdy ktoś nagle wrzuca drobną zmianę, która wysypuje cały proces. Najlepiej jeszcze jak zdarzy się to w piątek przed wyjściem z pracy. Najlepiej publikować system partiami – wysypie się dana część systemu to ponowna publikacja danego wycinka zajmuje mniej niż 15 minut. Rollback jednego podsystemu jest mniej kosztowny niż rollback całego rozwiązania.

Część wskazówek może się wydawać się nad wyraz niestosowna, niekorporacyjna czy innego rodzaju niepoprawna politycznie. Patrząc jednak przez pryzmat jakimi osobami wolę się otaczać to jednak zespoły, w których członkowie nie boją się mówić o problemach, stawiają na swoim kiedy trzeba oraz dobrze się bawią.

Dzięki temu każdy się rozwija, nie jest nudno oraz co najważniejsze, nikt nie daje sobie wejść na głowę. A tymczasem, do następnego!


Zdjęcie główne artykułu pochodzi z unsplash.com.

najwięcej ofert html

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Amazon dołączył do Java Community Process. Prasówka Technologiczna: 2.11.2019 r.