Algorytmika, a praca programisty

Nastały u mnie ostatnio jakieś takie filozoficzne i myślicielskie czasy, mianowicie - "Jak to jest z algorytmiką w pracy programisty?".
Studiuję, cały czas staram się poszerzać swoją wiedzę z zakresu programowania oraz informatyki, dlatego nie mam pewności czy też wiedzy, co do pracy programisty. Wiadomo, że programistów, albo lepiej - ludzi tworzących oprogramowanie można podzielić na klepaczy i programistów. Ci pierwsi, kiedy dostają zadanie zaczynają po prostu go klepać, nie zastanawiając się, jak po co - dobrze zna język to zaklepie dany program. Druga grupa, to grupa bardziej "wyrafinowana", która myśli nad tym, co robi i stara się to robić najlepiej jak się da, a co z tego czasem wychodzi to inna sprawa :P. Mówię to przez pryzmat tego, co udało mi się słyszeć i czytać w ostatnich latach - bo jako tako, doświadczenia w firmie nie mam. Dlatego, jeśli opowiadam farmazony to mnie zjedźcie ;).

Tu też nasuwa się moje pytanie - skoro programista chce rozwiązywać problem najlepiej, jak się da to czy znajomość algorytmiki jest mu w tym niezbędna? Nie chodzi mi tu o jakieś super skomplikowane algorytmy z Google'a, ale o te podstawowe, jak grafy, programowanie dynamiczne, algorytmy tekstowe, kombinatoryczne itd. Wiem, że to też są rozbudowane przykłady, jednak od tego zaczyna się nauka algorytmów w większości przypadków. Jak to się przekłada na pracę typowego programisty w jakiejś firmie X (no, pomijamy tu może Google czy Microsoft)? Czy często korzystacie z drzew czerwono-czarnych, algorytmu Dijkstry, Eulera czy KMP itp.? Czy też może sama algorytmika ma służyć do poszerzania granic i rozwijania samego myślenia z mniejszym naciskiem na wykorzystywanie w dalszym etapie pracy?

Czytałem różne rzeczy, jedni piszą, że jest to potrzebne inny, że wcale tego nie używają. A jak jest z tym naprawdę?

Ci pierwsi, kiedy dostają zadanie zaczynają po prostu go klepać, nie zastanawiając się, jak po co - dobrze zna język to zaklepie dany program. Druga grupa, to grupa bardziej "wyrafinowana", która myśli nad tym, co robi i stara się to robić najlepiej jak się da, a co z tego czasem wychodzi to inna sprawa

Większość problemów, z którymi napotykam się w pracy, nie wymaga specjalnie dużo myślenia, tylko zwykłego klepania. Fakt, że ja jestem na najniższym możliwym stanowisku (tj. student).

Czasem jednak zdarza się (sytuacja z którą obecnie walczę), że jest sobie system działający od dłuższego czasu, ale ze względu na zmiany poza nim (np. w ilości dziennie przetwarzanych danych) nagle zaczął zajmować 1.2GB pamięci. No i jest problem, trzeba system zoptymalizować. No i tutaj znajomość algorytmów/sprytnych struktur danych nagle staje się nieoceniona.

Algorytmika:

• bardzo istotna w każdej gałęzi szeroko pojętej Informatyki, m.in. obróbka grafiki, komunikacja sieciowa, bazy danych, algorytmy genetyczne, kryptografia.
• pełni kluczową rolę w tworzeniu innowacji np. algorytm PageRank i historia powstania Google.
• jest szeroko wykorzystywana poza Informatyką np. algorytmy giełdowe, mechanika kwantowa.
• wymagająca myślenia, przez niektórych postrzegana jako rozrywka umysłowa
• sprawia frajdę i uzależnia

Większość roboty to klepanie, ale czasem jest też wymyślanie. Poza tym takich rzeczy jak tablice mieszające czy drzewa zrównoważone używa się na co dzień, np klasy java.util.HashSet czy java.util.TreeMap i warto wiedzieć jakie mają złożoności operacji i przynajmniej z grubsza wiedzieć jak działają. A jeśli na algorytmach się nie znasz, jak większość programistów, to do tworzenia algorytmów cię nie wezmą. Proste.

Myślę, że jak ktoś udowodni, że jest dobry w algorytmach to inni będą z jego wiedzy chętnie korzystać.

Znajomość algorytmiki przez wielkie A - czyli tej formalnej, drzewa, grafy, tablice hashujące, listy, stosy, sterty - przydaje się przy tworzeniu normalnych programów (jak sam napisałeś, nie dotyczy to osób zajmujących się zawodowo na przykład tworzeniem algorytmów w Google) dość rzadko.

Ale istnieje druga strona medalu - algorytmika ukryta, z której korzystasz nieświadomie co kilkanaście minut pisania. Nie musisz odróżniać VListy od B-Drzewa, ale musisz mieć pewną umiejętność wymyślenia sposobu rozwiązania problemu w kodzie programu - niejako przetłumaczenia go na język komputera.
Przykłady takich zadań:

• narysowanie choinki (o podanej wysokości i szerokości) w konsoli
• znalezienie w tablicy wszystkich ciągów rosnących i na przykład zsumowanie ich elementów
• mnożenie wielkich liczb (w postaci tablicy znaków każda - mnożenie pisemne)

Ludzie zaczynający programować mają bardzo duże problemy z takimi zadaniami - nie dlatego że nie znają zupełnie swojego języka programowania tylko dlatego że nie umieją w nim myśleć.

Edit: No i chociaż co to złożoność obliczeniowa oraz dlaczego jest tak ważna właściwie trzeba wiedzieć żeby nie być bezmyślnym klepaczem.

Można nie znać algorytmów i spokojnie zarobić na chleb a nawet zrobić karierę w 90% prac w IT.
Z drugiej strony najciekawsze (przynajmniej dla mnie) i najbardziej innowacyjne projekty wymagają algorytmicznego myślenia i także często znajomości konkretnych działów matematyki.
Tak więc każdy ma wybór: jeżeli kogoś nie nudzi samo pisanie niezbyt skomplikowanego kodu (w standardowych projektach komplikacja objawia się przez dużą ilość nieskomplikowanego kodu) i raczej nie ma głowy do algorytmów to może sobie spokojnie odpuścić ten dział (wystarczy znajomość podstaw, np. żeby oszacować jak szybko działają operacje na mapie, liście itd).
Jeżeli ktoś lubi algorytmy i matematykę to też może znaleźć pracę gdzie będzie rozwijał te umiejętności. Minus jest taki, że takiej pracy jest raczej mało, z drugiej strony może być dobrze płatna.

W mojej obecnej pracy takich "algorytmów algorytmów" używałem do sortowania i wyszukiwania, żadnego algo wymienionego przez autora topica nie musiałem używać. W ogóle nad samą czystą implementacją (konkretnych metod) nie ma dużo myślenia, wystarczy znać technologię. Myśleć trzeba podczas projektowania hierarchii klas, rozdzielaniem odpowiedzialności itp.

Jeśli chodzi o złożoność czasową to na pewno wiedza w tym zakresie jest niezbędna - dobrze zoptymalizowany program to program lepszy. Rzucone przeze mnie algorytmy były takimi przykładami, które pierwsze nawinęły mi się na myśl. Jestem ciekawy też, jak w aplikacjach biznesowych wykorzystywane jest sortowanie wielu danych przy jej dużej liczbie? Czy stosuje się z reguły wbudowane funkcje sortujące, które gównie mają zaimplementowane Quicksort'y czy też wykorzystuje się bardziej popularne i prostsze algorytmy typu insertion sort lub merge sort? Jaki ogólnie, aplikacje biznesowe mają stosunek do algorytmiki? Czy polega to na dobrej znajomości danej technologii i umijętności jej wykorzystania w danym problemie, czy też idzie się dalej i rozbudowuje struktury, drzewa itp. przy projektowaniu danych?
Sama wiedza algorytmiczna wydaje mi się ciekawa, choć czasem na prawdę nie ma się pomysłu do wymyślenia dobrego algorytmu.:)

@up, naprawdę duże dane sortowałabym B-drzewem. W pewnym momencie nie jest już takie ważne, w jakim tempie dana operacja się wykona, ważne jest, by wykonała się w ogóle - a nie np. wywalała się na OutOfMemoryException.

aurel napisał(a)

@up, naprawdę duże dane sortowałabym B-drzewem. W pewnym momencie nie jest już takie ważne, w jakim tempie dana operacja się wykona, ważne jest, by wykonała się w ogóle - a nie np. wywalała się na OutOfMemoryException.

No niby tak, jednak jeśli potrzebujemy szybki dostęp do bardzo dużego zbioru danych danych? Wtedy czas jest istotny i czasem sortowanie, które da wynik w czasie o kilka sekund szybszym jest lepszym wyjściem niż algorytm, który sortuje dłużej.

several napisał(a)

Myśleć trzeba podczas projektowania hierarchii klas, rozdzielaniem odpowiedzialności itp.

A to jest przy tworzeniu współczesnych systemów informatycznych ważniejsze niż samodzielne implementowanie starych algorytmów.
I projektowanie obiektowe jest ogólnie rzecz biorąc trudniejsze. Wystarczy spojrzeć na tych szpecjalistów po uniwerkach, którzy na studiach sortowali grafy wielkich liczb bąbelkowo wzdłuż i wszerz przy użyciu ONP, a programowanie obiektowe polega u nich na stworzeniu static class UniversalClass z 20k linii metod statycznych.

Algorytmy to ciekawa sprawa - niestety na studiach są takiej staroświeckiej formie i mogą wydawać się przez to nieprzydatne. Dotyczy to szczególnie zagadnień optymalizacyjnych, nawet tak prosta rzecz jak sprawdzanie czy dana liczba jest pierwsza może sprawić komuś trudność jeśli będziemy rozpatrywać liczby 300 cyfrowe :D

Chociaż to też pewnie dużo zależy od tego kto jakie rzeczy pisze.