![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 77 Pomógł: 0 Dołączył: 4.02.2014 Ostrzeżenie: (20%) ![]() ![]() |
Cześć, w swojej karierze programisty zauważyłem pewne dość popularne zjawisko, które według mnie nie koniecznie jest dobre, chodzi o sposób zabierania się do tworzenia i planowanie projektów.
Główni programiści lub menadżerowie projektów, tworzą jakieś ogólne opisy funkcjonalności na 2-3 strony w zależności od złożenia projektu i to jest wszystko co dostaję jako wiedzę o projekcie, na której mam bazować ( Jeszcze widoki psd, ale to oddzielna kwestia ). Zaczynając pracę nad projektem posiłkując się takim dokumentem w momencie kiedy zaczynam tworzyć daną funkcjonalność za każdym razem muszę dopytywać jak dokładnie ma działać i wyglądać, bo jej opis jest zbyt ogólny. Bardzo często widoki (psd) nie uwzględniają wszystkich potrzebnych funkcjonalności, o których wiadomo jest od początku, lub byłoby wiadomo gdyby bardziej szczegółowo projekt został obmyślony. Mam wrażenie jakby to był jakiś standard w pracy w zawodzie programisty i, że właśnie tak powinno się pracować. Jakieś takie spontaniczne tworzenie aplikacji i dokładniejsze planowanie poszczególnych funkcjonalności w trakcie ich tworzenia. Porównać to można do budowania domu, bez jego projektu, bezwiednego i nieprzemyślanego wcześniej zabierania się za każdy następny etap budowy (nie chciałbym w takim domu mieszkać ). Nie wiem z czego to wynika, czy to jest kwestia lenistwa menadżerów projektów i głównych programistów, natłoku zadań, podejścia, czy jeszcze czegoś innego. Według mnie przed w ogóle rozpoczęciem pisania jakiegokolwiek kodu i tworzenia widoków psd, aplikacja powinna być rozpisana tak szczegółowo jak to tylko możliwe, dzięki czemu w czasie trwania prac nie ma zaskoczeń, przestojów, zbędnego zastanawiania się za co następne się brać i jak to wykonać, bo wszystko jest rozpisane, a pracę idą płynniej, efektywniej, sam kod może być bardziej uporządkowany i przemyślany. Uważam, że porządna specyfikacja zawiera w sobie takie elementy jak: - wypisane wszystkie podstrony ( wszystkie adresy url) - wszystkie formularze odpowiedzialne za wprowadzanie i edycję danych w poszczególnych funkcjonalnościach wraz z wszystkimi polami, walidacją i przyciskami - wszystkie dane na poszczególnych podstronach jakie mają zostać wyświetlone ( index rekordów, show rekordu w zależności czy mają istnieć) - wszystkie formularze odpowiedzialne za usuwanie danych, pojedyncze lub mnogie, lub takie i takie - najlepiej wszystkie akcje, które użytkownik może wykonać tj. get, post itp. - studium przypadku poszczególnych akcji, żeby wychwycić możliwe błędy lub problemy. - jeśli to mozliwe to zaplanowanie bazy danych ze wszystkimi polami, kluczami i referencjami Chciałbym poznać Wasze zdanie na ten temat i dowiedzieć się ilu jest ludzi, którzy w jakimś stopniu podzielają moje zdanie. Może dodalibyście coś do tej listy? Sądzę, że żeby napisać optymalną i efektywnie funkcjonującą aplikację, szczegółowe jej obmyślenie jest nieodzowne. Detale uważam za całkowicie istotne, bo to one zbierają się na całokształt. Wątpię, żeby google lub inne marki w dziedzinie aplikacji www, podchodziły w sposób spontaniczny do tworzenia swoich projektów. |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 77 Pomógł: 0 Dołączył: 4.02.2014 Ostrzeżenie: (20%) ![]() ![]() |
Cytat Żyjesz w świecie utopii. Teoria mówi jedno, a praktyka pokazuje co innego. Czas to pieniądz, często nie ma czasu na "tracenie" go na tworzenie dokumentacji i pełnej specyfikacji systemu. W pracy zajmujemy się akurat pojedynczymi modułami, dostajemy konkretną funkcjonalność do wykonania i to robimy. Mimo, że są to mniejsze kroki niż cały projekt od 0 to też nie mamy czasu na przygotowanie się do zadania. Otrzymujemy czasem wręcz szczątkowe informacje i trzeba zacząć robić. W międzyczasie uściśla się wymagania, niektóre wywalające do góry nogami to co już zostało stworzone. Problem jest w określaniu terminów takich prac gdy do końca nie wiesz co i jak trzeba zrobić. Swego czasu kolega otrzymał do oszacowania (cytat!): "Zmiany na widoku użytkowników"... To już było kuriozum smile.gif no i dla mnie to jest właśnie programistyczna tragedia. Ps. nie mówię o dokumentacji. Cytat A ja napiszę tak: ciesz się, że w ogóle dostajesz jakieś plan. W mojej praktyce zawodowej spotykam się, zwłaszcza w pracy z systemami ticketowymi, jedynie ze skromną informacją od klienta na zasadzie: chciałbym aby to było zrobione tak i tak. Koniec. O wszystko trzeba podpytać, czasami klienta uświadomić, że rozwiązanie w tej formie jaką on sobie wymyślił nie sprawdzi się w praktyce, albo że można zrobić coś zupełnie inaczej, znacznie lepiej. Często przypomina to niedokończoną książkę, z której, pomimo materialnego braku kartek i okładki trzeba zrozumieć główny wątek, motywy bohaterów i napisać jej streszczenie. Bez sporej dozy zdrowej wyobraźni ani rusz. W idealnym świecie, programista bez otrzymania konkretnej dokumentacji technicznej planowanego projektu tj. diagramów pakietów, klas, erd, sekwencji itd. w ogóle nie powinien zabierać się do pracy. Niestety rzeczywistość wygląda zupełnie inaczej. Czasami przypomina to walkę z klientem o każdy strzęp, niemal ochłap informacji na temat planowanej modyfikacji. Jaki z tego wniosek? Zdobywanie wiedzy o wdrożeniu jest częścią naszej pracy. Odpowiednie zadawanie pytań klientowi/PMowi, logiczne wnioskowanie, budowanie pełnego obrazu na podstawie fragmentów bazując jedynie na doświadczeniu i wiedzy jest tak samo częścią naszego warsztatu jak znajomość podstaw języka programowania, w którym pracujemy, albo podstaw frameworka na którym budujemy aplikacje. Ja nie mówię o współpracy z klientem bezpośrednim, trudno wymagać od klienta bezpośredniego specyfikacji heheh. Mówię o podejściu głównych programistów i menadżerów projektów do tego. tak po za tym, jak się robi marne oprogramowanie, to nie dziwota, że trzeba spinać się i pisać szybko, bo się dostaje marne pieniądze. Ten post edytował Omenomn 18.12.2015, 16:06:01 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 12.10.2025 - 22:58 |