Praca dla wielkich korporacji

Matthew @ 2011-01-27 — Kategorie: Programowanie

Czemu nie należy programować dla wielkich polskich korporacji? Kod który się dostaje jest marnej jakości, pisany przez fanatyka C, który wyznawał zasadę, że jeżeli nikt inny nie będzie w stanie tego kodu rozwijać, to nie będą mogli zwolnić jego twórcy (mimo wieku wskazującego na posiadanie wnuków nadal pracuje w firmie). Fragmenty napisane w C++ (pewnie już przez kogoś innego) są cholernie wolne. Nie, nie dlatego że są napisane w C++, tylko dlatego że zatrudnia się do tej pracy oszołomów którzy w C++ pisać nie potrafią. Przykład? Split na stringu dostarczony w Boost jest 3 razy szybszy od tego co został ręcznie napisany w projekcie który mam przyjemność pisać (chcę umrzeć…). Ale nie można wykorzystać szybkich i gotowych bibliotek Boost, bo musiałoby to przejść przez całą biurokrację aby była możliwość wstawienia jednego include’a i dorzucenia kilku plików… jakby nietechniczna biurokracja wiedziała lepiej ode mnie co jest mi potrzebne do napisania wydajnego kodu. Dlaczego tak? Bo jest to znacząca zmiana powodująca rozrastanie się kodu. A to że większość softu mają w Javie EE i wrzucenie tam czegoś powoduje ogromne narzuty wydajności, pamięci i dysku to już nikt tego nie widzi. Żeby było ciekawiej kod nie zawiera praktycznie żadnych komentarzy, dokumentacja niewiele mówi i jest pisana dla biurokratów, nie dla programistów. Na sam koniec trzeba przeprowadzić i udokumentować testy. Bardzo szczegółowo… czy ja mogę prosić o równie szczegółową dokumentację i komentarze do kodu (chcę umrzeć po raz drugi…)? Po wszystkim piszemy dokumentację końcową opisującą jakie zmiany zaszły w kodzie. Żeby nie było za łatwo, należy ją napisać na wzór poprzednich dokumentacji, które zupełnie nic nie mówią o tym co zostało zmienione. Znaczy nic nie mówią programistom, bo ten język to chyba tylko gryzi-ołówki na wysokich szczeblach rozumieją, którym trzeba tą samą informację powtórzyć w kilku różnych sekcjach których tytuły nie odpowiadają temu ani co zostało zmienione ani gdzie (chcę umrzeć po raz trzeci).

Wniosek: nic tylko podziwiać programistów. Pracują na marnym kodzie, piszą głupoty (bo inaczej się nie da) w dokumentacji, której nikt techniczny i tak później nie przeczyta, bo nie zawiera grama przydatnych informacji.

Komentarze:

Nie martw się. Kiedyś przyjdzie następny programista i będzie mówił dokładnie to samo o Twoim kodzie.

@bigfun: chciałbyś. ;P Ja akurat swoje zmiany do tego projektu komentuję.

Use a spellchecker ;)
„Znaczy nic nie mówią programistą” raczej „programistOM”

@badboy: spellchecker niewiele da, bo obie formy są poprawne tylko w różnych sytuacjach. ;] Ale dzięki, poprawione.

Pozwolę sobie skomentować Twój wpis, jako dotyczy mnie bezpośrednio jak i innych programistów. Jestem w wieku wskazującym na posiadanie wnuczków, cóż Ciebie też to czeka jak i każdego innego programistę. Z tego też powodu posiadam większe doświadczenie niż świeżo upieczeni inżynierowie. Nie mówię o umiejętnościach lecz o doświadczeniu. Zobaczysz za 10-15 lat. Powstaną nowe technologie a Ty będziesz miał rodzinę, dzieci i masę innych problemów. Ważniejszych niż poznawanie nowych technologii. Drugą sprawą jest ów pisanie różnych procedur, fragmentów kodu od zera, a nie korzystanie z bibliotek. Ostatnio moja firma przyjęła kilku inż. na staże. Byłem bardzo podekscytowany mogąc ich po sześciu tygodniach wyrzucić za drzwi. Przyszli tacy samozwańczy programiści-magicy i jedyne co potrafili to przychodzić do takich dziadków jak ja i wypytywać o funkcje biblioteczne zawarte w kodzie, tłumacząc się, że na studiach dobrze poznali tylko stdio.h! Nie zrobili nic konstruktywnego! Popsuli jedno stanowisko i jedną bazę danych (nic nie wartą ale w raporcie odnotowano), a ludzie, którzy się nimi zajmowali przekroczyli deadline o trzy tygodnie dzięki czemu premie dla całego zespołu zostały rozdane dla /dev/null.

@zargon: nie czepiam się wieku programisty, ale jego podejścia do sprawy (piszemy trudny do zrozumienia kod, żeby nie mogli nas tak szybko wyrzucić). Wydajność jego kodu jest bardzo dobra, ale sposób w jaki został napisany woła o pomstę do nieba.
Poznawanie nowych technologii jest wpisane w nasz zawód. Poza tym nie chodzi o to że zostało to napisane ręcznie (bo bez problemu mógłbym napisać kod splita który jest szybszy od boosta – czasu mało a inne rzeczy były do robienia), ale o podejście biurokratyczne korporacji i panów siedzących za biurkami którzy w życiu linijki kodu nie napisali a chcą narzucać co ja mam używać w programie.
A tymi marnymi programistami to do czego pijesz?

„Poznawanie nowych technologii jest wpisane w nasz zawód”

Jakby nie patrzeć praca z kodem stworzonym przez kogoś innego – niekoniecznie wspaniałego – też jest wpisana w nasz zawód.

Post aż kipiący nienawiścią..

Owszem, czasami przychodzi nam pracować z kodem złej jakości… czasem się okazuje, że nie wszystkie fragmenty kodu są idealnie napisane, innym razem mamy Tworzyć dokumentację na podstawie poprzedniej, która nie istnieje…

„Kod złej jakości”, jest niestety bardzo subiektywnym wyrażeniem i mogę przypuszczać, że na swoje oczy prawdziwego kodu „złej jakości” jeszcze nie widziałeś ;) Nie żebym ja widział (no chyba że ktoś mówi o moim :P), ale za każdym razem gdy sądzę, że widzę jakieś dno, to okazuje się, że za jakiś czas widzę jeszcze gorszę. Parę razy jednak w moim życiu zdarzyło się doświadczyć bardzo ciekawej rzeczy. W informatyce-programowaniu jest pewna grupa problemów, które wydają się na początku proste, później jednak kod obrasta w poprawki obsługujące przypadki szczególne, poprawki do poprawek poprawiające jeszcze coś innego. Często kod końcowy nie ma nic wspólnego z kodem początkowym. Inna stara prawda mówi, że podobno trzecia implementacja jest najlepsza, gdyż pierwsza nie wie nic o problemach które zaistnieją, druga będzie przekombinowana, a dopiero trzecia będzie stanowiła złoty środek.

Co do dokumentacji… ja już się przyzwyczaiłem do jej pozornego braku w niektórych miejscach. Gdzieś powinna być dostępna dokumentacja ogólna mówiąca o tym jak funkcjonuje dany system, czy moduł, jednak nie możemy oczekiwać, że będziemy mieli dokumentacje do każdej funkcji czy klasy (w drugim przypadku ktoś może powiedzieć, że w przypadku klas powinniśmy, jednak wg mnie nie zawsze).

Co mam na myśli poprzez pozorny brak dokumentacji? Często funkcja blame podpowiada bardzo dużo na temat zmian. Jeżeli mamy nazwisko autora zmian poprzednich, to już mamy kogo męczyć ;) Jeżeli owa osoba jest np. modul ownerem, to w jej obowiązku powinno być odpowiedzenie na moje pytania dotyczące funkcjonowania danego modułu.

Generalnie to kod powinien być najlepszą dokumentacją. Jeżeli jakiś fragment kodu jest niejasny, to powinien być w miarę możliwości przepisany, by komentarza nie wymagał.

Co potrzeby pisania dokumentacji, to starałbym się wymusić, by przynajmniej moja dokumentacja mogła być generowana z kod.

A co do złych warunków… to uwierz mi, że dopóki nie trafisz do firmy(a słyszałem o takich) w której to nie będziesz mógł usunąć żadnego fragmentu kodu (co najwyżej zakomentować), to wówczas dopiero Cię szlak trafi ;)

Powietrze jest tak ciężkie, że aż do ziemi przygniata.
>>Uczen zapytal mistrza: „Tam gdzie wschodzi slonce jest taka wielka
drzewiasta struktura, ktora ludzie nazywaja ‚Zarzadem Firmy’. Sklada
sie z wicedyrektorow i ksiegowych. Wydaje liczne oswiadczenia,
z ktorych kazdy mowi ‚Zgodnie z zarzadzeniem’ albo ‚W terminie do’
i nikt nie wie o co chodzi. Co roku nowe nazwiska pojawiaja
sie na galeziach i zadnego z tego pozytku. Jak taka nienaturalna
rzecz moze istniec?”

Mistrz odpowiedzial: „Obserwujesz ta wspaniala strukture i jestes
oburzony, ze nie ma z niej zadnego pozytku. Czy nie mozesz
rozkoszowac sie jej nie konczacymi sie zawirowaniami? Czy nie
podoba ci sie swoboda programowania pod oslona jej galezi?
Czemu obchodzi cie jej bezuzytecznosc?<< Dla rozluźnienia polecam lekturę http://rudy.mif.pg.gda.pl/~bogdro/tao_programowania.txt

Dodaj komentarz:

 

Subscribe without commenting