У нас были свои разногласия, но все же…

Текст публикуется в переводе. Автор статьи – Mohammad Faisal.

Какие качества делают хорошего инженера великим?

За последние 5 лет я имел честь работать с самыми разными людьми – от зеленых новичков до настоящих ветеранов разработки. Но лишь одного из них я могу назвать по-настоящему великим.

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

Давайте начнем…

Он не был самым быстрым

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

Бэкенд для этого уже был готов, и руководство очень хотело включить эту фичу в релиз.

Но Он отказался это делать.

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

Дело не только в скорости.

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

Его код читался как стихотворение

Спустя много времени, уже после того, как Он покинул компанию из-за конфликта с руководством, мне выпала честь работать над Его проектом.

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

         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 правил, многие из которых я тогда даже не понимал.

Он делал все по-своему

Меня часто сбивало с толку его многословие в коде.

Позвольте привести очень простой пример. Нам часто приходится сортировать массивы объектов. В Google можно очень быстро найти сниппет для решения этой распространенной задачи. Просто скопируйте его и измените при необходимости название свойства:

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

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

Лишь спустя время я понял, что осмысленные имена важнее, чем сокращение кода на пару строк.

В долгосрочной перспективе все решает именно простота обслуживания кода. И Он был в этом мастером.

Он был против перемен

Когда в React появились хуки, все сообщество моментально бросилось переписывать все свои проекты на функциональные компоненты. Но Он не позволил нам это сделать.

Да, вероятно, это была не самая хорошая идея, ведь сейчас почти каждая новая кодовая база написана именно на функциональных компонентах. И все же Он хотел, чтобы мы подождали.

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

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

Он ушел

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

На первый взгляд мы выполняли одну и ту же работу – предоставляли новую функциональность, которую хотело руководство. Но его код просто поразил меня. Все – от структуры папок до именования переменных – говорило о заботе, которую он вкладывал в свою работу. Это заставило меня влюбиться в программирование.

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

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

Хороший фрагмент кода – это настоящая красота!

И я до сих пор придерживаюсь этой философии.

***

Да, у нас было много разногласий, пока мы работали вместе. Вероятно, Он не всегда был прав, иногда он казался мне неприятным человеком (возможно, дело было в выражении его лица). Тем не менее, он является величайшим разработчиком React (и возможно, величайшим разработчиком в целом), которого я когда-либо встречал.