От мидла к синьору. Часть первая
Если попробовать свести разницу в уровнях разработчиков к одному критерию, то, я думаю, это будет качество принимаемых решений. Например, решения по дизайну кода, архитектуре, выбору технологии и т. д.
Первое наблюдение: джун не в состоянии сам принять решение, ему нужна помощь. Мидл, скорее всего, сам выберет какое-то решение, но оно может не быть оптимальным в перспективе. А решение, которое примет синьор, не только закроет текущую задачу, но и останется актуальным в будущем.
Второе наблюдение: мидлы часто говорят о нехватке информации, контекста. Например, ссылаются на незнание архитектуры проекта, отсутствие документации, непроработанность требований и т. д. А опытный разработчик в тех же условиях может сам разобраться и предложить несколько вариантов.
На основе этих наблюдений уточним критерий уровня разработчика — это качество принимаемых решений в условиях недостаточной информации.
Под качеством я имею ввиду «живучесть» решения. То есть принятое когда-то решение не начинает приносить проблемы и неудобства по мере развития системы. Другими словами, оно является эволюционно устойчивым.
Можно ли разработчику улучшить навыки принятия решений и таким образом вырасти? Я думаю, да. Здесь я собрал несколько советов по развитию этих навыков. А в следующей статье будут практические принципы, которые помогут сделать выбор.
Итак, перейду к советам по развитию качества принятия решений.
Читайте больше, чем пишите
Наверное, один этот совет мог бы потянуть на целую заметку, настолько это важно. Я имею в виду и существующий код, связанный с вашей задачей, и код-ревью изменений ваших коллег, и сторонний код.
Давайте чуть подробнее.
Вы несколько дней работали над задачей, отправили её на ревью и узнали, что в проекте уже есть нечто похожее. Или вообще используется совсем другой подход. Не знаю, что может быть грустнее при работе над кодом.
Как этого избежать? Заложите время на то, чтобы разобраться, в том, что уже есть. Если расширяете схему БД, посмотрите, как именуются похожие по смыслу поля в других таблицах. Если пишите тесты, проверьте, какие уже есть фикстуры. Посмотрите, какое разделение слоев в проекте (апи, работа с данными, и т. д.).
Может быть, сначала стоит перенести или обобщить часть существующего кода, провести небольшой рефакторинг.
Профит — меньше кода, меньше времени и сил на отладку, меньше багов, проще ревью. Также придется меньше думать о раскладке файлов, именовании и т. д. Казалось бы, всё это очевидно, но увы, разработчики часто об этом забывают.
Вдумчивое, глубокое код-ревью — это отличный способ развиваться. Можно узнать новые подходы и идеи. И, кроме того, проанализировать, с какими проблемами сталкивался автор, и какие решения он принимал. То есть реконструировать его процесс мышления и таким образом развивать свое. А ещё при таком процессе реконструкции вы можете предложить более удачное решение.
Каждая строчка кода, каждая функция, каждое имя переменной отвечает на какой-то вопрос. Подумайте, что это за вопрос, и есть ли ответ лучше.
В следующий раз, когда возникнет вопрос по сторонней библиотеке, попробуйте не лезть в документацию, а почитайте исходники. Это не только даст более однозначный ответ для большинства задач, но и позволит прокачать важный навык ориентирования в незнакомой кодовой базе. А также это даст насмотренность — подходы, идеи и паттерны, которые вы сможете использовать в работе.
Читать сторонний код можно по-разному. Например, настроить пути в IDE или редакторе, чтобы переход к определению срабатывал и для сторонних библиотек.
А можно просто скачать исходники и искать там ответ, заодно разобравшись со структурой проекта. Например, посмотрите, как именно работает опция утилиты или параметр конфига, если это нужно для вашей задачи.
Вернемся к качеству принятия решений.
Считывайте идеи и паттерны, не вникая в детали
Если немного абстрагироваться, то можно начать видеть схожие идеи в разных областях. Например, для меня, одна из самых красивых идей в IT — это двухбуквенные операторы сравнений утилиты test — eq, ne, gt, lt, ge, le. Соответственно, это
Эту схему легко запомнить и легко воспроизвести — всегда используются две буквы, минимально необходимые для различения операторов. Другие варианты именования были бы не такими однозначными — equal? equals? greater-or-equal? greater-equals? Ту же двухбуквенную схему именования для методов сравнения мы и видим и в Python — __eq__, __ne__ и т. д.
Да, это принцип наименьшего удивления. Но я говорю про практическую сторону — путь к понятным, легко считываемым решениям лежит через анализ сторонних систем.
Участвуйте в эксплуатации сервисов
Код, лежащий в системе контроля версий, сам по себе не даст вам фидбэка о надежности, прозрачности и удобстве эксплуатации системы. Достаточно ли информации в логах, чтобы найти причину проблемы? Нет ли там спама, затрудняющего поиск нужной информации? Насколько быстро мониторинг поможет обнаружить аномалию, если что-то пойдет не так? Насколько надежны сторонние системы, на которые вы полагаетесь?
Опыт эксплуатации — деплой, разбор ошибок, чтение логов, — дает понимание, как на самом деле работает система, какие ситуации могут быть и при этом не были предусмотрены на этапе разработки. Хорошая книга на эту тему — «Release It!».
Обобщим. Важна обратная связь о том, как ваше решение живет во времени. Эта обратная связь даст вам опыт. Вот вы что-то решили, а как оно в проде? А легко ли с этим работать? А может ли кто-то, кроме вас, с этим разобраться в случае проблемы?
Стройте гипотезы об устройстве систем
Допустим, вам надо найти некоторое решение проблемы. Учитывая, что в мире миллионы разработчиков, есть высокая вероятность, что вы не первый с такой проблемой, а ещё, что за последние полвека появилось нечто готовое.
Но как найти это нечто, когда непонятно, что искать?
Подумайте, как бы выглядело идеальное решение. Наверное, им было бы удобно пользоваться, и оно хорошо вписалось бы в архитектурную модель. Сформулируйте ограничения архитектуры, подумайте о сценарии использования. Может, это расширение к фреймворку? А, может, это в целом похоже на то, что уже делает некая система, и там был бы уместен параметр конфигурации, который решает ваш случай? И вот уже ваш поисковый запрос становится более конкретным. Найти расширение под фреймворк проще, чем абстрактное нечто.
Если практиковать этот подход регулярно, то со временем ваши гипотезы станут точнее. И это пригодится не только для поиска готовых решений, но и для разработки собственных. Другими словами, сформулировать несколько предположений и сузить область поиска — эффективнее, чем перерыть всю документацию в поисках решения.
Пока это все, продолжение будет во второй части. Спасибо, что дочитали! Буду рад обсудить статью в комментариях, возможно, что-то потребует уточнений.
