Tyle się mówi o rozwoju programistów. Ba, sam o tym często gadam. Że to dobre, że trzeba, żeby nie stać w miejscu a iść do przodu…
Ale powiedzcie mi: jak ma się rozwijać programista w typowym programistycznym polskim (i pewnie nie tylko) dev-kołhozie? Przychodzi do roboty, siada do projektu, po 8h wstaje i wychodzi. Niby normalka, ale… niekoniecznie. Moim zdaniem kluczowe jest pytanie: do jakiego projektu ten programista siada? Jeżeli od lat gapi się w monitor i dłubie w tym samym kodzie, utrzymuje i poprawia bugi w rozwiązaniu które zna na wylot, bo od baaardzo dawna nie widział niczego innego, to jego możliwości rozwoju są, lekko mówiąc, dość ograniczone.
Owszem, firma wyśle go na “autoryzowane szkolenia” żeby się rozwinął. Ale o tym już pisałem: “Szkolenia programistyczne, czyli maszyna ssąco-uciszająca” (BTW: wkrótce prawdopodobnie coś więcej w tym temacie).
Owszem, może sam oglądać jakieś dev-kursy i czytać dev-książki, ale gdzie zastosuje i sprawdzi nową wiedzę?
No tak, może wrócić do domu i robić “coś własnego”. Ale po pierwsze: ile razy można robić to “coś własnego” co ma zerowe zastosowanie i zaraz wędruje do kosza? A po drugie: tak, takie “coś własnego” daje frajdę, ale otwarcie się na nowe możliwości i prawdziwe poznanie “jakiejś rzeczy która jego nie jest” przychodzi dopiero wraz z przejściem całego cyklu tworzenia oprogramowania: od planowania po wdrożenie i support. Ile takich domowych projektów wchodzi w fazę wdrożenia i supportu? Nada.
Nie wspominając już o tym, że wiele osób po pracy po prostu nie ma na takie rzeczy czasu i sił (co w pełni zrozumiałem po powiększeniu rodziny).
Refleksje takie (i sporo innych) wywołało u mnie całe to zamieszanie wokół TDD: czy to żyje czy nie żyje? Ile osób tyle opinii, ale jak odróżnić kto wie o czym mówi a kto ściemnia? Z dysputy między @DHH, Fowlerem a Beckiem (część 1, część 2, umiarkowanie polecam) jasno wynika, że nawet taki koleś jak twórca Railsów nie jest do końca wiarygodny w temacie, w którym wygenerował taką burzę. Ja osobiście byłem zdziwiony jego poglądami i doświadczeniami. Ale zaczynam dryfować od tematu na rafy i skały, lasy i knieje…
Jak zatem umożliwić programiście rozwój? Gdzie ma szansę napisać soft, poświęcając na to niemało czasu, mając szansę na zweryfikowanie jakichś praktyk czy bibliotek od początku do końca? Ano w pracy oczywiście. Ale jak? Przecież jest jeden projekt, nie zmienimy nagle sposobu jego tworzenia tylko po to żeby ktoś się czegoś nauczył, nie?
Ano nie, nie trzeba tego robić. Wiecie co jest moim zdaniem rozwiązaniem tego problemu? Wiele projektów! :) I nie chodzi mi o to, żeby firma nieprogramistyczna posiadająca zespół dev pracujący nad jednym własnym systemem do użytku wewnętrznego nagle brała zewnętrzne zlecenia tylko po to żeby na nich eksperymentować. To samo można robić w ramach tego jednego systemu właśnie!
Zobaczcie… Przychodzi nowe wymaganie: trzeba zrobić “coś”. To “coś” nie jest stuprocentowo powiązane z “core” systemu. Może to być wysyłanie maila czy SMSa, może być wygenerowanie komunikatu z jakiegoś szablonu, może to być komunikacja z jakimś zewnętrznym systemem… Wystarczy zmienić mindset i zamiast ślepo klikać na solucję i wybierać “new project”, otworzyć nową instancję VS i kliknąć “new solution”. Założyć nowe repozytorium kodu zamiast pchać wszystko w jedno miejsce. Widzicie różnicę? Ta jedna prosta zmiana uwalnia nas od wszystkich ograniczeń: wykorzystywanych bibliotek, ich wersji, a nawet praktyk i stylu kodowania!
Oczywiście pojawiają się nowe wyzwania, jak chociażby zarządzanie administracyjne wieloma aplikacjami zamiast jednej. Tutaj przychodzą z pomocą świetne narzędzia (jak Octopus Deploy), które nie tylko ten problem w znacznym stopniu mitygują, ale też uświadamiają, że podejście “wieloaplikacyjne” jest po prostu lepsze niż podejście “monolityczne” nawet z administracyjnego punktu widzenia (można chociażby aktualizować tylko małą część systemu zamiast całości za każdym razem). A jakie ciekawe wyzwania się rodzą! Jak te aplikacje mają się między sobą komunikować? Przez wspólną bazę? A może na gołym MSMQ? A może RabbitMQ? A może nad to jeszcze MassTransit albo NServiceBus? A może zwykłe API RESTowe wystawione na Nancy czy ServiceStack? To jest FUN!
Dochodzi też problem taki, że jak programista pracujący nad takim pobocznym projektem wpadnie pod pociąg (ale w Polsce, jak się okazuje, jednak nie pod Pendolino;) ) to ktoś inny musi jego kod przejąć. A tam będzie “straszne nowe”. Z jednej strony – rozumiem takie obawy. Ale trzeba na to spojrzeć z rozsądnego punktu widzenia… Trzeba tak dobierać zakres projektów “eksperymentalnych”, aby ich ogarnięcie nie było niemożliwe w skończonym czasie. Trzeba też zdawać sobie sprawę z tego, że programista MUSI się uczyć, nikt (chyba że jakiś pechowy leń) nie dojedzie do emeryturki (hehe) na wiedzy zdobytej na studiach (he-he i jeszcze raz he). Bardzo pomaga też praktyka dokumentowania swoich doświadczeń tak, aby nie szły w tak zwane zapomnienie. Albo w piach, jak krew. Firmowy OneNote to rozwiązanie doskonałe i bardzo pomocne w spisywaniu dev-bojów przez każdego programistę.
W Ultrico jest nas trzech, z czego dwóch (w tym ja) od niewiele ponad roku. Pracowałem nad około 10 projektami. Sam zacząłem chyba dwa. W jednym mogłem użyć Simple.Data, w innym NHibernate. W jednym projekcie jest Angular, w innym Knockout, w jeszcze innym być może sprawdzimy React. Tu mamy Moq, tam NSubstitute. Tu nlog, tam Serilog. Tu Shouldy, a tam Fluent-Validation. Tu rake, tam psake, a gdzieniegdzie dodatkowo wspomniany Octopus. Tu “czyste” TDD, tam raczej testy integracyjne… Długo by wymieniać. Wcześniej w Predice też projektów było dużo (ale i inna specyfika firmy) i też można było się pobawić, poeksperymentować. Ale znam również ból siedzenia w korpo, gdzie codziennie widzę to samo i na jakąkolwiek wzmiankę o wypróbowaniu czegoś innego, poszerzeniu horyzontów, dostaje się po łbie.
Opisywane przeze mnie środowisko pewnie ma swoje nazwy – może jakieś kojarzycie? Jedni nazwą to “microservices”. Inni: SOA. Jeszcze inni jeszcze inaczej albo wcale.
Ja tego nie nazywam w ogóle, bo dla mnie najważniejsze jest jedno: możliwość programowania przez eksplorację (podlinkowany post sprzed 4 lat!, aktualny do dziś). My, devy siedzące na samym dole w tych dev-kopalniach, powinniśmy walczyć o swoje prawa. Nie mamy Solidarności która będzie palić opony w naszym imieniu, ale zasugerować zmiany może każdy. A jak się nie da, to każdy z kolei może znaleźć bardziej elastyczne miejsce, w którym spędzi 1/3 swojego życia. Cel: zabić nudę. Nie dać się marazmowi. Nieustannie czerpać przyjemność z pracy. I rozwijać się nawet na “zwykłym” etacie.
Jak to u Was wygląda? Jak “ostrzycie piłę”? Możecie eksperymentować, czy jesteście uwiązani do jednego danego monolitu jak Jaś do Małgosi?
