Jest cytat często przypisywany Albertowi Einsteinowi, który bardzo mi się podoba (i jestem pewien, że najbardziej lubię):
Wszystko powinno być jak najprostsze, ale nie prostsze.
Jest pewne dochodzenie, czy to powiedział, czy nie, ale kwestia pozostaje bez względu na to, kto to powiedział.
Łatwo jest wziąć ten pomysł i zastosować go do rzeczy, które robimy w życiu codziennym, których nie chcemy robić, prawda?
- Nie chcę sprzątać swojego pokoju, więc posprzątam go wystarczająco.
- Wykonam tylko tyle pracy, żeby zadowolić klientów i to wystarczy.
- Wypełnię [jakąkolwiek odpowiedzialność] w [najniższym możliwym stopniu], a ponieważ Einstein [rzekomo] to powiedział, kim jestem, by się spierać.
Mimo że się z tym nie zgadzam (a dyskusja na ten temat wykracza poza zakres tego postu), rozważam ten pomysł w kontekście tworzenia stron internetowych.
I żeby było jasne, nie mówię o projektowaniu stron internetowych. Nie jestem projektantem. Nie chcę mówić w imieniu czegoś, czego nie jestem częścią. Ale jeśli chodzi o dostarczanie rozwiązań dla osób korzystających z oprogramowania, a raczej tworzenia stron internetowych, jestem o wiele bardziej skłonny i przygotowany do rozmowy o tym.
Ściśle mówiąc, często zastanawiam się, czy zrobiliśmy tworzenie stron internetowych bardziej skomplikowanym (i dlaczego to zrobiliśmy) i czy użycie najprostszej rzeczy, która jest potrzebna, jest wszystkim, co jest naprawdę potrzebne przy tworzeniu rozwiązań dla innych.
Najprostsza rzecz, jaka jest potrzebna
Niedawno pisałem o różnych aspektach samego front-endowego rozwoju (w kontekście szybkiego wyciągnięcia czegoś z domu) i o tym, jak teraz mamy narzędzia do budowania wyłącznie dla tego aspektu stosu programistycznego.
Jeśli chodzi o takie narzędzia, niezależnie od tego, na jakim poziomie stosu pracujemy, zadaję sobie pytanie:
Czy ta użyteczność jest niezbędna do skutecznego i pozytywnego ułatwienia opracowania rozwiązania dla kogoś innego?
Na przykład uważam, że Composer jest bardzo przydatny. Pozwala mi łatwo zarządzać bibliotekami innych firm, aktualizować je w razie potrzeby i włączać je do moich projektów.
Podobnie uważam, że narzędzia, które sprawdzają moje zatwierdzenia przed wysłaniem ich do GitHub, są przydatne, ponieważ pozwalają mi wychwycić problemy z jakością kodu, które w przeciwnym razie zajęłyby więcej czasu podczas procesu przeglądu kodu.
Weźmy jednak na przykład niektóre narzędzia do kompilacji frontonu, takie jak Grunt, Gulp, Yarn, Node, Mix i tak dalej. Żeby było jasne, niektóre z nich robią to samo, co inne, podczas gdy inne służą innym celom.
Punkt, nad którym pracuję, jest następujący:
W którym momencie narzędzia, których używamy do rozwoju, utrudniają nam tworzenie czegoś i skuteczne dostarczanie czegoś?
W naszej dziedzinie jest coś, co sprawia, że czujemy potrzebę pozostania na krawędzi technologicznej. Ale myślę, że należy dokonać ważnego rozróżnienia: jedną rzeczą jest być świadomym narzędzia, a jedną rzeczą jest go używać.
Świadomość
Wspaniałą rzeczą w wiedzy, że coś jest dostępne, jest możliwość zbadania tego i ustalenia, czy jest to dla nas przydatne.
To nie jest przełomowy ani nowy pomysł, ale myślę, że niektórzy z nas omijają to. Zamiast badać i oceniać, często go pomijamy i sprawdzamy, jak szybko możemy z niego korzystać.
Oddanie go do użytku
Zaletą oddania czegoś nowego do użytku jest to, że uzyskujemy korzyści – lub oczekiwane korzyści – które wspomniana użyteczność ma zapewnić.
Niebezpieczeństwo polega na tym, że narzędzie może nie być dostępne za sześć miesięcy, rok, a nawet dwa lata, a technologie, które ma ulepszyć, mogą się zmienić, gdy nie dotrzyma kroku.
Dlatego ważne jest, aby być świadomym tej użyteczności, jednocześnie określając, czy jest ona przydatna.
O tej prostocie
Wracając jednak do mojego pierwotnego punktu, jest tak: jeśli czas potrzebny na skonfigurowanie, nauczenie się, opracowanie, wdrożenie i korzystanie z nowego narzędzia w ramach przepływu pracy, myślę, że warto zastanowić się, czy jest to naprawdę warte czas w twoim stosie narzędzi.
Klienci nie będą dbać o to, czy używasz dowolnego narzędzia, z którego korzystasz. Ufają, że jesteś dobrym zarządcą rozwiązania, za wdrożenie którego ci płacą, i częścią tej odpowiedzialności za bycie mądrym i sumiennym w swoim czasie.
Jeśli narzędzie, z którego korzystasz, w jakikolwiek sposób utrudnia wspomnianą odpowiedzialność, może nie być opłacalne w danym projekcie.
I ostatecznie to sprowadza się do mnie: jeśli to, czego używam, pomaga mi zbudować najlepsze możliwe rozwiązanie, a nie robię tego kosztem klienta, to prawdopodobnie warto z niego skorzystać. W tym celu często wystarczy najprostszy zestaw narzędzi i nic więcej.
W przeciwnym razie warto rozważyć zastosowanie w przyszłym projekcie, ale nie w czasie klienta.