Tworzenie małych i autonomicznych części aplikacji, mających cechy:
- readable - forma kodu łatwa do czytania, dużo akapitów, czyli funkcji i małe rozdziały, czyli klasy
- understable - zrozumiałego w odniesieniu do samej treści kodu, pisać nazwy zmiennych i funkcji w sposob klarowny
- manageable (replaceable) - zarządzalne, wymianialne, czyli modułowa konstrukcja, łatwa to zastąpienia struktura i architektura, tak by łatwo wymienić poszczególne klasy i biblioteki, itp.
https://tom.sapletta.pl/jak-wykonac/pisarz-artysta-poeta-i-dobre-rady-oraz-wzorce/
Daily Flow skupia się na codziennym wykorzystaniu potencjału twórczego do wypracowania powtarzalnych procesów i uzyskania powtarzalnych produktów realizując automatyzację. Twórcze działanie powinno być wykorzystane w każdym działaniu, aby uzyskać najlepsze efekty na małym odcinku produkcji. Wyspecjalizowane procesy połączone w schematach pozwalających na uzyskanie oczekiwanych efektów.
Realizacja programowanych i automatycznie wykonywanych i testowanych procesów.
W tej metodzie konieczne jest tworzenie standardów na poziomie każdej decyzji. Dlatego potrzebna jest dokumentacja. Potrzebne są dane statystyaczne do mierzenia wydajności na poziomie każdego procesu
Metoda nie tyle zarządzania, co wykorzystawnia własnego potencjału do szybkiego uzyskania wyników. Nie chodzi w tym o uzyskanie zgodnego w 100% efektu, ale by uzyskać efekt oraz narzędzia.
Podstawą Flow jest doskonalenie warsztatu pracy i siebie samego a nie tylko produktu - oprogramowania. Oprogramowanie jest tylko produktem wykorzystania tych narzędzi, zasad i technik.
Dzięki skupieniu na lepszych narzędziach można uzyskać lepsze produkty. Taki selfedevelopment, przyczynia się do szybkiego wzrostu całości a nie skupia się tylko na produkcie działań, ale przede wszystkim na działaniach, procesach i technikach.
Ten kierunek pozwala na bardziej zaawansowaną realizację automatyzacji.
trochę więcej informacji na temat samego flow w psychologii: https://github.com/tom-sapletta-com/CycloneGenesis/blob/master/Flow.md
Ten sposob funkcjonowania bedzie sprzyjal osobom tworczym, otwartym na nauke, tym, ktorzy maja juz jakies doswiadczenie w realizacji projektow. Nie jest to rozwiazanie dla kazdego, gdyz nie kazdy ma taka wiedze by podejmowac decyzje co do calej drogi rozwoju projektu, dlatego warto wziac pod uwage to, ze w przapadku dzialania w grupie, warto znalezc kogos kto bylby ekspertem wspierajacym dostepnym dla realizatorow. W przypadku smaodzielnego funkcjonowania mozna wiele rzeczy sie nauczyc po drodze samemu wykorzystujac kod juz napisany przez innych ludzi poprzez repozytoria na github, itd
Mysle, ze najlepszym rozwiazaniem, jest brak presji, takze w kwestii zastanawiania sie czy flow bedzie jutro czy tez nie. Lepiej jest zwyczajnie robic to co sie lubi, wowczas flow same przychodzi, gdyz ciagle jestesmy w stanie zywego zainteresowania tematem zadania. Sami wyznaczamy sobie cele i je realizujemy, mamy tez zdefiniowany termin, wiec sam czas jest motywatorem i stymulatorem.
Co istotne, zadania rowniez dopieramy z sami, nawet je tworzymy, gdyz to czynnosc pozadana, pozwalajaca na sprecyzowanie zadan.
Rezultatem celu ma być aplikacja do zdalnego wywoływania komend w terminalu przez przegladarkę.
Tworze aplikację DevOpsTerminal, w ktorej zamierzam stworzyć:
- frontend z Jquery UI Po rozpoczeciu tworzenia frontend'u, mam juz trochę kodu. Po rozmowie z kolegą myślę, że lepszym rozwiązaniem byłby Bootstrap zamiast jqueryUI. Nie usuwając projektu z frontend'em Jquery UI, tworzę nowe repozytorium w którym implementuje to samo za pomocą innej technologii Bootstrap.
Otwierając się na inne rozwiązania jeszcze w trakcie realizacji celu można zdobyć dodatkową wiedzę. Jednoczensie tez zbieramy więcej danych pod innym kątem, ale zawsze można wrócić do pierwszego projektu.
Kluczem w takim podejsciu jest tworzenie za pomoca malych kroków, np realizacja w ciągu 8h ciągłej pracy. Pisanie oprogramowania w wielu etapach pozwala na uzyskanie większej sprawności, gdyż można kontrolować każdy mały element. Budować oprogramowanie z małych autonomicznych bloków-klocków. Wówczas kazdy etap może być łatwo wyelimnowany/zastapiony, dzieki czemu łatwiej jest zbudować całość, z małych wymiennych cegiełek.
Male wymienne moduly
Podobnie jest z ta ksiazka, obecnie tworze kilka projektow jednoczesnie, ktore z osobna sluza zdefiniowanemu celowi, poprzez ktory ucze sie realizowac projekty w jak najwydajnieszy sposob. Np. projekt DevOpsTerminal sluzy do wydajniejszej obslugi wielu serwerow i skryptow. Przy okazji staram sie zapisywac moje przemyslenia i wskazowki na przyszlosc dla innych realizowanych projektow.
Ta analiza pozwala mi zglebic nature tworzenia projektow i pozwala mi lepiej zrozumiec sposob realizacji celow.
W codziennej pracy nie ma zbyt wiele czasu na to, ewentualnie jeden raz w tygodniu.
Tutaj nie ma tego problemu, gdyz każdy czas jest dobry.
Wiec pisze te rzeczy, aby lepiej zrozumiec i wykorzystac to co robie, tym samym juz teraz moge lepiej wykorzystac to co umiem.
Zamiast czekać do końca projektu, warto zastanowić się przed jego rozpoczęciem, czy w ogóle powinien być realizowany tak jak został zaplanowany, bo może kontorlowane małe etapy poprzez DailyFlow dadzą lepsze rezultaty?
DevOpsTerminal zostanie i tak stworzony, ale dzięki lepszemu zrozumienuiu otoczenia, będę w stanie lepiej przygotować aplikację jeszcze przed jej wykonaniem i kolejnymi krokami, jakimi niewątpliwie bedzie refaktoryzacja.
W przypadku realizacji małych modułów składajacych się na dużą aplikację lub system, łatwe jest wymienianie źle funkcjonujących elementów, a poprzez Continnuos Integration łatwo dalej utrzymać aplikację działającą.
W obecnej postaci wiele refaktoryzacji ma charakter pielęgnacji kodu, co nie jest potrzebne, gdyż to co realizuje kod jest istotne a nie jak wygląda.
W przypadku tradycyjnego ulepszania, refaktoryzacji, poprawiania, trudno o tworzenie optymalnego kodu, gdyż kodem jest cały system, łatwiej zarządzać małymi wymienialnymi cegiełkami systemu i tym zajmuje się właśnie DailyFlow, skupione na tworzeniu małej działającej części systemu.
Koszyk z zakupami
W programowaniu dochodzi do skrajności , gdzie Tworzenie jest tańsze nić Refaktoryzacja. Coś co w hardware-owym świecie jest nie do pomyślenia, gdyż łatwiej naprawić samochód niż wytworzyć nowy.
Warto wprowadzić standardy w komunikacji i tworzeniu oprogramowania, gdzie zdefiniowane są moduły i klient może wybrać z istniejących.
Obecnie sytuacja wyglada tak: Klient + ktos techniczny uzgadaniaja co bedzie zrobione a programisci niech mysla, niech buduja , bo przeciez wiemy czego chcemy a jak nawet nie, to przeciez programista to naprawi, bo przeciez mu placimy i to duzo!
Wyobraźmy sobie sytuację, gdzie programiści mają sklepik, gdzie klient wewnętrzny lub/i zewnetrzny moze kupić to co chciałby mieć w swojej aplikacji. Jesli nie ma danego produktu (modułu), to kleint opisuje specyfikę i zamawia bezposrednio u programisty. Programiści tworzą moduł i wspierają go na kilka lat do przodu.
Takie podejście zadowoli każdą stronę.