Кодревью: Запахи кода
Делюсь небольшим контентом связанным с запахами кода. Я уже делал один и второй сборник в закрытой базе знаний.
Здесь я же хочу поделиться интересными для меня "запахами", почти как парфюмер. Кода я понюхал много и чаще споры об этих запахах возникают на кодревью.
Давайте же разберем несколько примеров:
1. Force Unwrapping и Force Casting. Многими нелюбимая вещь, которая может привести к крашем. В проде нужно свести к минимуму любой потенциальный сбой приложения
2. Переизбыток синглтонов. Сами по себе синглтоны не несут в себе зла, но их злоупотребление может сделать код сложнее. Так усложнится рефакторинг и предсказуемость.
3. Дублирование кода. Наверное, самый частый запах. Когда код повторяется в разных местах класса или приложения, то усложняется, поддержка кода и возникает риск ухудшения стабильности приложения.
4. Надуманная сложность. Одна из главных проблем охотниками за повышениями и любителей поумничать — выдувать из воздуха сложность задач и делать сложным простое. Сорри, яндекс, но ваших разрабов часто за это ругают. Нужно всегда правильно рассчитывать как можно обойтись более лаконичным решением и не усложнять без необходимости.
5. Комментарии. Комментарии важны для любого кода, поскольку они улучшают понимание разработчиками этого конкретного кода. Следовательно, комментарии можно добавлять везде, где возникает необходимость, но не слишком много, поскольку это может нарушить поток кода и усложнить его.
Основная цель комментариев — определить логику и обоснование различных частей кода и объяснить их точку зрения. Однако разработчику следует избегать переусердствовать, поскольку слишком много комментариев приведет к усложнению и баннерной слепоте, а иногда и комментированию очевидных вещей.
Делюсь небольшим контентом связанным с запахами кода. Я уже делал один и второй сборник в закрытой базе знаний.
Здесь я же хочу поделиться интересными для меня "запахами", почти как парфюмер. Кода я понюхал много и чаще споры об этих запахах возникают на кодревью.
Термин “запах кода” (code smell) некоторое время назад был введен Кентом Беком и популяризирован книгой Мартина Фаулера о рефакторинге (Refactoring: Improving the Design of Existing Code).
В русскоязычном переводе можно встретить “код с душком”. Такой перевод явно говорит о том, что речь идет о чем-то не слишком хорошем.
Давайте же разберем несколько примеров:
1. Force Unwrapping и Force Casting. Многими нелюбимая вещь, которая может привести к крашем. В проде нужно свести к минимуму любой потенциальный сбой приложения
2. Переизбыток синглтонов. Сами по себе синглтоны не несут в себе зла, но их злоупотребление может сделать код сложнее. Так усложнится рефакторинг и предсказуемость.
3. Дублирование кода. Наверное, самый частый запах. Когда код повторяется в разных местах класса или приложения, то усложняется, поддержка кода и возникает риск ухудшения стабильности приложения.
4. Надуманная сложность. Одна из главных проблем охотниками за повышениями и любителей поумничать — выдувать из воздуха сложность задач и делать сложным простое. Сорри, яндекс, но ваших разрабов часто за это ругают. Нужно всегда правильно рассчитывать как можно обойтись более лаконичным решением и не усложнять без необходимости.
5. Комментарии. Комментарии важны для любого кода, поскольку они улучшают понимание разработчиками этого конкретного кода. Следовательно, комментарии можно добавлять везде, где возникает необходимость, но не слишком много, поскольку это может нарушить поток кода и усложнить его.
Основная цель комментариев — определить логику и обоснование различных частей кода и объяснить их точку зрения. Однако разработчику следует избегать переусердствовать, поскольку слишком много комментариев приведет к усложнению и баннерной слепоте, а иногда и комментированию очевидных вещей.
С днем программиста
Хочу поздравить всех программистов с этим праздником. С самого раннего детства я увлекался компьютерами и зарабатывал только с помощью них: проходил игры за деньги, переустанавливал винду и программы, записывал dvd диски с фильмами и продавал. В моем колхозе уже с 13 лет он помогал мне зарабатывать. Ничего другого я не умел.
Уже в студенчестве я начинал писать первые сайты на фрилансе, а потом уже и приложения. В чем-то другом я никогда не видел себя. Влюбившись в свое ремесло и каждый день стараясь быть лучше.
Поздравляю всех тех, кто любит свою профессию и получает удовольствие от работы. Гигабайты счастья и здоровья вам. Триллионы сумм на офферах
Хочу поздравить всех программистов с этим праздником. С самого раннего детства я увлекался компьютерами и зарабатывал только с помощью них: проходил игры за деньги, переустанавливал винду и программы, записывал dvd диски с фильмами и продавал. В моем колхозе уже с 13 лет он помогал мне зарабатывать. Ничего другого я не умел.
Уже в студенчестве я начинал писать первые сайты на фрилансе, а потом уже и приложения. В чем-то другом я никогда не видел себя. Влюбившись в свое ремесло и каждый день стараясь быть лучше.
Поздравляю всех тех, кто любит свою профессию и получает удовольствие от работы. Гигабайты счастья и здоровья вам. Триллионы сумм на офферах
Запах кода: необоснованная сложность
Поговорим чуть подробнее про запах кода "необоснованная сложность". Прошлый пример не всем понравился и я попробую дать пояснения.
Избыточная сложность — это когда мы пытаемся сделать слишком раздутые конструкции и усложнения, где можем обойтись без ущерба к выразительности.
Когда у нас есть золотая середина между лаконичностью и понятностью.
Конечно, можно сказать, что программист просто глупый и не привык сложностям. Это универсальное оправдание любой человеческой лени. Но в больших и крупных проектах мы пишем не просто рабочий код, но и код, который проще читать.
А читать проще код, который не строит из себя умного и объясняет сложные вещи просто. Экономит множество когнитивных ресурсов и упрощает понимание.
В скриншотах я приложил более понятный пример, который встречается на собеседованиях. А также отрывок из книги "Ум программиста. Как понять и осмыслить любой код". В следующих постах мы разберем отдельные главы подробнее
Поговорим чуть подробнее про запах кода "необоснованная сложность". Прошлый пример не всем понравился и я попробую дать пояснения.
Избыточная сложность — это когда мы пытаемся сделать слишком раздутые конструкции и усложнения, где можем обойтись без ущерба к выразительности.
Когда у нас есть золотая середина между лаконичностью и понятностью.
Конечно, можно сказать, что программист просто глупый и не привык сложностям. Это универсальное оправдание любой человеческой лени. Но в больших и крупных проектах мы пишем не просто рабочий код, но и код, который проще читать.
А читать проще код, который не строит из себя умного и объясняет сложные вещи просто. Экономит множество когнитивных ресурсов и упрощает понимание.
Одна из главных задач хорошего кода в проде — упростить когнитивную нагрузку
В скриншотах я приложил более понятный пример, который встречается на собеседованиях. А также отрывок из книги "Ум программиста. Как понять и осмыслить любой код". В следующих постах мы разберем отдельные главы подробнее
Ищу экспертов с опытом
Вчера записывали мок-собес, с разрабом из известного мессенджера, "как проектировать Телеграм" и получилось очень круто. Это не был собес, а получилось нечто среднее между интервью, мок-собесом, воркшопом и подкастом.
Мне всегда были скучны подкасты и неинтересны. Из 1,5 часов обычно можно сжать до 15 минут. А тут формат систем дизайна держит внимание и не отвлекает от мыслей. Как в том меме в инстаграмах про кинотеатр для СДВГшников, где на пол экрана идет фильм, а на остальные пол экрана идет какой-то рандомный видос.
В таком уникальном формате ты получаешь сразу визуализацию мыслей, а опыт эксперта помогает узнать какие подводные камни могут ожидать тебя при разработке нетривиальных задач. Так в дружеской атмосфере мы узнали о пагинации и синхронизации сообщений, а также производительности.
Это вдохновило меня снова улучшить контент и собирать для такого формата экспертов с уникальным опытом. Поэтому ищу ребят для подкаста-интервью в формате систем дизайна:
- экспертов CI/CD
- архитекторов
- разрабов GPU
- необычных приложений
- музыкальных и видео плееров
- разрабов дизайн системы
- BDUI
- кроспплатформу
- и других
Такое интервью будет без оценок и свободным в формате воркшопа, где аудитория сразу получит лучшие практики.
Ну и если ты просто хочешь пройти собес для самопроверки, то тоже пиши
Вчера записывали мок-собес, с разрабом из известного мессенджера, "как проектировать Телеграм" и получилось очень круто. Это не был собес, а получилось нечто среднее между интервью, мок-собесом, воркшопом и подкастом.
Мне всегда были скучны подкасты и неинтересны. Из 1,5 часов обычно можно сжать до 15 минут. А тут формат систем дизайна держит внимание и не отвлекает от мыслей. Как в том меме в инстаграмах про кинотеатр для СДВГшников, где на пол экрана идет фильм, а на остальные пол экрана идет какой-то рандомный видос.
В таком уникальном формате ты получаешь сразу визуализацию мыслей, а опыт эксперта помогает узнать какие подводные камни могут ожидать тебя при разработке нетривиальных задач. Так в дружеской атмосфере мы узнали о пагинации и синхронизации сообщений, а также производительности.
Это вдохновило меня снова улучшить контент и собирать для такого формата экспертов с уникальным опытом. Поэтому ищу ребят для подкаста-интервью в формате систем дизайна:
- экспертов CI/CD
- архитекторов
- разрабов GPU
- необычных приложений
- музыкальных и видео плееров
- разрабов дизайн системы
- BDUI
- кроспплатформу
- и других
Такое интервью будет без оценок и свободным в формате воркшопа, где аудитория сразу получит лучшие практики.
Ну и если ты просто хочешь пройти собес для самопроверки, то тоже пиши
Жирный подгон вам ко дню программиста! В прошлом посте я говорил, что совершенно случайно получился новый формат. Он похож на смесь мок-интервью, воркшопа и подкастов.
В нем мы попытались спроектировать телеграм с помощью эксперта, у которого рабочий опыт был только в чатах. Чаты — это отдельный вид приложений, со своей сложностью и спецификой. В них много бизнес-логики, а процент разнообразия куда больше, чем в регулярном приложении.
Получилось очень здорово. Мы проговорили:
Такое интервью получилось куда более полезным, где ты понимаешь нюансы и тонкостей разработки. Обогащая себя новыми знаниями и увеличивая кругозор. Мне дико понравилось.
Для следующих таких интервью ищу ребят из платформенных команд, FAANG'ов или видео/аудио плееров.
Канал эксперта: @alexdevaslifestyle
Please open Telegram to view this post
VIEW IN TELEGRAM
Что выведется в консоль?
Anonymous Quiz
11%
5, 10
5%
Ошибка компиляции
8%
10, 10
33%
5
38%
10
5%
nil
Почему вам нужен ментор
Пару месяцев назад я разочаровался в менторстве, но благодаря новой системе мотивации на рынке, где поощряют менторство, и многим умным людям пересмотрел. Это не поменяло моего отношения к куче низкокачественных специалистов, которые используют беззащитность и наивность новичков и продают советы по накрутке как что-то полезное и высококачественное.
Я скорее увидел другую сторону. Качественную культуру взаимного роста. Где огромное множество существует хороших менторов, которых так просто не найдешь в интернете и чьи услуги не всегда доступны. Кто не впихивает свою "консультацию", а использует это как инстурмент развития.
Белых и серых менторов, кто помогает расти себе и другим. Делятся своей уникальной экспертизой, выходят за границы запроса "пройти собесы", развивают инженерную культуру и площадки для взаимообогащения. Разбираются в педагогике и дают хорошие ориентиры для дальнейшего обоюдного сотрудничества. Таким мне больше нравится быть.
Более того, я продолжаю искать ментора себе, который будет подсвечивать точки роста и помогать распутывать узлы.
Вот хороший выпуск от ex топов крупных компаний как майрософт и jetbrains. Авторы разбирают крутые вопросы:
🟣 Зачем менти нужно идти к ментору
🟣 Различие между коучем и ментороством
🟣 Зачем ментору менторство
🟣 Гросс майндсет
🟣 Конфлиткты интересов и многое другое
Пару месяцев назад я разочаровался в менторстве, но благодаря новой системе мотивации на рынке, где поощряют менторство, и многим умным людям пересмотрел. Это не поменяло моего отношения к куче низкокачественных специалистов, которые используют беззащитность и наивность новичков и продают советы по накрутке как что-то полезное и высококачественное.
Я скорее увидел другую сторону. Качественную культуру взаимного роста. Где огромное множество существует хороших менторов, которых так просто не найдешь в интернете и чьи услуги не всегда доступны. Кто не впихивает свою "консультацию", а использует это как инстурмент развития.
Белых и серых менторов, кто помогает расти себе и другим. Делятся своей уникальной экспертизой, выходят за границы запроса "пройти собесы", развивают инженерную культуру и площадки для взаимообогащения. Разбираются в педагогике и дают хорошие ориентиры для дальнейшего обоюдного сотрудничества. Таким мне больше нравится быть.
Более того, я продолжаю искать ментора себе, который будет подсвечивать точки роста и помогать распутывать узлы.
Вот хороший выпуск от ex топов крупных компаний как майрософт и jetbrains. Авторы разбирают крутые вопросы:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Почему вам нужен ментор?
Андрей Бреслав (ex-JetBrains, а теперь основатель стартапа) и Александр Ложечкин (ex-Microsoft, ex-Amazon, а теперь CIO в банке) рассуждают, спорят, делятся опытом, и просто болтают на темы развития людей, руководства, технологий и всего остального.
Сайт…
Сайт…
Никто не будет думать о твоем повышении кроме тебя
Сейчас читаю нахваленную многими книгу The Software Engineer's Guidebook, автора сайта pragmatic engineer и уже разобранную нами "Growing as a Mobile Engineer"
Книга мне уже нравится и много мыслей заходят. Возможно, будет серия постов про самые интересные мысли и советы.
Первые главы сразу говорят, что нет никаких четких критериев роста. Помню свою позицию, когда я ждал помощи. Думал, придя в крупную компанию за мое развитие должен взяться мой менеджер и работадатель. Ведь я ресурс и в их заинтересованности чтоб этот ресурс развивался. Со стыдом вспоминаю свою наивность.
Наша среда обитания — очень динамичная и непостоянная. Нужно всегда держать руку на пульсе, а те, кто перестал практиковаться, следить за ней из первых рядов и ушел учить жизни и успеху — уже устарели или имеют искаженную картину.
Более того, сценарий и роадмапы карьерного пути сильно отличаются где вы работаете — стартап это или бигтех. Не везде упорный труд приведет вас к повышению и к желаемым ожиданиям. А еще более важный совет: никогда не будет постоянных критериев роста.
Новички в индустрии всегда ругаются, что нет четких критериев между грейдами. Жалуясь на нее, обвиняя третих лиц. Но создать предсказуемые условия в самой динамической среде — утопия. Наша индустрия не терпит регламенты и законы. То, что вчера работало — сегодня упадет из-за санкций или перевернется из-за ИИ. Позиция нытья — детсткая и проигрышная.
Сейчас я все сильнее выстраиваю фундамент развития в нашем сообществе. Один из них — быть проактивным и не зависеть от менторов, руководителей, гайдов и роадмапов. Развивать любознательность, смелость и крепкость. Создавать инфраструктуру для взаимопомощи. Самим их строить и отвечать за свой рост. Брать ответственность в свои руки и не быть нытиками, которые жалуются на сломанную индустрию.
Сейчас читаю нахваленную многими книгу The Software Engineer's Guidebook, автора сайта pragmatic engineer и уже разобранную нами "Growing as a Mobile Engineer"
Книга мне уже нравится и много мыслей заходят. Возможно, будет серия постов про самые интересные мысли и советы.
Первые главы сразу говорят, что нет никаких четких критериев роста. Помню свою позицию, когда я ждал помощи. Думал, придя в крупную компанию за мое развитие должен взяться мой менеджер и работадатель. Ведь я ресурс и в их заинтересованности чтоб этот ресурс развивался. Со стыдом вспоминаю свою наивность.
Наша среда обитания — очень динамичная и непостоянная. Нужно всегда держать руку на пульсе, а те, кто перестал практиковаться, следить за ней из первых рядов и ушел учить жизни и успеху — уже устарели или имеют искаженную картину.
Более того, сценарий и роадмапы карьерного пути сильно отличаются где вы работаете — стартап это или бигтех. Не везде упорный труд приведет вас к повышению и к желаемым ожиданиям. А еще более важный совет: никогда не будет постоянных критериев роста.
Новички в индустрии всегда ругаются, что нет четких критериев между грейдами. Жалуясь на нее, обвиняя третих лиц. Но создать предсказуемые условия в самой динамической среде — утопия. Наша индустрия не терпит регламенты и законы. То, что вчера работало — сегодня упадет из-за санкций или перевернется из-за ИИ. Позиция нытья — детсткая и проигрышная.
Сейчас я все сильнее выстраиваю фундамент развития в нашем сообществе. Один из них — быть проактивным и не зависеть от менторов, руководителей, гайдов и роадмапов. Развивать любознательность, смелость и крепкость. Создавать инфраструктуру для взаимопомощи. Самим их строить и отвечать за свой рост. Брать ответственность в свои руки и не быть нытиками, которые жалуются на сломанную индустрию.
Недавно произошел забавный случай. Мне писал коллега, что проводил свой собес в крупном банке с помощью нашей базы знаний. Он задавал уточняющие вопросы, рядом с методичкой открыв наш ноушен. Это приятно, но смешное в том, что кандидат отвечал ответами 1 в 1 будто читал из той же самой методички. Было одновременно забавно и приятно, что наши сборники используются по обе стороны. Но лучше все же не зубрить ответы и не списывать...
Поэтому я стараюсь собирать самые интересные и полезные вопросы. Даже если вы не готовитесь к собесам, то это поможет вам держать себя в тонус. Как решение кроссвордов или загадок по вечерам. Эту идею мы также несем с "ежедневными задачами в чате".
Любые знания и навыки атрофируются, если их не использовать. Именно поэтому многим так сложно выходить на рынок после долгих перерывов. В стрессовых условиях тратя очень много времени для нагонки формы. Уж лучше поддерживать форму регулярно и дисциплинированно.
В этом сборнике я собрал интересную тему анти-паттернов:
Также к вопросам приложены материалы для подготовки
Please open Telegram to view this post
VIEW IN TELEGRAM
Что такое анти-паттерны?
Ну и сразу готовый ответ на один из прошлых вопросов, который есть в крутейшем курсе для мобильных архитекторов (судя по отзывам). Мне очень понравилась эта формулировка, где анти-паттерны — это не самое лучшее и рискованное решение, которое было лениво выбрано и может быть заменено чем-то лучшим
Эта формулировка для тех, кто говорит, что их не существует 🙂
https://www.youtube.com/watch?v=Btm3CTI6eMA
Ну и сразу готовый ответ на один из прошлых вопросов, который есть в крутейшем курсе для мобильных архитекторов (судя по отзывам). Мне очень понравилась эта формулировка, где анти-паттерны — это не самое лучшее и рискованное решение, которое было лениво выбрано и может быть заменено чем-то лучшим
Эта формулировка для тех, кто говорит, что их не существует 🙂
https://www.youtube.com/watch?v=Btm3CTI6eMA
YouTube
Clean iOS Architecture 101: What is an anti-pattern?
This is why you should avoid anti-patterns in your iOS/Swift codebases.
Excerpt from the iOS Lead Essentials Podcast #014
You can also find us on ↴
Twitter ☛ https://twitter.com/essentialdevcom
Facebook ☛ https://facebook.com/essentialdeveloper
Instagram…
Excerpt from the iOS Lead Essentials Podcast #014
You can also find us on ↴
Twitter ☛ https://twitter.com/essentialdevcom
Facebook ☛ https://facebook.com/essentialdeveloper
Instagram…
Почему стало сложно найти работу?
Хорошая статья, которая объясняет почему стало и будет сложнее искать работу. Прогнозы не очень хорошие и понятно одно — находить работу будут не все. Давайте по пунктам:
🟣 Количество выпускников компьютерных наук самое большое в истории. Предложений на рынке стало больше.
🟣 Дорогое образование. Люди ищут более прибыльные специальности такие как компьютерные науки и тп.
🟣 Технологии и компьютеры очень популярны. Вся наша жизнь связана с ними, поэтому больше людей хотят их изучать.
Рынок вакансий уменьшился. Стали меньше публиковать вакансии и чаще увольнять.
🟣 Изменения процентных ставок и налоговых обложений заставили компании ужесточить найм.
🟣 FAANG'и начал нанимать меньшее количество людей.
🟣 Нанимать стало сложнее из-за большого количества обмана и лжи.
Повлиял ли на это AI?
🟣 В найм сотрудников стали меньше вкладываться, а больше в ИИ.
🟣 AI юзается для создания резюме, которые подходят под фильтр и проходят hr-скрининг. В результате кандидаты, что юзают AI для создания резюме, получают больше приглашений на собеседования, даже если они не соответствуют требованиям.
Ну а самый главный вывод — стоять на месте и не развиваться смертельно опасно
Хорошая статья, которая объясняет почему стало и будет сложнее искать работу. Прогнозы не очень хорошие и понятно одно — находить работу будут не все. Давайте по пунктам:
Рынок вакансий уменьшился. Стали меньше публиковать вакансии и чаще увольнять.
Повлиял ли на это AI?
Ну а самый главный вывод — стоять на месте и не развиваться смертельно опасно
Please open Telegram to view this post
VIEW IN TELEGRAM
r y x, r
Why does getting a job in tech suck right now? (Is it AI?!?)
A lot of new CS grads have been noting that is really hard to get a job. I’ve personally been contacted by a couple people, including outside of Twitter, about the difficulty of finding a job…
Почему if/else — это плохо
В чате сообщества мы уже недели полторы спорим о коде: что считается сложно, а что плохо; когда полезны комментарии; полезно ли помечать код MARK'ами; насколько полезны if/else.
Давайте разберемся когда же if/else считается плохой практикой.
1. Злоупотребление if/else может привести к проблемам чтения и дебагинга
2. Чаще лучше использовать guard, чем if/else
3. Не используйте if/else для проверки типов
Также в FAANGA'ах считается, что каждое использование if/else или bool флага приводит к усложнению чтения и поддержки кода в 4 раза.
Материалы для знакомста:
🟣 Don’t write if-statements
🟣 Stop Using If Statements In Your Swift Code
🟣 Why We Should Avoid Using `else` in Programming
В чате сообщества мы уже недели полторы спорим о коде: что считается сложно, а что плохо; когда полезны комментарии; полезно ли помечать код MARK'ами; насколько полезны if/else.
Давайте разберемся когда же if/else считается плохой практикой.
1. Злоупотребление if/else может привести к проблемам чтения и дебагинга
2. Чаще лучше использовать guard, чем if/else
3. Не используйте if/else для проверки типов
Также в FAANGA'ах считается, что каждое использование if/else или bool флага приводит к усложнению чтения и поддержки кода в 4 раза.
Материалы для знакомста:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Не секрет, что крупная компания в резюме влияет на успешность трудойстройства.
Если в вашем резюме есть опыт работы в яндексе/вк/сбере/любой_бигтех, то устроиться проще. Как думаете, с чем это связано?
Если в вашем резюме есть опыт работы в яндексе/вк/сбере/любой_бигтех, то устроиться проще. Как думаете, с чем это связано?
Final Results
52%
Сложность отбора. Если человек прошел сложные собесы, то значит чем-то заинтересовал
21%
Сложные задачи. Обычно в крупных компаниях интересней и сложнее задачи.
18%
Особое понимание корпоративной культуры.
16%
Опыт и компетенции. Сотрудник может быть полезен рассказав секреты конкурентов
46%
Похожий опыт из проверенных на рынке компаний. Многие компании — это университет для роста
17%
Все перечисленное
8%
Для меня компании не сильно важны
6%
Другое
Если тех.дир Тинька начал решать литкод, то ждем алгособесы в тиньке?
Ну а пока все наивно надеются, что алго-собесы вымрут и их отменят, мы в сообществе уже решили ~150 задач и ежедневно решаем и делимся кодом (иногда эмоционально). Где разрабы из JetBrains, Яндекса, Авито, Тинька и других компаний дают фидбэк и точки роста каждому.
Каждый сам выбирает готовить ли сани летом.
Ну а пока все наивно надеются, что алго-собесы вымрут и их отменят, мы в сообществе уже решили ~150 задач и ежедневно решаем и делимся кодом (иногда эмоционально). Где разрабы из JetBrains, Яндекса, Авито, Тинька и других компаний дают фидбэк и точки роста каждому.
Каждый сам выбирает готовить ли сани летом.