Wątek przeniesiony 2015-01-04 01:20 z Newbie przez somekind.

Praca programisty - pseudokod

0

Witam! W tym poście chciałbym przedstawić kod/ algorytm pracy programisty tak jak ja to widzę. Proszę o poprawienie jeśli gdzieś jest coś nie tak lub wygląda to inaczej.

pracaProgramisty (zadanie X)

  1. Dostaje się jakieś zadanie i dana grupa/ zespół programistów ma je wykonać.
  2. Dzielicie się pracą.
  3. Musisz zrobić Y w czasie Z
    3a. Zastanawiasz się jak to zrobić.
    3b. Szukasz odpowiednich narzędzi.
    3c. Robisz jakiś koncept, mape myśli, schemat(blokowy) jak ma to wyglądać.
    3d. Przechodzisz do kodowania.
    3d1 . Nie działa więc szukasz pomocy w swojej grupie.
    3d2 . Dalej nie działa więc piszesz na forum, Q&A.
    3e. Wysylasz dzialajacy kod na Github lub jakis system kontroli wersji.
  4. Twoj kod przegląda tester
  5. Dopóki tester znajduje błędy
    5a. Poprawisz kod
    5b. Kod nie działa? --> patrz punkt 3d1 oraz 3d2
  6. Zadanie gotowe
  7. pracaProgramisty(zadanie Y)

Parę pytań:
-czy czas Z jest liczony wraz z testowaniem aplikacji/ programu?
-czy po przyjęciu do pracy jest czas na zapoznanie się z technologiami używanymi w firmie?
-czy programista musi znać dokładnie biblioteki czy po prostu musi wiedzieć, że za pomocą danej biblioteki można to zrobić to i tamto i w razie potrzeby szuka składni i odpowiednich funkcji.

Z góry dziękuję za odpowiedzi! ^^

1

Ad.3. To nie tak. Estymacja to estymacja. Może się okazać że zadanie jest krótsze albo dłuższe. Zresztą idea jest taka żeby estymować za pomocą abstrakcyjnego parametry "story point" który określa trudność zadania. Wtedy można sobie na koniec każdej iteracji policzyć ile story pointów twój zespół potrafi średnio wykonać w ciągu iteracji. Jeśli estymujesz czasowo i przekroczysz czas to znaczy że estymacja była błędna ;)
Zwykle ten czas uwzględnia też "przetestowanie" z punktu widzenia developera. Tzn zanim cokolwiek commitujesz to sprawdzasz czy to co napisałeś działa i czy nie wysypuje całego systemu.
Ad.3e. Przed tym punktem masz code-review. Tzn 1-2 osoby przeglądają kod, który napisałeś i analizują czy czasem nie zrobiłeś tam czegoś głupiego. Następnie dostajesz zalecenia co warto poprawić. Dopiero potem commit.
Ad.3c. Rzadko kiedy pojedyncze zadania są na tyle skomplikowane żeby tak robić.
Ad.4. Przed ty punktem serwer CI buduje system z twoimi zmianami i puszcza testy automatyczne, które mogą wykryć że jednak coś popsułeś. W takiej sytuacji zwykle jest automatyczny revert twoich zmian (żeby inni developerzy mogli cały czas pracować na "działającym" kodzie).
Poza tym testerzy NIE przeglądają kodu. Testerzy zajmują się testami APLIKACJI a nie kodu. Tester odpala system z funkcjonalnością którą napisałeś i następnie klika / karmi system danymi testowymi etc. i na tej podstawie ocenia czy działa zgodnie z oczekiwaniami czy też nie. Testerzy zasadniczo nie widzą kodu

Zawsze jest czas na wdrożenie się. Ale nie mylmy tu pojęć. Twój pracodawca zakłada że znasz technologie - np. jestem devem javy to znaczy że znasz javę, pisałeś w springu to znaczy że znasz springa itd. Więc wdrożenie polega na poznaniu systemu i ewentualnie technologii "wewnętrznych".

Nikt nie każe ci wkuwać manuala na pamięć. Ale jednocześnie pewne rzeczy zwyczajnie będziesz wiedział jeśli będziesz ich używał.

0
OrientMantis24 napisał(a):

[...]

-czy programista musi znać dokładnie biblioteki czy po prostu musi wiedzieć, że za pomocą danej biblioteki można to zrobić to i tamto i w razie potrzeby szuka składni i odpowiednich funkcji.

Z góry dziękuję za odpowiedzi! ^^

To jest zagadnienie, ktore bardzo mnie ciekawilo na samym poczatku mojej przygody z programowaniem. Mam kuzyna, ktory na codzien programuje maszyny w duzej korporacji i generalnie to wlasnie on byl i jest dla mnie motywacja do pracy. Jak mu zadalem to pytanie, to stwierdzil, ze nie jest sie w stanie zapamietac wszystkich bibliotek jakie wystepuja. Najwazniejsze, to zeby miec ppjecie o tym co chce sie zrobic i ewentualne braki uzupelniac na biezaco poprzez poczytanie w necie o problemie, ktory aktualnie sie napotyka. Ja jestem na poczatku swojej kariery, szukam pracy w branzy, mam nadzieje zatem, ze o wiele bardziej doswiadczeni beda mieli rowniez podobne zdanie na ten temat.

0
OrientMantis24 napisał(a)

3c. Robisz jakiś koncept, mape myśli, schemat(blokowy) jak ma to wyglądać.

Shalom napisał(a)

Ad.3c. Rzadko kiedy pojedyncze zadania są na tyle skomplikowane żeby tak robić.

Zależy jakie zadania. Jeśli masz zaprojektować coś większego, to jednak zaplanowanie sobie wcześniej jak to będzie wyglądać bywa pomocne, a nawet jest czymś w rodzaju dobrej praktyki. A kartka papieru i długopis (ew. jakiś program do rysowania diagramów) to dobrzy przyjaciele programisty.

0

Jasne ale póki co 90% pracy w pl to rozwijanie istniejących systemów. Tam zadania zwykle są małe i jasno określone i raczej dość "oczywiste" jeśli chodzi o ich realizację.

1 użytkowników online, w tym zalogowanych: 0, gości: 1