Dlaczego zwinno\u015b\u0107? Scrum i inne metodyki zwinne<\/a><\/span><\/div>\nObie te skrajno\u015bci nie wr\u00f3\u017c\u0105 nic dobrego! Pierwsza powoduje, \u017ce projekt przeci\u0105ga si\u0119 ponad miar\u0119. To powoduje wymierne biznesowe straty. Cz\u0119sto projekt lepiej jest wypu\u015bci\u0107 niedopracowany ni\u017c mocno op\u00f3\u017aniony. Znamy to cho\u0107by z gier komputerowych, kt\u00f3re wymagaj\u0105 \u0142atania ju\u017c po premierze. Druga skrajno\u015b\u0107 sprawia, \u017ce program dzia\u0142aj\u0105cy z pocz\u0105tku sprawnie, z czasem zaczyna wymaga\u0107 nieproporcjonalnie du\u017co.<\/p>\n
Jakie s\u0105 nast\u0119pstwa decyzji programist\u00f3w?<\/h2>\n
Pochopne decyzje techniczne podj\u0119te na pocz\u0105tku mog\u0105 mie\u0107 trudne do przewidzenia konsekwencje. Odpowiedzialny programista zawsze powinien mie\u0107 \u015bwiadomo\u015b\u0107, jak cz\u0119sto podejmuje r\u00f3\u017cne wybory oraz jakie s\u0105 ich nast\u0119pstwa. Poni\u017cej kilka przyk\u0142ad\u00f3w:<\/p>\n
J\u0119zyk programowania<\/h3>\n
Cho\u0107 nie ma tu regu\u0142y, do szybkiego prototypowania lub tworzenia niedu\u017cych aplikacji nadaj\u0105 si\u0119 j\u0119zyki skryptowe, np. Python, JavaScript lub te\u017c Ruby. Da si\u0119 w nich r\u00f3wnie\u017c tworzy\u0107 wydajne, du\u017ce aplikacje. Nie bez powodu jednak do\u015b\u0107 powszechnie uznaje si\u0119, \u017ce programy pisane w C i C++ mog\u0105 zosta\u0107 bardziej zoptymalizowane. Oznacza to po prostu mo\u017cliwo\u015b\u0107 lepszego wykorzystania tych samych zasob\u00f3w.<\/p>\n
Czysty kod<\/h3>\n
Jedno z pierwszych mniej przyjemnych do\u015bwiadcze\u0144 pocz\u0105tkuj\u0105cego developera brzmi: \u201cnie pami\u0119tam, o co chodzi w moim w\u0142asnym kodzie\u201d. Kiedy po jakim\u015b czasie trzeba cokolwiek zmieni\u0107 lub ulepszy\u0107, cz\u0119sto okazuje si\u0119 to zaskakuj\u0105co trudne. Techniki zwane \u0142\u0105cznie \u201cclean code\u201d, popularyzowane m.in. przez Roberta C. Martina, u\u0142atwiaj\u0105 tworzenie \u0142atwo utrzymywalnych program\u00f3w. To oznacza, \u017ce wprowadzanie poprawek nie wywo\u0142uje frustracji i nie wi\u0105\u017ce si\u0119 z mozolnym przerabianiem.<\/p>\n
Wielow\u0105tkowo\u015b\u0107<\/h3>\n
W wi\u0119kszych aplikacjach naturalne jest skorzystanie z dost\u0119pno\u015bci kilku rdzeni CPU. Niestety nie ka\u017cde zagadnienie da si\u0119 roz\u0142o\u017cy\u0107 na kilka niezale\u017cnych, r\u00f3wnolegle wykonywanych zada\u0144. Co wi\u0119cej, w\u0105tki cz\u0119sto potrzebuj\u0105 si\u0119 ze sob\u0105 komunikowa\u0107 \u2013 to r\u00f3wnie\u017c wp\u0142ywa na wydajno\u015b\u0107. Dlatego zdarza si\u0119, \u017ce wbrew pozorom szybciej jest przeprowadza\u0107 obliczenia na jednym w\u0105tku. Po prostu nie nale\u017cy przes\u0105dza\u0107 o tym z g\u00f3ry.<\/p>\n
W\u0142a\u015bciwa optymalizacja.<\/h3>\n
Technik na przyspieszenie programu jest mn\u00f3stwo. Zasadnicze pytanie brzmi: jak si\u0119 za to zabra\u0107? Ot\u00f3\u017c warto zacz\u0105\u0107 od wyznaczenia w\u0105skich garde\u0142 (ang. bottlenecks). To cz\u0119\u015bci programu (zazwyczaj niewielkie), kt\u00f3rych wykonanie trwa najd\u0142u\u017cej lub kt\u00f3re zajmuj\u0105 najwi\u0119cej pami\u0119ci. Warto mie\u0107 na podor\u0119dziu testy \u2013 benchmarki, kt\u00f3re zmierz\u0105 zu\u017cycie zasob\u00f3w i poka\u017c\u0105, czy optymalizacja w danym miejscu w og\u00f3le ma racj\u0119 bytu.<\/p>\n
Dynamiczne alokacje pami\u0119ci.<\/h3>\n
Jej cz\u0119ste zajmowanie i zwalnianie potrafi znacznie spowolni\u0107 dzia\u0142anie programu i znacznie wp\u0142yn\u0105\u0107 na szybko\u015b\u0107 komputer\u00f3w. Niejeden j\u0119zyk programowania dokonuje ich niejawnie, tzn. bez wyra\u017anego zaznaczenia tego w kodzie. Odci\u0105\u017ca to programist\u0119 z konieczno\u015bci zarz\u0105dzania pami\u0119ci\u0105. Dzi\u0119ki temu \u0142atwiej jest skupi\u0107 si\u0119 na implementacji. Niestety, kiedy aplikacja rozrasta si\u0119, mog\u0105 pojawi\u0107 si\u0119 problemy z zajmowaniem RAM-u. Je\u015bli od pocz\u0105tku wcale si\u0119 tym nie przejmowano, optymalizacja mo\u017ce nawet wymaga\u0107 przepisania ca\u0142o\u015bci od nowa.<\/p>\n
Kontenery<\/h3>\n
Czyli struktury do przechowywania danych, maj\u0105 du\u017ce znaczenie dla szybko\u015bci programu. Jedne maj\u0105 ma\u0142y narzut pami\u0119ci, inne pozwalaj\u0105 na szybkie wstawianie i usuwanie element\u00f3w, jeszcze inne wydajnie wyszukuj\u0105 informacje. Ale nie da si\u0119 mie\u0107 wszystkich zalet naraz. Warto wi\u0119c czasem po\u015bwi\u0119ci\u0107 czas na wyb\u00f3r tego w\u0142a\u015bciwego rozwi\u0105zania.<\/p>\n
Istnieje zatem spore pole do popisu dla tworzenia szybkich, wydajnych program\u00f3w. Jednak jako\u015b nie zawsze si\u0119 to udaje. Musi by\u0107 wi\u0119c jaki\u015b rozd\u017awi\u0119k mi\u0119dzy teori\u0105 a praktyk\u0105.<\/p>\n
Co faktycznie zdzia\u0142a developer<\/h2>\n
Powy\u017csze punkty faktycznie przedstawiaj\u0105 mo\u017cliwo\u015bci programist\u00f3w, ale tylko z punktu widzenia pisania kodu. Jest jeszcze druga strona, czyli\u2026 samo \u017cycie. Ograniczone s\u0105 nie tylko procesory, RAM i dyski, lecz r\u00f3wnie\u017c:<\/p>\n
Termin oddania projektu<\/h3>\n
Czy jest to projekt w szkole programowania, czy w pracy \u2013 istniej\u0105 deadline\u2019y. \u017beby przyspieszy\u0107 prac\u0119, ka\u017cdy czasem idzie na skr\u00f3ty. Niekiedy owocuje to np. sprytnym wykorzystaniem ju\u017c istniej\u0105cego rozwi\u0105zania, a kiedy indziej \u2013 po\u015bpiechem i ba\u0142aganem w kodzie. A to powoduje wzrost d\u0142ugu technicznego i cz\u0119sto wolniej dzia\u0142aj\u0105c\u0105 aplikacj\u0119!<\/p>\n
Do\u015bwiadczenie<\/h3>\n
Jak wspomniano, istnieje mn\u00f3stwo sposob\u00f3w na problemy, kt\u00f3re kto\u015b mia\u0142 ju\u017c wcze\u015bniej. Czy to kr\u00f3tka odpowied\u017a na StackOverflow, czy wydajna biblioteka, u\u0142atwiaj\u0105ca potrzebne obliczenia \u2013 Internet mo\u017ce by\u0107 bardzo pomocny w poszukiwaniach. Nie zast\u0105pi jednak rzetelnej wiedzy, bo zadanie trzeba przecie\u017c namierzy\u0107, nazwa\u0107 i wybra\u0107 dobre rozwi\u0105zanie. O ile\u017c lepiej, kiedy po prostu si\u0119 je zna!<\/p>\n
Koordynacja pracy w zespole<\/h3>\n
Wsp\u00f3\u0142praca w kilka os\u00f3b to chleb powszedni, wiele powsta\u0142o metodyk jej ulepszania \u2013 mo\u017cna tu podci\u0105gn\u0105\u0107 wi\u0119kszo\u015b\u0107 s\u0142ynnego Agile. Zgodno\u015b\u0107, w\u0142a\u015bciwy podzia\u0142 zada\u0144 i regularne ich omawianie s\u0105 kluczowe, aby post\u0119p szed\u0142 g\u0142adko i prowadzi\u0142 do dobrego wykorzystania zasob\u00f3w przez program.<\/p>\n
Mo\u017cliwo\u015bci umys\u0142owe<\/h3>\n
To prawdopodobnie najwa\u017cniejszy punkt, gdy\u017c nikt z nas nie jest idea\u0142em. W naszym \u015bwiecie b\u0142\u0119dy nazywa si\u0119 konkretnie bugami i praktycznie \u017caden program nie jest od nich wolny. Dobry developer jest pogodzony z faktem, \u017ce je robi. Przej\u015bcie przez pope\u0142nienie powa\u017cniejszych pomy\u0142ek to dobra nauka. Wa\u017cne jest, aby nie przecenia\u0107 swoich si\u0142 i ufa\u0107 raczej rzetelnie zrobionym testom ni\u017c w\u0142asnemu poczuciu nieomylno\u015bci.<\/p>\n
Podsumowanie<\/h2>\n
Przej\u015bcie od rozwoju sprz\u0119tu komputerowego do wydajno\u015bci umys\u0142owej przeci\u0119tnego programisty okaza\u0142o si\u0119 kr\u00f3tsze, ni\u017c mo\u017cna by si\u0119 spodziewa\u0107. Koniec ko\u0144c\u00f3w poj\u0119cie \u201cszybko\u015b\u0107 komputer\u00f3w\u201d jest wra\u017ceniem u\u017cytkownika ko\u0144cowego. Opiera si\u0119 na mn\u00f3stwie czynnik\u00f3w \u2013 zar\u00f3wno sprz\u0119towych, softowych, jak i czysto ludzkich. Warto mie\u0107 je wszystkie na uwadze w codziennej pracy. Kto\u015b powie, \u017ce to zbyt du\u017co naraz? C\u00f3\u017c, nikt nie m\u00f3wi\u0142, \u017ce ta robota zawsze jest lekka! Spokojnie i po kolei, do\u015bwiadczenie przychodzi z czasem. A skoro i tak wszyscy pope\u0142niamy b\u0142\u0119dy, to nie ma co si\u0119 ich wstydzi\u0107. Tylko poprawi\u0107 \u2013 i b\u0119dzie kolejna wersja!<\/p>\n