Качество кода *

Короткий ответ: нет. Тем не менее, раз про это вновь и вновь спрашивают на Reddit, Stack Overflow и других сайтах, пришло время подробно разобрать эту тему. Оказывается, есть много интересного, о чём можно порассуждать.

В статье «Ускоряем анализ данных в 180 000 раз с помощью Rust» показано, как неоптимизированный код на Python, после переписывания и оптимизации на Rust, ускоряется в 180 000 раз. Автор отмечает: «есть множество способов сделать код на Python быстрее, но смысл этого поста не в том, чтобы сравнить высокооптимизированный Python с высокооптимизированным Rust. Смысл в том, чтобы сравнить "стандартный-Jupyter-notebook" Python с высокооптимизированным Rust».

Возникает вопрос: какого ускорения мы могли бы достичь, если бы остановились на Python?

Под катом разработчик Сидни Рэдклифф* проходит путь профилирования и итеративного ускорения кода на Python, чтобы выяснить это.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.

Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.

В этом посте я сделаю краткий обзор ужасного уровня безопасности современного ПО, а затем порассуждаю о том, почему он настолько плох. Также я упомяну нормативные/юридические аспекты, которые могли бы снова сделать качество ПО приоритетным. Наконец, я расскажу о написанном мной полезном ПО , позволяющем доказать, что сегодня по-прежнему можно разрабатывать минималистичное и простое ПО, остающееся современным.

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

Просматривая недавно соцсети, я наткнулся на этот скриншот. Разумеется, его сопровождало множество злобных комментариев, критикующих попытку этого новичка в программировании решить классическую задачу computer science: операцию деления с остатком.

В современном мире, где ИИ постепенно заменяет программистов, отнимая у них работу и совершая переворот в том, как мы подходим к рассуждениям о коде, нам, возможно, следует быть более открытыми к мыслям людей, недавно пришедших в нашу отрасль? На самом деле, показанный выше код — идеальный пример компромисса между временем и задействованной памятью. Мы жертвуем временем и в то же время памятью и временем компьютера! Поистине чудесный алгоритм!

Поэтому я решил изучить эту идею проверки чётности числа при помощи одних сравнений, чтобы понять, насколько хорошо она работает в реальных ситуациях. Я сторонник высокопроизводительного кода, поэтому решил реализовать это на языке программирования C, потому что он и сегодня остаётся самым быстрым языком в мире с большим отрывом от других (благодаря гению Денниса Ричи).

Когда на меня накатывает хандра, я бросаю всё и пилю свой игровой движок. Это неблагодарное занятие, но меня прёт.

В самом начале у меня были такие планы: вжух-вжух, щас возьму ведро, накидаю туда всяких библиотек для графики, физики и звуков, добавлю сетевую библиотеку по вкусу, перемешаю всё с какой-нибудь системой сообщений, и готово. Приключение на 15 минут.

И вот я тут спустя 5 лет.

Несколько лет назад я отказался от всего и полностью сосредоточился на WebAssembly. В то время Rust имел наилучшую поддержку компиляции в WebAssembly, а самые полнофункциональные среды исполнения WebAssembly были основаны на Rust. Rust был лучшим из вариантов. С места в карьер я нетерпеливо начал разбираться, чем же вызван такой ажиотаж.

С тех пор мы с потрясающими разработчиками создали Wick, — фреймворк приложений и среду исполнения, использующие в качестве системы основного модуля WebAssembly.

Спустя три года, выполнив несколько развёртываний в продакшен, написав электронную книгу и выпустив примерно сто пакетов на crates.io, я решил, что настало время поделиться своими мыслями о Rust.

Приветствую!

В конце первой части статьи по исследованию саундбара Yamaha я упомянул о плачевном состоянии его безопасности. Но вот то, насколько оно плачевное, я тогда представлял не до конца.

▍ Страдание

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

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

Вас приветствует ваш зануда!

Если вы следите за моей ленивой активностью, то заметили бы, что у меня много от чего пригорает. Вот, например:
- У меня пригорает от низкосортных статей на потоке: Питон против Безумного Макса, или как я посты на Хабре замораживал
- У меня пригорает от Django: Окей, Джанго, у меня к тебе несколько вопросов
- И от Яндекса тоже: Собеседование в Яндекс: театр абсурда :/
- И от рекрутеров: Я единственный из 1400, или самый крутой рекрутинг, что я проходил

Посмотришь так - я уже давно должен был сгореть. Но я, аки феникс, возрождаюсь, и сегодня у меня горит от, внезапно, Питона, на котором я пишу больше десяти лет. Если вам интересно, что же, по моему мнению, с ним не так - то прошу под кат.

Я начал программировать на Rust несколько лет назад, и это постепенно изменило мой подход к разработке программ на других языках программирования, особенно на Python. До того, как я начал использовать Rust, я обычно писал код на Python очень динамично, без подсказок типов, повсюду передавая и возвращая словари и время от времени возвращаясь к интерфейсам со «строковой типизацией». Однако, испытав на себе строгость системы типов Rust и заметив все проблемы, которые она предотвращает, я внезапно стал сильно беспокоиться всякий раз, когда возвращался к Python и не получал тех же гарантий.

• Отдавайте предпочтение полиморфизму, а не «if/else» и «switch»
• Код не должен знать о внутреннем устройстве объектов, с которыми он работает
• Функции должны быть маленькими
• Каждая функция должна выполнять одну задачу
• Принцип «DRY» — Don’t Repeat Yourself («не повторяйся»)

Готофобия – это боязнь использовать инструкции goto. Обычно возникает из-за непонимания и незнания контекста этой проблемы, а также из-за историй о незапамятных временах в истории программировании. Разработчики, страдающие готофобией, готовы жертвовать удобочитаемостью своего кода, только бы не прибегать к goto.

Код Хабра день за днём впитывает в себя время, мысли и чаяния многих людей. Этому коду более 10 лет: он оброс множеством знаний, в том числе и тайных. Места c bus factor = 1 — не эка невидаль, а вполне конкретные люди с ответами на часто задаваемые вопросы.

Меня зовут Антон Каракулов, я тимлид команды бэкенд-разработки Хабра. Хабр стартовал в 2006 году, и за всё время здесь поработало, наверное, команд пять. Мне посчастливилось быть в двух из них, забегал в третью.

Эту статью я написал в рамках проекта Хабра «IT-гид», где разработчики рассказывают про свои направления. Постарался собрать в ней главные практические выводы и интересные грабли, которые нам попадались в процессе превращения старого хабракода в чистый, масштабируемый и понятный для всех — то есть человекочитаемый.

Все события утрированы, а совпадения — беспочвенны.

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

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