В этой статье мы затронем один из самых простых, но в то же время наиболее важных навыков в программировании. Ведь именно грамотное именование кода позволяет говорить о его качестве.
Существует четыре главных фактора, которые отличают хороший код от плохого: читаемость, изменяемость, безопасность и производительность. Первые три — тесно связаны, и главным среди них является именно читаемость.
Ведь читаемость это фундамент, без которого ничего не получится.
В этой статье мы рассмотрим, как статический анализатор PVS-Studio воодушевляет заняться рефакторингом кода. Ведь чем короче, проще и понятнее код, тем меньше в нём ошибок.
Здравствуйте, уважаемые читатели!
В этой статье я хотел бы продолжить тему появления субъязыка текстовых запросов к нейросетям (которая может быть полезна не только для инженеров, но и всех энтузиастов, которые, как, к примеру, и я проводят значительное время за работой с ИИ-генераторами).
Компания Anthropic, которая разработала семейство больших языковых моделей (LLM) Claude представила новый ИИ-инструмент, суть которого заключается в использовании уже готовых, универсальных, оптимизированных текстовых запросов по соответствующим темам, что позволяет повысить скорость и эффективность работы с нейросетевыми ресурсами.
Инструмент и соответствующий раздел веб-сайта Anthropic, на котором он размещен, получили название Prompt Library – Библиотека Запросов – а в качестве подзаголовка представлена фраза Explore optimized prompts for a breadth of business and personal tasks (Осваивайте оптимизированные запросы для решения широкого спектра деловых и личных задач).
Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы.
Баги, которые удалось найти в движке qdEngine, оказались весьма разнообразны, поэтому не хочется мешать всё в кучу в одной публикации. Читатели могут упустить интересные темы, связанные с написанием качественного кода. Поэтому разбор проекта выйдет в виде серии публикаций, первая из которых посвящается наиболее интересным срабатываниям с точки зрения плагина PVS-Studio.
Любому программисту знакомо понятие "ссылка". Под этим термином обычно понимают небольшой объект, главная задача которого обеспечить доступ к другому объекту, физически расположенному в другом месте. Из-за этого ссылки удобно использовать, они легко копируются, и с их помощью очень просто получить доступ к объекту, на который эта ссылка ссылается и можно получить доступ к одним и тем же данным из разных мест программы.
К сожалению ссылки, точнее ручное управление памятью, является наиболее частой причиной возникновения различных ошибок и уязвимостей в программном обеспечении. А все попытки автоматического управления памятью с помощью различных менеджеров упираются в необходимость контролировать создание и удаление объектов, а также периодически запускать сборщик мусора, что отнюдь не положительно сказывается на производительности приложений.
Тем не менее, ссылки в той или иной форме поддерживаются во всех языках программирования, хотя под этим термином часто подразумеваются не полностью эквивалентные термины. Например, под словом "ссылка" можно понимать ссылку как адрес в памяти (как в С++) и ссылку, как указатель на объект (как в Python или Java).
Хотя встречаются языки программирования, которые пытаются решать данные проблемы за счет концепции "владения" (Rust, Аргентум или NewLang). О возможном решении этих и других имеющихся проблем со ссылками далее и пойдет речь.
Привет, Хабр! Меня зовут Грант, я уже 5 лет занимаюсь backend-разработкой в SimbirSoft, а с 2021 года возглавляю Backend-отдел компании в Краснодаре. В последние несколько лет неоднократно замечаю, что на входном интервью соискатели часто путают принципы разработки. Поэтому в этой статье решил разобрать, как проще их понимать, какие связи между ними прослеживаются, стоит ли учить все или что-то можно пропустить. А еще попробую раскрыть некоторые особенности, какие секреты скрывают популярные принципы разработки.
Всем привет! Думаю многие читали кучу книжек по поводу Hexagonal, Onion, Clean, Layer Architecture и у вас могли остаться спорные вопросы как в сложности понимания материала, так и в реализации данных подходов в ваших проектах. Сегодня я хочу затронуть тему “Организации кода” и показать насколько это важно и легко одновременно на примере Layer Architecture (Слоистая архитектура).
Статические анализаторы помогают не только обнаруживать ошибки и дефекты безопасности, но и делать код чище. Выявляя лишние проверки, дублирующие действия и другие аномалии, можно сделать код проще, красивее и легче для чтения. Разберём это на практическом примере рефакторинга функции.
Легаси — реальность любого программиста. Объясняем, как софт становится легаси и почему это нормально, а также какие существуют плюсы при работе с легаси. Не всегда стоит относиться к легаси как к проклятию, стоит взглянуть на него как на естественный этап жизненного цикла программного обеспечения. Меня зовут Алексей Рузин, я уже 27 лет работаю и знаю, как работать с легаси.
«Легаси» — это слово, которым программисты пугают друг друга (и менеджеров). Оно означает устаревший софт, работать с которым обычно сложно и/или неприятно по причине небольшого «выхлопа» в пересчете на вкладываемые усилия. В целом, словом «легаси» можно назвать любой «код», который сложно поддерживать. И чем сложнее, тем он более «легаси».
Сегодня расскажем, откуда оно берется, как удерживать его “в рамках” и чем оно может быть полезно для начинающих специалистов.
Каждый код уникален. Несмотря на работу линтеров, спустя несколько лет вы с уверенностью сможете определить, что писали вы, а что — другой разработчик. Даже если не помните, что это была за задача. А ещё, код может рассказать об авторе едва ли не больше, чем разговор с ним. Например, какие книги он читал, на каких языках писал раньше. Можно сделать выводы о характере и привычках автора и предположить, как быстро он сможет вырасти.
Я Юрий Митус, фронтенд-разработчик в Сбере. Предлагаю поговорить о коде, который мы пишем, и практиках его улучшения. Расскажу, на что обращать внимание, покажу типичные ошибки, которые «портят» код и как их избегать. Научу писать код так, чтобы вас хотели нанять и перенять ваши практики.
Здравствуйте, меня зовут Дмитрий Карловский и я.. люблю власть. Когда я берусь за клавиатуру, каждый байтик начинает плясать под мою дудку. Но когда этих байтиков становится по настоящему много, уследить за всеми становится сложно. Поэтому давайте сравним популярные паттерны проектирования, позволяющие разделить большое приложение на компоненты, чтобы властвовать над ними максимально эффективно и независимо.
Так как одна и та же прикладная сущность встречается в приложении во многих местах, в разных контекстах, и должна иметь разное представление, то базовая декомпозиция заключается в выделении модели предметной области, которая является источником истины для всех мест её отображения.
Привет, Хабр! Привет, меня зовут Иван Шурыгин, я работаю fullstack-разработчиком, в свободное время занимаюсь исследованием опенсорс-проектов, люблю покопаться в репозиториях. Таким образом в свое время наткнулся на Node. У меня есть аккаунт на вАЙТИ — если возникнут вопросы по статье, пишите в личку. С радостью отвечу.
Еще в студенчестве, слушая подкасты, я узнал про среду выполнения Bun.js. Тогда она была в бета-стадии и только теоретически подавала надежды на то, чтобы составить конкуренцию Node.js и Deno. Тогда я подумал, что это крутая штука, которая однажды может «выстрелить».
Прошло время, я сменил несколько стеков: успел поразрабатывать на .net, позже стал Java-разработчиком. При этом моя любовь к Node не угасала. А в сентябре 2023 года я понял, что оказался прав в своей вере в Bun.js: она вышла в релиз.
Сегодня я расскажу об этой новой среде выполнения, опишу процесс эволюции рантаймов JavaScript и продемонстрирую производительность Bun в сравнении с Node.js.
В блоге beeline cloud мы делились историями и мнениями разработчиков — как программист-самоучка выучил 30 языков программирования, в каких случаях парное программирование не работает и почему некоторые проекты угасают, когда из компании уходит тимлид разработки. Сегодня поговорим о том, как изучать азы информатики при помощи Stack Overflow, даже если ваше образование не связано с компьютерными технологиями. Вот интересный перевод.
Мое основное образование далеко от ИТ. Но приблизительно в 2016 году я придумал, как изучать основы информатики при помощи Stack Overflow. Так у меня появилось увлекательное хобби. В свободное время я проглядываю сайт в поисках вопросов, получивших наибольшее количество голосов.
Сам метод, а также результаты, которые он приносит, я описал в своей статье 16-часовая тренировка для разработчиков. В чем же основные его преимущества? В том, что такой подход зачастую намного лучше, чем чтение учебников во время обучения в ВУЗе.
Ответ со Stack Overflow, получивший наибольшее количество голосов, позволит вам оперировать опытом отраслевого эксперта из первых рук. И это в совокупности с краткой теоретической справкой (которую хорошие специалисты как правило приводят в своих ответах).
Одному из вопросов, набравшему наибольшее количество голосов на Stack Overflow (сейчас это порядка 24 миллионов «плюсов»!), я хочу посвятить эту статью.
В прошлый раз мы разобрали пример, когда асинхронная операция использует дополнительный поток. Этот пример многим показался провокационным и даже вредным, что для меня выглядит достаточно странным. Насколько я понял основной претензией является то, что этот пример для многих как бы отрицает «экономное использование потоков», как это сформулировано например здесь-«metanit: Асинхронное программирование» .
Конечно, многие обиделись на меня за то, что я посмел возражать признанному авторитету, который вынес в заголовок своей очень известной работы фразу There is no thread (Там нет потока) ведь хорошо известно, что: «нет пророка в своем отечестве», и, видимо, быть не должно, но это все эмоции.
Давайте я покажу, как преобразовать мой пример, чтобы он продемонстрировал не только то самое «экономное использование потоков», но и откуда оно берется.
