Trochę o szkoleniu młodzieży

Właśnie zdałem sobie sprawę, że niedawno minęło 10 lat od kiedy zacząłem moją przygodę z programowaniem. Przypominam sobie od czego ja zaczynałem i na samą myśl o kodzie, który wtedy tworzyłem pojawia się uśmiech na mojej twarzy 🙂

Jako młodzi programiści na początku zawsze popełniamy błędy i często podążamy niewłaściwą drogą. Jak zatem poradzić sobie na początku, na co zwrócić szczególną uwagę, a czego się wystrzegać?

Na początek odpowiedzmy sobie na pytania, dlaczego pomimo tego, że w dużej mierze nasze projekty nie są jakieś strasznie skomplikowane i głównie polegają na odebraniu jakiś danych z formularza użytkownika, zwalidowaniu poprawności i zapisaniu w jakiejś bazie danych. To dlaczego większość z tych projektów kończy się klęską albo w najlepszym przypadku strasznym skomplikowaniem? Każdy kto przejmuje ten kod w utrzymanie zaczyna przeklinać…?

To co pierwsze przychodzi mi do głowy to skłonność do nadmiernego kopiowania cudzych rozwiązań. Metoda copiego pasta? Pomijam już takie przypadki, które zdarzyło mi się niestety widzieć w swojej karierze jak skopiowana metoda mająca 1000 linijek, wklejona pod spodem, a w niej zmieniona jedna linijka i jeden parametr – tego chyba nie trzeba komentować… Ucząc się programować czy to w ogóle szukając rozwiązań problemów korzystamy z dobrodziejstw Internetu. No i niestety często zdarza się, że kopiowane są rozwiązania bez przemyślenia jak to się wpisuje w aplikację, którą tworzymy, jaki ma to wpływ na architekturę? Moja rada jest taka, jeśli już kopiujemy jakieś rozwiązanie, spróbujmy je napisać po swojemu, coś pozmieniać, uruchomimy być może w ten sposób proces myślowy, który doprowadzi nas do lepszego rozwiązania? To samo tyczy się tzw. kodu legacy, który otrzymujemy w spadku w utrzymanie, często zdarza się, że nie zastanawiamy się nad tym jak to jest zrobione, wychodzimy z założenia, że skoro działa to po co coś zrobić lepiej, a często jeszcze bardziej bałaganimy… Jeśli jesteśmy na początku swojej przygody z programowaniem, nie róbmy tak, w ten sposób nie uczymy się niczego nowego, tylko stajemy się bezmyślnymi koderami, zawsze każde własne rozwiązanie, nawet jeśli jest niedoskonałe ale było próbą zrobienia czegoś lepiej to dobry pomysł – dzięki temu zdobywamy cenne doświadczenie.

Druga sprawa to nadmierne przywiązywanie się do frameworków i buzzwordów, tak sam pamiętam swoją fascynację MVC, po prostu musiałem tego gdzieś użyć, nieważne co to za projekt czy klient chce aplikację desktopową – musi być przy użyciu MVC. Jasne, że frameworki i różnego rodzaju fajne nowinki zawsze będą nas najbardziej kręcić, w końcu jesteśmy programistami, czyli osobami technicznymi i technologia zawsze będzie nas najbardziej kręcić. Po prostu zachowajmy umiar, nie starajmy się na siłę wciskać rozwiązań tylko dlatego, że są fajne albo modne. Co z tego, że nasza aplikacja jest napisana w Angularze, przy użyciu EntityFramework i SignalR skoro działa wolno i nie spełnia wymagań biznesu? W tej branży chodzi o to aby dostarczyć klientowi rozwiązanie jakiego potrzebuje, biznes nie potrzebuje frameworków, biznes chce zarabiać pieniądze, frameworki mają nam pomóc osiągnąć ten cel.

Jeśli Uncle Bob się nie myli pisząc na swoim blogu, że co 5 lat liczba programistów się podwaja to przed senior developerami, dev leadami, architektami stoi niezłe wyzwanie. Jak ogarnąć młodzież, jak sprawić, aby czerpali radość z poszukiwania rozwiązań, aby chcieli się uczyć nie tylko nowych frameworków ale też wzorców projektowych i dobrych praktyk. Jeśli jesteś starym wyjadaczem, guru czy zwał jak zwał to właśnie przed Tobą stoi największe wyzwanie. To Ty musisz być wzorem do naśladowania, ale Twoim zadaniem nie jest tylko nadawanie kierunku projektu i określania żelaznej architektury, którą robiłeś już setki razy. Jeśli sam nadal programujesz to dobrym pomysłem będzie, aby Ci ludzie poznali procesy myślowe, które doprowadziły do końcowego rezultatu, może wykorzystać do tego celu code review? Twoją najważniejszą misją powinno być przekonanie tych ludzi do ciągłej nauki, do szukanie samodzielnie rozwiązań, tak aby czerpali z tego co robią satysfakcję.

Dodaj komentarz