[Перевод] Писать код просто, а читать сложнее

Написать код легко. Если у вас в голове сложилось решение, и вы уверенно владеете синтаксисом вашего любимого языка программирования, то напишете код с лёгкостью. А может быть у вас есть LLM, которая напишет за вас целые функции? Тогда ещё проще. Но сложнее всего не писать код, а читать. Требуется время, чтобы загрузить себе в голову ментальную модель системы. Вот это по-настоящему трудозатратно. Ментальная модель складывается у вас в голове, когда вы читаете код. Это ваша внутренняя «карта», по которой понятно, как работает система, где находятся самые хитрые её части, что от чего зависит. Не имея такой карты в голове, вы просто смотрите на текстовые строки. Когда я выполнял работу по заказу, большинство из моих заданий начинались одинаково. Мне ставили задачу пофиксить баг или добавить новую фичу в приложении, которое я видел впервые. Сначала моя ментальная модель была как чистая доска. Чтобы приступить к её заполнению, я открывал домашнюю страницу и разбирался, на что она похожа. Я открывал исходный код страницы: это React? jQuery? Сторонний плагин? Я просматривал базу кода, чтобы выяснить, используется ли у них где-нибудь ещё такая карусель, которую они просят поставить на первой страницы. Знакомился с их сборочным процессом, конфигурацией для тестирования, с тем, каким инструментарием они пользуются. Каждая мелкая деталь, которую я обнаруживал, встраивалась в ту модель, которая складывалась у меня в голове.

https://habr.com/ru/companies/piter/articles/947744/

#искусственный_интеллект #совершенный_код #написание_кода #чтение_кода

[Перевод] Паттерны проектирования в Python, о которых следует забыть

Попробуйте поискать в Интернете «Паттерны проектирования на Python» — и получите целую простыню туториалов, демонстрирующих, как в точности воспроизвести на Python паттерны проектирования из книги «Банды четырёх». Там же будут диаграммы классов, иерархии фабрик и столько шаблонного кода, что выхлопа хватит, чтобы отопить маленькую деревню. Так вам внушают, будто вы пишете «серьёзный» код. Умно. Профессионал ьно. Готово для корпоративного использования. Но вот в чём проблема: большинство из этих паттернов решают проблемы, которые в Python просто отсутствуют . Паттерны разрабатывались для таких языков как Java и C++, где для выполнения самых базовых вещей требуется настоящая эквилибристика — нет ни функций первого класса, ни динамической типизации, ни модулей в качестве пространств имён. Разумеется, вам потребуется Фабрика или Синглтон, если без них в вашем языке просто не с чем работать. Слепо копировать эти паттерны в Python — не признак большого ума. Из-за них ваш код сложнее читать, тестировать, а также объяснять очередному бедняге, которому этот код придётся поддерживать. Возможно, через три месяца этим беднягой станете вы..

https://habr.com/ru/companies/piter/articles/939022/

#перевод #python #ооп #совершенный_код

Окно в терминальной стадии

Что нужно для взаимодействия с операционной системой исключительно через клавиатуру? Это вопрос, на который каждый разработчик даст свой ответ, и как на него ответили Microsoft, выпустив Windows Terminal?

https://habr.com/ru/companies/pvs-studio/articles/931576/

#windows_terminal #cpp #pvsstudio #c# #windows_11 #статический_анализ #совершенный_код

Покерная лаборатория закрывается, ловите исходники

Я делал этот проект более полутора лет, сейчас отказываюсь от него. И, чтобы эти полтора года не были прожиты зря) открываю исходники. Java+Spring. Принимайте проект «как есть», со всеми ad-hoc костылями, незаконченными исследованиями, TODOs, а также всевозможными KISS, DRY, и, как их… SOLID с GoF. Предполагается, что вы знакомы с покером, имеете неплохие навыки программирования, поверхностно разбираетесь в теории игр.

https://habr.com/ru/articles/915882/

#покер #теория_игр #машинное+обучение #боты #карточные_игры #дерево_решений #совершенный_код #говнокод #искусственный_интеллект #opensource

Как NASA ошиблись в исходном коде планеты

Баги в коде — явление нередкое, но сегодня мы исследуем не просто ошибки, а настоящие космические баги! Что скрывает проект, созданный в недрах NASA? Готовьте свои шапочки из фольги! Поехали!

https://habr.com/ru/companies/pvs-studio/articles/915850/

#статический_анализ #pvsstudio #java #nasa #open_source #static_analysis #чистый_код #совершенный_код

Код-ревью под микроскопом: как нетоксично давать обратную связь и проверять код без нервов

Привет! Меня зовут Артем Валевич, я тимлид в AGIMA . Одна из важнейших моих обязанностей — код-ревью, то есть проверка кода на качество, надежность и соответствие требованиям проекта. Этот процесс может ощутимо улучшить продукт, а может превратить жизнь всей команды в ад. Ключ к этому процессу — в умении не перегибать палку. Давайте посмотрим, как может выглядеть токсичный и нетоксичной фидбек, а заодно на то, как можно оптимизировать сам процесс ревью.

https://habr.com/ru/companies/agima/articles/911764/

#кодревью #тимлидство #управление_разработкой #совершенный_код #критерии_качественного_ревью

Low-hanging fruit

Разработчики любят чистый код, а "Правило бойскаута", по слухам, делает его еще чище. На первый взгляд, подход кажется разумным: исправляешь мелкие недочёты, переименовываешь переменные, удаляешь лишние комментарии — удобно, быстро, безопасно. А главное, можно сказать, что внёс вклад! Однако если такие правки не решают реальных проблем, это превращается в поверхностный рефакторинг, создающий лишь иллюзию прогресса. Это можно описать метафорой low-hanging fruit — когда разработчики выбирают самые лёгкие и очевидные задачи, избегая более сложных и значимых изменений.

https://habr.com/ru/articles/891808/

#совершенный_код #рефакторинг

Хоть и безобразно, но единообразно

Здравствуйте! Сегодня мне хотелось бы обсудить с вами один армейский принцип, который может оказаться невероятно полезным при написании и поддержке вашей кодовой базы.

https://habr.com/ru/companies/domclick/articles/883012/

#рефакторинг #техдолг #разработка_приложений #совершенный_код #кодстайл #архитектура_приложений

Параллельные сортировки больших массивов объектов и пути уменьшения асимптотической сложности лучших алгоритмов

Резюме. Мы обсуждаем здесь наилучшие способы оптимизации сортировки сверх-больших массивов составных объектов по нечисловым ключам. Также рассматривается способ уменьшения количества выполняемых операций (сложность) имеющихся алгоритмов сортировки. Конкретный базовый алгоритм сортировки выбирается разработчиком по своему усмотрению (см. условие 1 в замечаниях). Введение: Проблематикой имплементации паралелльной сортировки занимаются разные специалисты по всему миру. Подавляющее число специалистов рассматривает платформы GPU и их суперскалярность как эффективную (в вычислительном плане) базу для разработки новых алгоритмов. На Хабре исследованиями в этой области занимались [ KS1 ], [ KILY1 ], [ PatZ1 ], [ Ms1 ]. Стоит отметить несколько минусов выбранного авторами похода:

https://habr.com/ru/articles/882802/

#совершенный_код #алгоритмы #программирование

Заговор разработчиков против корпораций: архитектура и принципы

С момента написания предыдущей статьи я находился под пристальным вниманием. Попытка опубликовать материалы на англоязычных платформах обернулась фиаско — в первые же минуты легионы последователей тайного братства обрушились с критикой: — Нет никакой организации! — вопили они. Подозреваю, что слежка велась через мой телеграм-канал . Тем не менее я жив, а значит, пора поведать об архитектурной подлости неимоверных масштабов. Вы узнаете, как ведется борьба с крупными корпорациями изнутри и снаружи, как умы разработчиков заражают деструктивными идеями в обертке сакральных истин. Узнать тайны, о которых молчали

https://habr.com/ru/articles/878620/

#web_разработка #oop #функциональное_программирование #solid #dry #system_design #архитектура #clojure #совершенный_код #монорепозиторий

Работает? Трогай! Рефакторинг

«Работает — не трогай!» — знакомая фраза? Звучит как девиз стабильности. Но в наше время все меняется со слишком большой скоростью, а такой подход может стать настоящей ловушкой Джокера. Оставленный без внимания проект рискует превратиться из мощного инструмента решения проблем в неподъемный багаж, неспособный соответствовать новым требованиям. Как же понять, когда «не трогать» становится опаснее, чем «поменять»? Как определить момент, когда старый код начинает замедлять развитие, а не поддерживать его? Сегодня я хочу поговорить с вами о рефакторинге — о том, как найти баланс между работоспособностью и необходимостью изменений, как сохранить проект конкурентоспособным и жизнеспособным, и как, наконец, сделать этот самый рефакторинг.

https://habr.com/ru/articles/873386/

#рефакторинг #разработка #программирование #проектирование #вебразработка #советы_разработчику #совершенный_код #инструменты #технический_долг #практики_программирования

[Перевод] Пишем медленный код на Go

Подождите, что? Медленный код? Разве мы не должны беспокоиться об ускорении наших Go-программ? На самом деле, нет. Оптимизация кода на Golang ради производительности - это попросту трата времени, и вот почему: 1. Производительность в большинстве случаев не имеет значения 2. Go и так быстрый 3. Читаемость важнее скорости Эти аргументы нуждаются в объяснении, и я его дам. Для них есть исключения, как, собственно говоря, для всех нетривиальных утверждений. Честно говоря, стоит сказать, что эти 3 пункта вряд ли являются компромиссом среди программистов-инженеров. Так что, прежде чем начать снижать мне рейтинг и писать негативные комментарии("Худшая статья на Хабре"), прочитайте до конца. Прочитать до конца

https://habr.com/ru/articles/871726/

#go #golang #чистый_код #совершенный_код #быстрый_код #скорость #читаемость_кода #читаемость #производительность

Как экономить нервы и время при отладке кода

Отладка кода — это краеугольный камень разработки программного обеспечения, ведь именно на этом этапе выясняются все слабые стороны разработчиков и практик написания кода, которые они выбрали. Невозможно не допускать ошибки, но можно сэкономить много ресурсов при их исправлении. Цель этой статьи максимально коротко и понятно посвятить читателей в отладку.

https://habr.com/ru/articles/861390/

#отладка #Подходы_к_отладки #Отладить #поиск_ошибок #совершенный_код #Программистпрагматик #поиск_багов

Чистый код: Начало

По дате публикации, данная статья является завершением, а на самом деле предисловием к циклу статей написанных по теме чистого кода. В статьях отразил свой взгляд на создание гибкого и читаемого программного кода, где акцент сделан на примерах. Текущая же статья посвящена общим принципам написания кода, который легко читать, понимать и поддерживать (KISS если так больше нравится). Сразу хочу предупредить, что многие положение отраженные в этой статье могут вызвать сомнения в их корректности, но это личное мнение автора, опирающееся на опыт. Чистый код не для всех. Признает это читатель или нет, но сообщество разработчиков не однородно. Нас нельзя сравнивать даже в начале карьеры. Между выпускником месячных курсов на Python, и выпускником университета обладающего теорией и знанием нескольких языков программирования большая разница. Да и должностное разделение никто не отменял.

https://habr.com/ru/articles/838466/

#совершенный_код #чистый_код #проектирование #программирование

Чистый код: Аргументы командной строки

Поскольку эта статья завершает цикл про SOLID с примерами, хотелось бы показать, как эти принципы позволяют создавать что-то большее. В этой статье создадим небольшой модуль, каркас (framework), для работы с аргументами командной строки. Обработка аргументов командной строки, с одной стороны, один из простейших примеров, который используют для решения начинающие разработчики. С другой, существует множество решений которые не только не соответствуют принципам SOLID, но и построены таким образом, что внесение почти любого изменения требует значительной переработки кода. Разработку модуля начнем с определения цели, очень тривиально, но правильно поставленная цель, значительно упрощает реализацию. Основной целью модуля будет создание инструмента удобного для пользователя. Легко добавлять, изменять значения аргументов, легко перебирать значения. Опишем функционал модуля.

https://habr.com/ru/articles/838464/

#совершенный_код #чистый_код #проектирование #программирование

Чистый код: Инверсия зависимостей (DIP)

Инверсия зависимостей - это стратегия зависимости от интерфейсов или абстрактных функций и классов, а не от конкретных функций и классов. Проще говоря, когда компоненты нашей системы имеют зависимости, мы не хотим напрямую внедрять зависимость одного компонента в другой. Вместо этого мы должны использовать определенный уровень абстракции между ними. Вот такое сложное определение. Где, «Проще говоря», только больше запутывает чем поясняет, хотя все передает верно. Этот принцип пожалуй самый сложный для объяснений, хотя его суть очевидна. Начну пояснения с бытового примера. Для работы лампы освещение необходим провод, ну и электричество естественно. Логичным является, встроить эту лампу в светильник, который будет играть двойную роль, защитную и декоративную. Что делать, если лампа вышла из строя, очевидно снять плафон вывинтить лампу и вставить новую и так далее, но это стало возможно, когда мы применили принцип инверсии зависимости. Конструкторы разделили светильник на части, в программировании они называются модулями. Каждую из этих частей снабдили интерфейсами. Для лампы сделали интерфейс — патрон. Для плафона интерфейс — держатели и так далее. Теперь есть возможность извлечь лампу и заменить ее на другую, если у этих ламп интерфейсы совместимые. А что если светильник не разборный. Нам придется его разрушить, или выкинуть и купить новый. То же происходит и в программном обеспечении. Если мы в самом начале неправильно разделили на модули и не выполнили инверсию зависимостей, при малейших изменениях, нам придется переписывать большой участок кода, и это хорошо, если этот код мы писали сами. Разобраться проще.

https://habr.com/ru/articles/838462/

#совершенный_код #чистый_код #проектирование #программирование

Чистый код: Принцип разделения интерфейса (ISP)

Принцип разделения интерфейсов предполагает, что вы не должны заставлять клиента реализовывать интерфейс, содержащий методы, которые ему не нужны. Вместо этого вам следует разбить более крупные интерфейсы на более мелкие, ориентированные на конкретные случаи использования. Этот принцип пожалуй самый простой для понимания, но важный при реализации. С разделением интерфейсов мы встречаемся постоянно, правительство любой страны имеет интерфейсы, которые называются министерствами, компании - интерфейсы в виде отделов, материнская плата - интерфейсы для подключения памяти, процессоров и другой периферии. Тоже самое логично делать и в программировании. В чем суть принципа разделения интерфейсов. Если перефразировать простыми словами, не нужно делать два дела сразу. Сознание человека так и построено, вспомните детскую задачку, когда просят одновременной дотянуться пальцем до кончика носа и гладить живот по часовой стрелке. Прежде чем создавать свой пример, давайте рассмотрим пару участков кода из интернета. Из кода удалены приватные части классов, а так же конструкторы и параметры методов. Исключительно для экономии места. Первый пример, выдержка из огромного класса интерфейса API, весь класс содержит около 30 методов и не представляет интереса, но показанный участок, иллюстрирует проблемы которые возникли у автора кода при модификации.

https://habr.com/ru/articles/838460/

#совершенный_код #чистый_код #проектирование #программирование

Чистый код: Принцип подстановки Барбары Лисков (LSP)

Принцип подстановки Лисков гласит, что если метод использует базовый класс, то он должен иметь возможность использовать любой из его производных классов без необходимости иметь информацию о производном классе. Трудно предоставить разумный пример иллюстрирующий этот принцип, так как соблюдение элементарной логики и правил чистого кода по именованию методов и переменных, не позволяет его нарушить. Если в базовом классе есть метод save(), отвечающий за сохранение информации, а вы не пытаетесь его переделать для загрузки данных, у вас все в порядке. Рассмотрим тонкости соблюдения этого принципа, на довольно сложном примере. Начнем с класса хранения данных.

https://habr.com/ru/articles/838458/

#совершенный_код #чистый_код #проектирование #программирование

Чистый код: Принцип открытости закрытости (OCP)

Принцип открытости/закрытости гласит, что программные объекты (классы, методы, функции и т. д.) должны быть открыты для расширения, но закрыты для модификации. Идеальной реализацией данного принципа является интерфейс. Ничего лишнего, нечего модифицировать, можно только расширять.

https://habr.com/ru/articles/838456/

#совершенный_код #чистый_код #проектирование #программирование

Чистый код: Принцип единственной ответственности (SRP)

Принцип единой ответственности гласит, что программный модуль должен иметь единственную ответственность, то есть у него должна быть одна и только одна причина для изменения. Для того, чтобы понять как рассуждать, чтобы прийти к соблюдению этот принципа, давайте разберем пару типичных примеров. Первый взят из популярного репозитория.

https://habr.com/ru/articles/838454/

#совершенный_код #чистый_код #проектирование #программирование