{"id":738,"date":"2020-04-28T09:23:48","date_gmt":"2020-04-28T09:23:48","guid":{"rendered":"https:\/\/kalkus.dev\/?p=738"},"modified":"2023-08-24T23:18:01","modified_gmt":"2023-08-24T23:18:01","slug":"prototyp-glupcze","status":"publish","type":"post","link":"https:\/\/kalkus.dev\/blog\/2020\/04\/28\/prototyp-glupcze\/","title":{"rendered":"Prototyp, g\u0142upcze!"},"content":{"rendered":"\n

Tworzenie oprogramowania jest jednym z najbardziej z\u0142o\u017conych przedsi\u0119wzi\u0119\u0107, jakich podejmuje si\u0119 nasza cywilizacja. Nie dotyczy to co prawda ka\u017cdego projektu, istniej\u0105 rzeczy proste, trywialne, ale nawet za nimi ci\u0105gnie si\u0119 ogon bibliotek, system\u00f3w operacyjnych, procesor\u00f3w i ca\u0142ej koncepcji programowania, wraz z algorytmami, maszyn\u0105 turinga i j\u0119zykami formalnymi. S\u0105 jednak r\u00f3wnie\u017c projekty same w sobie niezwykle skomplikowane \u2013 systemy tradingowe, symulacje fizyczne, oprogramowanie symuluj\u0105ce zwijanie bia\u0142ek…<\/h4>\n\n\n\n

R\u0119kodzie\u0142o<\/strong><\/h3>\n\n\n\n

Mimo ca\u0142ej tej z\u0142o\u017cono\u015bci, jest w programowaniu duch r\u0119kodzie\u0142a.<\/p>\n\n\n\n

Pracujemy nieraz nad arcydzie\u0142ami koronkowej abstrakcyjnej tw\u00f3rczo\u015bci, rozpi\u0119tymi na setki tysi\u0119cy linii kodu w spos\u00f3b jakby\u015bmy toczyli waz\u0119 za czas\u00f3w dynastii Han.<\/p>\n\n\n\n

Poni\u017cej przyk\u0142adowa waza. Pi\u0119kna rzecz, ale od czasu panowania dynastii Han, 206 BC\u2013220 AD, troch\u0119 czasu min\u0119\u0142o…<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Co z\u0142ego w toczeniu wazy? Niby nic. Tyle, \u017ce w przypadku wazy mo\u017cna, jak s\u0105dz\u0119, nada\u0107 jej jaki\u015b pocz\u0105tkowy kszta\u0142t, a potem malowa\u0107 kolejne fragmenty nieco improwizuj\u0105c. Tutaj smok, tam feniks, jaki\u015b ornamencik.<\/p>\n\n\n\n

I cz\u0119sto wychodzi \u0142adnie.<\/p>\n\n\n\n

Gorzej jednak, kiedy prze\u0142o\u017cymy to na programowanie. Robimy jakie\u015b MVC, tam dwa przyciski, tu jaki\u015b dropdown, pod spodem kontrolerek i repozytorium i jako\u015b to b\u0119dzie.<\/p>\n\n\n\n

I czasami wychodzi \u0142adnie.<\/p>\n\n\n\n

Warto by jednak by\u0142o, zanim zaczniemy implementowa\u0107, lepi\u0107, kleci\u0107 i klepa\u0107, zastanowi\u0107 si\u0119, co tak w zasadzie system ma robi\u0107. Bo co waza ma robi\u0107, to wiadomo, a czy b\u0119dzie mia\u0142a dwa smoki i i trzy feniksy, czy te\u017c pi\u0119\u0107 ornament\u00f3w i jednego smoka, to ju\u017c detal, o ile si\u0119 je \u0142adnie namaluje. Troch\u0119 te\u017c kr\u00f3cej si\u0119 tworzy tak\u0105 waz\u0119. Gorzej jednak, jak w trakcie lepienia naszej wazy-MVC przychodzi klient i m\u00f3wi, \u017ce chce czajnik. I jeszcze raz za dwa tygodnie i dodaje, \u017ce elektryczny…<\/p>\n\n\n\n

Agile w dw\u00f3jnas\u00f3b<\/strong><\/h3>\n\n\n\n

Wydawa\u0107 by si\u0119 mog\u0142o, \u017ce brak planu na pocz\u0105tku projektu mo\u017ce wynika\u0107 z dominacji Agile na rynku. Promuje ona tworzenie jak gdyby ad hoc, w kr\u00f3tkich odcinkach czasu. S\u0105dz\u0119 jednak, \u017ce brak planu to co\u015b naturalnego, amatorskiego. Tak projekty tworz\u0105 studenci. Siadaj\u0105 do kompilatora i pr\u00f3buj\u0105. Pr\u00f3buj\u0105, pisz\u0105, nie planuj\u0105. Mi\u0142o jest co\u015b zacz\u0105\u0107, da\u0107 si\u0119 poch\u0142on\u0105\u0107 entuzjazmowi. Mniej sympatycznie jest tworzy\u0107 plan, analizowa\u0107, przewidywa\u0107 problemy, a potem tego planu si\u0119 trzyma\u0107.<\/p>\n\n\n\n

Jest taka s\u0142ynna grafika w \u015bwiecie Agile. Ilustruje tworzenie MVP na przyk\u0142adzie budowania samochodu. Znalaz\u0142em swego czasu ciekawsz\u0105:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Przez pewien czas s\u0105dzi\u0142em, \u017ce w istocie jedynie dolny rysunek ukazuje w\u0142a\u015bciw\u0105 drog\u0119, a tradycyjny przyk\u0142ad z hulajnog\u0105, rowerem, motocyklem i samochodem jest b\u0142\u0119dny.<\/p>\n\n\n\n

Tymczasem oba s\u0105 poprawne. W zale\u017cno\u015bci jednak od sytuacji.<\/p>\n\n\n\n

Wyr\u00f3\u017cni\u0142bym dwa modele tworzenia produktu:<\/p>\n\n\n\n

  • kreatywny<\/li>
  • konserwatywny<\/li><\/ul>\n\n\n\n

    Produkt tworzony kreatywnie mo\u017ce wyewoluowa\u0107 w dowolnym kierunku. Przyk\u0142adowo \u2013 projektujemy pierwszy smartphone. Nie wiemy jak ma wygl\u0105da\u0107. Produkt mo\u017ce ewoluowa\u0107 znacz\u0105co, a feedback od klienta jest kluczowy i ma prawo kompletnie zmieni\u0107 produkt.<\/p>\n\n\n\n

    Produkt tworzony konserwatywnie jest czym\u015b, co ju\u017c istnieje na rynku i nie planujemy go rewolucjonizowa\u0107 (albo czym\u015b co\u015b wr\u0119cz wiemy jak ma wygl\u0105da\u0107, bo wynika z regulacji rynku, ustawy itp.). Chc\u0105c zbudowa\u0107 nowy model samochodu nie ma sensu tworzy\u0107 hulajnogi. Mo\u017cemy poeksperymentowa\u0107 z nadwoziem, wyposa\u017ceniem, ale nie z sam\u0105 koncepcj\u0105 auta.<\/p>\n\n\n\n

    Prototyp<\/strong><\/h3>\n\n\n\n

    Wydawa\u0107 by si\u0119 mog\u0142o, \u017ce prototypowanie jest czym\u015b oczywistym. Pisarze tworz\u0105 pierwsze szkice, kt\u00f3re potem udoskonalaj\u0105, ubieraj\u0105 w szczeg\u00f3\u0142y, a czasami zupe\u0142nie przerabiaj\u0105. Malarze zwykle zaczynaj\u0105 obraz od zarysowania g\u0142\u00f3wnych jego element\u00f3w, r\u00f3wnie\u017c tworz\u0105c na pocz\u0105tku co\u015b w rodzaju prototypu. Projekty samochod\u00f3w zawsze zaczynaj\u0105 si\u0119 od produkowanych w jednym, czy kilku egzemplarzach wersji demo. Tymczasem w oprogramowaniu bywa r\u00f3\u017cnie.<\/p>\n\n\n\n

    Widzia\u0142em projekty, gdzie nigdy niczego nie prototypowano. Proces tworzenia oparty by\u0142 o pe\u0142n\u0105 implementacj\u0119 w ka\u017cdym sprincie. Zupe\u0142nie bezrefleksyjnie marnotrawiono czas, cho\u0107 mo\u017cna by\u0142o narysowa\u0107 na kartce propozycje rozwi\u0105za\u0144 i doj\u015b\u0107 do konsensusu miesi\u0105ce szybciej.<\/p>\n\n\n\n

    Moim zdaniem ka\u017cda aplikacja, kt\u00f3ra posiada interfejs graficzny (co stanowi spor\u0105 cz\u0119\u015b\u0107, je\u015bli nie wi\u0119kszo\u015b\u0107 rynku) MUSI zacz\u0105\u0107 si\u0119 od designu, nast\u0119pnie przej\u015b\u0107 w \u201eklikalny\u201d prototyp, by w ko\u0144cu zosta\u0107 w pe\u0142ni zaimplementowana.<\/p>\n\n\n\n

    Stworzenie designu u\u0142atwia zrozumienie produktu i zadawanie w\u0142a\u015bciwych pyta\u0144. Wi\u0119kszo\u015b\u0107 os\u00f3b jest wzrokowcami i potrzeba im wizualnej reprezentacji tego, nad czym maj\u0105 podj\u0105\u0107 prac\u0119.<\/p>\n\n\n\n

    Prototyp z kolei pozwala dostarczy\u0107 klientowi co\u015b namacalnego w czasie o wiele szybszym od pe\u0142nej implementacji. Rozwi\u0105zuje to frustracj\u0119 biznesu zwi\u0105zan\u0105 z czekaniem na pierwszy rezultat. Nic pewnie nie irytuje bardziej, ni\u017c s\u0142uchanie przez dwa miesi\u0105ce technicznych sprawozda\u0144 bez mo\u017cliwo\u015bci ujrzenia wyniku pracy, je\u015bli zainwestowa\u0142o si\u0119 kilkadziesi\u0105t lub kilaset tysi\u0119cy z\u0142otych w rozw\u00f3j produktu.<\/p>\n\n\n\n

    W wielu firmach speciali\u015bci od UI i UX s\u0105 bagatelizowani lub w og\u00f3le si\u0119 ich nie zatrudnia. To b\u0142\u0105d. To gigantyczne przeoczenie. Ich praca to nie tylko rysowanie okienek \u2013 ich wysi\u0142ek u\u0142atwia wszystkim zrozumienie produktu oraz prac\u0119 nad nim. Projekty zaczynajmy od szkicu, designu, przechod\u017amy do prototypu, a ko\u0144czmy na implementacji!<\/p>\n","protected":false},"excerpt":{"rendered":"

    Tworzenie oprogramowania jest jednym z najbardziej z\u0142o\u017conych przedsi\u0119wzi\u0119\u0107, jakich podejmuje si\u0119 nasza cywilizacja. Nie dotyczy to co prawda ka\u017cdego projektu, istniej\u0105 rzeczy proste, trywialne, ale nawet za nimi ci\u0105gnie si\u0119 ogon bibliotek, system\u00f3w operacyjnych, procesor\u00f3w i ca\u0142ej koncepcji programowania, wraz z algorytmami, maszyn\u0105 turinga i j\u0119zykami formalnymi. S\u0105 jednak r\u00f3wnie\u017c projekty same w sobie niezwykle […]<\/p>\n","protected":false},"author":1,"featured_media":801,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[103,204,78,7],"tags":[122,40,121,47],"_links":{"self":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/738"}],"collection":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/comments?post=738"}],"version-history":[{"count":24,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/738\/revisions"}],"predecessor-version":[{"id":800,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/738\/revisions\/800"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media\/801"}],"wp:attachment":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media?parent=738"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/categories?post=738"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/tags?post=738"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}