7 простых привычек 1% лучших инженеров

Я работал с феноменальными инженерами как в крупных компаниях, таких как FAANG, так и в небольших компаниях, таких как стартапы.

Некоторые из этих инженеров создали свои собственные компании, возглавили разработки, изменившие привычный нам веб (например, Vercel), или стали руководить миллиардными проектами в крупных технологических компаниях.

За время работы с ними я заметил, что у всех них были некоторые общие привычки в программировании и коде, который они создавали.

Используйте последовательные стандарты

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

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

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

• Компания Google выложила в открытый доступ некоторые из своих руководств по стилю.
• У Meta есть руководство по стилю C++ для некоторого открытого кода.
• Совет: Форматирование линтера для вашей команды определенно стоит того, чтобы потратить время на его создание, если такового еще нет.

Пишите эстетичный, простой код

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

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

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

Coderized на YouTube

Не допускайте сюрпризов

Код не должен приводить к неожиданностям. Это достигается путем соблюдения принципов написания кода и написания правильных тестов.

Хороший код предсказуем.

Хорошим примером принципов являются принципы SOLID. Хотя изначально они были разработаны для ООП, их можно распространить и на общее программирование:

• Единая ответственность: Класс должен иметь только одну ответственность.
• Открытость-закрытость: Программные объекты (классы, модули и т.д.) должны быть открыты для расширения, но закрыты для модификации, что позволяет создавать предсказуемый, сопровождаемый код.
• Подстановка Лисков: Подтипы должны быть заменяемы своими базовыми типами без ущерба для корректности программы.
• Разделение интерфейсов: Код не должен зависеть от гигантских интерфейсов, в которых он не используется полностью. Вместо этого пакеты должны содержать и допускать импорт более мелких, специфических интерфейсов.
• Инверсия зависимостей: Модули высокого уровня не должны зависеть от модулей низкого уровня; и те, и другие должны зависеть от абстракций, что способствует более гибкому и разделяемому системному дизайну.

Тесты обеспечивают ясность и предсказуемость кода. Они обеспечивают уверенность. Хорошее автоматизированное тестирование позволяет командам вносить изменения в код, не опасаясь сломать что-то невидимое.

Хороший код предсказуем

К некоторым типам тестов относятся:

• Юнит-тесты для отдельных компонентов и изолированных функций.
• Интеграционные тесты для взаимодействия между несколькими компонентами.
• Сквозные тесты, оценивающие функциональность всей системы с точки зрения пользователя.

Тесты должны быть простыми. Если тест прошел неудачно,  должно быть легко определить, что именно пошло не так.

Также важно знать, что не следует тестировать.

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

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

Часто общайтесь

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

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

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

Это может быть простое обращение к коллеге для быстрого просмотра документа или добавление дополнительных ревьюеров кода к важному пул-реквесту.

Отделите себя от самого кода

Лучшие инженеры не привязываются к самому коду.

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

Код — это не личное, поэтому обратная связь воспринималась ими спокойно.

Код не идеален. Никому не нужен идеальный код. Важен код, который дает изменения.

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

Кодируйте быстро… и медленно

Лучшие инженеры, которых я знаю, завершают проекты быстро… кодируя медленно.

Звучит странно, правда?

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

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

Альтернатива, которую я испытал на себе, когда был стажером и junior-разработчиком, а также, я уверен, испытывали и многие другие, — это броситься на 3 шага вперед, натолкнуться на преграду, а затем отступить на 5 шагов назад.

Код для человека, а не для компьютера

Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, который может понять человек. — Мартин Фаулер.

Код предназначен для людей, а не только для компьютеров.

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

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

У кода есть три аудитории: читатели-люди, читатели-машины и пользователи.

Лучшие инженеры, которых я знал, всегда оценивали ценность своего кода для всех аудиторий.

Если они не попадали хоть в одну из аудиторий, код не уходил в продакшн.

Не следуйте правилам слепо

Приведенные выше «правила» и «принципы» — это всего лишь рекомендации.

Не все можно аккуратно и красиво вписать в рекомендации.

Иногда код, который вы пишете, представляет собой квадрат, который просто не может вписаться в круг. Это нормально.

Иногда границы должны быть расширены.

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

Если этого не сделать, то в будущем кто-то, например, вы, возможно, посмотрите на этот код и подумаете: «Ух ты, какой же я был тупой тогда. Почему это не соответствует нашим стандартам?».

И тогда все потратят 20 часов на переделку кода, чтобы он соответствовал стандартам, а придут к тому же выводу, что и раньше. Звучит знакомо?

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

Зато он может быть последовательным, чистым, понятным, тестируемым и ценным.

…

Я заметил и другие особенности этих инженеров, о которых я напишу в будущем:

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

Источник