Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> automatyzacja pracy
jarmiar
post
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ć
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi
thek
post
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ć?
Go to the top of the page
+Quote Post

Posty w temacie


Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 6.10.2025 - 01:07