Wracamy z Waszą ulubioną serią artykułów. Tak jak w każdej z poprzednich edycji, poszukaliśmy pytań zadanych przez juniorów na różnych grupach na Facebooku i poprosiliśmy seniorów, by na nie odpowiedzieli. Zobaczcie, czego możecie nauczyć się z ich wypowiedzi.

Pytanie #1

Norbert Orzechowicz. Kojarzycie czy jest może jakiś tool online do testowania kodu php, ale z zależnościami z packagista?

 

Odpowiada Damian Dziaduch, lider zespołu oraz specjalista od wydajności w GForces Polska:

 

Nie jestem pewny czy dobrze rozumiem pytanie, ale jeśli chodzi o platformę, która zaciągnie cały twój kod wraz z zależnościami, zbuduje cały stack to świetnie w tym się sprawdzi każdy CI (continuous integration). W obecnej firmie używamy Scrutinizer. Ostatnio postawiłem tam całe środowisko oparte na Dockerze. Odpalają się tam nasze testy w Codeception, kod jest oceniany przez metryki, które sobie wybieramy. Dla każdego commita jest uruchamiana inspekcja, która jest oceniana i może zostać automatycznie zaakceptowana lub też odrzucona na podstawie wybranych kryteriów, jak np. pokrycie testów, ocena klas / metod itp. Po akceptacji Scrutinizer może automatycznie zrobić deploy na produkcję. Jest sporo alternatyw, np. Travis CI, Jenkins, Circle CI, BitBucket ma też coś swojego od niedawna. Polecam poczytać, porównać i wybrać co najbardziej Ci pasuje.

Pytanie #2

Marlena Grabowska. W jakim środowisku najlepiej pisać testy automatyczne? (NIE jednostkowe, tylko np. funkcjonalne)? Co do aplikacji webowych, a co do desktopowych?

 

Odpowiada Mateusz Pacholec, Senior Software Developer w Objectivity:

 

Od początku współtworzę aplikacje głównie webowe, w związku z czym wypowiem się tylko o nich. Niemal w każdym projekcie do testów automatycznych wykorzystywaliśmy Selenium. Jest to narzędzie łatwe w użytkowaniu i można sobie fajnie stworzyć swoją otoczkę i z niej korzystać. Co więcej, Selenium można użyć nie tylko do testowania, ale po prostu do szeroko rozumianej automatyzacji. Trzeba jednak pamiętać, że jest on czasami kapryśny i potrafi się zaciąć i trzeba uruchomić test ponownie.

 

Odpowiada Damian Dziaduch, lider zespołu oraz specjalista od wydajności w GForces Polska:

 

Do testowania akceptacyjnie aplikacji webowych polecam Behat. U nas to bardzo fajnie działa. Nasze QA / PM tworzy pliki feature w języku Gherkin. Jest to język czytelny dla każdego. Następnie te pliki trafiają do nas, by je oprogramować używając Behat i Mink, które umożliwiają sterowanie przeglądarką przez kod. Bardzo łatwo zautomatyzować klikanie ręczne, a przy okazji pisząc specyfikację w czytelnym języku jakim jest Gherkin. Polecam spróbować!

Pytanie #3

Tymek Petyniak. W jakim języku najłatwiej byłoby napisać program tworzący podaną liczbę kont e-mail na Gmail i odpowiadających im kont na Facebooku? Chciałbym, by wybierał losowo z “bazy” w np. Excelu Imię, Nazwisko i inne dane.

 

Odpowiada Mateusz Pacholec, Senior Software Developer w Objectivity:

 

Tak naprawdę najłatwiej będzie w języku, w którym czujesz się najlepiej. W każdym języku odnajdziesz odpowiednie narzędzia do zrealizowania żądania do API producenta. W tym podejściu musisz założyć odpowiednie konta u producentów (Google / Facebook), aby uzyskać dostęp do ich API, a następnie odnajdujesz w dokumentacji sposób w jaki utworzyć takie konto. Następnie wystarczy skonstruować odpowiednie żądanie i wysłać je na adres API. Koniec końców najczęściej sprowadza się to do utworzenia obiektu, serializacja i wysłanie.

 

Odpowiada Iwona Jóźwiak, PHP Developer, magento developer w Divante.pl:

 

Język nie ma znaczenia, ale znaczenie już mają biblioteki/narzędzia, z których skorzystamy. Dość ciekawym rozwiązaniem jest Google Fusion Tables, dzięki któremu można tworzyć rozbudowane tabele. Dzięki api z kolei szybko otrzymamy dostęp do rekordów, które posłużą do tworzenia kont za pomocą GMAIL API. Wszystko tak naprawdę zależy jednak od konkretnej sytuacji i potrzeb.

Jeśli miałabym postawić na któryś z języków, to wybrałabym taki, który znam, ale i dla którego dostarczana jest odpowiednia biblioteka. Nie ma bowiem sensu wynajdywać koła na nowo.

Pytanie #4

Grzegorz Foota. Czy to prawda, że najlepiej zająć się testowaniem przed programowaniem np. na froncie?

 

Odpowiada Michał Załęcki, Senior Software Engineer w Tooploox; Trainer w BlockchainPro.pl:

 

Nie. Zaryzykuję tutaj stwierdzenie, że to osoby, które testują oprogramowanie będą lepiej wypełniać swoje obowiązki już wiedząc jak programować: testy automatyczne, integracja skryptów wykorzystujących popularne wektory ataków itd. Jeżeli jesteś zainteresowany karierą programisty, programuj. Jeżeli interesuje cię frontend to wejdź na freecodecamp.org i sprawdź czy programowanie to coś dla ciebie, czemu będziesz w stanie poświęcić wiele godzin, bo nie ma drogi na skróty, by wyróżnić się na tle innych kandydatów. W mojej ocenie, poprzednie doświadczenie w roli testera może być plusem, ale raczej ze względu na znajomość zwinnych procesów, narzędzi, z którymi pracują zespoły niż wiedzę techniczną.

 

Odpowiada Iwona Jóźwiak, PHP Developer, magento developer w Divante.pl:

 

Niezależnie od tego, w jakim języku programowania pracujemy, podstawowe umiejętności testera są wymagane. Kilkunastoletnie doświadczenie pokazuje mi, że na ogół jednak myślimy dość schematycznie, przez co wiele wariantów nam umyka. Kończy się to później zwrotką, że jakiś mechanizm nie działa. Zarówno technologie frontendowe, jak i backendowe pozwalają na wykonywanie testów jednostkowych i rozbija się to już o nasz świat. Dzięki takim testom uszczelniamy nasz kod, co sprowadza się do mniejszej liczby niepożądanych sytuacji. Kiedyś w Divante przeprowadzono szkolenie UX dla programistów. Była to bardzo ciekawa inicjatywa polegająca na uzmysłowieniu osobom technicznym, że świat jest „kolorowy” i ma naprawdę wiele odcieni. Oznacza to, że potencjalny użytkownik może wykonać zaplanowany przez siebie schemat po swojemu. Od tamtego czasu chętnie przeglądam materiały związane z psychologią testów czy użytecznością interfejsów. Pozwala mi to szerzej testować moją pracę, a i dzięki temu mam mniej zwrotek od testera i klientów. Nie oznacza to jednak wydaje mi się, że możemy w pełni funkcjonować bez testerów.

Pytanie #5

Szymon Wiśniewski: Pracuję jako junior fullstack developer. Na co dzień mam do czynienia między innymi z: C#, Angular 5, SQL, Non-SQL, Azure (service bus, logic apps, function apps, monitorig), PowerShell, Auth0, TeamCity, Octopus. Dodatkowo aplikacja jest rozbudowana i rozproszona. Jako samouk mam często problem z ‚ogarnięciem’ tego wszystkiego jednocześnie ciągle skakanie po technologiach powoduje, że nie czuję jakbym robił progres. Zastanawiam się czy jest to ścieżka, przez którą każdy musi przejść, czy jest coś co mogę zrobić, żeby szybciej przeskoczyć do ‘ogarniania’. Książki i kursy, które do tej pory przerabiałem raczej prezentowały przepaść między teorią, a praktyką. Próba uczenia się wszystkich tych technologii na raz, też chyba z góry skazana jest na porażkę.

 

Odpowiada Robert Witkowski, Senior Software Engineer w Altkom Software & Consulting:

 

Jeśli przychodzisz do firmy jako samouk bez doświadczenia komercyjnego to Twój pracodawca powinien zapewnić Ci bardzo duże wsparcie na początku pracy. Rzucanie na głęboką wodę “od tak” kończy się właśnie takimi problemami. Przez okres wdrażania do projektu (a przy rozbudowanym projekcie może to trwać kilka miesięcy) powinieneś mieć swojego mentora, którego będziesz mógł zapytać i pomęczyć w cięższych chwilach. Takie tematy jak monitoring, wdrażanie na Azure, narzędzia CI/CD nie powinny Cię na początku w ogóle interesować, ponieważ tym powinny zajmować się osoby bardziej doświadczone.

Masz rację, że na początku drogi ciężko jest to wszystko ogarnąć jednocześnie. Oprócz poznawania konkretnych technologii dochodzi również nauka tematów bardziej ogólnych takich jak wzorce projektowe, architektura aplikacji, środowiska CI/CD. Uwierz mi, że nie tylko Juniorzy mają z tym problem. Dla doświadczonego programisty przeskok z monolitycznej aplikacji (która wykorzystywała jedną bazę danych, wdrażana była poprzez kopiowanie paczek na serwer klienta, a JavaScriptu było tam jak na lekarstwo) na projekt taki jak opisałeś, to również bardzo duże wyzwanie.

Kursy i książki bardzo pomagają w zrozumieniu podstaw i koncepcji. Jednak to “praktyka czyni mistrza”. Jeśli sam prywatnie przerabiałeś kursy to nie powinno zabraknąć Ci chęci i ambicji, żeby spróbować napisać taką aplikację samemu jako pet project. Poprzez sformułowanie “taką aplikację” mam na myśli aplikację, która wykorzystuje technologie opisane przez Ciebie, ale pozbawiona jest skomplikowanej logiki biznesowej. Spróbuj kolejno poznawać komponenty i dodawać je do swojego projektu. Zacznij od backendu w C# z relacyjną bazą danych, dodaj kilka formatek w Angularze, dodaj bazę NoSQL, spróbuj wdrożyć aplikację na Azure’a i kolejno dodawaj technologie używane w projekcie.

Jako “doraźne rozwiązanie problemu” proponuje powiedzenie wprost swojego Team Leader’owi, że najpierw chciałbyś skupić się bardziej na zadaniach związanych z backendem/frontendem, a tematy takie jak monitoring, deployment itp zostawić na później.

Nie poddawaj się, bo masz naprawdę duże szczęście, że na początku swojej drogi trafiłeś do projektu, w którym używana jest cała gama nowoczesnych technologii i koncepcji. Jeśli nie zabraknie Ci ambicji i samozaparcia to w krótkim czasie możesz naprawdę mocno się rozwinąć.


Cykl „Od Juniora do Seniora” (poprzednie części znajdziecie tutaj: 1234, 5, 6, 7, 8) tworzymy razem z Wami, dlatego czekamy na kolejne pytania, które możemy zadać seniorom. Zamieście je w komentarzach albo wyślijcie na adres piotr@justjoin.it, a najciekawsze trafią do szóstej części cyklu.

Zapraszamy do dyskusji
Nie ma więcej wpisów

Send this to a friend