Szybkie prototypowanie i refaktoryzacja

Czasami, kiedy rozpoczynam mały projekt (np. Aplikację na Androida), nie wiem, które podejście zadziała na końcu, i po prostu wybieram jedno podejście i próbuję. Ale jeśli nigdy wcześniej nie stosowałem tego podejścia (w przypadku aplikacji, których nigdy wcześniej nie programowałem), to jest to jak wkraczanie w nieznany teren. Nie wiem, jakich bibliotek użyć (być może muszę wypróbować kilka bibliotek) i jest tak wiele nieznanych (jak: jak uzyskać surowe dane audio w Androidzie)

Zatem mój proces rozwoju przebiega następująco:

• Napisz fragment kodu, aby sprawdzić, czy podejście ma szansę. (Im bardziej niepewne jest to podejście, tym brzydszy jest kod)
• Jeśli to działa, dużo refaktoryzuj, aż będzie piękne

Myślę, że może to być strata czasu, gdybym szczegółowo zaplanował projekt oprogramowania, byłoby to jak zaplanowanie podróży bez mapy.

Czy to część rozwoju aglie? Jak radzisz sobie z nieznanym terenem przy tworzeniu oprogramowania?

To nie ma nic wspólnego ze zwinnością, ale ludzie zakładają, że tak jest, ponieważ tak myślą, że zwinny; bezgłowy rozwój kurczaków w hipisowskiej gminie.

To, co robisz, polega na ocenie technologii, ponieważ obecnie nie masz wystarczającego doświadczenia, aby dokonać oceny. Jest to dobre i nigdy się nie kończy, ponieważ nowe biblioteki, frameworki, języki i platformy pojawiają się prawie codziennie.

Sposób radzenia sobie z nieznanym jest naprawdę dobrym pytaniem i sprowadza się do zbadania alternatyw, ich oceny, a następnie wybrania.

Umiejętności, które zwykle kojarzą się z Agile, pomagają tutaj tworzyć kod, który jest równie łatwy i bezpieczny do refaktoryzacji. TDD jest dobrym przykładem. Zachęca cię do rozważenia swojego rozwoju pod kątem wyników. „Ten kod powinien dać ten wynik”, który skupia umysł i zmniejsza ilość kodu, który nie przyczynia się do rozwiązania celu.

Jeśli napiszesz kod zgodnie z zasadami SOLID (akronim), później będziesz w dobrej sytuacji, aby wymienić bibliotekę, jeśli dokonałeś złego wyboru lub, jak to często bywa, przerastasz swój wybór.

Dobrze, że zadajesz tego rodzaju pytanie. Jest zbyt wielu programistów, którzy z różnych powodów nie ryzykują pojawienia się „ignorantów”, poświęcając czas na wybór właściwej technologii. Popełniaj błędy na początku projektu, nie późno. Eksperymentowanie jest kluczem, a nie marnotrawstwem, więc myślę, że podchodzisz do tego we właściwy sposób.

Czy to część rozwoju aglie? Jak radzisz sobie z nieznanym terenem przy tworzeniu oprogramowania?

To, co opisałeś, nie jest zwinne. Rozwój zwinny polega bardziej na promowaniu planowania adaptacyjnego, rozwoju ewolucyjnego i dostarczania z iteracyjnym podejściem czasowym. Agile zachęca do szybkiego i elastycznego reagowania na zmiany. Tak więc przefaktoryzowanie kodu w miarę postępu programowania zawiera w sobie elementy metodologii Agile.

Radzenie sobie z nieznanym fragmentem projektu zaczyna się od zebrania znanych wymagań, od projektu na wysokim poziomie. Gdy zdobędziesz większość komponentów, możesz poszukać właściwego rozwiązania. To powiedziawszy, budowanie małego dowodu koncepcji przed pełnym rozwinięciem jest podejściem, które podąża nasz zespół.

Istnieją zasady opracowywania oprogramowania o nazwie SOLID . Z mojego doświadczenia wynika, że ​​stosowanie ich do problemów / problemów jest zawsze krokiem naprzód w ulepszaniu bazy kodu twojego projektu.

W zależności od projektu, jeśli pracujesz sam nad małym projektem, może być sensowne przeprowadzenie badań technicznych i badań w ramach rozwoju. I chociaż nie jest częścią Agile, oczywiście można zastosować metodologię Agile, aby dodać do tego pewną kontrolę. Jednak powoduje to, że proces jest bardzo trudny do przewidzenia / lub przedziału czasu. Może być w porządku, nawet szybciej, jeśli pracujesz samotnie nad małym projektem, który jest całkowicie twój, pozwól, aby twoje wymagania się rozwijały, gdy się je uczysz. Po drodze stosuj dobre zasady, bądź konsekwentny i nie powinieneś zbyt wiele zmieniać faktorów.

W pracy używamy Kanban, Scrum i bardziej tradycyjnych podejść do wodospadu. W zależności od projektu uważam, że złożone rozwiązania z dobrze zdefiniowanymi wcześniejszymi wymaganiami nie najlepiej nadają się do zwinności, jednak wielu się nie zgodzi.

Zanim zaczniemy pracę nawet nad zwinnym projektem (wszystkie z wyjątkiem najprostszych), tworzymy dokumentację. Mamy makietę (jeśli dotyczy interfejsu użytkownika), zestaw wymagań i specyfikację funkcjonalną.

Programista zostanie poproszony o utworzenie specyfikacji technicznej ze specyfikacji funkcjonalnej, a podczas tego procesu określimy technologię i przeprowadzimy wszelkie wstępne badania, które będą nam potrzebne. Ten proces wydaje mi się tak ważny, ponieważ daje możliwość dostrzeżenia luk w wymaganiach / specyfikacjach funkcjonalnych - i daje duże decyzje technologiczne przed ludźmi z doświadczeniem i wiedzą systemową do podejmowania takich decyzji.

Istotną rzeczą jest to, że specyfikacja funkcjonalna może być listą wypunktowanych punktów, a specyfikacją techniczną będzie zwykle model, z pewnymi wypunktowanymi punktami i sterami technologicznymi, w niektórych przypadkach może to tylko 3 lub 4 strony.

Nawet podczas prowadzenia zwinnego projektu tworzymy dokumentację:

• Cała dokumentacja ma swój koszt.
• Opracowanie w oparciu o ruchome i źle zdefiniowane wymagania na wysokim poziomie wiąże się z pewnymi kosztami.
• Właściwa równowaga do powyższych zależy od twojego projektu, kultury i ludzi.
• Dokumentujemy W samą porę dokumenty stają się nieaktualne.
• Dokumentujemy ledwo / wystarczająco.
• Nie utrzymujemy ani nie aktualizujemy tych dokumentów, nie wkładamy w to wiele wysiłku. One są małe. Spodziewamy się ich wyrzucić.
• Eliminujemy wielkie niewiadome, takie jak decyzje technologiczne, mgliste wymagania i architektura z góry.
• Wiemy, co rozwijamy, zanim zaczniemy.
• Ufamy programistom podejmowanie świadomych decyzji dotyczących dokumentacji i omawianie wszelkich problemów.
• Cenimy komunikację zamiast dokumentacji, dlatego oczekujemy, że wszyscy zaangażowani będą się często komunikować.
• Systemy (przegląd) dokumentujemy po opracowaniu, a nie w trakcie, nie wcześniej.

Widzisz, w naszym zwinnym procesie jest mały wodospad.

Jeśli pracujesz sam, stwórz model z góry (schemat!), Baw się i wybierz technologię, a następnie, gdy masz koncepcję wysokich wymagań, biegnij dalej i rozwijaj zwinnie iteracyjny sposób, ale rozważ dobre zasady i spójność w miarę przemieszczania się i trzeba będzie ponownie rozkładać mniej, więcej zmieniać na bieżąco.

Ale ogólnie, jeśli wiąże się to z prawdziwymi kosztami (nie hobby), wiedz, co rozwijasz, zanim napiszesz kod, ale nie marnuj zbyt wiele czasu na pisanie dokumentacji, która szybko się zwolni, gdy zmienisz zdanie i powinieneś zmień zdanie podczas rozwoju, gdy będziesz lepiej poinformowany. Twój projekt może znacznie zmienić kurs, ale zacznij od dobrego, dobrze określonego fundamentu.

Z grubsza tak rozpoczynam nowe projekty i działa całkiem dobrze, zakładając, że mówimy o małych projektach. Na przykład nie wybrałbym tej drogi, gdybym pisał ORM lub coś takiego. Czasami uciekam się do bardziej formalnych badań, kiedy naprawdę jestem nad głową. Ale w większości zaczynam pisać kod i widzę, co się stanie. Musisz jednak być przygotowany na wyrzucenie dużej ilości kodu.