Nie trzeba raczej nikogo przekonywać, ze programowanie jest procesem dość złożonym. Dobry program składa się z tak wielu elementów: kodu, który jest łatwy w utrzymaniu, testów, architektury, dokumentacji, wzorców projektowych.... Można tak wyliczać i wyliczać. Mam jednak do Was, drodzy czytelnicy, pytanie. Zastanawialiście się kiedyś co tak naprawdę jest najtrudniejszym elementem programowania? Co Wam wtedy przyszło na myśl? Tony książek i tutoriali, które musieliście przewertować by zdobyć potrzebną wiedzę? Kontakt z klientem, który rzadko wie, czego chce? Czy może coś innego, mniej namacalnego?
Zdaje sobie sprawę, że jest to pytanie mocno subiektywne, dlatego chciałbym wam przedstawić mój punkt widzenia. Pierwszy raz będę uzewnętrzniał się na temat nie do końca techniczny, nie poparty stricte dowodami. Liczę na wyrozumiałość, a zarazem chętnie poznam Wasz punkt widzenia - zapraszam do komentowania ;)
Bo najtrudniejsze jest...
Uczestniczyłem w projektach różnego rozmiaru - i tych angażujących wieloosobowe zespoły, jak i mniejszych, nad którymi sam sprawowałem piecze (no dobra, ja i kubek kakałka). Część z nich rozwijałem przez lata, inne ledwo kilka tygodni, czasem dni. Pracując nad każdym z nich spotykał mnie ten sam, dotkliwy problem. Czasem, fakt, była to moja wina, jednak równie często wynikało to z błędów pozostałych członków zespołu.
Zgodnie z tradycją wszystkich wielkich dzieł, nie przejdę jasno i klarownie do meritum. Pełne wczucie się w sytuacje wymaga nakreślenia tła. A zacznę od prostego stwierdzenia. Żyjemy w społeczeństwie informacyjnym. Zewsząd docierają do nas informacje o nowych technologiach, framework-ach czy innych faktach z bardzo szybko rozwijającej się branży IT. Cały ten pęd zdobywania wiedzy, konieczność wychodzenia poza strefę komfortu czy myślenia out-of-the-box często znacząco odbija się na powodzeniu / jakości / terminie dostarczenia wykonywanego produktu.
Sam pamiętam sytuacje, gdy wracałem z jakiejś konferencji z nastawieniem "Zmienię swój świat na lepsze, zastosuję XYZ", gdzie jako XYZ możecie podstawić dowolną technologię. Czasami odnosiłem sukces, jednak zdecydowana większość takich prób kończyła się de-motywującym fiaskiem. Jako przykład pragnę opisać historię z początków prac jako programista .NET. Miałem już wtedy kilka lat pracy zawodowej na karku. Zaczynałem jako PHP-owiec, później przerzuciłem się na Front. Posiadając różnorodne doświadczenia planowałem się wykazać i zacząć "z grubej rury". Otrzymałem do zrobienia aplikacje komunikującą się asynchronicznie pomiędzy dwoma systemami, która ma działać jako usługa windows-a. Na pierwszy rzut oka nic trudnego. Zwyczajnie miała przesyłać wiadomości, pliki, trochę strumieni danych. Podjąłem decyzję, że użyje do tego programowania reaktywnego. Wtedy, w świecie frontend-u, na świat wypłynął Rx.js . Widząc implementację w .NET to od razu postanowiłem ubrudzić sobie ręce i wbić się w tą technologie.
Jak pewnie domyślacie się, nie wyszło to najlepiej :) Pomimo zostawania po godzinach, nadal nie byłem zadowolony ze swojego projektu. Co z tego, że działał, jeśli stabilność pozostawiała wiele do życzenia? Przy dużych obciążeniu zajmował bardzo dużo zasobów. No tragedia.
... Zachowanie Zdrowego Rozsądku
Co mnie zawiodło? Przede wszystkim zdrowy rozsądek. Zabrakło głosu w głowie, który by powiedział:
"Człowieku? Co Ty robisz! Przecież to Twój pierwszy, większy projekt w tym języku... na tej platformie... no w tej firmie! Po co chcesz sobie dodawać nowy paradygmat, wraz z nową, nie do końca poznaną biblioteką" ?
Teraz wiem, że nie da się przeskoczyć etapu poznawania nowej technologii. Zdarza mi się sięgnąć po nowe rozwiązania, jednak nigdy z miejsca. Implementacje do projektu poprzedza minimum weekend intensywnego testowania możliwości i badania dokumentacji.
Z doświadczenia uważam, że zachowanie zdrowego rozsądku jest najtrudniejszą rzeczą w pracy programisty. Pamiętajcie, aby zastanowić się dwa razy, zanim dodacie jakąś zależność do projektu. Odpowiedzcie sobie na pytanie "Jakie problemy to rozwiązuje? Dlaczego chcę dodać to do projektu?".
Tym zdaniem was zostawiam.
Mam nadzieje, że nie zanudziłem :P. Macie pytania dotyczące codziennego życia z kodem? Nurtuje Was jakiś aspekt branży IT? Dajcie mi znać, chętnie opisze to w następnych postach:)
Jak zawsze, do następnego :)
Cześć