Если попробовать свести разницу в уровнях разработчиков к одному критерию, то, я думаю, это будет качество принимаемых решений. Например, решения по дизайну кода, архитектуре, выбору технологии и т. д.
Первое наблюдение: джун не в состоянии сам принять решение, ему нужна помощь. Мидл, скорее всего, сам выберет какое-то решение, но оно может не быть оптимальным в перспективе. А решение, которое примет синьор, не только закроет текущую задачу, но и останется актуальным в будущем.
Второе наблюдение: мидлы часто говорят о нехватке информации, контекста. Например, ссылаются на незнание архитектуры проекта, отсутствие документации, непроработанность требований и т. д. А опытный разработчик в тех же условиях может сам разобраться и предложить несколько вариантов.
На основе этих наблюдений уточним критерий уровня разработчика — это качество принимаемых решений в условиях недостаточной информации.
Под качеством я имею ввиду «живучесть» решения. То есть принятое когда-то решение не начинает приносить проблемы и неудобства по мере развития системы. Другими словами, оно является эволюционно устойчивым.
Можно ли разработчику улучшить навыки принятия решений и таким образом вырасти? Я думаю, да. Здесь я собрал несколько советов по развитию этих навыков. А в следующей статье будут практические принципы, которые помогут сделать выбор.
Итак, перейду к советам по развитию качества принятия решений.
Читайте больше, чем пишите
Наверное, один этот совет мог бы потянуть на целую заметку, настолько это важно. Я имею в виду и существующий код, связанный с вашей задачей, и код-ревью изменений ваших коллег, и сторонний код.
Давайте чуть подробнее.
Код, связанный с вашей задачей
Вы несколько дней работали над задачей, отправили её на ревью и узнали, что в проекте уже есть нечто похожее. Или вообще используется совсем другой подход. Не знаю, что может быть грустнее при работе над кодом.
Как этого избежать? Заложите время на то, чтобы разобраться, в том, что уже есть. Если расширяете схему БД, посмотрите, как именуются похожие по смыслу поля в других таблицах. Если пишите тесты, проверьте, какие уже есть фикстуры. Посмотрите, какое разделение слоев в проекте (апи, работа с данными, и т. д.).
Может быть, сначала стоит перенести или обобщить часть существующего кода, провести небольшой рефакторинг.
Профит — меньше кода, меньше времени и сил на отладку, меньше багов, проще ревью. Также придется меньше думать о раскладке файлов, именовании и т. д. Казалось бы, всё это очевидно, но увы, разработчики часто об этом забывают.
Код-ревью изменений ваших коллег
Вдумчивое, глубокое код-ревью — это отличный способ развиваться. Можно узнать новые подходы и идеи. И, кроме того, проанализировать, с какими проблемами сталкивался автор, и какие решения он принимал. То есть реконструировать его процесс мышления и таким образом развивать свое. А ещё при таком процессе реконструкции вы можете предложить более удачное решение.
Каждая строчка кода, каждая функция, каждое имя переменной отвечает на какой-то вопрос. Подумайте, что это за вопрос, и есть ли ответ лучше.
Сторонний код
В следующий раз, когда возникнет вопрос по сторонней библиотеке, попробуйте не лезть в документацию, а почитайте исходники. Это не только даст более однозначный ответ для большинства задач, но и позволит прокачать важный навык ориентирования в незнакомой кодовой базе. А также это даст насмотренность — подходы, идеи и паттерны, которые вы сможете использовать в работе.
Читать сторонний код можно по-разному. Например, настроить пути в IDE или редакторе, чтобы переход к определению срабатывал и для сторонних библиотек.
А можно просто скачать исходники и искать там ответ, заодно разобравшись со структурой проекта. Например, посмотрите, как именно работает опция утилиты или параметр конфига, если это нужно для вашей задачи.
Вернемся к качеству принятия решений.
Считывайте идеи и паттерны, не вникая в детали
Если немного абстрагироваться, то можно начать видеть схожие идеи в разных областях. Например, для меня, одна из самых красивых идей по именованию — это двухбуквенные операторы сравнений утилиты test - eq, ne, gt, lt, ge, le. Соответственно, это
equal (eq)
not equal (ne)
greater than (gt)
less than (lt)
greater than or equal (ge)
less than or equal (le)
Эту схему легко запомнить и легко воспроизвести — всегда используются две буквы, минимально необходимые для различения операторов. Другие варианты именования были бы не такими однозначными — equal? equals? greater-or-equal? greater-equals? Ту же двухбуквенную схему именования для методов сравнения мы и видим и в Python — __eq__, __ne__ и т. д.
Да, это принцип наименьшего удивления. Но я говорю про практическую сторону — путь к понятным, легко считываемым решениям лежит через анализ сторонних систем.
Участвуйте в эксплуатации сервисов
Код, лежащий в системе контроля версий, сам по себе не даст вам фидбэка о надежности, прозрачности и удобстве эксплуатации системы. Достаточно ли информации в логах, чтобы найти причину проблемы? Нет ли там спама, затрудняющего поиск нужной информации? Насколько быстро мониторинг поможет обнаружить аномалию, если что-то пойдет не так? Насколько надежны сторонние системы, на которые вы полагаетесь?
Опыт эксплуатации — деплой, разбор ошибок, чтение логов, — дает понимание, как на самом деле работает система, какие ситуации могут быть и при этом не были предусмотрены на этапе разработки. Хорошая книга на эту тему — «Release It!».
Обобщим. Важна обратная связь о том, как ваше решение живет во времени. Эта обратная связь даст вам опыт. Вот вы что-то решили, а как оно в проде? А легко ли с этим работать? А может ли кто-то, кроме вас, с этим разобраться в случае проблемы?
Стройте гипотезы об устройстве систем
Допустим, вам надо найти некоторое решение проблемы. Учитывая, что в мире миллионы разработчиков, есть высокая вероятность, что вы не первый с такой проблемой, а ещё, что за последние полвека появилось нечто готовое.
Но как найти это нечто, когда непонятно, что искать?
Подумайте, как бы выглядело идеальное решение. Наверное, им было бы удобно пользоваться, и оно хорошо вписалось бы в архитектурную модель. Сформулируйте ограничения архитектуры, подумайте о сценарии использования. Может, это расширение к фреймворку? А, может, это в целом похоже на то, что уже делает некая система, и там был бы уместен параметр конфигурации, который решает ваш случай? И вот уже ваш поисковый запрос становится более конкретным. Найти расширение под фреймворк проще, чем абстрактное нечто.
Если практиковать этот подход регулярно, то со временем ваши гипотезы станут точнее. И это пригодится не только для поиска готовых решений, но и для разработки собственных. Другими словами, сформулировать несколько предположений и сузить область поиска — эффективнее, чем перерыть всю документацию в поисках решения.
Пока это все, продолжение будет во второй части. Спасибо, что дочитали! Буду рад обсудить статью в комментариях, возможно, что-то потребует уточнений.
Комментарии (23)
Germanjon
15.12.2024 16:54Скажу наверное крамольную мысль: не всякий миддл превратится в сеньора. Может не хватить желания, настойчивости, знаний, навыков, софт-скиллов, склада ума, насмотренности.
Отсюда и появляются попытки обесценивания уровня сеньор. Когда миддл "формошлёпит" 5 лет и думает, что по прошествии этого срока он автоматически превращается в сеньора.
isumix
15.12.2024 16:54Заметил в последние годы что на хабр набежало много вайтишников которые искренне считают что максимум через 5 лет после курсов они уже синьоры.
MikeAlexeev Автор
15.12.2024 16:54поясните, пожалуйста, про обесценивание, может я Вас неправильно понял.
Я эту тему не затрагивал, но Вы об этом говорите. Вы увидели попытки обесценивания в статье?
Germanjon
15.12.2024 16:54Я эту тему не затрагивал, но Вы об этом говорите. Вы увидели попытки обесценивания в статье?
К статье как раз относится первая часть моего комментария. Вторая часть - следствие из этой мысли.
А мысль простая - нет серебряной пули, не всякий миддл станет сеньором и может быть ему это и не надо
MikeAlexeev Автор
15.12.2024 16:54Спасибо, что пояснили. Я с Вами согласен, не все смогут и не всем надо. А навязывание, что всем надо - это плохо.
Но тем не менее, я считаю, что взять в свою работу какие-то практики можно, пусть даже это и не приведет к смене должности. Например, плохого от чтения кода не случится. Я же самом-то деле не о должностях, а о мышлении, как его развивать. И я старался сделать текст короче, не расползаясь в пояснения по связанным вопросам. Поэтому есть ряд упрощений, в том числе и в заголовке
GospodinKolhoznik
15.12.2024 16:54для меня, одна из самых красивых идей в IT — это двухбуквенные операторы сравнений утилиты test -
eq,ne,gt,lt,ge,leЕсли это для вас одна из самых красивых идей, с которыми вы знакомы в IT, то вам рано писать статьи о том, как стать сеньором.
MikeAlexeev Автор
15.12.2024 16:54ок, допустим это мой личный недостаток, слишком парюсь с именованием, поэтому идею по удачному именованию оценил выше, чем оно того заслуживает.
Но это не было выводом статьи или чем-то, что я предлагаю.
Мне было бы более интересно обсудить рекомендации из статьи
ermouth
15.12.2024 16:54было бы более интересно обсудить рекомендации из статьи
Синьор понимает в развёртывании, внедрении и сопровождении. Ни одно из этих трёх слов в тексте не встречается, так что тут от просто мидла к продвинутому.
MikeAlexeev Автор
15.12.2024 16:54развёртывании, внедрении и сопровождении
поясните, что вы имеете ввиду под этими словами.
Внедрение - что внедряем и куда?
Развертывание и сопровождение - это экплуатация сервиса? в тексте есть про это, целый раздел
LyuMih
15.12.2024 16:54Сегодня ты сеньёр крутой, а завтра мидл простой.
(При переходе из одной компании в другую. Работает и в обратную сторону).
AlexunKo
15.12.2024 16:54Воображать синьора как волшебника, которому не нужно передавать контекст и заботиться о том, что всех вводных ему достаточно - типичная ошибка незрелого управления, перекладывающего свои проблемы и задачи с больной головы на здоровую, ожидая от дорогих спецов розовых чудес. Мой личный опыт показывает, что со временем это обходится себе дороже, особенно если синьор заподозрит что на нём любят кататься и не страдает отсутствием самоуважения.
MikeAlexeev Автор
15.12.2024 16:54та, ситуация, о которой Вы говорите - это крайность и плохая практика, не надо до этого доводить работу в команде. Я этого не имел ввиду, мне жаль, если Вы сделали такой вывод. Тезис был в том, что обычно синьор лучше мидла справляется в условиях недостатка информации. И эта ситуация недостатка информации встречается чаще, чем хотелось бы, по разным причинам, не только из-за управления. Например, может не быть хорошей доки по опенсорсному проекту, который надо интегрировать
AlexunKo
15.12.2024 16:54А опытный разработчик в тех же условиях может сам разобраться и предложить несколько вариантов.
Вот это слишком категоричное утверждение. Доставать информацию может эффективно как мидл так и синьор. Или, к примеру, мидл может работать дольше на проекте и на конкретных задачах быть эффективнее синьора. Тут еще момент - а оптимально ли давать им сопоставимые задачи, или же лучше занять синьора более сложными.
MikeAlexeev Автор
15.12.2024 16:54Вы приводите вопросы управления (кому какие задачи оптимально отдавать), они в статье не затрагивались, это отдельная тема. Ну то есть, допустим, какие-то задачи кому-то давать неоптимально. Как от этого меняются подходы к саморазвитию разработчика?
Вот это слишком категоричное утверждение.
если пытаться в паре строк описать ситуацию, то упрощения неизбежны. Я согласен с Вами, что бывают исключения и нельзя судить о професиональных качествах конкретнго человека по некой усредненной модели
AlexunKo
15.12.2024 16:54У меня просто в практике регулярно бывают случаи, когда именно синьор задает больше вопросов, прорабатывая больше слепых зон проекта и новых фич, как-раз потому что он более глубокий спец и ищет лучшее и качественное решение. Формально, глядя поверхностно, он как-бы менее самостоятелен и надоедает людям (когда мидл бы склепал быстренько все сам) своей коммуникацией, но в долгую это только лучше для проекта. А для незрелого менеджмента это плохо лишь потому что неудобно и как-раз потому, что в голове сидит это вредное вирусящееся убеждение что мол раз ты синьор то иди все делай хорошо и сам (ты же программист!).
Keeper11
15.12.2024 16:54Например, для меня, одна из самых красивых идей в IT
То есть до Лиспа автор ещё не добрался.
MikeAlexeev Автор
15.12.2024 16:54вижу, что это место зацепило не только Вас)
Надо было написать - идея по именованию. Я поправлю, чтобы обсуждение статьи не сводилось к обсуждению одной фразы.Как бы то ни было, та фраза - это не вывод, и не основная мысль.
ermouth
15.12.2024 16:54Ой, да ладно, какой Лисп, йот-комбинатор же! https://en.wikipedia.org/wiki/Iota_and_Jot
SergVedenyapin
15.12.2024 16:54Понравилась статья, но хотелось бы как-то глубже что ли)) насчет работы сеньором без контекста: столкнулся с ситуацией, когда фронт писали бэкендеры, при этом очень давно. Ведущие бэкендеры)) так вот, аналитик ушел, пришел джун. И я джун. И вот мы сидим и думаем, как правильно кнопки показывать в кебабе. Старый аналитик, вероятно, не лучше джуна, потому что сделал таблицу из 38 разных состояний и прописал для каждого из 38 состояний какие кнопки в каком состоянии. 11 кнопок на 38 состояний, вместо того, чтоб написать условие для каждой кнопки. И новый аналитик просто копипастит его таблицу... А бэкендер написал так как видит. По итогу теперь пришли к тому, что надо просто все переписать. Но аналитику не трогают, чтоб в следующий раз снова вернуться к вопросу а что и когда)))
ermouth
Если что они из Fortran-а.
adeshere
одна из самых красивых идей в IT — это двухбуквенные операторы сравнений
> Если что они из Fortran-а.
Не буду спорить насчет красоты, но как программист на фортране, я с какого-то времени стал предпочитать этим двухбуквенным совершенствам менее традиционные, но более короткие
>, <, >=, <=и так далее
Во-первых, один-два символа вместо четырех. Во-вторых, без точек, которые у нас обязательны в логических операторах типа
.and., .not.и пр. Иначе от них начинает рябить в глазах, например:if (ab.eq.cd.or.ef.gt.gh) ...Лично я в таких ситуациях (да и в более простых тоже) почему-то предпочитаю:
if (ab == cd .or. ef > gh) ...Хотя, если совсем уж начистоту, то на самом деле я всегда пишу так:
if ((ab == cd) .or. (ef > gh)) ...Конечно, согласно известной присказке, о синтаксисе не спорят. Но если язык допускает и первое и второе, то разговор о вкусах неожиданно может обрести смысл ;-)
ermouth
Занятно, что изначально, в первом драфте языка bp 1954, как раз были >, <, >=, <=. Но в первую версию языка это всё не попало, нормальный IF с логическими выражениями позже завезли.
У меня ж целый материал тут есть про историю Фортрана, вдруг вы не видели https://habr.com/ru/articles/740018/
adeshere
Спасибо за наводку,
действительно пропустил!
Мой камень в огород Хабра, который не позволяет удалять из ленты неинтересные лично для меня материалы, в результате чего она всегда перегружена, и многие интересные вещи проскакивают мимо. Особенно если не листаешь ее ежедневно...
А я всего-то-навсего просил сделать фильтрацию статей в ленте по "черному списку тегов", по принципу "все, кроме...". Точнее, я бы хотел двойной фильтр, чтобы:
1) если в статье есть интересующий меня тег (белый список), то она всегда попадала мне в ленту, независимо от пп.2. Но,
2) если в статье есть заведомо неинтересный мне тег (черный список), то она исключалась бы из моей ленты (кроме случаев из пп.1).
Но вместо этого можно лишь настраивать белый список, что и долго, и неудобно ввиду обилия возможных тегов. А главное, этот метод еще и требует постоянной актуализации списка, так как список возможных тегов меняется...
Сейчас займусь изучением ;-) А то мои познания из истории языка опирались преимущественно вот на это ;-))