Untitled

Программист пишет код, инженер разрабатывает софт

Чтобы быть разработчиком, надо уметь смотреть в 3 стороны: в глубь, в даль и в ширь.

- В глубь — это про то, как вы пишите код.
- В даль — это про то, как вы этот код будете поддерживать.
- В ширь — это про софт скилы.

В конце я напишу, какой пункт статьи к какому свойству я отношу.

Каких принципов мы будем придерживаться в наших проектах:

Я буду называть общие термины, которые могут подойти под любой язык программирования.

1. **Чистота в родительских компонентах**. Родительский компонент тут я имею в виду как конечный компонент, в который вложены другие компоненты. Примером такого компонента является хедер сайта. Он состоит из кнопки авторизации, регистрации, лого. Пример кода такого компонента:

```html
<Header>
  <Logo />
  <Menu />
  <AuthBlock />
</Header>

```

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

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

Антипример:

```html
<Header>
  If page == main {
    <MainMenu />
  } elif page == games {
    <GameMenu />
  }
  If user.isAuthorized {
    <ProfileBlock />
  } else {
    <AuthBlock />
  }
</Header>

```

1. **Использование дизайн системы**

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

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

1. **Читабельные названия переменных, функций, компонентов**

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

Хорошо:

```jsx
const claimButton; // название переменной для кнопки
const claimButtonIsClick?; // название булевой переменной для кнопки
const onClaimClickHandler; // название функции, которая будет вызываться при нажатии на claimButton

```

Плохо:

```jsx
const claimButtonClick; // что клик?
const claim; // что клейм?
const handler; // чего хендлер?

```

1. **Коммуникабельность**

Я разделю это на 2 пункта:

1. Общение с теми, кто ставит задачи. Тут самое важное — никогда не уходите в себя, не пропадайте. Если что-то непонятно в задаче, лучше спросить как можно быстрее, не бояться, что вы будете кому-то надоедать тупыми вопросами. Это поможет вам не терять время на додумывание и переделку, а также сделает проект лучше.
2. Общение с членами команды. Общаться с командой лучше в общих чатах. Это касается и обсуждения задач с теми, кто их ставит. Общаясь в общих чатах, все заинтересованные всегда в контексте того, что происходит на проекте и могут быстро вклиниться в беседу.

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

1. **Ревью задач не должно занимать больше 15 минут**

Такое правило действует в больших командах. Если ревью занимает больше 15 минут, значит какой-то процесс выстроен неэффективно. Процессы, которые влияют на этот пункт, включают график работы команды и процессы интеграции доставки кода (CI/CD). Чем дольше ревью задачи, тем больше разработчик будет сидеть без дела, ожидая комментариев.

1. **Мы работаем по методу lean startup**

Это значит, что мы всегда выкатываем минимально рабочую версию задачи и дорабатываем ее после фидбэка пользователей. Пример: для верстки текста на странице роадмапа проекта вам нужно 10 минут, а для добавления степпера — час. Но суть страницы уже передана, и можно выделить выполненные пункты жирным. Это займет 5 минут и позволит сразу перейти к другим важным задачам.

Соотношение пунктов:

1 - в глубь

2 - в даль

3 - в глубь

4 - в ширь

5 - в даль

6 - в ширь

Если вы не хотите становиться инженером, а хотите быть только программистом, то будьте хотя бы профессиональным программистом.