Co z tą Kohaną, czyli słów kilka o nieprogramowaniu

Zakohanie to taki dziwny stan, bo Kohana to dziwny framework. Korzystanie z niego wywołuje stan, w którym niczym kreskówkowy król Julian powtarzasz sobie „szybko, szybko, zróbmy to, zanim okażę się, że to kompletnie bez sensu”.

Gdy zacząłem pisać ten wpis, na webMASTAHu pojawił się już pierwszy artykuł dotyczący wykorzystania frameworka Kohana. Pomyślałem sobie wtedy, że będzie to ciekawe, gdy okaże się, że w jednym miejscu będzie można znaleźć artykuły promujące framework, a chwilę potem takie, które wręcz namawiają do niekorzystania z niego. Tak – tym wpisem chce sugerować, że jeśli chcesz teraz wybrać framework php do pracy to niech nie będzie to Kohana.

I Ty Brutusie…?

Framework Kohana wykorzystuję od kilku lat, w bardzo różnych projektach. Framework prosty jak budowa cepa, dający swobodę w zaśmiecaniu go swoimi konwencjami i kodem, który później może inspirować do pisania wpisów o staticach. Zostawmy jednak kod.

Kohana to społeczność i projekt, który z pewnych powodów mi się bardzo spodobał. Spodobał do tego stopnia, że postanowiłem obserwować wszystko co się wokół niego dzieje, zbierać informacje o tym co tworzy społeczność, a po drodze powstał fanpage polskiego wsparcia tegoż frameworka, na którym wrzucałem najbardziej interesujące informacje z nim związane. W ten sposób poznałem lub sprawdziłem kilkaset modułów dla Kohany zgromadzonych na githubie, na bieżąco prowadziłem obserwację rozwoju przynajmniej kilku open sourcowych aplikacji, śledziłem forum społeczności i Redmine’a zespołu deweloperskiego.

Wiedziałem, że w przyjdzie taki czas i nadarzy się taka okazja, by podzielić się 3. latami obserwacji projektu informatycznego. Nie myślałem tylko, że z fana projektu stanę się jego krytykiem.

Framework to nie tylko kod

Na temat kodu Kohany można dyskutować długo i namiętnie. Wiadomo, że jest to tylko narzędzie i może być uznane za fajne, lub nie – wszystko jest kwestią potrzeby, celu, czasem umiejętności. Jednak kiedy deweloper, grupa developerów, firma – decyduje się na wykorzystanie określonego narzędzia to zawsze (powiedzmy, że prawie zawsze) zbiera wszystkie za i przeciw. Kalkulujemy i oceniamy jakie skutki może przynieść wykorzystanie frameworka, który wybraliśmy. Chcemy aby był:

  • stabilny i bezpieczny,
  • dobrze udokumentowany,
  • z dobrym wsparciem,
  • dużymi możliwościami technicznymi,
  • tani we wdrożeniu (w zespole jak i projektach),
  • na który jest zapotrzebowanie rynkowe.

Niekoniecznie wybiera się narzędzie z najpiękniejszym kodem i „przekozackimi”, najnowszymi rozwiązaniami programistycznymi, wzorcami, praktykami, etc. Jest bardzo duża różnica w postrzeganiu atrakcyjności danego narzędzia w zależności od miejsca, z którego na nie patrzymy. Programista może podniecać się danym rozwiązaniem, a szefa programisty wcale to już nie będzie kręcić, bo jak mówi klasyk „MVC cię nie wykarmi, fanatyzm Ci ZUSu nie opłaci”.

Kilka prawdziwych historii

Wyobraźcie sobie, że prowadzicie projekt. W pewnym momencie projekt dzielicie na dwie gałęzie i chcecie rozwijać dwie jednocześnie oraz zapewniać dla nich wsparcie. W krótkim odstępie czasu uznajecie jednak, że macie nowe pomysły – pchacie więc je do wersji trzeciej. Dokładnie takie coś przeprowadzili deweloperzy Kohany. W pewnym momencie jednocześnie prowadzonych było pięć wersji frameworka i wszystkie były ze sobą niekompatybilne. Stabilna polityka rozwoju?

Może dołożę jeszcze ciekawy fakt. Niektóre taski przekładane były np. przez 3 lata. Z wersji do wersji. Wydawanie poprawionych wersji polegało w dużej mierze na przenoszeniu problemów do następnej wersji i ewentualnie tworzeniu nowych poprzez aktualnie wprowadzone poprawki. Oczywiście każde wydanie miało swoją wersję dokumentacji, ale żadna nigdy nie została w całości dokończona. Prawdę mówiąc korzystanie z Kohany w wersji 3.x przez dłuższy czas (zwłaszcza na początku) polegało na czytaniu kodu i dochodzeniu samemu co jak działa.

Kolejnym następstwem wielu wydań było to, że społeczność implementowała ogromną ilość modułów, ale w wielu wersjach. Nie można było sobie po prostu ściągnąć modułu, wstawić, odpalić i cieszyć się, że działa. To jeszcze mi dźwięczy w uszach „musisz sobie przepisać” – a więc skupiać się na samym narzędziu, zamiast na tym po co to narzędzie chcemy wykorzystać. Ileż to razy powtarzałem sobie, że przecież nie o to chodzi w korzystaniu z frameworka.

W tym szale i wyżywaniu się programistycznym, deweloperzy wytracali siły na dyskusje o wyższości jednej funkcji nad drugą, a nie myśleli o promocji frameworka, o dbaniu o społeczność, o tworzenie dobrej dokumentacji i zbieranie tego co robi społeczność.

Oczywiście funkcjonowało kilka kanałów komunikacyjnych (skoro tyle wersji to tutaj też nie mogło być inaczej). Tak więc błąd można było zgłosić ircem, na githubie, na forum, w system zarządzania projektem, co oczywiście spowodowało dublowanie się problemów i brak przejrzystości w tym co jest do zrobienia, bo nikt nad tym nie panował. Poza tym zgłaszanie wydawało się bezcelowe, skoro nie można było przewidzieć, czy za chwilę czasami nie będzie nowej wersji. Wiele razy mogłem przeczytać „poczekam z projektem na wersję 3.x.x”. Coraz częściej to czekanie kończyło się przygodą z innym frameworkiem.

Mogło być inaczej

Cyferki się zmieniały w wersjach, a projekt przestał się rozwijać. Tymczasem pojawił się Fuel, Laravel, nowe wersje Zenda i Symfony. Ładnie opakowane, świetnie udokumentowane, wspierane przez firmy/organizacje, w których widać było co to znaczy zarządzenie projektem.

Śmiem twierdzić, że gdyby w pewnym momencie zadbano o społeczność i pomyślano o marketingu projektu to dziś Kohana była by przed wymienionymi frameworkami pod względem popularności. Tak, to śmiała teza, ale według mnie KO mogła wypracować sobie taką pozycję wśród frameworków, jak WordPress wypracował sobie wśród systemów typu CMS. Wystarczyło zrobić jedną wersję, opracować listę modułów i poprowadzić oficjalną stronę z komunikatami i poradnikami. Prosty, przyswajalny szybko kod, kilkaset modułów i dokończona, zadbana dokumentacja zrobiłby swoje.

Dziś i jutro

Na chwilę obecną deweloperzy nie do końca mają plan jak rozwijać dalej framework, nie mają żadnego lidera, który by to wymyślił, ciągle nie zostało zamkniętych i zakończonych wiele zgłoszonych problemów. Po stronie rozwiązań technicznych framework już nie jest „jazzy” (tudzież „trendy”). Niewiele się przy nim dzieje, a po tym co pojawia się w wypowiedziach deweloperów na forum, rewolucji nie będzie.

Porównanie z innymi wygląda bardzo niekorzystnie. Dla mnie nie ma problemu gdy chce jakąś gotową funkcjonalność znaleźć – bo faktycznie przeklikałem te kilkaset modułów, jednak ktoś „świeży” złapię się za głowę i zacznie wyliczać „a np. w Symfony to mogłem to, a w Laravelu to już jest gotowe”. Na co może liczyć w przypadku Kohany? Hmm… „musisz sobie sam napisać”.

Podsumowanie

Framework ma być narzędziem do rozwiązywania problemów, a nie problemem, czy narzędziem do ich tworzenia. Kohana jest idealnym przykładem projektu pokazującego jak brak odpowiedniego zarządzania projektem może spowodować, że z obiecującego, staje się projektem upadającym.

Tak naprawdę Kohana nie ma już dziś żadnej z cech, które wymieniłem pisząc o tym co powinien mieć framework wybrany do pracy. Jeśli ktoś się zastanawia nad poznaniem go – strata czasu. Wiadomo, że projekty w nim stworzone trzeba utrzymywać, ale wykonywanie w nim nowych nie jest najlepszym pomysłem. Szybciej, taniej, wygodniej będzie wybrać inny framework.

Programista, web developer, marketingowiec. Od wielu lat związany z branżą reklamy i mediów. Robi backend, kocha frontend, będąc ewangelistą kilku technologii. Prywatnie minimalista, trochę introwertyk, perfekcjonista. Nie lubi kotów ;)

Send this to a friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL