Паттерны проектирования — любимый блок многих собеседований и частый гость реальных споров на работе. Какой паттерн где лучше использовать и чем они отличаются друг от друга?
В этой статье мы разберем главное отличие двух паттернов Proxy и Decorator. Такой вопрос мне задавали как и на собесах, так и в реальной жизни.
Оба паттерна вращаются вокруг идеи упаковки экземпляра существующего интерфейса в класс, который реализует тот же интерфейс и делегирует вызовы своих функций тем же функциям в своем внутреннем экземпляре. Хотя оба паттерна могут иметь схожие реализации, но имеют разные цели.
На слайдах можно увидеть разницу.
Детальную статью можно почитать в ноушене. Там я написал в чем же отличия этих паттернов от декоратора.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Мобильные разработчики, общий сбор!
29 августа в Санкт-Петербурге пройдёт VK JT Mobile, первая конференция VK для мобильных разработчиков на iOS и Android. Вспомним прошлое, обсудим будущее и, опираясь на наш опыт, расскажем, как моментально внедрять технологии, структурировать миллионы строк кода и постоянно улучшать продуктовые метрики.
В программе нестандартные сценарии работы с пушами, упрощение разработки с помощью нейросетей, фичи для анализа ошибок и даже реализация приложений для автомобилей. Подробнее — на сайте.
Регистрируйтесь, если хотите реализовывать сложные в разработке, но простые для юзеров приложения, а также разбираться в инструментах и практиках, которые применяют наши специалисты 🙋
29 августа в Санкт-Петербурге пройдёт VK JT Mobile, первая конференция VK для мобильных разработчиков на iOS и Android. Вспомним прошлое, обсудим будущее и, опираясь на наш опыт, расскажем, как моментально внедрять технологии, структурировать миллионы строк кода и постоянно улучшать продуктовые метрики.
В программе нестандартные сценарии работы с пушами, упрощение разработки с помощью нейросетей, фичи для анализа ошибок и даже реализация приложений для автомобилей. Подробнее — на сайте.
Регистрируйтесь, если хотите реализовывать сложные в разработке, но простые для юзеров приложения, а также разбираться в инструментах и практиках, которые применяют наши специалисты 🙋
Understanding Sendable protocol in Swift 6
Тип Sendable — это такой тип, который можно безопасно передавать в параллельной среде. Это могут быть типы значений, такие как структуры, финальные классы с константными свойствами, акторы, которые автоматически защищают свое изменяемое состояние, и многое другое.
В этой статье можно легко познакомиться для чего нужен такой тип, какую проблему он решает и какие проблемы он создает😂
Тип Sendable — это такой тип, который можно безопасно передавать в параллельной среде. Это могут быть типы значений, такие как структуры, финальные классы с константными свойствами, акторы, которые автоматически защищают свое изменяемое состояние, и многое другое.
В этой статье можно легко познакомиться для чего нужен такой тип, какую проблему он решает и какие проблемы он создает
Please open Telegram to view this post
VIEW IN TELEGRAM
iOS Developer Diary
Understanding Sendable protocol in Swift 6 - iOS Developer Diary
Sendable protocol in Swift 6. The Sendable protocol indicates that type is safe to be used concurrently within new swift concurrency and The main rule is that ONLY Sendable types can escape an Actor or Task to another Actor or Task.
🌿 Результаты опросов среди руководителей "Определение грейдов в мобильной разработке"
Почти месяц назад я выкладывал пост о смутной границы на рынке среди разрабов. Сложно определить кто джун, а кто мидл. В чем разница мидла+ от сеньора.
Я решил пройтись по опытным руководителям крупных и неочень компаний: яндекс, авито, т-банк, вк и другие.
Где задал такие вопросы:
🟣 Для каких задач нужны джуниоры?
🟣 Для каких задач нужны мидлы?
🟣 Определи критерии для сеньор позиции? В чем ключевая разница между мидлом и сеньором?
Более детальный анализ можно увидеть в ноушене
Почти месяц назад я выкладывал пост о смутной границы на рынке среди разрабов. Сложно определить кто джун, а кто мидл. В чем разница мидла+ от сеньора.
Я решил пройтись по опытным руководителям крупных и неочень компаний: яндекс, авито, т-банк, вк и другие.
Где задал такие вопросы:
Более детальный анализ можно увидеть в ноушене
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Ответы на задачу недели
Летний режим — период отпусков, прогулок, пляжей и шашлыков. Хоть пусть и в ленивом режиме, но мы не перестаем развиваться. На днях я добавил новую рубрику — решение задач недели.
Это модифицированные задачи из литкода, измененные задачи из собесов. Или придуманы на ходу. Вот мы начали решать задачу из стажировок яндекса. Хотя, кто-то говорит, что и на собесах она появляется.
Такие задачи помогают не просто узнать чужие решения, но и подходы при написания кода. Увеличить насмотренность. Научиться техникам, которые помогут эффективнее проходить ревью.
Для кого-то важнее перфоманс, для кого-то меньше символов, для кого-то выразительность и логичность. Что бы это не значало.
Кстати, на следующей недели будет первый мок-собес по алгоритмам
Летний режим — период отпусков, прогулок, пляжей и шашлыков. Хоть пусть и в ленивом режиме, но мы не перестаем развиваться. На днях я добавил новую рубрику — решение задач недели.
Это модифицированные задачи из литкода, измененные задачи из собесов. Или придуманы на ходу. Вот мы начали решать задачу из стажировок яндекса. Хотя, кто-то говорит, что и на собесах она появляется.
Такие задачи помогают не просто узнать чужие решения, но и подходы при написания кода. Увеличить насмотренность. Научиться техникам, которые помогут эффективнее проходить ревью.
Для кого-то важнее перфоманс, для кого-то меньше символов, для кого-то выразительность и логичность. Что бы это не значало.
Кстати, на следующей недели будет первый мок-собес по алгоритмам
Опустошенный рынок или как возраждаются процессы развития
Вчера я писал пост про менторство, но решил чуть его переформулировать.
Почему компании начали меньше верить в найм и больше вкладывать во внутренние и внешние процессы развития?
Сейчас, в крупных компаниях, все больше делается акцент на скиллах менторства и обучения.
Почему? Казалось бы, есть орды разрабов у двери, которые жаждят своей работы. Почему же не нанимать их?
Во-первых, колличество не значит качество. Их базовые настройки не совсем нужного качества. У многих компаний свои кастомные технологии, уникальная культура, требования к софтам и хардам. Даже если ты был доном сеньором-помидором в своем бигтехе, то легко можешь не соответствовать стандартам другой компании.
Приведем пример с рынком машин. Сейчас с уходом многих диллеров процветает рынок китайского и отечественного автопрома. Закрывает ли он проблему спроса? Конечно же нет. При этом цена такая же как на машины классом и качества лучше.
И те, и другие есть за что критиковать. Они не закрывают потребность спроса. Для многих автолюбителей рынок хороших машин пуст, а из-за безвыходности приходится пересаживаться на машины качеством хуже.
Или как перейти на ВК или Рутюб, после блокировки ютуба. Вынужденная мера, которая забудется сразу, как разблокируют ютуб или найдут альтернативу лучше.
Также и на рынке труда. Хороших разрабов, которые еще и хотят ходить в офис, очень мало. Вместо них есть множество тех, кто за 2-3 месяца закончил курсы и объем их двигателя сжирает топлива больше, чем нужно. Быть может для обычных задач они подходят, но наниматель хочет лучшие кадры, а худшие отдавать конкурентам.
Но здесь есть выход. Пусть поставки и бракованные, но мы можем их пофиксить через менторов.
Огромные очереди стоят на улице у двери в поисках работы. Отзывать ли партию на ликвидацию? Нет. В отличие от машин мы можем их пофиксить и перенастроить
Новый тренд — это когда компании становятся не только местом работы, но и школой жизни и карьеры.
Вчера я писал пост про менторство, но решил чуть его переформулировать.
Почему компании начали меньше верить в найм и больше вкладывать во внутренние и внешние процессы развития?
Сейчас, в крупных компаниях, все больше делается акцент на скиллах менторства и обучения.
Почему? Казалось бы, есть орды разрабов у двери, которые жаждят своей работы. Почему же не нанимать их?
Во-первых, колличество не значит качество. Их базовые настройки не совсем нужного качества. У многих компаний свои кастомные технологии, уникальная культура, требования к софтам и хардам. Даже если ты был доном сеньором-помидором в своем бигтехе, то легко можешь не соответствовать стандартам другой компании.
Приведем пример с рынком машин. Сейчас с уходом многих диллеров процветает рынок китайского и отечественного автопрома. Закрывает ли он проблему спроса? Конечно же нет. При этом цена такая же как на машины классом и качества лучше.
И те, и другие есть за что критиковать. Они не закрывают потребность спроса. Для многих автолюбителей рынок хороших машин пуст, а из-за безвыходности приходится пересаживаться на машины качеством хуже.
Или как перейти на ВК или Рутюб, после блокировки ютуба. Вынужденная мера, которая забудется сразу, как разблокируют ютуб или найдут альтернативу лучше.
Также и на рынке труда. Хороших разрабов, которые еще и хотят ходить в офис, очень мало. Вместо них есть множество тех, кто за 2-3 месяца закончил курсы и объем их двигателя сжирает топлива больше, чем нужно. Быть может для обычных задач они подходят, но наниматель хочет лучшие кадры, а худшие отдавать конкурентам.
Но здесь есть выход. Пусть поставки и бракованные, но мы можем их пофиксить через менторов.
Огромные очереди стоят на улице у двери в поисках работы. Отзывать ли партию на ликвидацию? Нет. В отличие от машин мы можем их пофиксить и перенастроить
Новый тренд — это когда компании становятся не только местом работы, но и школой жизни и карьеры.
Я потихоньку выхожу из летней рутины. Почему-то, летом стало гораздо больше работы. К тому же, это тот период, который хочется больше проводить за границами четерых стен. Но этот период нужен, так как взяв паузу ты можешь сделать ретроспективу, посмотреть назад, вынести экшен айтемы и улучшить себя.
Так я формирую крепче свой контент и, не побоюсь этого слова, творчество. Оно строится на мнениях, фактах, сообществе и реальном опыте.
Отпуска заканчиваются. Начинаю приносить больше контента. На этот раз принес новый уникальный раздел, который почему-то аккуратно обходят другие. А я хочу делать на нем акценты.
Я нахожу себя. Мой контент становится более авторским. Я перестаю делать этот канал как десятки других — тупо выкладывать чужие статьи под сделанную за пять минут обложку в фигме. С развитием чатгпт качество и ценность такого контента падает. Я не хочу гордо называть это композицию "своим постом". Забавная такая приватизация.
Для этого нужно ревью. Умение адекватно прислушаться к фидбэку коллеги и внести фиксы. Да, из-за этого может показаться, что регулярность становится меньше, но качество только выигрывает. Так как имеет свойство настраиваться и концентрироваться.
Любое авторство не имеет место быть без публики и тонны фидбэка. Поэтому мне и нужен был чат. Он пишет комменты в моих реквестах. Не всегда комменты моих коллег понятны или приняты, но без них нельзя формировать свой стиль.
Пока остальные фокусируются на пересказе чужих статей или форме, то мы фокусируемся на контенте и личном уникальном опыте. Стараемся поднимать то, что поднимается только на реальной практике. В этом и различие авторского канала от новостного. Как говорится, чужой опыт ты не скопируешь просто прочитав книжку или статью. Личный уникальный опыт не может быть без кодревью. Без механизма валидации всех тех идей, которые ты собрал в очередной статье по чатгпт.
Честно признаюсь, Для меня кодревью — это одновременно самая важная и неважная вещь. С одной стороны, этот процесс помогает писать поддерживаемый код. С другой стороны, этот процесс не нужен, если были бы другие инструменты развития.
Но а пока таких процессов нет, то мы развиваем этот.
В любом бигтехе на код ревью часто уходит время больше, чем на само написания. Ведь читабельность кода часто превыше всего. Написанный код останется надолго и к нему нужно возвращаться спустя годы. Плохой процесс или его отсутствие может быть не только причиной плохого технического состояния проекта, но и даже причиной стресса или увольнения разработчиков.
Этот вопрос занимает много времени. Этому скиллу не научишься не пройдя реальный опыт в 10к комментов твоих реквестов.
Я собрал лучшие практики, книги, стайлгайды и советы, которые помогут писать код чище, улучшить процессы в команде и проходить ревью быстрее.
В этом блоке я собрал и буду собирать:
Я ценю всех, кто поддерживает. Качество моего контента зависит от адекватного фидбэка, моих интересов и ваших ожиданий.
Не нужно формировать мышление и знания на пересказах чужих статей. Только на реальном окружении и практических вещах. Через дискуссии и критическое мышление.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Кодируем
Зачем нужны алгоритмы?
Получается, ты изучаешь инструмент ради интрумента, а не для полевых условий.
Много людей продолжают думать, что алгосики - это баловство, ненужная трата времени и нигде не применяются.
Я уже писал про это в постах про рекурсию.
Тажке общался с вами в видео про методы решения задач.
🧠 https://t.iss.one/koduryem/26
В двух последних видео много говорили про дп, ход мышления и подходы к проблемам.
Также у меня есть видео про другие темы, такие как Heap, BinarySearch, LRU, LFU и др.
Please open Telegram to view this post
VIEW IN TELEGRAM
Подборка статей про рефакторинг кода
Я буду много раз тут писать, что рынок меняется и становится сознательным. Навык рефакторинга кода становится более важным в современной разработке. Период активного роста, когда нужно было делать много фич, закончился. Сейчас время поддержки.
Где нужно лезть в чужой код разного качества, уметь его читать и интегрировать свои фичи. Это отдельный навык, к которому не все готовы.
Для знакомства я собрал пару базовых статей:
🟣 Refactoring Swift: Best Practices to succeed
🟣 How to Refactor Your Swift Code Like a Pro
🟣 Refactor Legacy Code with Swift
🟣 Refactoring iOS Apps – A Pragmatic Guide
Я буду много раз тут писать, что рынок меняется и становится сознательным. Навык рефакторинга кода становится более важным в современной разработке. Период активного роста, когда нужно было делать много фич, закончился. Сейчас время поддержки.
Где нужно лезть в чужой код разного качества, уметь его читать и интегрировать свои фичи. Это отдельный навык, к которому не все готовы.
Для знакомства я собрал пару базовых статей:
Please open Telegram to view this post
VIEW IN TELEGRAM
SwiftLee
Refactoring Swift: Best Practices to succeed
Refactoring code is essential to maintain quality and readability. Using best practices you'll become better at succeeding a big code change.
Хорошего программиста от теорика консультанта определяет только код.
Задачи на рефакторинг кода становятся все более популярные. Интервьюеры и компании уходят от формата вопрос/ответ и идут к более практическим вещам. Эрудицией никого не удивишь, загуглить ответ на вопрос не составит труда. Теория себя изжила и уже недостаточно просто заучить ответы, прочитать статью. Важно применять свои знания на практике.
Такие задачи хороши тем, что сразу помогают оценить знания и навыки разработчика по множеству тем: от знания языка, памяти и многопоточности, до запахов кода и архитектур. А также лучше помогают найти кандидатов с реальным практическим опытом, а не хорошим скиллом прохождения собесов. В нем сразу можно оценить сколько комментариев разной критичности придется писать коллеге на кодревью
В рамках нового блока кодревью я буду поднимать вопросы, задачи и темы по поводу написания кода и работе в командах. Ведь программист и отличается от консультанта, что много пишет код. А значит умеет легко должен давать оценку коду.
Здесь будет минимум теории и максимум кода. В текущем блоке я собрал задачи:
Также мы придумали новый тренажер в чате — рефакторить код известных либ или опенсоурсов: от телеграма до alamofire
Please open Telegram to view this post
VIEW IN TELEGRAM