Dokladnie opisana praca programisty

3

Drodzy forumowicze,

Czy mozecie mi powiedziec jak dokladnie wyglada praca programisty ? Czy dostaje on polecenie typu : Stworz program w ktorym w lewym rogu jest guzik , na ktory po nacisnieciu pojawia sie okno w ktorym wpisujesz na dole liczby , ktore sa podliczane i wyswietlane w nastepnym okienku w lewym gornym rogu ? I zadaniem programisty jest napisanie czystego kodu ? Jezeli tak to kto zajmuje sie design ? I funkcjonalnoscia programu ?
Czy polega to na innej zasadzie i programista wymysla sam jak program ma wygladac i funkcjonowac ? :)

Prosze o dokladna odpowiedz, pilne.

1

Różnie.
I zależy gdzie.

Czasami polecenie brzmi „zrób program do kosztorysowania” i musisz się głowić co ten program w ogóle ma robić.
A czasami „wypełnij funkcje zgodnie z zadaną deklaracją klasy i według dokumentacji”.

Prosze o dokladna odpowiedz, pilne.
Nie ma dokładnej odpowiedzi, bo każdy projekt jest inny.

Ale zdaj sobie sprawę z jednego: 90% programistów nie „stwarza programów” tylko dłubie w masakrycznie źle napisanym kodzie powstałym 20 lat temu, w którym nic się kupy nie trzyma, nie wiadomo o co chodzi, ale ma poprawiać błędy.

0

Rozumiem , ale czy jezeli chodzi juz o programowanie to czesciej dostaje sie czesta zadana deklaracje klasy i dokumentacje ? Czy jest to rownie zalezne ?

Moj kolega w holandii skonczyl studia i jego ostatni projekt wygladal tak ze dostal dokumentacje gdzie pisalo wszystko dokladnie jak wygladac ma program ( ze strony design ) a jezeli chodzi o kod, musial on go sam napisac.
I jak wyglada to poprawianie bledow i jak sie nazywa ta funkcja ? :)

1

@trOnk12, teoretycznie to niby tak powinno być, ale ja jeszcze takiej dokładnej dokumentacji nie widziałam. Jest super, jak mam dokładnie opisane funkcjonalności, które projekt ma udostępniać. Zazwyczaj w praniu się okazuje, że są opisane tak mniej więcej i analityk niespecjalnie przewidział wachlarz różnych przypadków i trzeba się o wszystko dopytywać i uzgadniać już na etapie programowania.

Za to od kolegi słyszałam (z innej firmy), że ma tak fajnie, że testerzy piszą testy jednostkowe, a on tylko ma zrobić, żeby program je przechodził.

0

Wiec rozumiem ze to co kolega mi mowi , to jest tak jak powinno byc w pracy programisty ? :) Nie jest to zaniżanie kwalifikacji programisty lecz praca taka jaka powinna byc wykonana ? :)

Moim drugim pytaniem jest czy w takiej dokumentacji powinno byc nawet napisane to gdzie "guzik" powinien sie znajdowac w danym programie ?

Kolejnym pytaniem jest to jakiego wyksztalcenia jest analityk ? :)

0
trOnk12 napisał(a):

Moim drugim pytaniem jest czy w takiej dokumentacji powinno byc nawet napisane to gdzie "guzik" powinien sie znajdowac w danym programie ?

Tak, powinno.

Kolejnym pytaniem jest to jakiego wyksztalcenia jest analityk ? :)

Zapewne analitycznego.

0
trOnk12 napisał(a):

Kolejnym pytaniem jest to jakiego wyksztalcenia jest analityk ? :)

Powinien ogarniać geometrię analityczną.
Pozdrawiam
c***

1

Moim drugim pytaniem jest czy w takiej dokumentacji powinno byc nawet napisane to gdzie "guzik" powinien sie znajdowac w danym programie ?

No więc ja jestem programistą, a nie designerem. Jak zleca mi się zaprojektowanie GUI, to można się przejechać na moim zmyśle estetycznym... Potem oczywiście jest masa poprawek, ten button w prawo, tamten większy itp.
Dodatkowo nie płacą mi jak analitykowi, więc przykro mi, gdy zwalają na mnie jego robotę.
Choć muszę przyznać, że czasem po prostu lubię tak zająć się zagadnieniem dookoła programistycznym...

1
aurel napisał(a):

Moim drugim pytaniem jest czy w takiej dokumentacji powinno byc nawet napisane to gdzie "guzik" powinien sie znajdowac w danym programie ?

No więc ja jestem programistą, a nie designerem. Jak zleca mi się zaprojektowanie GUI, to można się przejechać na moim zmyśle estetycznym... Potem oczywiście jest masa poprawek, ten button w prawo, tamten większy itp.
Dodatkowo nie płacą mi jak analitykowi, więc przykro mi, gdy zwalają na mnie jego robotę.

Ach te kobiety. Zawsze takie niezdecydowane. Raz piszą, że designer jest od projektowania GUI, innym razem, że analityk...

trOnk12 napisał(a):

Kolejnym pytaniem jest to jakiego wyksztalcenia jest analityk ? :)

To zależy jakiej dziedziny dotyczy tworzone oprogramowanie. Jeżeli tworzony jest system dla księgowości, to analityk powinien mieć wykształcenie księgowe, jeśli tworzony jest system edukacyjny, np. wspomagający naukę matematyki, to analityk powinien mieć wykształcenie matematyczne. Oprócz tego, analityk powinien posiadać zdolność zrozumiałego wyrażania swoich myśli.
Niestety, ale w wielu polskich firmach, stanowisko analityka jest postrzegane jako kolejny stopień w karierze programisty. W takich firmach, analitykami często zostają programiści. Tego typu analitycy wykonują kiepską analizę i tworzą pogmatwaną dokumentację. Często w takich przypadkach łatwiej jest zapytać klienta jakiej funkcjonalności oczekuje, niż zrozumieć o co chodziło programiście, który awansował na analityka.

0

A wiec, moi drodzy tak jak praca wyglada mojgo znajomego w holandii powinna wygladac kazda praca informatyka ? :) po prostu swoja kreatywnosc uzywa w robieniu kodu a nie w design ? :)

0

Hmm, pracuję jako "software engineer" i generalnie poza klepaniem kodu to:

  • biorę udział w estymacjach projektu
  • opracowuje feature listy
  • wspieram opracowywanie solution proposali
  • robię research technologiczny

Jak już mamy konkretny projekt (czyli tak jak piszesz "zrób program który robi A", opisany w solution proposalu) to do nas (developerów) należy zaprojektowanie appki, zakodowanie, zrobienie UI (zwykle bazując na mockach).

0

W niewielkich firmach a szczególnie startupach programista robi wszystko - od kontaktu z klientami, po planowanie architektury, implementacje i testowanie.
W korporacjach zazwyczaj jest znacznie większa specjalizacja: programista jest małym trybikiem - dostaje specyfikacje stworzoną przez analityków i/lub projektantów i jego zadaniem jest przełożenie specyfikacji na kod. Jedyne testy jakie pisze to testy jednostkowe (o ile w ogóle).
To są dwie skrajności spektrum, w rzeczywistości możesz się spotkać z różnymi mieszankami w zależności od rozmiaru firmy i wykorzystywanej metodologii.

0

A ja pracuje w starym, smiedzacym, 20 letnim kodzie gdzie nikt nie wie o co chodzi, ale poprawic bledy trzeba. Na szczescie mam plan ewakuacji z tego miejsca, bo pracujac w ten sposob czlowiek sie uwstecznia a wyplata nie motywuje...

0
masakrator napisał(a):

A ja pracuje w starym, smiedzacym, 20 letnim kodzie gdzie nikt nie wie o co chodzi, ale poprawic bledy trzeba. Na szczescie mam plan ewakuacji z tego miejsca, bo pracujac w ten sposob czlowiek sie uwstecznia a wyplata nie motywuje...

Stary 20 letni kod, wcale nie musi być uwsteczniający. Jeśli znasz założenia funkcjonalne danego fragmentu systemu, to możesz zrobić refactoring brzydkiego kodu i zamienić go na piękny kod. Jak będziesz robił zmiany kroczek po kroczku tak jak woda podmywa skałę, to z beznadziejnie napisanego systemu otrzymasz dzieło sztuki.
A jaka później radość gdy w systemie kontroli wersji zobaczy się starą wersję kodu i porówna ją z nową.

0
Igor1981 napisał(a):
masakrator napisał(a):

A ja pracuje w starym, smiedzacym, 20 letnim kodzie gdzie nikt nie wie o co chodzi, ale poprawic bledy trzeba. Na szczescie mam plan ewakuacji z tego miejsca, bo pracujac w ten sposob czlowiek sie uwstecznia a wyplata nie motywuje...

Stary 20 letni kod, wcale nie musi być uwsteczniający. Jeśli znasz założenia funkcjonalne danego fragmentu systemu, to możesz zrobić refactoring brzydkiego kodu i zamienić go na piękny kod. Jak będziesz robił zmiany kroczek po kroczku tak jak woda podmywa skałę, to z beznadziejnie napisanego systemu otrzymasz dzieło sztuki.
A jaka później radość gdy w systemie kontroli wersji zobaczy się starą wersję kodu i porówna ją z nową.

W idealnym swiecie pewnie by tak bylo ale:

  1. kod jest nadal rozwijany - dodawane sa nowe funkcjonalnosci, wiec jakikolwiek refactoring wiazalby sie z wprowadzaniem zmian do obecnego kodu i refactoryzowanego
  2. wstepne estymacje architektow mowia o roku - dwoch potrzebnych na przepisanie tego calego bajzlu
  3. "klient za to nie zaplaci"
0
Masakrator napisał(a):
  1. kod jest nadal rozwijany - dodawane sa nowe funkcjonalnosci, wiec jakikolwiek refactoring wiazalby sie z wprowadzaniem zmian do obecnego kodu i refactoryzowanego

Nowy kod trzeba pisać porządnie, a nie refactoryzować go. A jak w nowym kodzie odnosisz się do starego, to jest to dobra okazja do poprawienia fragmentu starego kodu. Kroczek po kroczku, aż cel zostanie osiągnięty.

  1. "klient za to nie zaplaci"

Patrz co napisał @siararadek

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