Kawałek kodu z którego jesteś dumny i dlaczego?

możemy w sensie pokazać komuś z zewnątrz kod który pisałam dla innej firmy? No niech się w łeb walną
czyli tylko z projektów prywatnych a tam akurat bywa bajzel

Ja mam prawie 17 lat doświadczenia i mam tylko takie, z których nie jestem dumny.

W sumie nie wiem, co bym na takie pytanie mógł odpowiedzieć. Od pewnego momentu zacząłem pisać kod tak, że wszystkim co napisałem mógłbym się pochwalić i być z tego dumny, bo jest dobrze zrobione, przetestowane automatycznie, udokumentowane i działa : D. Z drugiej strony, nie jestem jakimś geniuszem, żeby chwalić się rewolucyjnym algorytmem jak np. słynny szybki pierwiastek z quake 3.

Znalazłem niedziałającego ifa po 3 dniach, odwróciłem warunek i działa. Wszyscy zadowoleni.

Tu raczej nie chodzi o rewolucyjny kod, który zmienia świat. Moim zdaniem wystarczy odnieść się do problemu (nawet niespecjalnie trudnego/wybitnego), który rozwiązałeś i jesteś w stanie go ładnie opisać. Mówisz co było problemem, dlaczego najprostsze rozwiązanie Cię nie zadowalało, co wypracowałeś finalnie i co to dało dla projektu/zespołu. Jeśli nie tworzysz jakiś rewolucyjnych rzeczy (jak 99,9% osób) to moim zdaniem jest to najlepsze podejście do tego typu zadania. Pokazujesz w ten sposób, że programujesz świadomie i się starasz.

Kiedyś byłem dumny jak zamiast pętli FOR zacząłem stosować iteratory - a teraz to jest już norma.
Duma i zadowolenie przy pisaniu kodu szybko znikają, gdy człowiek się rozwija.

Ja jestem dumny, jak wypieprzam znaczne bloki kodu, i program nie tylko ciągle działa, ale nawet lepiej

Łapię się do kategorii ?

Ja nie bardzo rozumiem, o co chodzi w takich pytaniach na rekrutacji.

Jeśli firma szuka programistów do pisania komercyjnego kodu, to powinni pytać raczej o kawałek kodu, którego się wstydzisz i dlaczego. Bo to by bardziej odzwierciedlało standardy jakości większości firm

Większość kodu komercyjnego to istny burdel (im więcej osób w zespole, tym większe spaghetti), więc co im z tego przyjdzie, że im pokażę swoją bibliotekę open source, która ma ciekawe techniki, czysty kod i 90-100% pokrycia testami? Chyba nic, bo komercyjnie takiego kodu raczej nikt nie pisze.

Ba, nawet w swoich prywatnych projektach jak zamiast skupiać się na kodzie i architekturze, zaczynam się skupiać na ficzerach, to jakość kodu często spada, bo zaczynam dodawać w pośpiechu różne rzeczy i w pośpiechu naginać dobre praktyki albo pakować coś w nie do końca przemyślaną architekturę.

Oj przecież to nic nie znaczące pytanie, wpisz tam cokolwiek, i tak przejdziesz do next etapu xd

mechanix napisał(a):

nie miałem takiego momentu, że kod który napisałem był jakoś szczególnie błyskotliwy i napawał mnie dumą

Ja bym raczej poprawił zdaniem, że może nie dumny, ale ciekawy projekt :>

Jeśli się gdzieś pracuje to ma się wydzielone konkretne zadania, jeśli samemu tworzysz projekt to jesteś one man army.

Dla mnie coś ciekawego to np. zbudowanie modelu 3d na podstawie zdjęć/filmu z różnych perspektyw, a detale jak rozwiązane przy pomocy jakich języków i jakim stylem, mniej istotne, chodź jak ktoś tylko na to patrzy, to może się nie spodobać.

Samo w sobie stworzenie ciekawego projektu, dla mnie jest trudne, trzeba wymyśleć coś ciekawego, potem potrzeba zaplanować wszystko, co potrzeba kupić, co wykonać, w czasie robienia wychodzą następne problemy.
Jak wyobraźnia zawodzi to trzeba wszystko mieć spisane na kartce papieru.

Dumnym ciężko jest być jeśli zrobisz jakieś rozwiązanie i się okaże, że istnieje jakieś lepsze to albo najlepsze jest albo średnie.

Pytanie, czy kawałek kodu, czy kawał kodu ;)

1. Nie wiem, czy całość projektu się liczy, ale kiedy przychodziłem do jednego miejsca to razem z resztą zespołu zastaliśmy bałagan doskonały. Duża aplikacja, która de facto pełniła rolę wielu aplikacji - wystarczyło podmienić klasę uruchomieniową. Oczywiście aplikacje nie miały za dużo z sobą wspólnego, może poza pewnymi kawałkami kodu. Do tego brak testów, wszystko było testowane podczas wdrożenia.
   Jak wychodziłem po dwóch latach to:

• projekt został przeorganizowany na moduły gradle'owe i libkę
• większość tych modułów miała już całkiem spore pokrycie testami
• błędogenność aplikacji spadła o jakieś 60%, tj. o ile wcześniej zdarzały się problemy związane z tym, że ktoś zmienił coś niechcący, o tyle po naszym refactorze wszystko zrobiło się ładne

1. Na mniejszą skalę - znów refactor kawałka przejętego systemu. Ogólnie system naklepany w Javie 1.4 i przeportowany na 1.5. Całość systemu była baaardzo słaba, natomiast jeden kawałek, służący do uploadu zdjęć do bazy danych w formie BLOBa był wyjątkowo paskudny. Ot, był to kawałek, który brał dane z jednego z czterech miejsc (w zależności od miejsca, w którym użytkownik kliknął - różniło się szczegółami) i zapisywał do jednego z dwóch miejsc w zależności od parametrów. Ponieważ wszystko było zapisane w dwóch klasach to ifologia ogarniająca de facto osiem przypadków biznesowych i kilkanaście mniejszych reguł była po prostu wspaniała.

Wydzieliłem dwa interfejsy (jeden do odczytu danych, drugi do zapisu), dorobiłem cztery implementacje pierwszego i dwa drugiego, dorobiłem odpowiednie if'y, które sprawdzały, która implementacja jest potrzebna i poszło.

alert('dupa');

Jak tak sobie pomyślę, to jestem dumny chyba jedynie z wypieprzenia kilka tysięcy linii kodu, który był nieużywany (były to nieskończone feature'y, które tylko śmieciły, bo ktoś robił je w pośpiechu i potem nie dokończył przez zmianę priorytetów).
Żadna nowa linijka kodu nie dała mi tyle radości. :)

Dla tego tematu zalozylem konto - wiec Witam :D
Tego co robie w pracy choc ciekawsze, oczywiscie pokazac nie moge.
Jendak czasem po godzinach klikam sobie w moj pet project. Kilka (wedlug mnie) ciekawych fragmentow:

• https://github.com/pandafolks/panda/blob/master/routes/src/main/scala/com/github/pandafolks/panda/routes/RoutesServiceImpl.scala#:~:text=private%20def%20searchMappers2point0(data%3A%20List%5B(String%2C%20MapperRecordPayload)%5D%2C%20groupName%3A%20String)%3A%20List%5B(String%2C%20MapperRecordPayload)%5D%20%3D%20%7B
• https://github.com/pandafolks/panda/blob/master/healthCheck/src/main/scala/com/github/pandafolks/panda/healthcheck/DistributedHealthCheckServiceImpl.scala#:~:text=private%20def%20backgroundJob()%3A%20Task%5BUnit%5D%20%3D
• https://github.com/pandafolks/panda/blob/master/routes/src/main/scala/com/github/pandafolks/panda/routes/RoutesTreeImpl.scala#:~:text=override%20def%20find(path%3A%20Path%2C%20standaloneOnly%3A%20Boolean%20%3D%20false)%3A%20Option%5B(RouteInfo%2C%20Map%5BString%2C%20String%5D)%5D%20%3D%20%7B

Dlaczego:

• napisane w jezyku, w ktorym nie pisze na co dzien
• w niektorych miejscach byc moze nawet funkcyjnie ;)
• ciekawe z algorytmicznego punktu widzenia

Rozpocząłem pracę w lokalnej firmie.
Mała firma mały zespół.
Na wstępie dostałem zadanie do wykonania, pewną aplikację automtyzującą pewne procesy.
Zajęło mi to około miesiąca, poukładałem wszystko w klasy, ładnie i logicznie (chciałem się wykazać).
Skończyłem dzień przed review(wtedy, było to nowum w zarządzaniu projektem, że inni komentują kod itp.).

Następnego dnia na review, szefu (który też był programistą), pokazał mi mój kod przerobiony wedle jego uznania.
Ze 2 klasy w każdej klasie kilka metod, a całość liczyła około 4k linii. Po prostu powsadzał mój kod w te swoje metody.
Potem zaczęła się gadka typu: Czemu tak długo? Po co tak komplikować? Po co svn w tak małym projekcie?
Po co te testy? (faktycznie napisałem własny "framework" testowy bo nie można było dosysać "obcych" modułów).
Z tego kodu nie jestem dumny.

Natomiast jestem dumny z kodu, który dostałem następnego dnia, w celu poprawy.
Kod na ~10k linii, 5 metod, każda metoda ~2k linii. Zdawkowe komentarze typu: "użycie biblioteki A".
Ten otrzymany kod pozwolił mi zweryfikować gdzie się znalazłem i jak szybko trzeba stąd uciekać.
Wypowiedzenie rzuciłem jeszcze tego samego dnia.

Głównie pisze narzędzia desktopowe sobie, albo kolegom z biura. Przeważnie cale testowanie odbywa się z poziomu użytkownika i to tam wyłażą błędy które później na czym prędzej musze poprawiać ;).
Nabrawszy wprawy na takich prostych projektach, podszedłem do dużego projektu z którego korzysta obecnie kilkanaście osób w firmie. Projekt ułatwia aktualizowanie danych w firmowym systemie ERP. Zanim zacząłem ten projekt pisać napisałem mnóstwo testów jednostkowych, wszystkie warunki brzegowe, wszystkie dopuszczalne i niedopuszczalne dane wejściowe, jakieś w ogóle abstrakcyjne przypadki wymyślałem i pod te testy pisałem cały kod biznesowy. Naprawdę jestem mega zadowolony z tych testów, z zakresu pokrycia kodu, z jakości testowanych aspektów, i z wyniku jaki dzięki nim uzyskałem. Bo uruchomienie tego projektu co prawda nie obeszło się bez błędów ale zdecydowana większość błędów dotyczyła raczej prezentacji danych czy widoków ale nie dotyczyła ryzyka uszkodzenia danych w ERP.
Szkoda że pomimo takiego dobrego doświadczenia wróciłem w innych prostszych i mniej odpowiedzialnych narzędziach do poprzedniego stylu pracy, czyli "szkoda czasu na testy lecimy z mięsem a potem jakoś się to poprawi" ;)

Widać, że autor tego HR'owego pytania nie ma pojęcia o duszy programisty. Pięknie, błyskotliwie wygląda... typu "gdzie widzisz siebie za pięc lat".

Prawda jest jedna, pomimo kwantowego sposobu bycia tego świata...
Wydaje mi się, że jak programista napisze kod, przeczyta, przetestuje, działą, zostawi to, to kiedy by nie wrócił, to i tak patrzy okiem gospodarza - czy to da się jakoś uprościć/ulepszyć... a programista rozwijać się musi, taka natura, więc jasno wynika, że nawet patrząc na własny kod, po jakimś czasie, w końcu widzimy, że coś dojżalszego można wstawić, wywalić coś co trąca wiochą... skrajnie trochę pisze - ale przecież z przyjemnością i po kryjomu poprawiamy swój kod. Nieważne pobudki - czy wydajność, czy czytelność, czy że koledzdy będą się śmiali, bo - co ja głupi? - zamiast frameworka użuć pisze surowego SQL? ..
To tak jak by czuć dumę ze swoich dzieci, wiedząc że robią się coraz głupsze.

Ale, autor (tego pytania rekrutacyjnego) chciał chyba miło połechtać osobę, bo wyrażnie namawia do - "chwal się..."
Tymczasem, mnie się wydaje, że dumę można poczuć, kiedy się dowiadujesz, że kod który wyprodukowałeś kilkanaście lat temu, działa do dzisiaj, nie był źródłem problemów i nikt nie chce go zmieniać. Znasz ten kod, chętnie byś go przepisał na lepsze.... ale on działa, robi swoje i ludzie są zadowoleni. O, to jest duma.
No bo jeśi moją pierwszą grywalną girkę napisałem na turbopascala, a umiejętności miałem tak mało że zamiast tablicy były pojedyńcze zmienne... no nie wiem, dumy z kodu zero - ale z programistycznej roboty byłem zadowolony, wręcz naćpany radością.

...nie dziwne, że nikt nie może sobie przypomnieć "złotych linijek kodu", bo i tak mogą być jescze bardziej złote.

*) moja wypowiedź nie ma wiele wspólnego z zasadami gramatyki - jeśki ktoś by jeszcze nie dowierzał.

A wy? Macie jakiś kawałek którym możecie się pochwalić?

pewnie, wrzuciłbym mu

Wole naklepać parę zadań leetcode czy AdventOfCode bo nie ma się co oszukiwać, na froncie mało jest algorytmiki.

Ja raczej odwrotnie - aoc czy lc wydają się być stratą czasu w porównaniu do sensownych projektów

te rekrutacje są pełne durnych pytań.

do tego czasem zadadzą 2 pytania z tyłka, a potem w ocenie od HR dostajesz brakuje wiedzy z XYZ WTF 2 pytania dostałem, to czemu inni rekrutujący stwierdzili, że mam wiedzę z XYZ.

z jakiego kodu jesteś dumny?
z żadnego. Prosty kod nie jest powodem do dumy, a skomplikowane rzeczy zawsze da się zrobićlepiej.

Z kodu który prezentował na ekranie animację 3d - tak zwaną wektorówkę napisaną do pewnego dema na procesorze 6502 (dla ATARI 800XL), który nie miał nawet wsparcia do mnożenia (poza przesuwaniem bitów - czyli mnożeniem x2) a potrzebne było w tym programie mnożenie przez sinusy i cosinusy. Program wynikowy mieścił się w jakichś 13kiB (tak kilobajtach). 100% własna produkcja bez copy-paste z cudzego kodu - stackoverflow wtedy jeszcze nie istniał :) Nawet procedura LINE (DRAWTO) zaimplementowana samodzielnie. Wszystko w asemblerze. Animacja wyciągała czasami 74 klatki/sekundę.

mechanix napisał(a):

A wy? Macie jakiś kawałek którym możecie się pochwalić?

Mam i to sporo. Jednak najprawdopodobniej pytający i tak by go absolutnie nie "zakumał" nie rozumiejąc kontekstu, zatem samo pytanie o taki kod jest dość dziwne.
Rzeczy proste t.j. zwykłe CRUDY czy fragmenty aplikacji obsługi formularzy raczej mają być czytelne i łatwe w rozbudowie - mało tu miejsca na szczególną finezję i bycie z tego dumnym.

Takich kodów, z których można być dumnym może być wiele rodzajów a sam kod wcale nie musi być czymś wyjątkowym. Instalowałem kiedyś sterownik dystrybutora paliw, który był podróbką innej znanej marki... Niestety nie był w 100% z nią kompatybilny. Klient był 500km od miejsca pracy i olanie problemu podczas wdrożenia wiązało się z koniecznością:

• powrotu do domu ;
• załatwieniu identycznego urządzenia do testów ;
• ponownym wyjeździe do klienta ;

Generalnie od cholery roboty... Postanowiłem więc na miejscu zdebugować (najpierw podglądając transmisję po RS) co się dzieje (w nie moim programie sterownika) i zauważyłem pewne rozbieżności w czasach odpowiedzi względem oryginalnego urządzenia (dystrybutor potrzebował więcej czasu na przyjęcie kolejnych rozkazów). Dopisałem jedną linijkę chamskiego delay_ms(2), który załatwił temat i wszystko zadziałało...
Byłem z tego dumny jak diabli bo po pierwsze nie byłem szczególnym specjalistą od tych sterowników po drugie oszczędziłem sobie, kolegom z firmy, i samej firmie kupę czasu i pieniędzy.|

Zatem prezentuję kod, z którego jestem dumny:

  delay_ms(2);

Mam też sporo programów/kodu, które moim zdaniem w piękny sposób rozwiązują pewne złożone zagadnienia z mojej branży. Sam kod może nie jest szczególny ale zawarta w nim idea napawa mnie dumą i radością, że coś takiego udało się w tak elegancki sposób rozwiązać.

Mało kiedy istotne jest dla mnie to w jaki sposób kod jest napisany poddając ocenie równe wcięcia, piękne funkcje itp... bo to wg mnie jest nuda dla dzieciaków, którzy bardziej jarają się tym jak i w czym piszą niż tym co piszą.

Jak się zastanowić, to dumę po napisaniu kodu czułem na początku nauki programowania. Duma nie wynikała z tego jakiej jakości był kod, ale z tego, że robił to co chciałem.
Nigdy później już tego nie miałem.

z żadnego, bo średnio po pół roku napisał bym wszystko w zupełnie inny sposób

jest to dla mnie sposób mierzenia czy się rozwijam, jak ten sam kod napisałbym tak samo po pół roku to znaczy że niczego się nie nauczyłem

Marcin Marcin napisał(a):

z żadnego, bo średnio po pół roku napisał bym wszystko w zupełnie inny sposób

Też mam takie myśli. Nawet najlepszy kod, jaki kiedyś napisałem nie jest na tyle dobry, żeby pokazać go jako przykład moich aktualnych umiejętności. Z kolei nawet najlepszy kod, jaki jestem w stanie teraz napisać, nie odzwierciedla moich umiejętności za pół roku czy rok.

Więc z czego tu być dumnym? W sensie jestem dumny z pomysłów, na jakie wpadłem kiedyś czy projektów, jakie zrobiłem, ale niekoniecznie z ich realizacji. A przynajmniej nie na tyle, żeby mówić "ojejku, jak jestem dumny z tego kodu" (bo co innego, jeśli pokazać jako przykład starannego poprawnego kodu "no, kiedyś coś takiego pisałem i kod w miarę czysty, pokrycie testami 90-100%, ogólnie może być").

No dobra, czasem jestem dumny ze snippetów na kilkanaście linijek kodu, które w prosty sposób robią coś fajnego. Może o to chodzi w tym pytaniu? O wrzucenie inspirującego snippeta?

W sumie ciężko dojść czy rekruterowi chodzi o pokaż projekt-arcydzieło będące dla ciebie tym, czym Linux dla Linusa Torvaldsa, czy pokaż projekt, gdzie masz najczystszy możliwy kod, genialną architekturę i 150% pokrycia testami czy pokaż inspirujący snippet zawierający ciekawą technikę.

LukeJL napisał(a):

Marcin Marcin napisał(a):

z żadnego, bo średnio po pół roku napisał bym wszystko w zupełnie inny sposób

Też mam takie myśli. Nawet najlepszy kod, jaki kiedyś napisałem nie jest na tyle dobry, żeby pokazać go jako przykład moich aktualnych umiejętności. Z kolei nawet najlepszy kod, jaki jestem w stanie teraz napisać, nie odzwierciedla moich umiejętności za pół roku czy rok.

Więc z czego tu być dumnym? W sensie jestem dumny z pomysłów, na jakie wpadłem kiedyś czy projektów, jakie zrobiłem, ale niekoniecznie z ich realizacji. A przynajmniej nie na tyle, żeby mówić "ojejku, jak jestem dumny z tego kodu" (bo co innego, jeśli pokazać jako przykład starannego poprawnego kodu "no, kiedyś coś takiego pisałem i kod w miarę czysty, pokrycie testami 90-100%, ogólnie może być").

No dobra, czasem jestem dumny ze snippetów na kilkanaście linijek kodu, które w prosty sposób robią coś fajnego. Może o to chodzi w tym pytaniu? O wrzucenie inspirującego snippeta?

W sumie ciężko dojść czy rekruterowi chodzi o pokaż projekt-arcydzieło będące dla ciebie tym, czym Linux dla Linusa Torvaldsa, czy pokaż projekt, gdzie masz najczystszy możliwy kod, genialną architekturę i 150% pokrycia testami czy pokaż inspirujący snippet zawierający ciekawą technikę.

Ja jestem dumny przeglądając kod sprzed 4 lat że mając tak małą wiedzę na podstawie tak prostych elementów byłem w stanie wpaść na genialne pomysły i rozwiązać problem. Pracowałem z tym co mam i nie zastanawiałem się czego nie umiem po prostu pisząc kod.

Ja bym napisał takiego który w ogóle nie powstał, np. z uwagi na inne podejście do rozwiązania problemu. Najepszy jest kod, który nie powstał, nie trzeba go utrzymywać, ani testować :)

sharper_99 napisał(a):

Ja bym napisał takiego który w ogóle nie powstał, np. z uwagi na inne podejście do rozwiązania problemu. Najepszy jest kod, który nie powstał, nie trzeba go utrzymywać, ani testować :)

z takiego jestem bardziej dumny