Pozdrawiam, koledzy. Dzisiaj porozmawiamy o rodzajach prac przygotowawczych, które należy wykonać, zanim zaczniesz dziko kodować. A dokładniej o planowaniu i tworzeniu architektury aplikacji. Ale od czego zacząć? Jak zbudować taką architekturę? Jak ze wszystkim, trzeba zacząć od początku. Mianowicie - z IDEA. Ideą naszego projektu było stworzenie użytecznego bota telegramowego z podstawową funkcjonalnością. Powtórzmy dokładnie co: „Ja, jako użytkownik, chcę mieć możliwość otrzymywania powiadomień, gdy w interesujących mnie grupach na JavaRush pojawią się nowe artykuły”. Kierując się zasadą YAGNI, zbudujemy naszą aplikację. Oznacza to, że zabierzemy tylko tyle, ile potrzebujemy. Nie będziemy tworzyć funkcjonalności z góry i z rezerwą tylko dlatego, że chcemy i kiedyś może nam się ona przydać. Tak, stworzymy czytelną i rozszerzalną aplikację, ale to nie znaczy, że stworzymy schemat bazy danych „na rozwój”. Aby nie wspierać tego „wzrostu”, stwierdziłem, że lepiej będzie z niego w ogóle zrezygnować. Pomoże nam to uniknąć niepotrzebnego wsparcia podczas rozwoju i niepotrzebnych testów. Później, gdy nasz projekt wejdzie do produkcji (znowu anglicyzm, od skrótu prod – produkcja), będziemy mogli zrobić coś więcej. Kiedy już zdecydujesz się na pomysł, musisz trochę się zbuntować i narysować. Co narysować? Przyda nam się możliwość zapisywania danych o subskrypcjach grupom różnych użytkowników. Wiem, że w Telegramie możesz użyć identyfikatora użytkownika w postaci identyfikatora czatu. I istnieje pomysł, jak faktycznie będzie przebiegać wyszukiwanie nowych artykułów: przeszukamy wszystkie grupy, które mają subskrypcje nowych artykułów i wyślemy je na czaty. Na tej podstawie w pierwszym przybliżeniu otrzymujemy co następuje (tutaj rozwinięcie bez ozdobników): Nie mam nadzieję, że zrozumiecie mój charakter pisma: Chcę dokładnie pokazać, jak i gdzie zaczyna się rozwój. Pierwszy etap został zakończony: w jakiś sposób zdecydowaliśmy, co się stanie. Modele/tabele znajdujące się w bazie zostały opisane powyżej. Ale to jest szkic: można i należy go dopracować i nadać mu bardziej czytelną formę. Podczas polerowania przypomniałem sobie, że chciałem też uzyskać statystyki dotyczące pracy bota. Dodałem to. Na tym rysunku jest więcej niż jasne, co i jak zostanie ułożone. Czyli jakie będą w nich tabele i pola, jakie będą nazwy encji dla tabel. Zdecydowano, że będzie ich kilka:
Użytkownik - informacja o użytkowniku telegramu, który będzie korzystał z naszego bota. Jak widać, zapisujemy tylko identyfikator czatu i flagę, niezależnie od tego, czy użytkownik jest aktywny, czy nie. Dlaczego? Ponieważ naszym celem nie jest zbieranie informacji o użytkownikach, ale przynoszenie im korzyści;
GroupSub - tutaj znajdą się informacje o grupie, do której masz subskrypcję oraz najnowszy artykuł, który został wysłany do subskrybentów;
Statystyki – nie stworzyłem dla tego schematu – zrobimy to później. Nie to jest głównym celem w MVP projektu.
Następnie chciałem bardziej szczegółowo pokazać sposób wyszukiwania nowych artykułów. W tym celu użyłem diagramu BPMN, który przekonwertowałem na obraz i otrzymałem coś takiego: Wszystko tutaj jest bardziej czytelne i zrozumiałe. W wyszukiwaniu będziemy pracować według tego schematu. Menedżerom bardzo podoba się ten schemat, bo jest zrozumiały nie tylko dla programistów :D Ogólnie rzecz biorąc, początek został zrobiony.
Utwórz repozytorium do pracy
Na koniec możesz utworzyć repozytorium do pracy z botem telegramowym.
Wypełniamy znane nam już elementy - nazwę repozytorium, jego krótki opis.
Dodaj licencję - Apache 2.0 (możesz wybrać licencję według własnego uznania).
Do pracy z projektem dobrze byłoby skorzystać z narzędzi GitHuba takich jak Project. Co to jest? To miejsce, w którym możesz tworzyć zadania, śledzić ich realizację i zapisywać status zadań. Ustal, kto będzie je wykonywał i nie tylko. Aby to zrobić, w utworzonym projekcie znajdziemy przycisk Projekty i tam utworzymy nowy: Jak widać, tutaj wskazałem nazwę projektu, opisałem go i wybrałem szablon, na którym będziemy pracować - Zautomatyzowany Kanban. Dla nas nie jest teraz tak ważne, co to oznacza. Najważniejsze, że będziemy mieli tablicę z zadaniami podzieloną na kolumny, gdzie każda kolumna będzie zawierać status zadania:
Do zrobienia - wszystkie zadania, które są zaplanowane do wykonania;
W toku – zadania, nad którymi aktualnie pracujemy;
Gotowe – zadania, które zostały już zrealizowane w ramach tego projektu.
W ten sposób będziemy wiedzieć o statusie naszych zadań. Które są w trakcie realizacji, a które już zakończone. Co więcej, jest to ważne i wygodne nie tylko w przypadku, gdy jest zespół, ale także wtedy, gdy pracujesz samodzielnie. Aby coś pojawiło się na tablicy należy utworzyć Zagadnienia.
Pisanie zagadnień (zagadnień) do projektu
Aby zrozumieć, jakie zadania napisać, zdecydujmy, co będziemy mieli w projekcie. Potrzebujemy aplikacji, którą można łatwo i szybko uruchomić, dzięki której będziemy mogli uzyskać dostęp do bazy danych, abyśmy mogli zarządzać i zmieniać schemat bazy danych, abyśmy mogli wykonywać żądania REST w JavaRush w celu uzyskania danych o artykułach. Na tej podstawie możesz wybrać następujące technologie:
SpringBoot – jako framework dla naszej aplikacji,
Spring Data - do pracy z bazą danych,
Flyway - do pracy z migracjami baz danych,
MySQL – jako baza danych dla projektu,
Telegrambot StringBoot starter - biblioteka do pracy z botem telegramowym,
Unirest to biblioteka do pracy z żądaniami REST.
Z powyższego zacznijmy tworzyć zadania.
Szablon tworzenia zadania
Zadania stworzymy według następującego szablonu:
Nazwa zadania będzie wyglądać następująco: JRTB-{IssueNumber}:{IssueDescription} , gdzie:
{IssueNumber} to numer seryjny problemu. Weźmy to jeszcze raz od ostatniego problemu;
{IssueDescription} – krótki opis problemu.
W treści zadania dokonamy jego bardziej szczegółowego opisu (czasami może on pokrywać się z opisem w nazwie zadania).
Kryteria akceptacji to lista wymagań, po spełnieniu której zadanie można uznać za zakończone. Że tak powiem, kryteria przyjęcia zadania. Za ich pomocą recenzent (z języka angielskiego recenzent – recenzent – osoba, która patrzy na sposób wykonania zadania) może zrozumieć, czy zadanie zostało całkowicie ukończone, czy nie.
Korzystając z tego szablonu utworzymy nasze pierwsze zadanie: Warto też dodać, że tworząc go od razu ustaliłem do jakiego projektu to zadanie się nadaje, kto będzie je wykonywał (cesjonariusz) i do jakiej wytwórni (etykiety) to zadanie należało. Następnie po prostu pokażę nazwy zadań z krótkim opisem i linkami do nich. Oni wszyscy są tutaj . Zadania wykonamy w przybliżeniu w tej samej kolejności, jak wskazano tutaj:
To już wygląda na początek projektu. Można powiedzieć, że pracowaliśmy jako architekt projektu i analityk biznesowy.
Wypełnianie repozytorium
Co jeszcze należy zrobić ZANIM zaczniemy kodować? - Autorze, ile tych akapitów możesz dodać, czy wyciągasz je z otchłani?? — Nie, jakość pracy widać w szczegółach. I to one mają sens. Dodajmy więc jeszcze jeden szczegół. Aby projekt stał się popularny i zrozumiały dla innych programistów, należy go wypełnić. Co powinienem dodać? Pełną listę tego, co można zrobić, opisałem w artykule Optymalizacja pracy z projektami na GitHubie: poznanie repozytorium szablonów Github . Gorąco polecam przeczytać. Ważne jest, abyśmy mieli jasne wersje i jasne zrozumienie tego, co robimy. Dlatego dodałem plik RELEASE_NOTES, w którym będą zapisywane zmiany w naszym projekcie. Jako przykład możesz spojrzeć na RELEASE_NOTES z mojego projektu (tak, dlaczego by nie pokazać w co wkładam swoją energię i kreatywność). Opisane są tam zmiany dla każdej nowej wersji. Dodałem także szablony do tworzenia nowych zadań, które mają 4 opcje:
Raport o błędach to zadanie tworzone przez użytkowników/testerów, którzy znajdą błąd w swojej pracy. To bardzo ważna rzecz: pomaga zarządzać poprawkami błędów;
Żądanie funkcji to zadanie polegające na dodaniu nowej funkcjonalności. Wszystkie pierwsze zadania w projekcie są zadaniami z żądaniem funkcji;
Prośba o ulepszenie – zadanie mające na celu poprawę działania aplikacji. Na przykład, aby zmienić odpowiedzi testowe podczas pracy z botem. Nie jestem pisarzem technicznym i mogę wymyślić nie do końca poprawne odpowiedzi. Jeśli więc masz chęć i możliwości to oferuj :)
Pytanie to pytanie do programistów dotyczące działania aplikacji. Bardzo przydatna rzecz. Powiedzmy, że nie ma zrozumienia dzieła lub są wątpliwości co do jakiegoś pytania – możesz w ten sposób zadać pytanie i uzyskać odpowiedź z pierwszej ręki.
Jeśli spojrzysz na GitHub, będzie to wyglądać dokładnie tak: Obecnie mamy również dokument dotyczący pracy z API JavaRush do pracy z grupami.
Co dalej?
No cóż, wykonujemy wszystkie te kroki i co, projekt zostanie zamknięty? Nie, wcale. Ten projekt będzie nadal żywy. Zostanie opracowany przeze mnie i wszystkich studentów/absolwentów JavaRush, którzy chcą wziąć udział. Jakie są Twoje plany na przyszłość? Dużo ich. Pierwszym planem jest utworzenie klienta Java dla API JavaRush. Twórcy obiecali, że ich Swagger będzie dostępny w otwartym dostępie. Przyjrzymy się również, czym jest swagger. Fajna i bardzo przydatna rzecz. Następnie zintegrujemy witrynę JavaRush z botem telegramowym. Połączmy użytkownika z botem w celu synchronizacji subskrypcji. Stwórzmy statystyki ukończenia kursu. I wszystko, czego chcesz jako społeczność JavaRush.
wnioski
Dziś rozmawialiśmy o pracy za kulisami przed powstaniem projektu. A dokładniej o tym, jak stworzyć plan pracy, bez którego można zmarnować mnóstwo energii. Powtarzam, początek projektu został już tutaj udostępniony publicznie . Jak zwykle sugeruję subskrypcję mojego konta na Githubie. W ten sposób możesz otrzymać zmiany w projekcie PRZED publikacją artykułu. Zakładam już, że wszyscy zainteresowani zarejestrowali się na Githubie. Tak, projekt nie postępuje tak szybko, jak byśmy chcieli. Jednak tak jak w pracy realne projekty. W kolejnym artykule opiszę dodawanie pierwszych zadań. Dziękuję wszystkim za przeczytanie i do zobaczenia wkrótce!
Nie mam nadzieję, że zrozumiecie mój charakter pisma: Chcę dokładnie pokazać, jak i gdzie zaczyna się rozwój. Pierwszy etap został zakończony: w jakiś sposób zdecydowaliśmy, co się stanie. Modele/tabele znajdujące się w bazie zostały opisane powyżej. Ale to jest szkic: można i należy go dopracować i nadać mu bardziej czytelną formę. Podczas polerowania przypomniałem sobie, że chciałem też uzyskać statystyki dotyczące pracy bota. Dodałem to. Na tym rysunku jest więcej niż jasne, co i jak zostanie ułożone. Czyli jakie będą w nich tabele i pola, jakie będą nazwy encji dla tabel. Zdecydowano, że będzie ich kilka:
Następnie chciałem bardziej szczegółowo pokazać sposób wyszukiwania nowych artykułów. W tym celu użyłem diagramu BPMN, który przekonwertowałem na obraz i otrzymałem coś takiego: 
Wszystko tutaj jest bardziej czytelne i zrozumiałe. W wyszukiwaniu będziemy pracować według tego schematu. Menedżerom bardzo podoba się ten schemat, bo jest zrozumiały nie tylko dla programistów :D Ogólnie rzecz biorąc, początek został zrobiony.
Jak widać, tutaj wskazałem nazwę projektu, opisałem go i wybrałem szablon, na którym będziemy pracować - Zautomatyzowany Kanban. Dla nas nie jest teraz tak ważne, co to oznacza. Najważniejsze, że będziemy mieli tablicę z zadaniami podzieloną na kolumny, gdzie każda kolumna będzie zawierać status zadania:
Warto też dodać, że tworząc go od razu ustaliłem do jakiego projektu to zadanie się nadaje, kto będzie je wykonywał (cesjonariusz) i do jakiej wytwórni (etykiety) to zadanie należało. Następnie po prostu pokażę nazwy zadań z krótkim opisem i linkami do nich. Oni wszyscy są tutaj . Zadania wykonamy w przybliżeniu w tej samej kolejności, jak wskazano tutaj:
Obecnie mamy również dokument dotyczący pracy z API JavaRush do pracy z grupami.
GO TO FULL VERSION