Frustracja przez (nie)optymalny kod

Witajcie,

chciałbym spytać Was o jedną kwestię. Mianowicie jak to jest z tym pisaniem optymalnego kodu w pracy?
Studiuję informatykę - wiadomo: często są jakieś programy do napisania. Jeśli chodzi o samo rozwiązywanie problemów, to raczej problemów z tym nie ma - program zazwyczaj robi co ma robić. Natomiast niezmiernie się irytuję i wkurzam, jeśli okaże się, że inni studenci napiszą ten sam program, ale w sposób bardziej zwięzły, optymalny, krótszy, szybszy, mniej pętli, funkcji, zmiennych itp. (na siebie oczywiście - że nie potrafiłem zrobić tego w lepszy sposób i że kiepski ze mnie programista). Prowadzący zajęcia oczywiście cieszą się, że są różne kody, nie zwracają w ogóle uwagi na to, aby kod był optymalny, a jedynie na to, aby program robił co ma robić, więc rzadko kiedy dostaje się jakiś feedback.
Jak wygląda ta kwestia w programowaniu komercyjnym? Jak duże znaczenie ma optymalizacja, jak dużą wagę się do tego przykłada? Chociażby w takim Web Devie.
Komuś też towarzyszy/towarzyszyła taka frustracja w podobnych sytuacjach? Pytałem znajomych ze studiów, to mówili, że nawet nie wiedzą o co mi chodzi

@Rozbisurmaniony: widać, żeś młody
jest na to taki kawał

Idzie młody nauczyciel i dźwiga w torbie wszystkie papiery. Mija starszego stażem nauczyciela i pyta:
– Proszę pana, pan to pewnie to wszystko ma w głowie?
– Nie proszę pana, ja to wszystko mam w d**ie – odpowiada sędziwy nauczyciel.

Twój PM nigdy nie popatrzy w kod, a nawet jakby popatrzył, to by nie zrozumiał, czy jest ładny, ale będzie się krzywił, że robiłeś taska godzinę dłużej niż mu wyszło z kalkulacji w Excelu.

Wygląda to różnie.

Na projektach komercyjnych często nikt nie zwróci uwagi o ile kod nie jest napisany z rażącym zaniedbaniem wydajności.
Zazwyczaj względy czytelności kodu są ważniejsze kosztem wydajności jednak do pewnej granicy i nie we wszystkoch przypadkach.

Ważne, żeby działał zgodnie z ustaleniami i nie walił błędami. Co do optymalizacji - oczywiście warto pisać jak najlepiej kod, jeśli są takie możliwości, ale też nie przesadzajmy. Są systemy gdzie to, czy coś ładuje się trochę dłużej nie robi różnicy, bo prędkość działania nie jest najważniejsza. Ale są też takie, gdzie to będzie mieć znaczenie.

Polecam zamienić frustrację w motywację do poprawy swojego kodu. Polecam chociażby zacząć od ebooków dotyczących refactoringu szczególnie w języku którego używasz na codzień.

Nie przejmuj się jeżeli twój kod nie jest najlepszy w grupie, moim zdaniem czytelniejszy kod jest zawsze lepszy, pamiętaj że programowanie to praca zespołowa, im łatwiej komuś zrozumieć twój kod, tym lepiej

krótszy kod =/= lepszy/szybszy

Rozbisurmaniony napisał(a):

Mianowicie jak to jest z tym pisaniem optymalnego kodu w pracy?

Ale co to znaczy optymalny?

• Optymalny czasowo (najmniej czasu trwa zadanie, request itd)
• Optymalny pamięciowo (najmniej ramu zjada podczas uruchomienia)
• Optymalny jeśli chodzi o czas dostarczenia (musiało zostać dostarczone na asap bo to bugfix na proda)
• Optymalny jeśli chodzi o czytanie (bo kod częściej się czyta)
• Optymalny jeśli chodzi o rozszerzanie (Tu mamy wzorzec Strategia bo dziś mamy tylko dwie Strategie i można by to zrobić na ifie, ale za miesiąc będzie 50 różnych Strategii)

itd itp

Zwykle za jedną optymalność płaci się utratą innej optymalności (prostota vs szybkość, zwięzłość vs możliwość rozbudowy)
itd itp

Co do mnie to uwielbiam programowanie funkcyjne i kod jest dla mnie maksymalnie czytelny jak jest tam minimalna ilość zmiennego stanu i tak staram się pisać, o ile nie ma innych wytycznych, i to uważam że standardowy sposób pisania standardowego optymalnego kodu. Ale wielokrotnie słyszałem że dziwne rzeczy piszę. (Głownie na początku przed Javą 8)

Dzięki Wszystkim za odpowiedzi. Może rzeczywiście za bardzo się tym przejmuję, niepotrzebnie. Pewnie za rok już całkiem inaczej będę na to patrzył i na pewno umiejętności będą inne, większe. Po prostu gdzieś z tyłu głowy miałem takie przeświadczenie (w sumie nie wiem skąd), że żeby coś było dobre, to musi być najlepsze ;) i rzeczywiście jak przedmówca napisał optymalizacja może być różna, zależnie od tego co chcemy osiągnąć

ZabawnyNick napisał(a):

Nie przejmuj się jeżeli twój kod nie jest najlepszy w grupie, moim zdaniem czytelniejszy kod jest zawsze lepszy, pamiętaj że programowanie to praca zespołowa, im łatwiej komuś zrozumieć twój kod, tym lepiej

krótszy kod =/= lepszy/szybszy

Czytelniejszy kod zawsze lepszy? Ty tak na poważnie?
Rozumiem, że jak ktoś Ci zarżnie bazę danych czytelnym kodem działającym nieoptymalnie to jest spoko ale gdy optymalny kod mniej czytelny działa przez 10 lat niezauważony to jest źle?

Zasada Pareta. 20% kodu odpowiada za 80% czasu wykonania. A w praktyce to pewnie nawet mniej niz 5% (edit: w sensie ze 5% kodu). Najbardziej oplaca sie optymalizowac waskie gardla.

Poza tym pisanie dobrego kodu wymaga najpierw obycia w pisaniu dzialajacego kodu. Jesli Ci zalezy to i tak przyjdzie z czasem.

Dużo się nie pomylę jeśli napiszę, że wielu z nas czasem ma "doła" i myśli o sobie źle porównując się do innych. Ale nic straconego. Pewnych rzeczy można się nauczyć. Co można zrobić w przypadku wątpliwości we własne umiejętności? Przypomnieć sobie o pewnych rzeczach

1. Każdy ma prawo czegoś nie umieć, szczególnie jeśli jest studentem. Ja mając za sobą niejedną batalię z kodem też czegoś nie wiem. Wtedy szukam w internecie albo pytam innych i nie patrzę czy są młodsi czy starsi. Nie sztuką jest przechwalać się wiedzą, ale przyznać do niewiedzy i wyciągnąć wnioski. A jeśli się przyznam, że nie wiem i ktoś mnie skrytykuje? To znaczy, że ta osoba dokonała osądu i krytyki. Osąd i krytyka nic nie wnoszą do tematu nauki. Kompletnie nic!
2. Już posiadana wiedza też coś wnosi, nawet jeśli są to podstawy. Wielu próbowało z podstawami i nie dali rady. Jeden krok zrobiony, robimy kolejne

Są trzy grupy ludzi:

• ci, co nie wiedzą czego nie wiedzą,
• ci, co wiedzą czego nie wiedzą i się tego uczą;
• ci, co już coś wiedzą,

Przechodząc z pierwszej grupy do drugiej już robimy postęp. Teraz pozostaje się uczyć i ćwiczyć, żeby wyrobić nawyki. Przypomnę tu przykład nauki pisania: dla szkrabów w podstawówce to nie lada wyzwanie. Dla wielu dorosłych z resztą też. Niech świadczy o tym mizerna liczba poczytnych pisarzy. W każdym razie raz nauczeni rzemiosła mamy je w nawyku i nie musimy myśleć jak się ono dzieje. Wniosek? Ćwiczyć i wyciągać wnioski!
Zapomniałbym dopisać: panika kiedy się nie wie a zrobić trzeba. My ani nasze problemy nie jesteśmy wyjątkowi. Tak samo ma dużo osób, tylko w innym wydaniu i nie każdy się przyznaje. Czasem można też coś skopać i nic się nie stanie. Zbugowany kod na prodzie? Zdarza się najlepszym. Oczywiście należy tego unikać. Chodzi o to, że nie ma co rozpaczać tylko robić swoje. Gdybyśmy tak wszystko rozpamiętywali, moglibyśmy pamiętać każdą wypełnioną przez siebie pieluchę i się za to winić.

Swego czasu był taki kolega. Kontakt się urwał, ale jak jeszcze był to pracował w dość dużej firmie, międzynarodowej. Narzekał że w pracy nie pisze się obiektowo. Wojny o to toczył.
Jego wizja obiektowości była ta właściwą.
Nie chciał zluzować gumy.
Nie powiem, technicznie chłopak ok, nie można się przyczepić, ale jak ktoś tu wspomniał najważniejsza umiejętność to umiejętność współpracy. Słabo u niego było bo albo wg niego albo wojna.
Inny kolega był po drugiej stronie barykady. Trafił na kogoś kto wie lepiej kiedy czego używać. Ztobilł słicza, a że opcji było więcej niż 3 ten ktoś na review kazał mu zrobić mapę.
Po wyrażeniu wątpliwości w odpowiedzi dostał, nie [CIACH!], rób jak mówię.
Uważaj tylko żeby te frustracje nie przeszły z kodu na jego twórców. Nie mówię żeby na review puszczać wszystko, ale żeby wiedzieć gdzie zluzować.

1. Poza pewnymi wyjątkami czytelność i rozszerzalność kodu jest dużo ważniejsza od zaoszczędzenia kilku cykli procesora. A i te wyjątkowe hotspoty optymalizuje się raczej później niż wcześniej. Nie mówie tu oczywiście o jakichś sytuacjach ekstremalnych, że ktoś robi O(2^n) zamiast O(n), albo generuje milion zapytań do bazy ;)
2. W pracy przykłada się wagę do tego zeby kod był zwięzły i czytelny, ale od tego są np. code review, gdzie więcej osób popatrzy na kod i zasugeruje co można poprawić. Programowanie to jest zajęcie "zespołowe".

Podpinam się pod pytanie.
Z uwagi na to że właśnie mam w pracy na tapecie raport który odpala (by design) jedno zapytanie na jeden wiersz (Mongo) to się zastanawiam, gdzie się podziały te wszystkie profilery, dibieje, testy wydajnościowe i programiści liczący bity.
Przecież 640 kB RAM powinno wystarczyć każdemu...

Poczytaj o złożoności obliczeniowej. Np. dlaczego(jeśli elementy tablicy są rosnące) lepiej użyć wyszukiwania binarnego niż liniowego.
Dlaczego używa się struktur drzewiastych(drzewa bst, czerwono-czarne) do układania danych w pamięci.
O co chodzi w O-notacji O(1) O(logn) O(n) (nlogn) O(n^2) O(n!)

https://www.geeksforgeeks.org/analysis-of-algorithms-set-3asymptotic-notations/
https://www.geeksforgeeks.org/analysis-of-algorithms-set-4-analysis-of-loops/
https://www.geeksforgeeks.org/analysis-algorithm-set-5-amortized-analysis-introduction/
https://www.geeksforgeeks.org/g-fact-86/

Komercyjnie zależy co programujesz w front-endzie raczej nie przejmują się złożonościa w embedded dużo częściej.
Ale jak coś działa a ma złożoność np. n^2 a ewidentnie można to zrobić w złożoności liniowej n to nawet na review każą Ci to przepisać.
Powinieneś mieć to na algorytmach i strukturach danych.

PerlMonk napisał(a):

Są trzy grupy ludzi:

• ci, co nie wiedzą czego nie wiedzą,
• ci, co wiedzą czego nie wiedzą i się tego uczą;
• ci, co już coś wiedzą,

Ja bym powiedział, że są:

• ci co nie wiedzą, że nie wiedzą
• ci co wiedzą, że nie wiedzą ale nie wiedzą ile
• ci co wiedzą, że nie wiedzą i wiedzą ile

Zawsze jest jakieś pole do poprawy - zwłaszcza przy kodzie. Niejednokrotnie miałem taką sytuację:

• napisałem kod z implementacją A
• dochodzę do wniosku, że jakbym przerobił to na B to by wyglądało lepiej
• B nie wygląda perfekcyjnie, więc zaczynam przerabiać
• kończy się na powrocie do A

Kiedyś mój kumpel powiedział, że aby zająć dwóch lub więcej seniorów na długie godziny to wystarczy im dać do rozwiązania prosty problem z prośbą, żeby było idealnie.