Czym jest „proof of concept”?

Wiesz, że jest teraz nowsze, w formie wideo, wyjaśnienie tego tematu na moim kanale Youtube? O pod tym linkem: https://youtu.be/V03LR64Uco4

Nieraz w pracy będziesz spotykać się ze wspomnianym w tytule „proof of concept”. Zwykle będzie to w kontekście jakiejś nowej funkcji, biblioteki czy algorytmu. Więc dzisiaj wpis w stylu słownika programisty.

Proof of Concept (w skórcie PoC) to w dużym skrócie implementacja jakiegoś rozwiązania, która ma za zadanie udowodnić, że to co chcemy wprowadzić ma sens, spełnia nasze oczekiwania i jest możliwe do zrealizowania.

Z założenia PoC jest rozwiązaniem tymczasowym i pisanym jak najszybciej. Bo kiedy spełni swoje zadanie czyli pokaże klientowi jak może działać nowa funkcja albo da odpowiedź na pytanie czy rozważane rozwiązanie ma prawo zadziałać jest zastępowane docelową implementacją.

Po co?

Ale po co pisać kod, który z góry jest skazany na wyrzucenie?

Odpowiedź jest dosyć prosta – takie podejście daje szansę zminimalizować ewentualny stracony czas w momencie kiedy okaże się, że rozwiązanie jakie chcemy użyć nie jest tym co spełnia nasze oczekiwania. Lepiej jest poświęcić 1 dzień i wyrzucić powstały, daleki od doskonałości kod niż spędzić tydzień nad dopieszczaniem całości i idealnym wpasowaniem w projekt po czym wyrzucić tą pracę bo nie działa tak jak chcemy.

Nie zawsze ma to sens

Ten sposób pracy oczywiście nie sprawdza się zawsze. Przede wszystkim nie ma sensu robić proof of concept w sytuacji kiedy robimy coś co jest bardzo podobne do rozwiązań jakie już mamy. Tak samo PoC traci sens jeśli docelowe rozwiązanie możemy zaimplementować równie szybko.

Kolejnym czynnikiem negującym sens PoC jest jakość kodu w naszym projekcie i podejście szefostwa do tejże. Bo jak cały kod jest pisany na wyścigi to pisząc PoC w sumie robimy kod produkcyjne ;)

Kiedy warto?

Proof of Concept warto rozważyć wtedy kiedy rozwiązanie jakie mamy dodać jest potencjalnie duże. Tzn. wymaga np. czasochłonnej integracji czy łączenia z obecnym kodem w bardzo wielu miejscach. Tak samo warto robić PoC kiedy proponujemy coś zupełnie nowego. Np. nowy framework albo bibliotekę. Wtedy takie PoC może być nawet osobną aplikacją, która pokazuje tylko rozwiązanie tego jednego problemu, dla którego ten framework albo biblioteka zostały wybrane.

Więc ceniąc swój czas i mając pracodawcę, który rozumie, że nowe rozwiązania wymagają sprawdzenia zdecydowanie polecam robienie PoC.

Może ono mieć postać napisanego bardzo szybko i bez zbędnej dbałości o jakość kawałka w projekcie. Wtedy zwykle robimy w repozytorium nową gałąź na niego. Innym rozwiązaniem jest zrobienie osobnej, niewielkiej aplikacji. Nie musi ona mieć np. docelowego interfejsu czy wszystkiego naokoło. Ma po prostu skorzystać z proponowanego podejścia w taki sposób żeby uwzględniać problem jaki mieliśmy do rozwiązania. Czyli przykładowo jeżeli wybieramy bibliotekę do supertabel na stronie to po prostu zrobimy sobie prostą aplikację webową, która będzie mieć tylko tą tabelę z danymi takimi samymi jak w bazie danych ale chociażby wpisanym ręcznie (chyba, że ta biblioteka miała rozwiązać problem wydajności przy dużej bazie danych wtedy oczywiście te dane możemy zaciągać bezpośrednio. Po prostu chodzi o ideę minimalizowania dodatkowej pracy).