9 najtrudniejszych zadań dla programistów
- 09.01.2014, godz. 13:00
Deweloperzy oprogramowania muszą sprostać wielu trudnym zadaniom. Większość z nich nie dotyczy jednak pisania kodu.
Deweloperzy oprogramowania muszą sprostać wielu trudnym zadaniom. Większość z nich nie dotyczy jednak pisania kodu.
Większość osób, które nie mają do czynienia z programowaniem, uważa, że to właśnie tworzenie oprogramowania jest najtrudniejszym zadaniem dla programisty. Faktycznie, nie jest to zbyt łatwe, ale programiści postrzegają to w zupełnie odmienny sposób. W jednej ostatnich dyskusji na forum Quora deweloperzy podzielili się swoimi odczuciami co do najtrudniejszych zadań, jakich wymaga od nich ich praca. Na podstawie forumowej punktacji i rozmów prowadzonych na innych forach dyskusyjnych stworzyliśmy listę 9 najtrudniejszych zadań dla programisty. Jak widać, pisanie kodów wcale do nich nie należy.
1. Nazywanie rzeczy
Zadanie: Wymyślanie nazw dla zmiennych, procedur, funkcji, klas, obiektów, baz danych, komponentów, itd.
Wyzwanie: Nawet niewielki program czy aplikacja wymagają nazwania wielu rzeczy. Wybór nazwy, która oddaje to, czym jest dana rzecz, w sposób spójny w całej aplikacji i zwięzły.
Cytaty:
"Wymyślanie znaczących nazw dla atrybutów danych i funkcji" Aditya Muraletharan
"W informatyce są tylko dwie trudne rzeczy: unieważnienie pamięci podręcznej i nazywanie rzeczy" Phil Karlton za Martin Fowler/Jatinder Singh
"...jeśli opanujesz usuwanie powtarzających się nazw i naprawianie złych nazw, wtedy opanowałeś projektowanie obiektowe" J.B. Rainsberger za Saager Mhatre
Zdjęcie: flickr/Jeremy Keith
2. Wyjaśnianie, czym zajmuje się programista (i czym się nie zajmuje)
Zadanie: Informowanie osobom niezwiązanym z programowaniem (rodzinie, znajomym, pracownikom innych działów), na czym polega praca programisty - i na czym nie polega.
Wyzwanie: Bliskie osoby nie rozumieją, z czego się utrzymujesz. Ciągłe prośby o rozwiązywanie wszelkich problemów związanych z działaniem komputera.
Cytaty:
"Próba wyjaśnienia (niemal każdemu), że naprawdę niewiem, jak naprawić komputer" Brandon P-Lost
"Wyjaśnienie mojej rodzinie, czym tak naprawdę się zajmuję" Utsay Singh Rathour
"Przekonywanie laików, że nie można programowć cały dzień i całą noc" Anand Safi
"Wyjaśnianie ludziom, że nie mam w każdym mieście sklepu, w którym mogę zainstalować im piracki system operacyjny czy jakiekolwiek inne pirackie oprogramowanie" Anbu Jey
Zdjęcie: flickr/Bruce Turner
3. Szacowanie czasu potrzebnego na ukończenie zadania
Zadanie: Szacowanie czasu potrzebnego do wykonania pracy jeszcze zanim rozpocznie się projekt.
Wyzwania: Próba odgadnięcia czegoś, z czym prawdopodobnie nie miało się do czynienia wcześniej, tworzenie szacunków na podstawie niejasnych wymagań i próba alokacji czasu potrzebnego na rozwiązanie nieprzewidywalnych problemów.
Cytaty:
"Strasznie trudno mi oszacować, ile niespodzianek przyniesie dany problem związany z programowaniem dopóki nie wypróbuję go w praktyce..." Jan Christian Meyer
"Moim daniem, najtrudniejsze są wszelkie szacunki, bo większość osób traktuje je jak obietnice" Samnang Chhun
"...przewidzenie czasu, jaki zabierze dane zadanie, jest w zasadzie niemożliwe..." Jack Menendez
Zdjęcie: flickr/Faith Raider
4. Kontakt z innymi ludźmi
Zadanie: Zbieranie informacji o wymaganiach klientów, przekazywanie kadrze kierowniczej bieżących raportów z projektu, współpraca z testerami i konsultacje projektowe z inżynierami.
Wyzwanie: Wyjaśnianie zawiłości technologicznych osobom spoza branży, radzenie sobie z tym, w jaki sposób inne osoby wpływają na wykonywaną pracę i niezgadzanie się z osobami od zapewnienia jakości lub innymi deweloperami.
Cytaty:
"Radzenie sobie z nie-inżynierami, którzy zachodzą nam drogę... Radzenie sobie z inżynierami, którzy mówią Ci, jak masz pisać kod..." Anonimowy użytkownik
"... ludzie z zerową wiedzą na temat branży, z którymi trudno jest się porozumieć" Inostdal
"czeka aż inny zespół skończy swoją pracę, co blokuje nasze działania..." Anonimowy użytkownik
Zdjęcie: flickr/Ray Crane
5. Praca na czyimś kodem
Zadanie: Konieczność utrzymania, naprawy lub wzbogacenia aplikacji lub części kodu, który został napisany przez innego programistę lub zespół programistów.
Wyzwanie: Próba zrozumienia, jak działa dana część zastanego kodu i właściwa interpretacja zamiarów pierwotnego dewelopera. To dużo trudniejsze, gdy nie ma go w pobliżu, a kod nie jest zbyt dobrze napisany, opisany lub udokumentowany.
Cytaty:
"Próba naprawienia źle udokumentowanego kodu" Omar Diab
"Odkrycie, że kod został napisany przez kogoś, kto chyba nie miał do tego wystarczających kwalifikacji" Nani Tatiana Isobel
"Próba rozszyfrowania tysięcy linijek nieudokumentowanego kodu" Simon Zhu
Zdjęcie: flickr/Garrett
6. Wdrażanie niechcianej funkcji
Zadanie: Wdrażanie funkcji, która, z jakiegkolwiek powodu, nie powinna się znaleźć w oprogramowaniu tylko dlatego, że tak nalega klient albo ktoś, kto zarabia więcej od Ciebie.
Wyzwanie: Odłożenie na bok osobistych odczuć i opinii, poświęcanie czasu i wkładanie wysiłków w odpowiednie wdrożenie (i obsługę) takiej funkcji.
Cytat:
"Można albo dostać szału albo przejść na wcześniejszą emeryturę" Sabbir Asgar
Zdjęcie: flickr/osaka19
7. Tworzenie dokumentacji
Zadanie: Stworzenie dokumentacji wyjaśniającej, jak działa kod lub aplikacja. Może zawierać niezależne dokumenty i komentarze do kodu. Grupa docelowa może obejmować zarówno innych deweloperów, jak i użytkowników końcowych.
Wyzwanie: Może być bardzo czasochłonnym zajęciem i odbierane jako strata czasu, zwłaszcza jeśli nikt nie przeczyta dokumentacji. Programiści zazwyczaj wolą tworzyć kod niż go dokumentować.
Cytaty:
"Tworzenie bezużytecznej dokumentacji, której nikt nie przeczyta i z której nikt nie skorzysta, tylko dlatego, że stanowi powszechną część procesu" Christian Dechery
"Tworzenie dokumentów, które mają zgrabnie wyjaśniać jak działa kod bez konieczności spojrzenia w niego" Raghu Nandan
"Pisanie dokumentacji, która jest dobra, obszerna i zwięzła - jednocześnie!" Ayush Goel
Zdjęcie: flickr/United States Mission Geneva
8. Pisanie testów
Zadanie: Pisanie testów jednostkowych, czyli testów programistycznych niewielkich jednostek oprogramowanie, których celem jest zapewnienie, że poszczególne funkcje i reguły będą zgodnie ze zdefiniowanymi wcześniej kryteriami. Takie testy pozwalają na wczesne wykrycie błędów i uchybień, na początkowym etapie tworzenia, i mogą ułatwić późniejsze testowanie regresji w przypadku modyfikacji kodu lub jego aktualizacji. W niektórych metodologiach tworzenia oprogramowania zaleca się pisanie testów przed stworzeniem kodu, a w innych przypadkach dopiero po fakcie.
Wyzwanie: Proces wyboru testów do napisania i zakodowania może być żmudny, co może być odczuwane jako dużo dodatkowej pracy poza samym tworzeniem aplikacji.
Cytat:
"Pisanie testów - poza tym, że jest trudne, to wcale nie sprawia przyjemności" Anonimowy użytkownik
Zdjęcie: flickr/Lachlan Hardy
9. Projektowanie rozwiązania
Zadanie: Zaprojektowanie i stworzenie rozwiązania technologicznego zgodnie z wymogami klienta tak, aby zostało wdrożone. Może to obejmować projektowanie danych i struktury kodu, algorytmów funkcjonalnych i aplikacji odzwierciedlających logikę biznesową w sposób satysfakcjonujący dla użytownika.
Wyzwanie: Upewnienie się, że projektowane rozwiązanie jest zgodne z oczekiwaniami klienta, jest dla niego zrozumiałe i może zostać stworzone w podanym terminie.
Cytaty:
"Myślenie o tym, jak zacząć w punkcie A, a skończyć w punkcie B, jest najtrudniejszą częścią zadania" misconfiguration
"Jeśli Twój projekt jest zbyt skomplikowany, prędzej czy później upadnie pod własnym ciężarem. Jeśli jest słaby, jest bezużyteczny" nvteighen
"Trudno przewidzieć, jak będzie działało rozwiązanie, dopóki tak naprawdę nie zaczniemy z nim pracować..." jpkotta
Zdjęcie: flickr/spare parts
Computerworld dostarcza najświeższe informacje, opinie, prognozy i analizy z branży IT w Polsce i na świecie.
W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]