![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 616 Pomógł: 12 Dołączył: 16.07.2006 Skąd: : getCity ( ); Ostrzeżenie: (0%) ![]() ![]() |
cześć
chciałbym sie was zapytać jak radzicie sobie z presją czasu i oczywiscie jak automatyzujecie swoją pracę od dłuższego czasu wiele prac wykonuję od podstaw, dzięki czemu tracę cenny czas i wydajność spada ;/, a chciałbym jakoś to przyspieszyć |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D ![]() |
Po pierwsze analiza problemu, oszacowanie zadań oraz czasu na to przeznaczonego, oczywiście z naddatkiem na ewentualny poślizg lub ewentualne zmiany ze strony klienta. Z doświadczenia nie warto zakładać więcej niż kilka godzin na dobę, gdzie faktycznie praca daje efekt. Niby możesz klepać kod na okrągło, ale nie sądzę by wydajnie i w pełni udało Cisię więcej niż 5-6 godzin uzyskać. Zawsze stracisz czas na przełączanie się między zadaniami, odejścia od moitora by coś przekąsić, odpocząć od kodu. Po jakimś czasie pracy stwierdzam też, że tylko metodyki zwinne. Pisanie kodu 2-3 miesiące, by potem przez tydzień czy dwa czekać na feedback, nieraz w ogromnych ilościach pierdółek, to nie jest dla mnie idealne rozwiązanie. Lepiej mieć wsparcie klienta i testerów na bieżąco. Do tego więc jakiś issue tracker by mieć oko na to co poprawiać lub ogólnie jakąś tablicę, wspólną z zadaniami, gdzie ewentualnie wrzucane będą znalezione przez klienta błędy. Lepiej to zrobi Tobie pod kątem organizacji pracy (wiesz gdzie jesteś, co masz zrobić), jak i klienta, który widzi postępy, przez co nie truje Ci. No i wie, że też coś robi, ma wpływ na swój projekt (IMG:style_emoticons/default/smile.gif)
Oczywiście dobrze mieć jakieś narzędzia do wykonywania automatyzacji zadań pokroju buildy, testy jednostkowe, testy regresji. Jednym słowem Continuous Integration w praktyce, czyli Hudson lub podobne narzędzie. Zapominasz, że coś takiego jest, Ty piszesz kod, reszta dzieje się w tle. Sprawdzasz raz na jakiś czas jak wyniki. Dobrze byłoby mieć także na oku potencjalne wąskie gardła, co możemy uzyskać narzędziami pokroju Sonar, które między innymi analizują kod, wyszukując instrukcji niebezpiecznych wydajnościowo (zbytnia złożoność) czy niezgodnych z założeniami początkowymi (choćby standardy kodowania). O bezpieczeństwie kodu poprzez repozytoria kodu chyba nie muszę wspominać? |
|
|
![]() ![]() |
![]() |
Aktualny czas: 6.10.2025 - 17:36 |