«Тогда я не понимал его мотивов»: рассказ о лучшем React-разработчике, какого я встречал

Программист Мохаммад Фейсал поделился в блоге историей знакомства с «величайшим», по его мнению, разработчиком. Она интересна тем, что автор понял, насколько крутым был его коллега только после того, как тот покинул организацию. Вот что написал Мохаммад. 

Он работал не на скорость

Было время, когда мы стремились делать релизы каждый месяц. В самом конце спринтерского цикла ввели новое требование — создать небольшой механизм на основе ролей во фронтенде.

Код бэкенда был уже готов, поэтому руководство решило перенести его в следующий релиз, но мой коллега отказался это сделать, чем вызвал недовольство руководителей.

Тогда я был на позиции младшего бэкенд-разработчика и не понимал его мотивов. Из описания стало ясно, что действие займет два дня, но он наотрез отказался его выполнять.

Позже до меня дошло. Дело в том, что работа на скорость стала нормой в культуре стартапов. В 99% случаев такая практика не повредит, но оставшийся 1% может нанести компании колоссальный ущерб, а иногда и карьере специалиста. 

Его код мог понять даже джун

Позже, после того как он ушел из компании, мне передали его проект. Это было честью.

Я вряд ли разберусь в собственном коде, если увижу его через 3–4 месяца, но код моего коллеги был настолько красив, что младший разработчик вроде меня с легкостью понимал, что он делает. Вот его часть:

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>
  )
}

Он придерживался лучших практик 

Будучи джуном, я не понимал, зачем это нужно, но со временем осознал, как следование лучшим практикам помогает писать чистый код.

У него был донельзя настроен анализатор кода Eslint. Помнится, в нем было 30–35 правил, большую часть из которых я тогда даже не понимал. 

Он выработал собственный стиль

Меня смущала «многословность» его кода. Он называл функции определенным, но последовательным образом. Например, в разработке часто нужно сортировать массив объектов. Немного погуглив мы получим следующий результат, который позволит изменить имя свойства.

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

Но мой коллега поступил бы иначе.

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 );

Кажется, разницы никакой. Оба кода делают одно и то же, но только позже я понял, что давать осмысленные имена важнее, чем сокращать строки. В долгосрочной перспективе все упирается в сопровождаемость и уменьшение технического долга. В чем моему коллеге не было равных. 

После появления хуков, все сообщество бросилось рефакторить свою кодовую базу на функциональные компоненты. Все, кроме него. Он хотел, чтобы мы подождали. И делал так каждый раз, когда выходила новая библиотека.

Меня это очень раздражало, даже возникали мысли, что он не использует эти библиотеки, потому что не знает, как с ними работать. Но потом стало ясно, что он просто относился к их появлению с опаской, так как понимал, что добавление всего и вся без разбора имеет свою цену, особенно в мире JavaScript. 

Философия чистого кода

Через 6–7 месяцев он сменил работу из-за конфликта с руководством. Так проект, который он поддерживал, перешел ко мне. Я просмотрел его код и понял, что он был идеальным. Несмотря на то, что мы выполняли одну и ту же работу, его действия были на другом уровне — от структуры папок до именования переменных. Его внимательность к каждой строчке кода заставила меня полюбить профессию и вдохновила на будущие свершения.

Тогда я понял, что нет ничего важнее в нашей профессии, чем писать хороший код. Эта философия до сих пор со мной.

Заключение

Во время работы мы часто не сходились во мнении. Может быть, он не всегда был прав, может, на первый взгляд он казался не совсем приятным человеком, но он — величайший разработчик, которого я видел. И равных ему я не встречал по сей день.