Извиняюсь, что поздно ответил, но отлично. Насколько я вижу по комментариям ниже кому-то это действительно помогло. Хотя признаюсь честно с примерами других паттернов будет сложнее. Из недавнего использовал разновидность фабрики для организации atLeastOneMessage при работе с апач кафкой. Есть желание продолжать статьи на тему паттернов? Если надо, то могу помочь в поиске практических примеров.
Извиняюсь, этого момента не знал, спасибо, что поправили. Хотя лично я предпочитаю не доверять интерпретаторам и компиляторам на 100%, так что знать про то как оно работает внутри в любом случае полезно. Ну и плюс интересно, как себя поведет cpython при более комплексной логике построения строки. В любом случае, в одной это ветке больше глубины погружения, чем во всей статье выше.
Тут недавно статья была про программирование за "гранью", где взяли рандомные куски кода на js и python, про которые даже стажер знать должен. Теперь глубокое погружение в + и * , когда про умножение и складывание строк рассказывают при первом изучении этих операторов, а про магические методы складывания и умножения узнают сразу, когда начинают изучать магические методы.
Глубокое погружение возможно было бы при рассказе про переполнения на python, а точнее его отсутствия в привычном виде и почему это так, или почему оно все же возможно при работе с pandas или numpy или при работе с float к примеру.
Глубокое погружение возможно было бы при рассказе о том как на самом деле складываются строки и какая алокация при этом происходит и почему складывание большого количества строк по средствам цикла не очень хорошая идея.
Ну или на крайний случай хотя бы пример какой-нибудь реализации магических методов. К примеру класс вектора реализующий метод складывания векторов. Уже было бы значительно полезнее. А так мы имеем, что новичок который прочитает статью вспомнит разве что про складывание строк, про которое он уже скорее всего знал, а про магические методы так ничего и не поймет. Тому же, кто знает про магические методы ваша статья тем более ничего не даст.
Что за странный микс языков в статье? Почему в хабах только программирование, когда половина статьи, если не больше касается отдельных языков? По пунктам статьи:
# Плохо
x = 10 y = 20
# Хорошо width = 10 height = 20
1. Касается всех языков - ок (к слову, x,y - корректны, когда это касается координат, также как i,j,k относительно определенных случаев)
// Обычное условие
if (isLogged) { message = "Пользователь авторизован"; } else { message = "Пользователь не авторизован"; }
// Использование тернарного оператора message = isLogged ? "Пользователь авторизован" : "Пользователь не авторизован";
2. Касается JS и Python(если знать в нем аналогичный синтаксис), но не применимо в Go к примеру
# Без функции
result = (x * y) + (x * z) - (y * z)
# С функцией def calculate_result(x, y, z): return (x * y) + (x * z) - (y * z)
result = calculate_result(x, y, z)
3.Касается всех языков, но статья называется программирование за гранью. Когда вынос кода в функцию вышел за грань?
# Без генератора
squared_numbers = [] for number in range(1, 11): squared_numbers.append(number ** 2)
# С генератором squared_numbers = [number ** 2 for number in range(1, 11)]
4. Касается только Python. Это не генератор, это list comprehension, он при своем вызове создаст сразу список. Генератор объявляется или через yield или как list comprehension, НО с круглыми скобками.
# С контекстным менеджером with open("example.txt", "r") as file: content = file.read() # Файл автоматически закроется после выхода из блока with
Контекстные менеджеры есть далеко не везде, честно признаюсь такую реализацию знаю только в python. В Go есть что-то похожее - defer, но суть у него все же другая
// Без использования nullish оператора
let user = getUser(); let username = user ? user.name : "Гость";
// С использованием nullish оператора let user = getUser(); let username = user?.name ?? "Гость";
Снова JS - опять же аналога для Go или Python я не помню
Так для кого эта статья? Для начинающего разработчика, который знает синтаксис Python и JS? Так если она для начинающих, то тут каждый пункт на отдельную статью можно растянуть, тк начинающему надо все рассказывать и уж точно не миксовать 2 языка в одной статье. Контекстные менеджеры на питоне и генераторы тоже отдельная глубокая тема, которая требует знания магических методов, включая асинхронные. Регулярные выражения тоже крайне глубокая тема, как минимум нужно уметь прикидывать пограничные случаи. И если она для начинающих, то что за программирование за гранью? Я к примеру, пришел как разработчик на Go прочитать статью, которая должны дать мне какие-то новые подходы, как разработчику в целом.
Честно говоря до сих пор не понимаю зачем делать столь абстрактные примеры, что их зачастую поймут только люди, которые эти паттерны знают, а разработчик который хочет их понять только сильнее запутается и тем более не будет понимать где их применять.
Ну а как пример, который имеет практический смысл могу предложить любую библиотеку, которая что-то делает внутри себя и на входе просит логгер, а у вас есть логгер, который в чистом виде не подходит для этой либы.
Тут вопрос не к вашей статье в частности, а к отсутствию практических примеров в целом при разборе паттернов
Не совсем согласен, если мидл требует присмотра, то это джун+ максимум. А если рассматривать это в ключе код ревью, то и для сеньоров оно лишним не будет.
Почему вы считаете, что его резюме пропускали мимо из-за вышки? Я вижу тут другой момент, возраст и егэ + отсутствие опыта в резюме из-за которого многие не видели смысла тратить время
Даже если он уйдет из компании или она закроется, то у него в любом случае будет опыт 1+ год из-за чего через фильтры многих hr он пройдет
Аргумент про армию не корректный, тк после вуза вопрос с армией будет также открыт
По поводу резюме автора вопрос крайне интересный, тк если судить по статье, то уже во время работы он узнал про typescript и scss. Как минимум typescript сейчас стандарт отрасли(если не считать дремучее легаси), который требуют от каждого джуна. А знание какого-нибудь препроцессора css дало бы еще +1 к резюме.
Из всех пунктов выше мы имеем, что взяли его скорее всего на позицию стажера(могли и джуном назвать, но сути не меняет - он стажер). А на стажера многие компании просто не видят смысла тратить свое время, когда количество джунов, особенно фронтенд джунов, превышает все разумные пределы. Я не спорю, что вышка дает плюс к резюме, но - опыт работы > вышка. А он этот опыт уже получает.
Хотелось бы отметить один важный момент, достаточно часто в юнит-тестах используют моки. В этом нет ничего плохого, но есть моменты, которые из-за этого стоит учитывать. К примеру у нас есть 4 юнита - A, B, C, D в A используются: B, C в C используются: D В данном примере сделаем вид, что все юниту используют моки на месте других юнитов (обычно конечно не везде моки, и это хорошо, но для примера оставим так) И к примеру A, C, D - покрыты тестами, а B - нет В данном случае мы имеем, что т.к C и D покрыты тестами, то мы можем быть уверены в их корректной работе(хотя всегда уверенным на 100% быть не стоит), а вот в юните A мы уверены быть не можем, тк его внутренняя логика хоть и верная, но когда мы подключим вместо мока юнит B, то могут быть ошибки. При таком сценарии юнит тесты наоборот несут больше вреда, чем пользы, тк могут дать ложную уверенность в корректности кода(хотя на самом деле это касается всех видов тестирования, если они написаны плохо)
Ну просто я на Go пишу, и заметить что дедлок существует куда проще, приложение просто падает, а вот в случае с лайвлоком можно долго не замечать, что приложение запущено, но полезной работы никакой не делает(Хотя есть косвенные признаки, когда на каком-то инстансе приложения сильно просел rps к примеру)
Вот вообще курсы и самообучение ни разу не похожи. Курсы: информация -> задача по этой информации -> повторить Самообучение: проблема -> гугл -> решение(ошибочное) -> проблема из-за решения -> гугл -> возможно правильное решение -> повторить
На просторах гугла можно найти очень много ложной информации, которую надо уметь отсеивать. Как мне кажется, если и идти на курсы, то только когда ты сам наступил на всевозможные грабли, и то, только для того, чтобы закрыть пробелы в базовых знаниях(а они будут).
Тут полностью согласен. Учитывая, что при решении схожих задач, но на разных местах работы, программист скорее всего возьмет решение, которое уже когда-то использовал(скоре всего даже не осознавая это). Правда это не касается каких-то специфичных алгоритмов, которые были придуманы для конкретной компании, вот их повторное использование точно будет осознано, ну и вполне могут быть юридические последствия.
Да, но может быть несколько подводных камней из-за которых это перестает выглядеть так просто: 1. Техлид имеет больший авторитет в компании, чем автор статьи. 2. Техлид долго в компании, в коде много легаси, проект держится только на нем
Ко всему прочему для руководства это может выглядеть иначе: 1. Как это выглядит для нас - тимлид собеседовал вполне толковых людей, но техлид их забраковал из-за чего не получилось закрыть вакансии 2. Как это может выглядеть для руководства - тимлид несколько месяцев не может найти толковых людей, а техлид старается не допустить плохих специалистов в компанию. Ко всему прочему из-за того, что тимлид не закрывает вакансии горит какой-то проект уже
Соответственно для руководства кредит доверия тимлиду может быть сильно меньше, чем техлиду. Я не говорю, что стоит ничего не делать и просто закрывать глаза, но и делать вид, что это исправляется по щелчку пальца тоже не стоит. К сожалению такие ситуации обычно куда сложнее.
Так я только за) Поэтому такие шпаргалки вдвойне бесполезны, если ты можешь развить тему, то они тебе и не нужны, а если нет, то твое незнание быстро раскроется. Ну и плюс, если знающий человек забудет какие-то термины(такое в целом не редкость), то в любом случае даже на пальцах сможет найти общий язык с интервьюером(если тот конечно сам разбирается, а не взял просто магический опросник, с надеждой на то, что тот за него работу сделает).
В каком-то комментарии выше ответили, что эта статья написана в ответ на другую статью. Другой вопрос, что все вопросы, которые там(и здесь) перечислены, построены таким образом, что каждый можно раскрывать минут по 10, дополняя краевыми случаями. Банально устройство мапы и синхронизация - казалось бы, если мы уверены, что будем писать в параллельно только уникальные значения, то может обойтись без синхронизации? Нет, не можем, по той причине, что, когда бакеты будут заполнены в среднем на 6.5(размер бакета 8, если я правильно помню), то будут пересчитаны новые бакеты и запущен процесс перебалансировки, а в этот момент, другая горутина может писать в мапу, что в конечном итоге вызовет панику.
Спасибо, про некоторые моменты не знал. За это и люблю комментарии на хабре) 1. Про полторы секунды до запуска GC не знал от слова совсем. С одной стороны в обычной работе это быть проблемной не должно, но в случае падения сервиса, может произойти так, что из-за этой задержки сервис будет падать и падать, что в целом может привести к отказу всех остальных инстансов. Я правильно понимаю? Были ли у вас случае в проде, когда это действительно было проблемой? И не поможет ли запуск хартбита с задержкой как минимум 1.5-2 секунды (хотя обычно столько занимает поднятие сервера, подключение к хранилищам и тд) 2. Имхо, но запятые это вкусовщина 3. Передача по значению - когда переходил с питона, то было не очень удобно, со временем привык, ide в целом это закрывают. Хотя, если затронули вопрос передачи аругментов, то хотелось бы увидеть опциональные поля, проверка полей в структурах-конфигах не самая приятная процедура, когда полей там 10-20. 4. С рефлексией полностью согласен, но насколько я знаю (хотя могу и ошибаться), сейчас разработчики go пишут новые стандартные библиотеки на основе дженериков, правда сколько времени займет переписывание большего функционала go - впорос. 5. Дополню пункт про передачу слайса, мапы и тд. На самом деле это далеко не самые опасные случаи, про них практически все знают. На что действительно стоит обращать внимание, так это на структуры, в которых есть указатели, и на структуры, с мапами и слайсами(для таких структур я в 90% случаев стараюсь передавать сразу указатель на структуру) 6. Но немного не согласен со строками, насколько я знаю строки - это массив символов. Единственный момент, что go нам не позволяет видоизменять этот массив, а при присвоении другого значения в переменную, мы просто создаем новую строку в памяти.
Если в каких-то моментах ошибся, то буду рад, если меня поправят.
Действительно интересно, но у меня есть подозрения, что добавляет колонки в конец, только если точечно переставлять в конец колонки. Но тут вопрос, что быстрее.
Лично мне совесть не позволит привести в команду человека, в котором я не уверен. Я понимаю, что люди разные, но, как мне кажется, при таком отборе, со временем может собраться команда, где все примерно так думают, есть и другой вариант развития событий, если этот процесс не контролировать, то со временем может случиться то, что вы описали выше, когда все друг другу брат сват и тд, но никто толком не работает. В общем, как обычно, без серебряной пули
Извиняюсь, что поздно ответил, но отлично. Насколько я вижу по комментариям ниже кому-то это действительно помогло. Хотя признаюсь честно с примерами других паттернов будет сложнее. Из недавнего использовал разновидность фабрики для организации atLeastOneMessage при работе с апач кафкой. Есть желание продолжать статьи на тему паттернов? Если надо, то могу помочь в поиске практических примеров.
Извиняюсь, этого момента не знал, спасибо, что поправили. Хотя лично я предпочитаю не доверять интерпретаторам и компиляторам на 100%, так что знать про то как оно работает внутри в любом случае полезно. Ну и плюс интересно, как себя поведет cpython при более комплексной логике построения строки. В любом случае, в одной это ветке больше глубины погружения, чем во всей статье выше.
Тут недавно статья была про программирование за "гранью", где взяли рандомные куски кода на js и python, про которые даже стажер знать должен.
Теперь глубокое погружение в + и * , когда про умножение и складывание строк рассказывают при первом изучении этих операторов, а про магические методы складывания и умножения узнают сразу, когда начинают изучать магические методы.
Глубокое погружение возможно было бы при рассказе про переполнения на python, а точнее его отсутствия в привычном виде и почему это так, или почему оно все же возможно при работе с pandas или numpy или при работе с float к примеру.
Глубокое погружение возможно было бы при рассказе о том как на самом деле складываются строки и какая алокация при этом происходит и почему складывание большого количества строк по средствам цикла не очень хорошая идея.
Ну или на крайний случай хотя бы пример какой-нибудь реализации магических методов. К примеру класс вектора реализующий метод складывания векторов. Уже было бы значительно полезнее. А так мы имеем, что новичок который прочитает статью вспомнит разве что про складывание строк, про которое он уже скорее всего знал, а про магические методы так ничего и не поймет. Тому же, кто знает про магические методы ваша статья тем более ничего не даст.
Мне скорее интересно, что это за компания такая, где все менеджеры решили стать разработчиками, а разработчики менеджерами
Что за странный микс языков в статье?
Почему в хабах только программирование, когда половина статьи, если не больше касается отдельных языков?
По пунктам статьи:
1. Касается всех языков - ок (к слову, x,y - корректны, когда это касается координат, также как i,j,k относительно определенных случаев)
2. Касается JS и Python(если знать в нем аналогичный синтаксис), но не применимо в Go к примеру
3.Касается всех языков, но статья называется программирование за гранью. Когда вынос кода в функцию вышел за грань?
4. Касается только Python. Это не генератор, это list comprehension, он при своем вызове создаст сразу список. Генератор объявляется или через yield или как list comprehension, НО с круглыми скобками.
5. Касается далеко не всех языков, в JS синтаксиса к примеру этого нет, аналогичное [-1] надо выполнять через array.length-1
Контекстные менеджеры есть далеко не везде, честно признаюсь такую реализацию знаю только в python. В Go есть что-то похожее - defer, но суть у него все же другая
Снова JS - опять же аналога для Go или Python я не помню
Так для кого эта статья? Для начинающего разработчика, который знает синтаксис Python и JS? Так если она для начинающих, то тут каждый пункт на отдельную статью можно растянуть, тк начинающему надо все рассказывать и уж точно не миксовать 2 языка в одной статье. Контекстные менеджеры на питоне и генераторы тоже отдельная глубокая тема, которая требует знания магических методов, включая асинхронные. Регулярные выражения тоже крайне глубокая тема, как минимум нужно уметь прикидывать пограничные случаи. И если она для начинающих, то что за программирование за гранью? Я к примеру, пришел как разработчик на Go прочитать статью, которая должны дать мне какие-то новые подходы, как разработчику в целом.
И последний вопрос, что за тег "пиши код блядь"?
Честно говоря до сих пор не понимаю зачем делать столь абстрактные примеры, что их зачастую поймут только люди, которые эти паттерны знают, а разработчик который хочет их понять только сильнее запутается и тем более не будет понимать где их применять.
Ну а как пример, который имеет практический смысл могу предложить любую библиотеку, которая что-то делает внутри себя и на входе просит логгер, а у вас есть логгер, который в чистом виде не подходит для этой либы.
Тут вопрос не к вашей статье в частности, а к отсутствию практических примеров в целом при разборе паттернов
Не совсем согласен, если мидл требует присмотра, то это джун+ максимум. А если рассматривать это в ключе код ревью, то и для сеньоров оно лишним не будет.
Почему вы считаете, что его резюме пропускали мимо из-за вышки? Я вижу тут другой момент, возраст и егэ + отсутствие опыта в резюме из-за которого многие не видели смысла тратить время
Даже если он уйдет из компании или она закроется, то у него в любом случае будет опыт 1+ год из-за чего через фильтры многих hr он пройдет
Аргумент про армию не корректный, тк после вуза вопрос с армией будет также открыт
По поводу резюме автора вопрос крайне интересный, тк если судить по статье, то уже во время работы он узнал про typescript и scss. Как минимум typescript сейчас стандарт отрасли(если не считать дремучее легаси), который требуют от каждого джуна. А знание какого-нибудь препроцессора css дало бы еще +1 к резюме.
Из всех пунктов выше мы имеем, что взяли его скорее всего на позицию стажера(могли и джуном назвать, но сути не меняет - он стажер). А на стажера многие компании просто не видят смысла тратить свое время, когда количество джунов, особенно фронтенд джунов, превышает все разумные пределы. Я не спорю, что вышка дает плюс к резюме, но - опыт работы > вышка. А он этот опыт уже получает.
Хотелось бы отметить один важный момент, достаточно часто в юнит-тестах используют моки. В этом нет ничего плохого, но есть моменты, которые из-за этого стоит учитывать.
К примеру у нас есть 4 юнита - A, B, C, D
в A используются: B, C
в C используются: D
В данном примере сделаем вид, что все юниту используют моки на месте других юнитов (обычно конечно не везде моки, и это хорошо, но для примера оставим так)
И к примеру
A, C, D - покрыты тестами, а B - нет
В данном случае мы имеем, что т.к C и D покрыты тестами, то мы можем быть уверены в их корректной работе(хотя всегда уверенным на 100% быть не стоит), а вот в юните A мы уверены быть не можем, тк его внутренняя логика хоть и верная, но когда мы подключим вместо мока юнит B, то могут быть ошибки.
При таком сценарии юнит тесты наоборот несут больше вреда, чем пользы, тк могут дать ложную уверенность в корректности кода(хотя на самом деле это касается всех видов тестирования, если они написаны плохо)
Ну просто я на Go пишу, и заметить что дедлок существует куда проще, приложение просто падает, а вот в случае с лайвлоком можно долго не замечать, что приложение запущено, но полезной работы никакой не делает(Хотя есть косвенные признаки, когда на каком-то инстансе приложения сильно просел rps к примеру)
Вот вообще курсы и самообучение ни разу не похожи.
Курсы:
информация -> задача по этой информации -> повторить
Самообучение:
проблема -> гугл -> решение(ошибочное) -> проблема из-за решения -> гугл -> возможно правильное решение -> повторить
На просторах гугла можно найти очень много ложной информации, которую надо уметь отсеивать. Как мне кажется, если и идти на курсы, то только когда ты сам наступил на всевозможные грабли, и то, только для того, чтобы закрыть пробелы в базовых знаниях(а они будут).
Тут полностью согласен. Учитывая, что при решении схожих задач, но на разных местах работы, программист скорее всего возьмет решение, которое уже когда-то использовал(скоре всего даже не осознавая это). Правда это не касается каких-то специфичных алгоритмов, которые были придуманы для конкретной компании, вот их повторное использование точно будет осознано, ну и вполне могут быть юридические последствия.
Бывают ли в C# лавйлоки? Если да, то вот их на порядок сложнее искать, чем дедлоки и тд.
Да, но может быть несколько подводных камней из-за которых это перестает выглядеть так просто:
1. Техлид имеет больший авторитет в компании, чем автор статьи.
2. Техлид долго в компании, в коде много легаси, проект держится только на нем
Ко всему прочему для руководства это может выглядеть иначе:
1. Как это выглядит для нас - тимлид собеседовал вполне толковых людей, но техлид их забраковал из-за чего не получилось закрыть вакансии
2. Как это может выглядеть для руководства - тимлид несколько месяцев не может найти толковых людей, а техлид старается не допустить плохих специалистов в компанию. Ко всему прочему из-за того, что тимлид не закрывает вакансии горит какой-то проект уже
Соответственно для руководства кредит доверия тимлиду может быть сильно меньше, чем техлиду. Я не говорю, что стоит ничего не делать и просто закрывать глаза, но и делать вид, что это исправляется по щелчку пальца тоже не стоит. К сожалению такие ситуации обычно куда сложнее.
Так я только за)
Поэтому такие шпаргалки вдвойне бесполезны, если ты можешь развить тему, то они тебе и не нужны, а если нет, то твое незнание быстро раскроется. Ну и плюс, если знающий человек забудет какие-то термины(такое в целом не редкость), то в любом случае даже на пальцах сможет найти общий язык с интервьюером(если тот конечно сам разбирается, а не взял просто магический опросник, с надеждой на то, что тот за него работу сделает).
В каком-то комментарии выше ответили, что эта статья написана в ответ на другую статью. Другой вопрос, что все вопросы, которые там(и здесь) перечислены, построены таким образом, что каждый можно раскрывать минут по 10, дополняя краевыми случаями. Банально устройство мапы и синхронизация - казалось бы, если мы уверены, что будем писать в параллельно только уникальные значения, то может обойтись без синхронизации? Нет, не можем, по той причине, что, когда бакеты будут заполнены в среднем на 6.5(размер бакета 8, если я правильно помню), то будут пересчитаны новые бакеты и запущен процесс перебалансировки, а в этот момент, другая горутина может писать в мапу, что в конечном итоге вызовет панику.
Спасибо, про некоторые моменты не знал. За это и люблю комментарии на хабре)
1. Про полторы секунды до запуска GC не знал от слова совсем. С одной стороны в обычной работе это быть проблемной не должно, но в случае падения сервиса, может произойти так, что из-за этой задержки сервис будет падать и падать, что в целом может привести к отказу всех остальных инстансов. Я правильно понимаю? Были ли у вас случае в проде, когда это действительно было проблемой? И не поможет ли запуск хартбита с задержкой как минимум 1.5-2 секунды (хотя обычно столько занимает поднятие сервера, подключение к хранилищам и тд)
2. Имхо, но запятые это вкусовщина
3. Передача по значению - когда переходил с питона, то было не очень удобно, со временем привык, ide в целом это закрывают. Хотя, если затронули вопрос передачи аругментов, то хотелось бы увидеть опциональные поля, проверка полей в структурах-конфигах не самая приятная процедура, когда полей там 10-20.
4. С рефлексией полностью согласен, но насколько я знаю (хотя могу и ошибаться), сейчас разработчики go пишут новые стандартные библиотеки на основе дженериков, правда сколько времени займет переписывание большего функционала go - впорос.
5. Дополню пункт про передачу слайса, мапы и тд. На самом деле это далеко не самые опасные случаи, про них практически все знают. На что действительно стоит обращать внимание, так это на структуры, в которых есть указатели, и на структуры, с мапами и слайсами(для таких структур я в 90% случаев стараюсь передавать сразу указатель на структуру)
6. Но немного не согласен со строками, насколько я знаю строки - это массив символов. Единственный момент, что go нам не позволяет видоизменять этот массив, а при присвоении другого значения в переменную, мы просто создаем новую строку в памяти.
Если в каких-то моментах ошибся, то буду рад, если меня поправят.
Действительно интересно, но у меня есть подозрения, что добавляет колонки в конец, только если точечно переставлять в конец колонки. Но тут вопрос, что быстрее.
Можешь заглянуть к нему в тг за ответом :)
Лично мне совесть не позволит привести в команду человека, в котором я не уверен. Я понимаю, что люди разные, но, как мне кажется, при таком отборе, со временем может собраться команда, где все примерно так думают, есть и другой вариант развития событий, если этот процесс не контролировать, то со временем может случиться то, что вы описали выше, когда все друг другу брат сват и тд, но никто толком не работает. В общем, как обычно, без серебряной пули