Sieć pełna jest porad dotyczących dobrych praktyk tworzenia oprogramowania. Możemy czytać o SOLID, DRY, KISS, Demeter, GRASP. Pytanie czy to jednak wszystko? Czy wyczerpujemy tym samym listę praktyk, które są warte uwagi. Z naszego punktu widzenia – ZDECYDOWANIE NIE! Jest jeszcze wiele elementów, które warto wykorzystywać podczas procesu wytwarzania oprogramowania. Dlatego, w 10-tym odcinku podcastu Dev:Cast zdecydowaliśmy się zebrać 10 zasad (nie bez przyczyny 😃), które według nas są kluczowe aby fachowo wykonywać swoją programistyczną robotę – bez względu na wykorzystywany paradygmat, język czy ograniczenia biznesowe.

💣 Nasz TOP 10 dobrych praktyk tworzenia oprogramowania 💣

1. Single Responsibility Principle
2. Nazewnictwo oddające intencję
3. Zasada małych kroków
4. Wybór odpowiednich narzędzi do rozwiązywanego problemu
5. Nie komplikuj – sięgaj po najprostsze rozwiązanie
6. Rozwiązuj, a nie generuj problemy
7. Znajdź równowagę pomiędzy wymaganiami, ograniczeniami, a implementacją
8. Analizuj => Planuj => Działaj
9. Jedyną stałą, jest zmiana
10. Dostarczaj działający kod

Krążąc przy „zasadzie małych kroków” wspomnieliśmy o S.M.A.R.T., a rozmawiając o „nie komplikuj – sięgaj po najprostsze rozwiązanie” przewinął się wątek prześmiewczego rozwiązania zadania FizzBuzz.

Na koniec czekała na nas mała niespodzianka… Podsumowując temat wyszło nam, że „matką” wszystkich zasad, która przynosi niesamowite korzyści, a jest często pomijana… Jest TECHNIKA TDD 👌 Więcej o niej możecie poczytać na stronie Dariusza Woźniaka, gdzie znajdziecie najfajniejszy, darmowy kurs TDD 💪

Czy dobre praktyki tworzenia oprogramowania zostały przez nas wyczerpane? Co dodałbyś od siebie? Co jest ważne w codziennej pracy programisty?

O Coding Dojo pisałem całkiem niedawno, w odniesieniu do działającej na śląsku inicjatywie. Tym razem jednak udało mi się porozmawiać z organizatorami Coding Dojo Silesia na temat Coding Dojo oraz samej inicjatywy. Tak aby dowiedzieć się więcej o wymaganiach, tego co można się nauczyć, grupie docelowej oraz formie spotkania.

Marek oraz Michał organizują 28 czerwca kolejną edycję swojego wydarzenia, będzie dotyczyć ona języka PHP, gdzie my, autorzy DevEnv wystąpimy w roli wsparcia mentorskiego 😉 Spotkanie startuje o 18:00 i odbywa się w katowickiej siedzibie firmy Clear Code. Jak sami organizatorzy zapewniaj nie zabraknie pracy w parach, rozkminy nad kodem, networkingu z innymi programistami oraz czegoś dobrego na ząb i soku z gumijagód 🍻

Wszelkie dodatkowe informacje uzyskacie na podstronie wydarzenia: "Coding Dojo Silesia #3 – PHP edition", a tym czasem zapraszam was do odsłuchu dziewiątego odcinka podcastu Dev:Cast!

Podział odpowiedzialności w zespołach często bywa bardzo jasno określony. Zdarzają się jednak sytuacje kiedy wymagania względem wykonywanej pracy nie mają za dużo wspólnego z faktyczną rolą projektową. Zdarzało mi się zastępować Team Leader, działać w roli Lead Quality Assurance – na tyle na ile pozwalała mi wiedza i umiejętności. Takie kołczingowe wychodzenie poza strefę swojego komfortu ;) Jednak nie jest to zadanie łatwe, obawy przed przejęciem odpowiedzialności bywają nieco paraliżujące – nie ma co się dziwić, chcemy pokazywać się tylko z dobrej strony, zapewniając, że jesteśmy profesjonalistami. Jednak bycie profesjonalistą oznacza czasem przekroczenie granicy, która definiuje nas właśnie w tym pojęciu.

W ósmym odcinku rozmawiamy o tym dlaczego programiści, pracujący w interdyscyplinarnych (dodałbym pseudo) zespołach boją podejmować się zadań związanych z testowaniem dostarczonych funkcjonalności.

Co robicie gdy w iteracji zaczyna brakować zadań dla programistów, a testerzy nie wyrabiają? Dodajesz kolejne zadania do todo czy jednak rozmawiasz z zespołem programistycznym, aby przetestował zadania czekające na fazę testów? Daj znać w komentarzu!

Jingle Music by: www.bensound.com

Kontynuując wątek Legacy Code chcemy przedstawić wam sposoby na jego ujarzmienie. Praca z Legacy Code może stawiać nie lada wyzwania ale także być przyjemna. Nie zawsze także rozchodzi się o całościowe przepisywanie projektu – szanujemy swój czas oraz pieniądze naszego klienta. Czasem wystarczają proste zmiany w obrębie wybranych komponentów aby usprawnić sobie co dzienną pracę z systemem.

W siódmym odcinku definiujemy sobie sposoby wdrażania usprawnień – większy oraz mniejszych w Legacy Code, wdrażając je „przy okazji” lub „planując z góry”. Wspominamy także o bardzo ważnym aspekcie, który często jest pomijany, a przynosi niesamowite efekty podczas badania odziedziczonego kodu tzw. spike.

Jak wy pracujecie z odziedziczonym kodem? Jakie stosujecie praktyki? Jak radzicie sobie z planowaniem zmian? Jeśli masz coś dodania, to serdecznie Cię zapraszamy do zostawienia komentarza pod odcinkiem 😉

Jingle Music by: www.bensound.com

Gdy słyszysz Legacy Code dostajesz gęsiej skórki? Nic dziwnego. Jest wiele negatywnych elementów, które w odziedziczonym kodzie utrudniają dalszy rozwój oprogramowania. To chociażby spagetti code, duplicated code, czy nie deterministyczne testy jednostkowe.

W szóstym odcinku podcastu rozmawiamy o tym czym jest tytułowy Legacy Code oraz co nas w nim denerwuje – jakie elementy sprawiają, że po dniu pracy mamy dość, a Bartek najchętniej siałby kukurydze na swoim polu ;)

Chcemy kontynuować w kolejnych epizodach Dev:Cast tematykę utrzymywania oraz rozwoju odziedziczonego kodu, tak aby praca z nim stawała się łatwiejsza, a zarazem dostarczała nam frajdy i satysfakcji.

Jakie elementy o których nie wspomnieliśmy wkurzając Cię najbardziej w utrzymywaniu Legacy Code? Podziel się z nami swoimi spostrzeżeniami w komentarzu :)

Jingle Music by: www.bensound.com

Początkujący programiści często zadają pytanie jaki powinien być lub jaki wybrać pierwszy język programowania? W gąszczu dostępnych form komunikacji ze światem binarnym ciężko na początku się odnaleźć. Nie wiadomo jaki punkt zaczepienia chwycić, czym się sugerować. Bywa i tak, że ten pierwszy język programowania jest wynikiem wielu losowych czynników – studia, post na forum, znajomy programista.

W piątym odcinku Dev:Cast rozmawiamy o wyborze pierwszego języka – jak się zabrać za wybór, czym się kierować. Dyskusja była na tyle obfita w ciekawe stwierdzenia, że przekroczyliśmy nasz umowny limit 20 minut. Mamy nadzieję, że nieco dłuższa forma nie będzie wam tym razem przeszkadzała.

Jak myślicie na który z języków padł nasz typ? Co polecamy?

Który według was język programowania warto wybrać na początek? Od czego Wy zaczynaliście? Jak ma się on teraz do waszej pracy? Zachęcamy do dyskusji w komentarzach.

Jingle Music by: www.bensound.com

Czy automatyzując analizę kodu do maksimum, ciągle potrzebujemy przeprowadzać Code Review? Czy czynnik ludzki będzie jeszcze wtedy potrzebny? Czy nie jest to moment kiedy fundamenty przeglądu kodu nie mają racji bytu?

W czwartym odcinku Dev:Cast rozmawiamy o sensowności procesu Code Review. Szukamy elementów, które ciężko będzie zastąpić nawet najbardziej wyrafinowanymi automatami. Zastanawiamy się i rozmawiamy o wymianie wiedzy poprzez Code Review.

Pada również stwierdzenie, że junior developer powinien czytać kod tworzony przez bardziej doświadczonego programistę. Zgadzacie się z tym?

Jakie jest wasze nt. przeglądów kodu? Stosujecie ten proces w praktyce? Jak wygląda on u was? Jak się u was sprawdza?

Jingle Music by: www.bensound.com

Praca zdalna, nawet ta sporadyczna wymaga odpowiedniego przygotowania. Wszystko z pozoru wygląda na prostą sprawę, jednak nagle okazuje się, że pomimo 12 godzin przed komputerem nie ma namacalnego efektu. Tu coś nas rozproszyło. Następnie oderwaliśmy się od komputera dosłownie na minutę, a finalnie wpadliśmy w wir obowiązków domowych – sprzątając, porządkując czy wyjeżdżając na szybkie, 2 godzinne zakupy :)

Aby nasza praca zdalna była efektywna, należy przygotować się na poziomie:

- technicznym – który może obejmować konfigurację VPN, środowiska developerskiego, konfiguracji mikrofonu oraz słuchawek;
- mentalnym – abyśmy faktycznie pracowali np. poprzez ustalenie konkretnego timeboxu;
- przestrzennym – by móc usiąść w miejscu, gdzie jest nam wygodnie i bez przeszkód możemy wykonywać swoją pracę.

Podczas rozmowy, poruszamy tematy związane z tym jak się przygotować do pracy zdalnej oraz na co zwracać szczególną uwagę. Tak aby nasza praca była bardziej efektywna i przede wszystkim, nie zaczynała się o godzinie 8:00 i trwała do późnej nocy – oczywiście mam na myśli, 8 godzinny dzień roboczy :)

Lubisz popracować zdalnie, ale coś ciągle odwraca Twoją uwagę? Domownicy nie dają Ci spokoju? Zapraszamy do trzeciego odcinka podcastu Dev:Cast, może zaproponowane rozwiązania będą Ci pomocne.

Jingle Music by: www.bensound.com

Nadeszła pora aby przedstawić drugi odcinek podcastu Dev:Cast. Tym razem dyskutujemy o temacie Tomasza, który brzmiał: "dlaczego developerzy boją się odbijania notek". Rozmawialiśmy o tym czemu boimy się popełniać błędy i co jest przyczyną strachu. Staraliśmy się szukać rozwiązania w oparciu o budowanie przyjaznego środowiska, które pozwala na popełnianie błędów. Błędów które powinny służyć nauce. Podczas rozmowy bardzo szybko okazało się, że każdy z nas ma doświadczenia z sytuacjami, gdzie popełniony błąd traktowany był w negatywny sposób. Nawet ten trywialny.

Jeżeli w Twoim otoczeniu panuje przekonanie, że za błędy należy karać – ten podcast jest dla Ciebie. Może to jest powodem przeciągających się terminów realizacji zadań?

Witajcie w pilotażowym odcinku podcastu Dev:Cast. Pierwszym poruszanym tematem jest długi, rozciągający się w czasie Daily Scrum. Czasem pojawiają się tematy, które powinny zostać jedynie zasygnalizowane i kontynuowane już po tzw. standupie. Niestety stają się niezłą odskocznią od głównego wątku rozmowy, zajmując czas, a nie raz wyzwalając zażartą dyskusję. Rozważamy jak można zapobiec takiemu problemowi bez osoby sprawującej supervisora. Jeśli pracujesz w scrumie i czujesz, że Twoje daily stało się za długie oraz „wymemłane” – to idealne trafiłeś. Niech pierwszy odcinek Dev:Cast pomoże Ci w rozwiązaniu tego problemu.