Jaki jest najlepszy Programista React?

Co czyni inżyniera naprawdę godnym uwagi?  W ciągu ostatnich 5 lat miałem zaszczyt pracować z różnymi ludźmi — od świeżej, młodej krwi po weteranów tej branży. Jednak mało jest osób, które chcą przyjrzeć się czemuś dokładniej.

Podzielę się dzisiaj z wami historią jednego z najlepszych inżynierów, którego miałem okazję poznać. Najlepsze w tym wszystkim jest to, że zdałem sobie z tego sprawę dopiero po jego odejściu z firmy.

No to zaczynajmy.

Nie był jednym z najszybszych

Swego czasu firmie zależało, aby pojawiały się comiesięczne aktualizacje. Już pod sam koniec sprintu, pojawiło się nowe wymaganie, aby stworzyć niewielki mechanizm autoryzacji we frontendzie, oparty na rolach.

Ponieważ kod backendu już istniał, kierownictwo chciało to już zamieścić w kolejnym wydaniu.

Ów inżynier nie poszedł jednak na te warunki, a kierownictwo nie było z tego zadowolone.

Byłem wtedy juniorem i w mojej głowie pojawiło się pytanie: dlaczego tak się zachował?  Z tego co zrozumiałem, było to do wykonania w ciągu dwóch dni. On jednak stanowczo odmówił.

Nie chodzi tylko o szybkość.

W kulturze startupów taki rodzaj pospiesznej pracy stał się już normą, jednak w późniejszym etapie mojej kariery zdałem sobie sprawę, że tak naprawdę inżynier, o którym opowiadam, miał rację. Może w 99% przypadków takie praktyki nie są szkodliwe, jednak pozostały 1% może zaszkodzić firmie, a czasami nawet konkretnej karierze!

Jego kod czytało się jak poezję

Już dużo później, po jego odejściu z firmy (przez jakiś konflikt z kierownictwem), miałem zaszczyt pracować nad jego projektem.

Trochę wstyd, ale nie potrafiłem zrozumieć własnego kodu (gdybym spojrzał na niego po 3-4 miesiącach), natomiast jego kod był tak piękny, że taki junior, jak ja nie miał absolutnie żadnego problemu ze zrozumieniem co się w nim dzieje.

Tutaj przykład.

export const SomeComponent = () => {
  
  const userInfo = getUserInfo();
  
  const profileDetails = getProfileDetailsOfUser(userInfo.id);
  
  const aboutData = extractAboutData(profileDetails);
  
  const personalData = extractPersonalData(profileDetails)
  
  return (
    <UserDetails>
      <About data={aboutData} />
      <PersonalInfo data={personalData} />
    </UserDetails>
  )
}

Trudno to docenić w 3-minutowym artykule, ale kiedy zaczniesz pracować nad projektem z setkami komponentów, ten kawałek kodu przyniesie ci błogość i spokój ducha.

Zależało mu na najlepszych praktykach

To właśnie dzięki niemu zrozumiałem, jak ważne jest przestrzeganie najlepszych praktyk. Są one trudne do zrozumienia dla juniora, ale w miarę upływu czasu zrozumiałem, jak trzymanie się najlepszych praktyk automatycznie pomaga w pisaniu czystszego kodu.

Miał rozbudowaną konfigurację Eslint.  Pamiętam, że było tam jakieś 30-35 zasad i wielu z nich nawet wtedy nie rozumiałam.

Robił rzeczy po swojemu

Jedną z rzeczy, która mnie dziwiła w jego kodzie, była jego gadatliwość. Nazywał funkcje w wyjątkowy, ale konsekwentny sposób.

Pozwolę sobie podać bardzo prosty przykład. Bardzo często potrzebujemy posortować tablicę obiektów, prawda? Szybkie wyszukiwanie w Google dałoby coś takiego, a my po prostu zmienilibyśmy nazwę właściwości.

sortedArray = objs.sort((a,b) => (a.last_nom > b.last_nom) ? 1 : ((b.last_nom > a.last_nom) ? -1 : 0))

Ale nie w jego przypadku. Zrobiłby mniej więcej coś takiego.

function compare( a, b ) {
  if ( a.last_nom < b.last_nom ){
    return -1;
  }
  if ( a.last_nom > b.last_nom ){
    return 1;
  }
  return 0;
}

objs.sort( compare );

Oba kody robią dokładnie to samo, ale przy jego sposobie kodowania nie musiałbym patrzeć na kod przez 2 minuty, próbując zrozumieć, co się w nim dzieje. Tak, jak w przypadku mojego kodu.

Później w mojej karierze zrozumiałem, że znaczące nazwy są ważniejsze niż redukcja dwóch linijek Twojej bazy kodu.

Na dłuższą metę wszystko sprowadza się do możliwości utrzymania i redukcji długu technologicznego. I on był w tym mistrzem.

Był przeciwny zmianom

Po tym jak hooki weszły już w życie, cała społeczność rzuciła się w kierunku refaktoryzacji swojej bazy kodowej w funkcjonalne komponenty. Ale on nam na to nie pozwolił.

Tak, wtedy nie był to może dobry pomysł, bo teraz prawie każda nowa baza kodu jest pisana z komponentów funkcjonalnych, ale mimo to chciał, żebyśmy poczekali.

Każda nowa technologia/biblioteka jest jak nowa, błyszcząca zabawka. Każdy chce się nią bawić. Od czasu do czasu pojawia się jakaś nowa biblioteka i zastanawiamy się, jak możemy ją wykorzystać w projekcie.

Jednak prawie za każdym razem odmawiał ich dodania. Muszę przyznać, że momentami czułem się lekko poirytowany. Czasem nawet myślałem, że odmawia może dlatego, bo sam nie wie jak z nich korzystać.

Z czasem stało się jasne, że był on świadomy nowych zmian, ale bardzo ostrożnie do nich podchodził. Rozumiał, że dodawanie czegokolwiek i wszystkiego ma swój koszt, szczególnie w świecie JavaScript.

Odszedł

Po 6-7 miesiącach zmienił pracę przez jakiś konflikt z kierownictwem.

Projekt, który prowadził, trafił w moje ręce. Zacząłem przeglądać jego kody, a później zdałem sobie sprawę, jaki był niesamowity. Na pozór wykonywaliśmy tę samą pracę. Dostarczaliśmy funkcje, które były wymagane.

Ale to, co zrobił wewnątrz kodu, po prostu zwaliło mnie z nóg. Od struktury folderów po nazewnictwo zmiennych. Dbałość, jaką wkładał w każdą linijkę kodu, sprawiła, że zakochałem się w programowaniu. Zdałem sobie sprawę, że:

Dobry kawałek kodu to kwestia piękna!

I nadal kieruję się tą filozofią.

Wnioski

Gdy pracowaliśmy razem, nie zawsze się ze sobą zgadzaliśmy. Może nie miał racji przez cały czas, może miał jakieś problemy z wyrażaniem siebie, ekspresją, przez co nie był za bardzo lubiany.

Niemniej jednak jest on najwspanialszym programistą Reacta (a może i najwspanialszym programistą w ogóle), jakiego do tej pory spotkałem.

A czy Ty znasz kogoś takiego?