Предположу, минусуют те, кто не смог прочитать статью Кокса на английском и ожидал увидеть в предисловии описание на русском, что такое SparseMap и GenerationsMap.
В качестве исследовательского проекта - библиотека выглядит отлично и очень интересно. Интересно было бы посмотреть на работу с большими объемами текстов, как она себя ведет по потреблению памяти.
С практической точки зрения функция парсинга получается многословной с большим кол-вом служебных слов (yield, lambda), которые говорят о протекании внутреннего устройства библиотеки в пользовательский код. Регекспы, действительно, выглядят посимпатичнее. Хотя там нет такой удобной работы с position.
Было бы интересно добавить в статью как раз один-два примера, где PGPC удобнее regexp.
Здесь стоит философски посмотреть на то, что качественный код - это не залог доходности бизнеса. Знаю, действительно, много проектов, которые успешны и при этом ужасны внутри.
Если подход тимлида устраивает бизнес: скорость разработки, качество проекта, прогнозируемость сроков - то его политика вполне оправдана. Здесь надо для себя просто решать, готов ли ты работать так, как тут заведено? Можно искать плюсы не в красивом коде, а в каких-то других показателях, например, пользы от твоего быстрого говнокода для бизнеса. А то что код пишешь в помойку, ну просто смириться, что твой код - это расходный материал в этом проекте.
Конкретно советы в этой статье я писал для тех проектов, которые стремятся к качественному коду. И мне больше нравится работать именно в таких проектах. Но выбор есть у каждого, особенно в наше счастливое для разработчиков время :)
Обычно смотрят и берут первый попавшийся образец, а потом оказывается, что это был неудачный пример.
Согласен, если недавно в проекте, то есть такой шанс. Но именно для этого тимлиды придумали код-ревью. И желательно, чтобы один из ревьюеров уже давно был знаком с проектом ну и был немного душнилой :)
Короткие функции по 20 строк - здорово. Только теперь нужно скакать между функциями и держать несколько контекстов в голове.
А тут уже должно вступать в силу правило именования функций: читаешь код функции, не погружаясь в вызываемые подфункции, и в хорошем проекте этого должно быть достаточно. Редко, конечно, такое бывает, но это не значит, что нам тоже надо поддаваться эффекту "разбитых окон" и писать непонятные функции с неожиданными side-effect-ами
Тест скорее не на компетентность программиста, а на то, своим ли делом он занимается. Если, конечно, говорить о настоящем программисте, как заявлено в заголовке, а не о школьниках 8 класса, как оказалось в комментариях.
А еще статья и особенно комментарии оказались хорошим тестом на умение излагать свои мысли людям. Кажется, что человек, преподающий детям, уже по профессии должен быть значительно более терпим и сдержан при обсуждении альтернативных точек зрения.
Популяризировать делегирование, действительно, похвально. По сравнению со множеством статей, восхваляющих наследование, мало материалов по хорошему уместному делегированию. Особенно в учебниках для начинающих. Из-за этого часто вижу монстров с десятком миксинов. Или того хуже люди рожают наследников, не поддерживающих API родителя и не относящихся к той же доменной области.
Но зря Вы так резко из крайности в крайность бросаетесь. Хвалить что-то или кого-то, принижая ценность другого - не слишком правильно. Для каждой ситуации полезен свой инструмент.
В больших проектах оно дает неплохой прирост производительности в командной работе и чистоте кода. Когда ты видишь, какие аргументы приходят тебе в функцию и какие надо передавать в другие, тебе меньше надо заниматься Goto Definition и чтением чужого кода. Это, во-первых, а, во-вторых, Type Hinting не располагает прокидывать через лапшу методов какой-нибудь dict, в который каждый из методов что-то подкладывает, а следующий чего-то ожидает там найти.
Дело, к сожалению, не в верстке и плохих маркетологах или верстальщиках. Все приведенные в статье примеры демонстрируют ярких представителей мусорного контента. В интернете почти не найти полезного контента. Многое написанное, в том числе на новостных сайтах, созданно именно для того, чтобы продавать рекламу. И со своим делом эти сайты отлично справляются. Люди на ютубе питарды во рту взрывают исключительно чтобы поднять рейтинги своих каналов и заработать на рекламе. И пока на такой контент будут находиться потребители, будут ресурсы, на нем зарабатывающие.
Жалко, что пока его почти нигде не найти, во всяком случае через интернет-магазины. А на аналог от Меандра узм-51мд, который везде продают, есть нарекания по качеству разъемов — резьба срывается даже при небольшой затяжке.
Спасибо за перевод. Но, пожалуйста, прочитывайте статью хотя бы разок перед тем, как опубликовать. Сложно продираться через опечатки, несогласованные предложения и дословный английский перевод.
Подозреваю, что Вам так и не удалось переубедить коллег в спорах, раз даже целую статью написали.
А все потому, что при всей неидельности pip + venv в разы ускоряет разработку и deploy, а эмоциональной-идеологический батхерт отнимает время и нервы.
Предположу, минусуют те, кто не смог прочитать статью Кокса на английском и ожидал увидеть в предисловии описание на русском, что такое SparseMap и GenerationsMap.
В качестве исследовательского проекта - библиотека выглядит отлично и очень интересно. Интересно было бы посмотреть на работу с большими объемами текстов, как она себя ведет по потреблению памяти.
С практической точки зрения функция парсинга получается многословной с большим кол-вом служебных слов (yield, lambda), которые говорят о протекании внутреннего устройства библиотеки в пользовательский код. Регекспы, действительно, выглядят посимпатичнее. Хотя там нет такой удобной работы с position.
Было бы интересно добавить в статью как раз один-два примера, где PGPC удобнее regexp.
Здесь стоит философски посмотреть на то, что качественный код - это не залог доходности бизнеса. Знаю, действительно, много проектов, которые успешны и при этом ужасны внутри.
Если подход тимлида устраивает бизнес: скорость разработки, качество проекта, прогнозируемость сроков - то его политика вполне оправдана. Здесь надо для себя просто решать, готов ли ты работать так, как тут заведено? Можно искать плюсы не в красивом коде, а в каких-то других показателях, например, пользы от твоего быстрого говнокода для бизнеса. А то что код пишешь в помойку, ну просто смириться, что твой код - это расходный материал в этом проекте.
Конкретно советы в этой статье я писал для тех проектов, которые стремятся к качественному коду. И мне больше нравится работать именно в таких проектах. Но выбор есть у каждого, особенно в наше счастливое для разработчиков время :)
Читал, читал. Не согласен, не согласен :)
Но эти две статьи точно должны быть рядом. Спасибо, что принесли эту ссылку.
Согласен, если недавно в проекте, то есть такой шанс. Но именно для этого тимлиды придумали код-ревью. И желательно, чтобы один из ревьюеров уже давно был знаком с проектом ну и был немного душнилой :)
А тут уже должно вступать в силу правило именования функций: читаешь код функции, не погружаясь в вызываемые подфункции, и в хорошем проекте этого должно быть достаточно. Редко, конечно, такое бывает, но это не значит, что нам тоже надо поддаваться эффекту "разбитых окон" и писать непонятные функции с неожиданными side-effect-ами
Тест скорее не на компетентность программиста, а на то, своим ли делом он занимается. Если, конечно, говорить о настоящем программисте, как заявлено в заголовке, а не о школьниках 8 класса, как оказалось в комментариях.
А еще статья и особенно комментарии оказались хорошим тестом на умение излагать свои мысли людям. Кажется, что человек, преподающий детям, уже по профессии должен быть значительно более терпим и сдержан при обсуждении альтернативных точек зрения.
Популяризировать делегирование, действительно, похвально. По сравнению со множеством статей, восхваляющих наследование, мало материалов по хорошему уместному делегированию. Особенно в учебниках для начинающих. Из-за этого часто вижу монстров с десятком миксинов. Или того хуже люди рожают наследников, не поддерживающих API родителя и не относящихся к той же доменной области.
Но зря Вы так резко из крайности в крайность бросаетесь. Хвалить что-то или кого-то, принижая ценность другого - не слишком правильно. Для каждой ситуации полезен свой инструмент.
А все потому, что при всей неидельности pip + venv в разы ускоряет разработку и deploy, а эмоциональной-идеологический батхерт отнимает время и нервы.