Technika blah

Technika blah


Ile razy zastanawiałeś się jaką nazwę nadać? Zawsze chciałbyś posługiwać się językiem wszechobecnym, ale on nie istnieje od początku tylko powstaje z czasem. Wobec tego pojawia się problem, bo jak nazywać rzeczy gdy jeszcze nie wiesz jak maja być nazwane i do tego je zakodować? Na szczęście jest na to rozwiązanie – technika blah.

Czym jest technika blah

W dużym skrócie technika blah polega na tym ze zamiast wymyślać na siłę jakąś nazwę, stosujesz nazwę abstrakcyjną w ogóle nie powiązaną z tym co robisz a nawet jeszcze lepiej, nie związaną z programowaniem. Aby ją zastosować wystarczy tylko kilka kroków:

  • wybierz nazwę i używaj jej w każdym miejscu
  • stwórz task na zmianę nazwy
  • ustaw datę spotkania na temat wyboru odpowiedniej nazwy

Nazwa

Nazwa powinna być abstrakcyjna i nie powiązana z domeną w której pracujesz. Również nie powinna narzucać żadnych skojarzeń abyś mógł później na podstawie zachowania wybrać odpowiednią nazwę. Na pewno złymi nazwami w tej technice są

  • user
  • manager/management
  • worker
  • common/util

Możesz zadać sobie pytanie dlaczego? Z jednego prostego powodu. Jeśli nadasz czemuś nazwę, z którą masz jakieś skojarzenia, to podświadomie będziesz starał się dopasować zachowanie do tej nazwy. Głównym założeniem techniki blah jest to aby być wolnym od jakichkolwiek skojarzeń. Dzięki temu finalna nazwa będzie bardzo dobrze pasować do zachowania.

Czy jeśli coś chodzi jak kaczka i kwacze jak kaczka, to czy jest kaczką?

Dobrymi nazwami które możesz użyć to tytułowe blah, ale oprócz tego

 Właściwie nie masz tu ograniczeń. Gdy już wybrałeś swoją nazwę, używaj jej w kodzie a także w rozmowach, opisach tasków, na daily i wszędzie gdzie to będzie potrzebne. Z tego powodu w Twoim kodzie pojawią się między innymi:

  • BlahController
  • BlahService
  • BlahEntity/BlahRepository
  • BlahAggregate

Mogą one być zlokalizowane w module, pakiecie blah i posiadać metody

createBlah();
getBlahId();

Ta sama nazwa pojawia się w bazie, eventach, twoim CI i CD i innych elementach infrastruktury. Ważne aby nazwa była w całym kodzie spójna. Dzięki temu później łatwo znajdziesz elementy, które musisz zrefaktoryzować i nadać już ostateczną nazwę. Oczywiście musisz używać tej nazwy podczas rozmów technicznych między developerami ale także z businessem i ekspertami dziedzinowymi. Na pewno każdego zaciekawi o czym mówisz.

Technika blah
Technika blah

Task

W zależności na jakim poziomie próbujesz wybrać nazwę, to ten czas może zając od kilku dni do nawet kilku sprintów. Im dłuższy czas tym łatwiej się przyzwyczaić do tej nazwy i zapomnieć o jej zmianie. Aby temu zapobiec w momencie rozpoczęcia prac stwórz taska, na rename i nadaj mu dosyć wysoki priorytet. Kolejną ważną kwestią jest to, że nie możesz zrobić tego zadania, dopóki nie odbędzie się spotkanie na którym wybierzecie finalną nazwę. Później refactor będzie prostą rzeczą.

Spotkanie

Po pierwsze termin spotkania musisz ustalić na taki okres gdy będziesz wiedział ze funkcjonalność będzie już prawie skończona. Dzięki temu łatwo opiszesz co Twoje blah robi a uczestnicy skupią się na wybraniu odpowiedniej nazwy. Jeśli planujesz, że cala implementacja zajmie więcej niż jeden sprint, to zrób taska aby przypomniał Ci o zorganizowaniu spotkania. Na spotkaniu powinny być osoby zaangażowane w funkcjonalność oraz ci, których to interesuje. Jeśli wybrana ma być jakaś nazwa biznesowa a nie tylko techniczna to również biznes powinien być obecny na tym spotkaniu.


Spotkanie polega na tym, ze opisujesz co zrobiłeś używając jeszcze Twojej nazwy blah, jakie ma to zachowanie i czym to jest. Dzięki temu, że nie masz żadnej konkretnej nazwy, można to porównać do tego jak opisujesz dziecku coś skomplikowanego. Nic nie stoi na przeszkodzie abyś zasugerował jakaś nazwę. Jednak ostateczna nazwa powinna być wybrana wspólnie, najlepiej po dyskusji. Bardzo często dużym zaskoczeniem dla uczestników spotkania jest to, że nazwa którą ktoś wymyślił na początku, jest całkowicie niepoprawna. Co więcej nazwa którą wybierzecie, jest dużo lepsza z biznesowego i technicznego punktu widzenia. Po spotkaniu zostaje Ci już tylko zrobić refactor blah na docelowa nazwę i zamknąć taska.

Kiedy stosować

W teorii nie ma ograniczeń kiedy stosować tą technikę. Właściwie możesz nawet na poziomie zmiennej lokalnej tylko że to nie ma za bardzo sensu. Ale sens już jest w momencie gdy rozmawiasz o pakiecie, module, mikroserwisie lub gdy modelujesz domenę i nie masz nazwy na swój agregat. Dla tych elementów technika blah daje największe korzyści.

Technika blah czy warto

Gdy nie masz żadnych wątpliwości jak coś nazwać lub tworzysz prostego CRUDA to wtedy nie warto stosować tej techniki. Jednak gdy Twoja domena jest skomplikowana, dopiero ją odkrywasz lub nie potrafisz łatwo nazwać funkcjonalności, to wtedy warto abyś rozważył tą technikę. Technika blah sprawi że nazwa którą wybierzesz będzie odpowiednia i dokładnie określała co znaczy. Także każdy będzie jej używał świadomie a o to też chodzi w ubiquitous language.

A czy ty stosowałeś tą technikę? Może masz jakiś inny sposób na wybieranie prawidłowych nazw?