18.07.20237 min
Michael Long

Michael LongSenior Lead iOS Engineer

Ułomność anegdotycznego rozwoju oprogramowania i jak je przerwać

Dowiedz się, czym jest anegdotyczny rozwój oprogramowania, jakie są jego skutki i jak odwrócić taką tendencję.

Ułomność anegdotycznego rozwoju oprogramowania i jak je przerwać

Co w sytuacji, kiedy nie ma uniwersalnych rozwiązań?

Anegdotyczne tworzenie oprogramowania definiuje się jako nadmierne poleganie na osobistych doświadczeniach lub opiniach podczas projektowania i tworzenia oprogramowania.

Zakładam, że nigdy wcześniej o tym nie słyszałeś, ale właśnie w ten sposób większość ludzi pisze i rozwija oprogramowanie. A jeśli się nad tym zastanowić, to jak mogłoby być inaczej?

Jak inaczej moglibyśmy to zrobić? Jak inaczej możemy pisać oprogramowanie, jeśli nie w oparciu o własną edukację, własne umiejętności i własny warsztat?

Istnieje odpowiedź na to pytanie, ale najpierw zastanówmy się nad niektórymi niebezpieczeństwami, które się za tym kryją.

Niebezpieczeństwa

Spójrzmy jeszcze raz na definicję:

Anegdotyczne tworzenie oprogramowania definiuje się jako nadmierne poleganie na osobistych doświadczeniach lub opiniach podczas projektowania i tworzenia oprogramowania.

W czym tkwi problem?


Po pierwsze

Anegdotyczne dowody, jakiekolwiek, zwykle nie są prawdziwie reprezentatywne dla większej populacji lub grupy. Jest to wiedza oparta przede wszystkim na osobistych obserwacjach, często gromadzonych w sposób przypadkowy lub niesystematyczny. (Stack Overflow, jest tu ktoś?)

W związku z tym opieranie decyzji dotyczących rozwoju oprogramowania wyłącznie na osobistym doświadczeniu może nie odzwierciedlać dokładnie potrzeb lub preferencji projektu lub jego użytkowników. Może to prowadzić do powstania oprogramowania, które jest źle zaprojektowane, trudne w użyciu lub nieprzydatne dla znacznej części docelowych odbiorców.


Po drugie

Niepotwierdzone dowody są podatne na błędy i odchylenia.

Gdy twórcy oprogramowania polegają wyłącznie na własnych doświadczeniach, mogą być pod wpływem własnych uprzedzeń czy też wspomnień, co może prowadzić do błędnego lub niepełnego zrozumienia danego problemu.

I wreszcie, poleganie na niepotwierdzonych dowodach w rozwoju oprogramowania może prowadzić do braku transparentności i odpowiedzialności.

Kiedy decyzje opierają się na osobistych doświadczeniach, a nie na danych empirycznych, może być trudno uzasadnić lub wyjaśnić te decyzje innym. To z kolei może powodować problemy w zakresie komunikacji, współpracy i podejmowania decyzji w zespole programistów, a także z interesariuszami lub klientami.

To wszystko z pewnością może być problematyczne, ale bardziej martwi mnie sam proces tworzenia oprogramowania. Co dzieje się pod maską?

Zacznijmy więc od przykładu.

Testy jednostkowe

Czytałem ostatnio wiele artykułów i komentarzy na temat tego, co dokładnie stanowi „najlepszą praktykę” w tworzeniu oprogramowania. Opinie zazwyczaj są podzielone, a czasami sekcje komentarzy stają w ogniu.

Weźmy na przykład praktykę programistyczną znaną jako testowanie jednostkowe.

Jeśli nigdy tego nie robiłeś, nigdy tego nie praktykowałeś lub nigdy nie pracowałeś w organizacji, która tego wymagała, to testy jednostkowe mogą wydawać się stratą czasu, energii i zasobów.

A jeśli twój punkt widzenia należy do tej drugiej kategorii, to dzielenie kodu na odrębne widoki i modele widoków również może wydawać się niepotrzebne.

W końcu jedną z głównych korzyści płynących z takiego działania jest przeniesienie logiki biznesowej poza widok do miejsca, w którym można to zobaczyć i przetestować. Ale jeśli nie testujemy, to po co podejmować dodatkowy wysiłek?

To samo dotyczy korzystania z systemu lub strategii wstrzykiwania zależności. Chodzi tutaj o zmniejszenie sprzężenia i ponownym ułatwieniu testowania i mockowania obiektu. Ale jeśli nie testujemy, to powtarzam jeszcze raz, po co podejmować dodatkowy wysiłek?

Wracając więc do naszego tematu, jeśli osobiście nie widzisz takiej potrzeby - i jeśli stanowi to twój główny argument, aby tego nie robić - to angażujesz się w anegdotyczny rozwój oprogramowania.

Nie robię tego. Nigdy tego nie robiłem. Moja firma tego nie robi. Więc raczej nie jest to potrzebne.

A każdy, kto myśli inaczej, jest idiotą.

Można też odwrócić ten argument. Jeśli zawsze to robiłeś lub jeśli pracujesz w środowisku medycznym lub finansowym, które ma wymagania dotyczące testowania i pokrycia kodu, to prawdopodobnie również będziesz miał trudności z rozważeniem sytuacji w startupie lub podczas tworzenia aplikacji proof-of-concept, w której może to nie być uzasadnione.

Obie strony cierpią na anegdotyczną ułomność rozwoju oprogramowania.

Wpadasz w pułapkę, gdy mówisz: „No cóż, nigdy nie robiłem tego w ten sposób...”; lub tego biegunowe przeciwieństwo: „Zawsze robiłem to w ten sposób...”; lub nawet po prostu: „Z mojego doświadczenia...”

Anegdoty.

Uniwersalne rozwiązanie

W ciągu ostatnich kilku dekad praktykujący tworzenie oprogramowania i inżynierii oprogramowania stworzyli wiele najlepszych praktyk i zasad, takich jak SOLID, DRY i tym podobne. Stworzyliśmy architektury takie jak MVVM, Clean, VIPER i wiele innych.

Te praktyki są często oparte na zgromadzonej wiedzy i doświadczeniu ekspertów w danej dziedzinie i zostały zaprojektowane, aby pomóc programistom osiągnąć najlepsze możliwe wyniki.

Jednak najlepsze praktyki, frameworki i architektury nie są sztywnymi zasadami.

Można je wykorzystać jako punkt wyjścia lub przewodnik, ale należy je również dostosować i opracować w razie potrzeby, aby jak najlepiej odpowiadały potrzebom konkretnego projektu i zespołu.

Mamy tu jednak szerszy obraz, który uważam, że trafia do sedna problemu.

Nie ma uniwersalnych rozwiązań.

Aplikacja z listą zakupów nie jest zbudowana na taką samą skalę jak aplikacja do obrotu finansowego. Firma z jednym zespołem deweloperów, lub nawet tylko z jednym deweloperem, boryka się z innym zestawem problemów niż firma z wieloma zespołami pracującymi nad wieloma funkcjami jednocześnie.

Aplikacja bankowa działa w oparciu o inny zestaw zasad, ograniczeń i wymogów prawnych niż aplikacja Sudoku.

Jeśli pracowałeś głównie nad mniejszymi aplikacjami, to ilość modularyzacji i hermetyzacji zwykle wymagana w przypadku aplikacji komercyjnej z pół tuzinem zespołów może wydawać się ciężka, przesadzona i całkowicie niepotrzebna.

A jeśli wpadnie Ci w ręce artykuł opowiadający się za takim podejściem, to od razu podziękuj. „Dlaczego miałbyś to robić? Nigdy nie musiałem tego robić!”

Anegdoty.

Jeśli więc anegdotyczny rozwój oprogramowania jest problemem, to jakie jest jego rozwiązanie?

Na to pytanie mamy kilka odpowiedzi.

Współpraca

Współpraca może wnieść do procesu rozwoju różne perspektywy i wiedzę specjalistyczną. Współpracując z innymi osobami o różnym pochodzeniu, doświadczeniu i umiejętnościach, programiści mogą korzystać z szerokiej gamy pomysłów i podejść, co może skutkować bardziej kreatywnymi i skutecznymi rozwiązaniami.

Współpraca może również pomóc w skuteczniejszym identyfikowaniu i rozwiązywaniu problemów. Współpracując ze sobą, programiści mogą dzielić się wiedzą i zasobami, a także pomagać sobie nawzajem w rozwiązywaniu pojawiających się problemów.

To w tym momencie dzielisz się swoim doświadczeniem. Twoim punktem widzenia.

Mówiąc krótko, mając zróżnicowany zespół, przechodzimy ze sfery indywidualnych, osobistych anegdot do krainy konsensusu.

Do tego dochodzi z kolei...

Edukacja

Edukacja może pomóc programistom w głębszym zrozumieniu zasad tworzenia i projektowania oprogramowania. Zdobywając i rozumiejąc solidne podstawy, możemy być lepiej przygotowani do podejmowania świadomych, opartych na dowodach decyzji podczas procesu rozwoju.

Nie wystarczy jednak wymienić pięciu zasad stojących za SOLID. Musimy również wiedzieć, dlaczego te zasady istnieją. Jakie problemy próbowali rozwiązać?

Jeśli rozumiemy, jak działają poszczególne elementy, jesteśmy w stanie lepiej ocenić ich przydatność w danym projekcie. Jesteśmy w stanie przedyskutować i rozważyć te wytyczne oraz znaleźć między nimi kompromisy.

Edukacja w obszarach innych niż rozwój oprogramowania może również pomóc w poszerzeniu horyzontów. Wprowadzając nowe pomysły, koncepcje i perspektywy, programiści mogą poszerzyć swoje rozumienie świata i swojego miejsca w tym świecie.

Rozwój oprogramowania nie odbywa się przecież w próżni.

Ponadto, specjaliści od oprogramowania powinni być proaktywni w poszukiwaniu możliwości uczenia się i poszerzania swojej wiedzy. Może to wiązać się z zaangażowaniem w społeczność programistów, uczestnictwem w konferencjach i warsztatach oraz udziałem w bieżących szkoleniach i możliwościach rozwoju zawodowego.

Współpraca i edukacja są ważne, ale w gruncie rzeczy obie opierają się na jednej podstawowej wartości.

Otwartość umysłu

Bycie otwartym na nowe pomysły jest ważnym aspektem uczenia się i poszerzania wiedzy w każdej dziedzinie, w tym w tworzeniu oprogramowania.

Będąc otwartymi na nowe pomysły, twórcy oprogramowania i inni specjaliści mogą pogłębić swoje zrozumienie i perspektywę oraz mogą lepiej przystosować się do nowych technologii i metod w miarę ich pojawiania się.

Inżynieria oprogramowania stale ewoluuje wraz z rozwojem i przyjmowaniem nowych technologii i podejść. Ewolucja ta może być spowodowana różnymi czynnikami, w tym zmianami potrzeb i preferencji użytkowników, zmianami w środowisku biznesowym, a nawet po prostu postępem w dziedzinie sprzętu komputerowego i oprogramowania.

I paradygmaty się zmieniają.

SwiftUI jest pod tym względem przykładem, ponieważ wiele najlepszych praktyk, które kiedyś mieliśmy lub które zostały opracowane dla innych platform i innych języków, po prostu nie działa dobrze w środowisku SwiftUI.

Jeśli jednak wiemy, w jaki sposób zaprojektowano architekturę i jakie problemy próbowano rozwiązać, a także jeśli rozumiemy, jak działa SwiftUI i jak zarządza widokami i aktualizacjami, jesteśmy w stanie lepiej ocenić przydatność danego podejścia lub praktyki.

Zwłaszcza jeśli weźmiemy pod uwagę pytania z szerszej perspektywy:

  • Jak duża jest aplikacja?
  • Na czym polega złożoność?
  • Jakie są ramy czasowe?
  • Jak duży jest zespół?
  • Jaki jest nasz cykl wydawniczy?
  • Jakie mamy dodatkowe wymagania i ograniczenia?


Wszystkie te kwestie należy rozważyć i wziąć pod uwagę. 

Podsumowanie

Czy zatoczyliśmy pełne koło? Praktykowanie powyższego pogłębia wiedzę i doświadczenie, ale czy po raz kolejny rozwijamy się tylko w oparciu o naszą osobistą wiedzę i doświadczenia? No więc.. i tak. I nie.

Ponieważ teraz - miejmy nadzieję - działamy w oparciu o wspólną wiedzę i wspólne doświadczenia. Opieramy się na zgromadzonej wiedzy i mądrości ekspertów w naszej dziedzinie.

Zdajemy sobie sprawę, że nasza wiedza w danej dziedzinie może być w pewien sposób ograniczona i że zawsze powinniśmy starać się ją poszerzać. Jesteśmy świadomi faktu, że najlepsze praktyki, procesy i narzędzia ewoluują i zmieniają się w czasie, a jeśli wiemy dlaczego, możemy ocenić ich przydatność dla danego projektu. Gdzie pasują. Gdzie nie pasują. I gdzie należy je dostosować.


Oryginał tekstu w języku angielskim przeczytasz tutaj.

<p>Loading...</p>