Совершенный код

Недавно мне довелось побеседовать с разработчиком Thunderbird о проектировании API. В ходе этой беседы я поделился соображениями о RNP, новой реализации OpenPGP, которую Thunderbird недавно стал использовать вместо GnuPG.

Собеседник скептически отнесся к моему тезису о том, что API RNP нуждается в улучшении, и спросил, «разве это не субъективно – какие API лучше, а какие хуже?». Согласен, у нас нет хороших метрик для оценки API. Но не соглашусь, что мы в принципе не в силах судить об API.

На самом деле, подозреваю, что большинство опытных программистов узнают плохой API, если увидят его. Думаю, далее в этой статье получится разработать хорошую эвристику, которую я попытаюсь выстроить на моем собственном опыте работы с (и над) GnuPG, Sequoia и RNP. Затем я рассмотрю API RNP. К сожалению, этот API не только можно запросто использовать неправильно – он к тому же обманчив, поэтому пока его не следует использовать в контекстах, где принципиальная роль отводится соблюдению безопасности. Но целевая аудитория Thunderbird – это люди, известные своей уязвимостью, в частности, журналисты, активисты, юристы и их партнеры, отвечающие за коммуникацию; все эти люди нуждаются в защите. На мой взгляд, это означает, что в Thunderbird должны лишний раз подумать, стоит ли использовать RNP.

Роберт Мартин представил принципы SOLID в 2000 году, когда объектно-ориентированное программирование стало настоящим искусством для программистов. Каждый хочет создать что-то долговечное, которое можно использовать повторно, насколько это возможно, с минимальными изменениями, которые потребуются в будущем. SOLID - идеальное название для этого.

Фактически, объектно-ориентированное программирование работает лучше всего, когда мы можем отделить то, что останется, от того, что изменится. Принципы SOLID помогают разделять это.

Мне лично нравится идея, лежащая в основе принципов SOLID и я многому из нее научился.

Не уверен, что это будет исправлено.

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

Всем привет, я Максим Кравец из Holyweb, и мы продолжаем разговор о паттернах (первую статью о Singleton можно почитать вот тут). Героя нашего сегодняшнего сюжета порой называют «wrapper» или «обертка», поскольку он оборачивает исходный код, но мне больше нравится название «декоратор» — оно точнее отражает не механику, а суть происходящего.

Чуть меньше года назад, когда по всему миру начали распространяться локдауны в связи с Covid-19, большинство людей начало запасаться туалетной бумагой и консервами. Но лично я стремился получить нечто другое: реализовать функцию поиска.

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

Как и множество других писателей и художников, я держу личный веб-сайт, работающий уже в течение почти 20 лет. Решив заняться кодом, я смахнул пыль с моих заржавевших знаний JavaScript, и начал искать библиотеки нечёткого поиска, которые можно подключить к веб-сайту для упрощения поиска эссе из моей коллекции.

v-agent ориентированное программирование (VAOP) - это методология программирования, основанная на представлении алгоритма в виде v-agent script, который позволяет программному агенту, получившему название v-agent, выполнять операции закодированные в модулях v-agent box.

Идеологически v-agent ориентированное программирование - добивается того, чтобы алгоритм был записан в одном месте в виде, понятном всем - заказчикам, программистам и исполняющей среде (компьютеру), что улучшает процесс взаимодействия всех при создания программного продукта и, что особенно важно, существенно снижает затраты на этапе поддержания работы и адаптации к изменению внешних условий в Будущем.

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

Неважно, каких размеров ваше приложение на Node.js. Неважно, как хорошо вы написали код. Вам просто необходимо знать, как он работает в продакшене. Разработчик интерфейсов в поисковом портале Яндекса Алексей Попков сделал доклад о том, как выяснить, что происходит внутри запущенного процесса.

Что нужно, чтобы заглянуть в этот чёрный ящик? Ответ — опенсорс, все бесплатно, бери и внедряй.

— Всем привет. Немножко про то, кто я такой. Меня зовут Лёша, я разрабатываю внутренние сервисы Яндекса. Уже третий год делаю всякие Node.js-приложения, менторю разработчиков в Яндекс.Практикуме и измеряю все, до чего дотягиваются руки, потому что это весело.

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

Тебе нужно использовать SVG фавиконки. Они поддерживаются во всех современных браузерах.

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

В наши дни кажется, что все, что вам нужно, это подписаться на Twitter или выступить на TEDx, чтобы назвать себя футурологом. Но Тим О’Рейли - основатель легендарной компании по обучению технологиям O’Reilly Media - не такой гуру. Его вдумчивые наблюдения за тенденциями в области вычислительной техники и его поддержка открытого исходного кода (задолго до того, как это считалось крутым) дают ему должное уважение.

Поэтому, когда Тим О'Рейли недавно высказал мнение про будущее индустрии программного обеспечения, профессиональные разработчики обратили на это внимание.

Если вы программист, то есть много практик, которые можно ненавидеть.

Жестко запрограммированные значения. Двойная логика. Сложные иерархии наследования. Но должны ли входить комментарии в этом списке?

Давным-давно, во времена доисторического программирования, писать комментарии считалось обязательной составляющей написания кода. Когда вы писали код, его наполняли короткие и точные комментарии. Затем чистый код и agile программирование стали ведущими. Пуристы кричали про вред комментариев, которые наполняли неструктурированный и уязвимый код. Внезапно комментарии стали ошибкой, антипаттерном, сборниками откровенной лжи.

Многие разработчики почувствовали себя.

Всем привет, я Максим Кравец, CEO команды веб-инженеров Holyweb, адептов JavaScript. И сегодня хочу поговорить о паттернах проектирования.

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

В начале апреля на хабре была опубликована статья «JavaScript: Стек вызовов и магия его размера» — её автор пришёл к выводу, что каждый кадр стека занимает (72 + 8 * число_локальных_переменных) байтов: «Получается, что мы посчитали все верно и можем утверждать, что размер пустого ExecutionStack в Chrome равен 72 байтам, а размер коллстэка — чуть меньше одного мегабайта. Отличная работа!»

Для затравки — немного изменим код, использованный AxemaFr для экспериментов:

{let i = 0;

const func = () => {
  i += 1.00000000000001;
  func();
};

try {
  func();
} catch (e) {
  console.log(i);
}}

Вместо 1 теперь на каждом шаге прибавляем чуточку больше, и в результате вместо 13951 получаем 12556.000000000002 — как будто бы в функции добавилась локальная переменная!

Повторим вопросы, которыми задавался Senior Frontend Developer AxemaFr: «Почему же так? Что изменилось? Как понять, посмотрев на функцию, сколько раз она может выполниться рекурсивно?!»

Эта статья о том, как извлечь максимум пользы из статической системы типов при дизайне вашего кода. Статья пытается быть language agnostic (получается не всегда), примеры на Java и взяты из жизни.

«Комментарии должны составлять 5% от общего количества баллов», — заявил мой коллега-преподаватель.

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

«Я хочу, чтобы студенты изначально перенимали хорошие привычки. Вы ведь согласны, что добавление комментариев улучшает качество кода?», — спросил меня коллега, немного расстроенный моей негативной реакцией.

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

Добрый день! Работая разработчиком Oracle PL/SQL, часто ли вам приходилось видеть в коде dbms_output.put_line в качестве средства debug-а? Стоит признать, что к сожалению, большинство (по моему личному мнению и опыту) разработчиков Oracle PL/SQL не уделяет должного внимания логированию как к «спасательному кругу» в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.

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

Пользователи иногда спрашивают, как появляются новые диагностики в статическом анализаторе PVS-Studio. Мы отвечаем, что черпаем вдохновение из разнообразнейших источников: книг, стандартов кодирования, собственных ошибок, писем наших пользователей и так далее. Сегодня мы придумали новую интересную диагностику и решили рассказать историю, как это произошло.

Привет, меня зовут Григорий Бизюкин, я преподаватель Школы разработки интерфейсов и фронтенд-разработчик в Яндексе. Давайте поговорим о функциональном программировании в мире JavaScript. Мы все про ФП что-то слышали, нам всем оно интересно, но у меня, когда я искал полезные материалы для подготовки к лекциям, сложилось такое впечатление: есть куча статей, каждая из которых либо говорит об ФП общими словами, либо раскрывает отдельный маленький кусочек темы, чего, конечно, недостаточно.

^{Добавим функционального света}

Впервые я попробовал обобщить в одном месте самые популярные и, как мне кажется, применимые приёмы функционального программирования в лекции для ШРИ. Потом захотелось расширить материал и рассмотреть ещё больше концепций. В результате получилась эта статья. В ней мы разберём всё самое сложное простым языком с понятными примерами. Надеюсь, вам будет интересно!