Стоит ли учить [framework name]?

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

По этому поводу у меня есть радикальная идея: не нужно “учить” фреймворк. Все, что нужно выучить, вернее, освоить - это навык программировать. Навык программировать заключается в том, чтобы отображать объекты реального мира в виде абстракций, а также оперировать ими. Фреймворки, библиотеки и паттерны представляют собой лишь очередной способ делать это удобно. Возможно, для кого-то эта идея будет слишком радикальной, но на самом деле фреймворки, паттерны, библиотеки не рождаются из полного хаоса, они рождаются из удобных и практичных способов оперировать данными.

Поэтому не нужно “учить” очередной фреймворк; однако изучение новых фреймворков, библиотек и языков помогает качать главный навык - навык программировать, отсюда вытекает следующее: нужно учить программирование, а это удобно делать при изучении новых фреймворков, библиотек, языков и паттернов.

Но ведь [framework name] сделает мое резюме дороже?

Часто разработчики считают, что чем больше технологий они знают, тем дороже они как специалисты. По этому поводу у меня есть радикальная идея: важно не столько то, ЧЕМ вы делаете, важно то, ЧТО вы делаете. Одна из основных болей при найме - это разработчики, которые пишут код, не приходя в сознание, не пытаясь понять, что за код они пишут и какую бизнес задачу они решают. Такой рабочий процесс потом отражается в виде строчек резюме “делал фичи, фиксил баги”. Какие фичи делались, зачем и для чего, какой это принесло результат и пользу бизнесу, неуточняется.

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

На прошлой неделе прочла "Scrum" Джеффа Сазерленда. Делюсь с вами списком своих избранных цитат:

💡 Причина успеха методики проста. Я смотрел на то, как люди на самом деле работают, а не слушал то, что они говорят об этом.

💡 Любая задержка в рабочем процессе равно преступлению.

💡 Обнаружить ошибку как можно раньше и устранить.

💡 Планировать полезно. Слепо следовать плану - глупо.

💡 Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше (цитата из “Мифический человеко-месяц” Ф. Брукса).

💡 Дело было в базовой ошибке - и они ее не учли. Работники, ответственные за проект, считали, что можно спланировать все заранее.

💡 Карта - еще не живая местность.

💡 Сначала оценки работы колеблются от 400 процентов до двадцати пяти сверх реально потребовавшегося времени. Низкие и высокие оценки отличаются друг от друга в 16 раз. По мере того, как работа продвигается вперед, оценки все более приближаются к реальной величине - и так до того момента, когда уже нет никаких оценок, а есть одна реальность.

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

💡 Помните, мы говорим об оценках, а не о жестких планах.

💡 Главное, что нужно запомнить - порядок [задач в беклоге] постоянно меняется. Правильный порядок для нынешней недели уже не подойдет для следующей.

💡 Одна из плохих привычек, которая может появиться у компании из-за постоянно меняющихся потребностей рынка или из-за недопонимания руководством, в чем основная ценность - это приоритизация всего подряд. Любая мелочь становится делом первостепенной важности. “Тот, кто защищает все, не защищает ничего”.

💡 Я уже говорил о взятом из боевых искусств понятии “сюхари” (Shu Ha Ri). В состоянии Сю человек четко следует правилам, таким образом знакомясь со стоящими за ними идеями. В состоянии Ха человек начинает создавать собственный стиль, но при этом остается в границах обозначенных правил, лишь адаптируя их под свои потребности. В состоянии Ри человек окончательно избавляется от правил и создает саму идею.

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

Друзья, у меня есть для вас радикальная идея: важно не КТО говорит, а ЧТО говорит. Если спикер - крутой перец и он рассказывает про какой-то подход, это не значит, что вам нужно срочно тащить его к себе. Вам нужно понять, в какой ситуации подход был применен, какой дал эффект и какая ситуация у вас. Если ваши ситуации схожи, тогда подход можно применить. Аналогично с менее известными спикерами. Короче, друзья: продуктивнее размышлять над идеей и подходом, чем над тем, достаточно ли сеньорный спикер про него рассказал.

С огромным удовольствием посмотрела дискуссию о SOLID Кирилла Мокевнина и S0ER. По поводу SOLID у меня есть некоторое количество радикальных идей и сегодня я хочу поделиться с вами одной из них. Она звучала в ходе дискуссии, но мне хочется сделать на ней особый акцент. Я сформулирую ее следующим образом: не проект для SOLID, а SOLID для проекта.

Я периодически вижу, как начинающие разработчики, ознакомившись с принципами SOLID (и, будем честны, с любыми принципами вообще) начинают бездумно применять их везде - и где надо, и где не надо. Когда я преподавала на курсе об архитектуре фронтенд приложений, я говорила ученикам - никогда не применяйте принцип/паттерн/подход только потому, что так сказал какой-то умный дядя, применяйте, когда вы видите в этом реальный профит для вашего проекта. То же самое я советую вам: не отталкивайтесь от абстрактных принципов, отталкивайтесь от реальных нужд вашего проекта и вашей команды. Приведу несколько примеров:

❌ В этом классе я завязался на интерфейс калькулятора, а не на конкретную реализацию, потому что Мартин написал, что нужно соблюдать DIP
✅ В этом классе я завязался на интерфейс калькулятора, а не на конкретную реализацию, потому что у бизнеса есть планы на эксперименты с разными калькуляторами и поэтому удобнее не хардкодить конкретный калькулятор

❌ Я сделал компонент для отображения нотификаций и добавил ему пропс className, потому что так сделано во всех библиотеках
✅ Я сделал компонент для отображения нотификаций и добавил ему пропс className, потому что у нас может быть много разных вариантов нотификаций и так мы сможем использовать компонент в разных вариациях

❌ Я сделал компонент для отображения нотификаций и не добавил ему пропс className, потому что отображение - это зона ответственности компонента по SRP
✅ Я сделал компонент для отображения нотификаций и не добавил ему пропс className, потому что у нас есть дизайн система и мы должны зафиксировать варианты отображения компонента, чтобы он выглядел везде одинаково

На прошлой неделе дискутировали с командой о проектировании одного из компонентов интерфейса - делать ли контент компонента абстрактным и передаваемым снаружи (через механизм children в React) или же захардкодить контент прямо внутри компонента, а на вход передавать некий конфиг, который может регулировать отображение контента. В первом случае мы сможем сделать наш компонент совсем абстрактным и можно будет рендерить в нем абсолютно любой контент, а во втором случае - контент компонента будет ограничен реализацией.

В качестве одного из аргументов в пользу первого варианта звучала фраза “Мы никогда не узнаем, как именно бизнес захочет этот компонент использовать”. По этому поводу у меня есть радикальная идея: вне зависимости от того, какой вариант вы в итоге выберете, невозможно адекватно спроектировать компонент в случае, если вы понятия не имеете, как вы его будете использовать. Для того, чтобы что-то запрограммировать, вы должны точно знать, как вы будете использовать этот компонент/класс/сервис/сущность. В институте на кафедре автоматизированных систем управления нам говорили, что для автоматизации какой-либо системы необходимо точно понимать, что за систему, собственно, вы автоматизируете. Если вы не знаете, как будет использоваться компонент/сервис/сущность/система, то первоочередная задача будет это прояснить, а для этого необходимо собрать требования к системе у бизнеса.

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

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

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

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

Принцип открытости-закрытости (OSP) побуждает нас не вносить ломающие изменения в код, от которого зависят другие модули.

Применение принципа постановки Барбары Лисков (LSP) позволяет нам в полной мере использовать полиморфизм и работать с интерфейсом объекта, а не с его реализацией.

Принцип разделения интерфейсов (ISP) помогает нам регулировать количество зависимостей у модуля.

И, наконец, принцип инверсии зависимостей (DIP) позволяет нам зависеть в коде от абстракцией, а не от конкретных реализаций, что позволяет динамически подменять эти реализации “на лету”.

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

1. В первую очередь продумать интерфейс, (LSP, DIP);
2. Этот интерфейс должен позволять создавать абстракции, изменяющиеся вследствие решений одного актора (SRP) и не позволять лишних действий (ISP);
3. Этому интерфейсу может соответствовать несколько реализаций (OSP, LSP, DIP), что даст нам возможность использовать полиморфизм;
4. Частота изменения этого интерфейса должна быть обратно пропорциональна количеству его зависимостей (SRP, OCP).

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

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

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

P.S. И да, заранее закладывайте в сроки все те мероприятия, которые необходимы вам для достижения того качества, которое вы хотите соблюсти на данном проекте.

[Бесплатно и только для женщин] Круглый стол-девичник: «Борщ, дедлайны, 2 декрета: как быть женщиной в современном мире и не сойти с ума»

Сначала нам диктуют, как жить и где работать. Потом говорят, что мы должны работать наравне с мужчинами, но не дают этого делать. А потом требуют совмещать быт и работу. Быть современной женщиной чертовски сложно. Быть женщиной в IT — почти нереально. Но мы справляемся. И вам расскажем!

13 спикерок собираются вместе 📅 5 декабря (четверг) в 19:00 (МСК), чтобы обсудить:

– Сексизм и мизогинию, как всех интересует наша матка на каждом втором собеседовании
– Как нас не только не поддерживают, но и максимально задвигают
– Как можно не нести вторую смену после основной работы, не варить борщи и не выслушивать «а у мамы борщ был вкуснее»
– Как складывается жизнь, когда уходишь из хреновых браков, и как нам страшно было из них уходить
– Как мы справляемся, когда остались наедине с детьми и своей карьерой, как быть работающей мамой
– Как быть не стандартной конвенциональной красоты и при этом быть любимой и счастливой
– «Не высовывайся», как женщине строить личный бренд, как справляться с хейтом за вещи, которые мужчинам дозволены и не вызывают вопросов
– И как можно быть собой и быть счастливой
– И многое другое

Невыдуманные истории женщин, о которых невозможно молчать, и наша Girls Power в действии.
❗️ Вход только для женщин. Включенная камера обязательна. Анонимов будем удалять со стрима, чтобы нам никто не помешал.

📅 Дата и время: 5 декабря (четверг) с 19:00 до 21:00 по Москве.
🎙 Спикерки: Леся Набока, Люда Пак, Наташа Гришина, Оля Федосеева, Марго Лукина, Наташа Давыдова, София Сидорова, Ира Мазаева, Надя Гнусина, Карина Жданова, Ангелина Зинченко, Настя Румянцева, Настя Никулина. Умницы, красавицы, великолепные экспертки.

🔖 Как участвовать: Через обязательную регистрацию https://careerfactory.timepad.ru/event/3138085/
❓ Задавайте вопросы и рассказывайте истории — оставляйте их в комментариях к посту, и мы обязательно обсудим их на встрече.

💬 Дамы, приходите сами и берите с собой подруг. Мы вас ждем. Мы вам рады ❤️‍🔥
#GirlsPower