Tygodniowe wyzwanie programistyczne — #2

Kon­tynu­u­je­my wyzwanie! Wraz z początku­ją­cy­mi będziemy zas­tanaw­iali się jak zdefin­iować pewne określe­nia, a prak­ty­cy będą musieli odbyć nieco sen­ty­men­tal­ną wycieczkę. Gotowa?

Wyzwanie dla początkujących

Przed przys­tąpi­e­niem do zada­nia, zas­tanów się nad rezul­tatem Two­jej wczo­ra­jszej pra­cy: Czego dowiedzi­ałeś się o swoich umiejęt­noś­ci­ach? Czego się nauczyłeś? Co zro­bisz z tą wiedzą?

Zapewne pamię­tasz, jak na początku swo­jej nau­ki spo­tykałaś wiele pojęć, których znaczenia nie znałaś. Szukanie ich w Google też niewiele poma­gało — definic­je były napisane zbyt zaw­iłym językiem i nie były proste w zrozu­mie­niu. Wraz z tym, jak naby­wasz coraz więcej wiedzy, coraz łatwiej jest Ci rozszyfrowywać tak zapisane definic­je i samodziel­nie uczyć się dalej na pod­staw­ie mate­ri­ałów w sieci.

Niesie to jed­nak za sobą ryzyko — chcąc przekazać innym swo­ją wiedzę, sama najpraw­dopodob­niej uży­wasz coraz więcej spec­jal­isty­cznych słówek i żargonu.

Prawdzi­wym sprawdzianem czy opanowałaś dane zagad­nie­nie jest prosty test — czy umiesz wytłu­maczyć daną rzecz swoi­mi słowa­mi, w prosty sposób tak, aby nawet laik zrozu­mi­ał o co chodzi. To jest Twoim dzisiejszym zadaniem — stworze­nie definicji do poniższych zagad­nień tak, jak­by o wyjaśnie­nie ich zapy­tało Cię młod­sze rodzeństwo/dziecko. Możesz wybrać np. 4 określe­nia z poniższej listy lub sama wymyślić własne przykłady:

• aplikac­ja / program
• kod źródłowy
• meto­da / funkcja
• pęt­la
• instrukc­ja warunkowa
• kon­so­la
• test
• tabli­ca

Po stworze­niu definicji zas­tanów się, jaka jest jej najtrud­niejsza część (np. najtrud­niejsze użyte słowo lub odwołanie do jakiejś innej wiedzy) i spróbuj je wye­lim­i­nować. Pow­tarzaj aż do momen­tu, kiedy zabraknie ele­men­tów do wyeliminowania.

Jeśli masz w domu ‘obiekt testowy’ to ide­al­nie — możesz od razu sprawdz­ić, czy fak­ty­cznie dziecko zrozu­mie :) Tak czy inaczej nie zapom­nij podzielić się swoi­mi definic­ja­mi w komen­tarzu do even­tu na FB!

Nasza odpowiedź

Do tłu­maczenia wybral­iśmy trzy określe­nia z podanej przez nas listy i jed­no spoza niej (kom­pi­lac­ja). Nasze definic­je zna­jdziesz poniżej:

aplikac­ja / pro­gram — to taka instrukc­ja dla kom­put­era co ma robić po kolei; mogą w niej być zada­nia, żeby coś policzył, zapy­tał się człowieka o coś lub powiedzi­ał mu wynik. Kom­put­er może też rysować na ekranie różne rzeczy, jeśli instrukc­ja opisu­je jak to dokład­nie zrobić

kom­pi­lac­ja — jest to pro­ces tłu­maczenia z języ­ka ludzi (kod źródłowy) na język kom­put­erów potrzeb­ny, żeby kom­put­er rozu­mi­ał polece­nia wydawane przez człowieka. Po kom­pi­lacji pow­sta­je aplikac­ja / program.

kod źródłowy — instrukc­ja dla kom­put­era co dokład­nie ma robić krok po kroku, ale zapisana w sposób zrozu­mi­ały dla ludzi. Moż­na ją ‚zamienić’ na zapis zrozu­mi­ały dla kom­put­era (pro­gram) po uru­chomie­niu kompilacji

tabli­ca — tabli­ca to taka szu­flad­ka na różne infor­ma­c­je, które prze­chowu­je kom­put­er — podob­nie jak szu­fla­da, ma określony rozmi­ar (pojem­ność) i prze­gród­ki — mieszczą się do niej tylko ściśle określone infor­ma­c­je (a innych nie może­my tam umieścić)

W naszych definic­jach najwięk­szy prob­lem mieliśmy z tym, że ciężko nam było wytłu­maczyć jed­ną bez wyjaśnienia drugiej. Mimo wszys­tko udało nam się chy­ba opisać te kil­ka ter­minów w prosty sposób :)

Wyzwanie dla praktyków

Przed przys­tąpi­e­niem do zada­nia, zas­tanów się nad rezul­tatem wczo­ra­jszej pra­cy: Czego dowiedzi­ałeś się o swoich umiejęt­noś­ci­ach? Czego się nauczyłeś? Co zro­bisz z tą wiedzą?

Refak­to­ryza­c­ja kodu to jed­na z tych czyn­noś­ci, które wszyscy twierdzą że warto i należy to robić, ale w prak­tyce częs­to nie ma na to cza­su w pro­jek­cie. Jako że przez cały czas się uczysz, poz­na­jesz nowe rozwiąza­nia, sposo­by pode­jś­cia do pewnych zagad­nień i zauważasz dodatkowe zagroże­nia lub prob­le­my, kod który napisałeś kiedyś, dziś zapewne napisałabyś lep­iej i w bardziej prze­myślany sposób.

Podob­nie jak i my na pewno nie raz musi­ałaś napisać coś ‘na szy­bko’, obiecu­jąc sobie że jak tylko skończy się ten sprint to wró­cisz i popraw­isz ten frag­ment. Pewnie podob­nie jak nam, nie zawsze uda­je Ci się do niego w końcu wró­cić ;) Dzisiejsze zadanie pole­ga na tym, żeby odnaleźć jak­iś frag­ment kodu, który napisałaś w przeszłoś­ci (założe­nie: powinien być starszy niż 6 miesię­cy), a następ­nie zro­bić refak­to­ryza­cję i — w ide­al­nym przy­pad­ku — usunąć jak­iś związany z tym dług techniczny.

Jeśli masz prob­lem, żeby ziden­ty­fikować co moż­na popraw­ić, pomoc­ne mogą okazać się kat­a­lo­gi np. na stron­ie refactoring.com (gdzie zna­jdziesz konkrente przykłady i sytu­acje oraz ich anal­izę) lub refactoring.guru (gdzie z kolei są opisane ‘zapachy’ — syg­nały, które mogą wskazy­wać na potrze­bę refak­to­ryza­cji). Możesz też sko­rzys­tać z narzędzi do anal­izy kodu jak np. opisy­wany przez nas Sonar­Qube.

Dodatkowo, zas­tanów się, jaki wpływ na dzi­ałanie aplikacji miało­by niepopraw­ie­nie tego frag­men­tu oraz jakie korzyś­ci to przyniosło? Czy zmieniło to jej wyda­jność? Czy łatwiej jest ter­az rozsz­erzyć funkcjon­al­ność aplikacji? Czy poz­woliło to zak­tu­al­i­zować lub pozbyć się starej biblioteki?

Takie cofnię­cie się do kodu, który pisal­iśmy jak­iś czas temu to także świet­ny sposób na zobra­zowanie sobie, czego się nauczyłaś przez ten czas!

Jeśli to nie jest kod fir­mowy, pamię­taj, żeby podzielić się z nami swoim kodem ‘przed’ i ‘po’ w komen­tarzu na FB!

Nasza odpowiedź

Jako pro­jekt do refak­to­ryza­cji Ania wybrała swo­ją pier­wszą aplikację — learn­ing webapp. Z uwa­gi na to, że czas był ogranic­zony, wykon­ała tylko częś­ciowy refak­tor­ing — jego wynik zna­jdziesz na githu­bie: https://github.com/apietras/competence-today/commit/45c9171a0e1ce68234c0df195b418751d9b67642

To, co zmieniła to przede wszystkim:

• zrezyg­nowała z kon­fig­u­racji XML wszędzie, poza Secu­ri­ty (na przepisanie tej częś­ci nie star­czyło mi już czasu)
• dołączyła Spring Boot, żeby móc pozbyć się (praw­ie) wszys­t­kich wer­sji z pom.xml’a i zak­tu­al­i­zować moje zależności
• usunęła plik web.xml zastępu­jąc go klasą w Javie
• popraw­iła adno­tac­je tam, gdzie było to sen­sowne (np. @Transactional zmieniłam na Springowe)
• zamieniła joda-time na API do cza­su z Javy 8,

Oczy­wiś­cie pełniejszy refak­tor­ing powinien objąć nieco więcej, kil­ka pomysłów co moż­na by jeszcze poprawić:

• zmienić bib­liotekę mapu­jącą na nowszą (np. Orika)
• dodać Lombok’a aby nie gen­erować samodziel­nie get­terów i setterów
• prze­nieść kon­fig­u­rację Spring Secu­ri­ty do JavaConfig
• zak­tu­al­i­zować wido­ki i uży­wane bib­liote­ki JS

Było to dość ciekawe doświad­cze­nie — to zaskaku­jące jak sporo długu tech­nicznego aplikac­ja nabrała w ciągu 2 lat. Biorąc pod uwagę, że jest to sto­sunkowo prosty sys­tem, aż stra­ch pomyśleć, co czai się w niek­tórych więk­szych sys­temach, do których nikt nie zaglą­dał od lat ;)

Uwa­ga: ten refak­tor­ing jest przykła­dem, w którym nie popraw­ial­iśmy jakichś konkret­nych prob­lemów, a jedynie ‘unowocześnil­iśmy’ aplikację — tego rodza­ju popraw­ki także są ważne, ponieważ ułatwia­ją korzys­tanie z nowych opcji ofer­owanych przez bib­liote­ki w przyszłoś­ci i znacznie ułatwia­ją pracę z aplikacją w dłuższym terminie.

Pamię­taj, że nowe zada­nia będą się pojaw­iać codzi­en­nie o godzinie 11. Rozwiąza­nia będziemy umieszczać pod zada­ni­a­mi kole­jnego dnia o godzinie 18. Nie zapom­nij podzielić się swoi­mi odpowiedzi­a­mi i prze­myśle­ni­a­mi na wydarze­niu na face­booku, a jak masz ochotę to też w komentarzu ;)!

Lin­ki do wszys­t­kich zadań zna­jdziesz w innym wpisie na naszym blogu. Powodzenia!