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

Все то время, что я подбираю стажеров, я имею дело в основном с выходцами из других профессий. Типичный стажер – человек, который окончил ВУЗ по любому другому профилю (медики, учителя, админы, маркетологи, кого только не было), получил опыт работы по специальности и решил, что ему надо что-то другое. Мотивация перемены области деятельности, как я понимаю, обычно деньги и комфорт. Есть поверье, что средний начинающий программист – это человек, который работает из дома три часа в день, а остальное время купается в деньгах как Скрудж МакДак. 

Все эти чудесные люди практически в обязательном порядке проходят некие онлайн курсы и сразу по прохождении размещают резюме на вакансию junior-программист с ценником от 50 000 рублей. 

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

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

В этой статье мы поговорим о том, зачем вообще их нужно знать веб-разработчикам, и затронем тему оценки сложности алгоритмов и Big O нотации.

Зачем мне алгоритмы? Я фронтендер!

Вы наверняка задумались: «А зачем мне нужно тратить своё время на изучение этих сложных алгоритмов, если я работаю с фронтендом? Как знание графов и бинарных деревьев поможет мне лучше отцентровать одну div-ку внутри другой div-ки?»

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

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

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

Кстати, именно по этой причине многие крупные IT-компании требуют от своих потенциальных сотрудников знания фундаментальных основ computer science, к которым как раз относятся алгоримты и структуры данных, и с пристрастием спрашивают их на собеседованиях.

Ведь они ищут лучших из лучших, и знание алгоритмов как раз делает вас лучше как разработчика. Тем более, лучше инвестировать свое свободное время в новые знания и навыки, чем в сериалы на Netflix.

И на этой прекрасной ноте давайте перейдем к основной теме статьи.

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

Доклады были разными. Я хотел, чтобы они были захватывающими и полезными, так что мне пришлось разобраться в том, как сделать интересный доклад. Оказалось, что эти знания востребованы и среди программистов — начинающих докладчиков, и среди деврелов. В конце концов я решился написать статью на эту тему.

Материала оказалось много и статьи получилось две. Эта первая — о том, как придумать тему доклада.

Это время для фактов, а не для страха. Это время для науки, а не слухов. Это время солидарности, а не охоты на ведьм…
директор ВОЗ Tedros Adhanom Ghebreyesus про эпидемию COVID-19

Грантовая поддержка исследования

Фактически, в роли «научного грантодателя» для этой статьи выступают мои «меценаты» с Patreon. Благодаря им все и пишется. Поэтому и ответ они могут получить раньше всех других, и черновики увидеть, и даже предложить свою тему статьи. Так что, если интересно то, о чем я пишу и/или есть что сказать — поспешите стать моим «патроном» (картинка кликабельна):

Вы наверняка слышали это знаменитое высказывание от GoF: «Предпочитайте композицию наследованию класса». И дальше, как правило, шли длинные размышления на тему того, как статически определяемое наследование не настолько гибко по сравнению с динамической композицией.

Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования тоже проблемы. «И что же теперь, не использовать наследование вообще?» – спросите Вы.

Давайте посмотрим на то, как сильная зависимость между классами через наследование может сделать архитектуру вашей системы чрезмерно жесткой и хрупкой. И зачем использовать одно из самых загадочных и неуловимых в коде ключевых слов – final. Сформулированные идеи демонстрируются на простом сквозном примере. В конце статьи приведены приемы и инструменты для удобной работы с final классами.

Проблема хрупкого базового класса

Не так давно на хабре появилось несколько постов противопоставляющих функциональный и объектный подход, породивших в комментариях бурное обсуждение того, что вообще это такое — объектно ориентированное программирование и чем оно отличается от функционального. Я, пусть и с некоторым опозданием, хочу поделиться с окружающими тем, что думает по этому поводу Роберт Мартин, также известный, как Дядюшка Боб.

В недавнем выпуске подкаста DotNet&More мы обсуждали с Максимом Аршиновым его предстоящий доклад на Московский .Next "Блеск и нищета предметной модели". С позицией Максима можно будет легко познакомиться непосредственно на конференции. И, в качестве дополнения, я бы хотел рассмотреть видение великого спора Анемичная VS "Богатая" ("Насыщенная") доменные модели через призму некогда популярных GRASP шаблонов

Дискуссии идут достаточно давно, например:

• Anemic Domain Model [Перевод]
• [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
  Судя по 190 комментариями к последней статье, данная тема не теряет актуальности.

Прежде чем начать разбор, хотелось бы прояснить предмет спора. Основное отличие анемичной модели от богатой в том, что она не содержит бизнес логику в теле класса. Частным примером анемичной модели может быть всем известный паттерн DTO.

"Богатая" модель, в свою очередь, может содержать логику, описывающую бизнес правила, функции и т.д. Обратите внимание, что мы рассматриваем именно методы, отражающие бизнес логику. ToString, GetHashCode и прочие "технические" части классов не входят в предмет обсуждения, потому и игнорируются.

Single responsibility principle, он же принцип единой ответственности,
он же принцип единой изменчивости — крайне скользкий для понимания парень и столь нервозный вопрос на собеседовании программиста.

Первое серьезное знакомство с этим принципом состоялось для меня в начале первого курса, когда молодых и зеленых нас вывезли в лес, чтобы сделать из личинок студентов — студентов настоящих.

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

Случай, когда размер очереди был кратен трем, и являлся хорошей реализацией SRP.

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

• TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
• BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
• TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
• DDD — bound contexts, ubiquitous language, domain...
• FDD — да сколько можно?
• MDD — cерьезно, на основе диаграмм?
• PDD — ...

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

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

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

Карта каналов об эмиграции

На помощь приходит Telegram, где в последние годы появилось уникальное сообщество авторов жанра «я — эмигрант».

Каждый день очередной эмигрант решает вещать из своей страны и заводит канал в телеграме. Ребята (а 90% из них работают в IT или около IT индустрии) делятся полезными советами, общаются с читателями в чатах, пропагандируют свободу перемещения, рассказывают о плюсах и минусах эмигрантской жизни, честно и без прикрас выдают информацию, которую не найти в поисковиках.

Какие на самом деле жители выбранной ими страны? Как найти жилье? Как устроится на работу? В чем отличия менталитета? Или даже Как проходят свидания? Как строится личная жизнь в другой стране? Такого нет в Google! :)

Я собрал максимально большой список таких блогов, отсортировал по странам и делюсь с вами.

Качество кода и архитектура

• Мы минимизируем время доведения фичи до продакшна при сохранении приемлемого качества.
• Любая задача предполагает два решения: быстрое и правильное. Для любой фичи мы продумываем оба варианта так, чтобы была возможность апгрейдить быстрое решение до правильного, делая минимум ненужной работы «на выброс». Выкатив быстрое решение, некоторое время смотрим и понимаем, нужно ли правильное.
• Критично. Зачастую, разница по времени между тем, чтобы «решить первым попавшимся способом, забив костыль» и «решить красиво и аккуратно» – десять минут. Поэтому мы всегда думаем, перед тем как писать.

Данная статья является конспектом книги "Чистый Код" Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.