Wpis z mikrobloga

@Kuarito: wszystko po trochu, są róne sposoby - jeśli kod ma w miarę niezłą strukturę i dobre nazewnictwo, to da się szybko ogarnąć o co chodzi. Gorzej jak kod jest pisany przez 50 ludzi przez 10 lat na zasadzie "nie działa mi jeden przypadek, to dopiszę jeszcze jednego ifa i teraz działa" i większości tych ludzi nie ma już w firmie. Wtedy zabawa z takim dziełem w sumie nie różni się
  • Odpowiedz
@wodzik:
Jakby mi ktoś tak powiedział to rzuciłbym papierami tego samego dnia. Ostatnio w grudniu tak zrobiłem.
Im gorszy programista tym gorsza dokumentacja. Negatywnie wyróżniają się klepacze gówna >5 lat w jednej firmie którzy dokumentację, design i wymagania biznesowe mają w pustej głowie.

Dokumentacja i testy świadczą o tym, że jest czas aby je tworzyć czyli projekt prowadzony jest po ludzku. A przy takim projekcie jest spokój i dobrze się sypia
  • Odpowiedz
@tos-1_buratino: co w sumie programiści robią w pracy? Dla mnie to jest jakaś abstrakcja. Za bardzo się nie znam, ale powiedzmy, że jak np robisz 'tetrisa' to np robisz cały kod od 0, importujesz sobie bibliotekę graficzną i to co trzeba, deklarujesz jakieś bloczki, plansze, obroty przy inputach, jakąś logikę usuwania gdy rząd jest zapełniony itd itd. Jakby to ma sens.

Ale co w pracy się robi gdzie nad jednym wielkim
  • Odpowiedz
@LatajacyJeczmien:
Większość programistów obecnie pracuje z oprogramowaniem które łączy się do innych aplikacji poprzez sieć. Większość pracy to uzgodnienia z osobami odpowiedzialnymi za te inne aplikacje. Czytanie dokumentacji tych zewnętrznych systemów aby dostosować swój projekt do działania z nimi.
Dużo jest ustalania z klientem tego jak to ma działać. Czy wszystkie pomysły są sensowne.
Masa czasu to konfiguracja środowisk u siebie na kompie, na serwerze testowym, na produkcyjnym itp.
Jeśli są
  • Odpowiedz
@taraqui: @taraqui: @Krolik: jak się pracuje w Javie w tak zwanych sprintach to istnieje problem z dokumentacją. Ale wystarczy przeczytać kilka książek o czystym kodzie, mieć jakieś podstawowe doświadczenie i przede wszystkim zdrowy rozsądek. Niestety większość programistów nie potrafi myśleć. Oni myślą że potrafią myśleć ale nie potrafią czego przykładem jest dyskusja tutaj.

Kod może się sam dokumentować? Oczywiście że może. Ale kod to nie cały projekt. Podstawowe README
  • Odpowiedz
@LatajacyJeczmien: jest Scrum i scum master. Dostajesz taska, wycenionego przez jednego mózga, co siedzi w firmie 10 lat, i zna wszystko na wylot. Wycena na 20h, dla regurala w firmie 40h, wiec możesz liczyć 80h. Opis story na 3 zdania, z czego połowa źle, Aceptance criteria puste, bo biznes nie ogarnia.

Dzwonisz po ludziach, i w końcu wiesz gdzie zacząć. Apka kobyła, o architekturze lekko ociosanego monolitu, łączy się z jakimś
  • Odpowiedz
konto usunięte via Wykop Mobilny (Android)
  • 0
@Quzin: chciałem Ci przyznać rację do drugiego posta, a potem zobaczyłem pierwszy jak się #!$%@?łeś do #!$%@? wie czego i nazwałeś mnie żałosnym, teraz to fakaj bobla
  • Odpowiedz
Dokumentacja i testy świadczą o tym, że jest czas aby je tworzyć czyli projekt prowadzony jest po ludzku. A przy takim projekcie jest spokój i dobrze się sypia bo nie boisz się czy będzie nagły bug kolejnego dnia.


@tos-1_buratino: O to to. O zbędności dokumentacji mówią głównie ci, którzy #!$%@?ą w kołchozach gdzie liczy się to żeby zamykać 5 tasków dziennie w Jirze, a nie dowozić utrzymywalne, dobrze ustrukturyzowane i skalowalne
  • Odpowiedz