Рубрика «Совершенный код»

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

В языке PHP, начиная с 5-ой версии, доступен механизм исключений. В актуальной, 7-ой, версии этот механизм был улучшен и переработан с целью единнобразной обработки разных ошибок при помощи конструкции try{} catch...

В стандартной библиотеке (SPL) PHP предоставляет готовый набор базовых классов и интерфейсов для исключений. В 7-ой версии этот набор был расширен интерфейсом Throwable. Вот диаграмма всех имеющихся в версии 7 типов (изображение — ссылка):

Диаграмма типов исключения в PHP7

Читать полностью »

Проверим на примере: пишем сервис с аэропортами и направлениями.

defmodule Airport do
  defstruct [:id, :name]
end

defmodule Direction do
  defstruct [:origin, :destination]

  def example do
    madrid = %Airport{id: "MAD", name: "Madrid"}
    riga = %Airport{id: "RIX", name: "Riga"}
    %Direction{origin: riga, destination: madrid}
  end
end

Пока что всё в порядке. Отлично, съели печеньку, смотрим, что дальше в джире. Список самых популярных направлений?

Добавление to_string упрощает разработку и дебаг кода на Elixir'е - 1Читать полностью »

Идиоматичный Kotlin, набор хороших практик - 1

Чтобы полностью раскрыть все преимущества Kotlin, пересмотрим некоторые подходы, которые мы используем в Java. Многие из них могут быть заменены на лучшие аналоги из Kotlin. Давайте посмотрим на то, как мы можем написать идиоматичный код на Kotlin.

Читать полностью »

Введение

В настоящее время широко известны такие принципы написания программного кода (coding standards), которые позволяют облегчить его поддержку и развитие. Эти принципы используются многими софтверными компаниями, а средства разработки и статического анализа кода предлагают для этого разнообразную автоматизацию. В то же время инженерные задачи в программировании явно требуют расширения понятия «хороший код». Мы попробуем выйти на обсуждение «хорошего» инженерного кода через, казалось бы, весьма частный пример — через практику использования в алгоритмах константных параметров.
Читать полностью »

Изменение восприятия сложности - 1
Хочу поделиться очень субъективными мыслями об изменении отношения к сложности за последние лет 50. Возможно, мои наблюдения касаются всей инженерии, но я поостерегусь и буду писать только про разработку ПО.

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

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

Я же учился в основном по материалам, созданным в прошлом веке, «древним манускриптам», да ещё и научную фантастику читал классическую, поэтому невольно стал приверженцем «старой школы». В чем же разница?
Читать полностью »

Мне нравится думать, что я пишу хороший код. Ну или, что я хотя бы пишу больше хорошего кода, чем плохого.

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

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

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

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

Тестирование: простая дорожка в IT или серьезная затея? - 1
Читать полностью »

GoTo MeetUp: Security by Default - 1

Информационная безопасность — это важно; впрочем, это знание мало кому помогает. Количество соединенных general-purpose компьютеров (==сложность) растёт каждый день, происходят очень реальные инциденты от Heart или Cloudbleed до Stuxnet или проблем с бортовым компьютером Toyota (когда машина не останавливается), и ситуация не становится лучше сама по себе. Становится хуже, потому что "интернет вещей" — это стартапы, делающие физическую инфраструктуру типа лампочек или дверных замков (разработчики SCADA плачут кровавыми слезами). Потому что огромное количество кода пишется на memory-unsafe языках. Потому что образование разработчиков — это, как правило, либо про фичи (проекты / этожпрототип), либо про фундаментальные алгоритмы (что не помогает пониманию того, что система работает не в вакууме).

Кажется, что основных корней проблемы два: это небезопасный инструментарий — например, ЯП (C/C++) и библиотеки (OpenSSL), и люди. Люди забывают про ИБ, думают "выпустим что-нибудь, а потом разберёмся", не понимают tradeoff'ы своих инструментов (то, что "C — это быстро", знают все, а вот про memory unsafety и масштаб UB — немногие), etc. Первая проблема сейчас решается сообществом: разрабатываются безопасные языки типа Rust и простые, понятные библиотеки типа TweetNaCl. Остаётся вторая (ведь хорошим инструментам надо ещё научить, как и соответствующему мышлению).

Поэтому мы проводим митап по информационной безопасности Security by Default.

Читать полностью »

Жирные программы — факторы скорости - 1 Картинка из фильма «Размер имеет значение», 2009

Данная статья была начата в апреле 2016г в результате того, что компьютер опять стал работать медленнее, чем я щелкаю мышкой. Собственно, она является компиляцией многих тестов (некоторых еще с 2010г) и обсуждений с моим участием. Ее нельзя назвать полностью законченной, поскольку это не окончательные выводы, а некие промежуточные точки, показывающие на что обратить внимание и куда копать дальше.

Название частично позаимствовано из статьи Никлауса Вирта «Долой „жирные“ программы», которой в 2016г было ровно 10 лет, и актуальности она не утратила — а скорее вышла на новый уровень, кто не знаком — почитайте.

Рассмотрим разные аспекты, влияющие на производительность систем и программ.

Языковой аспект
Аспекты памяти
Аспекты реального мира
Неязыковые факторы
Аспект человеческого фактора
Читать полностью »

Идиомы Attorney-Client и Passkey для выборочного доступа к методам класса - 1 При проектировании приложений на C++ временами возникает необходимость предоставления доступа к закрытым методам класса другому классу или свободной функции. Для этого в языке C++ есть ключевое слово friend, которое предоставляет полный доступ не только к публичному интерфейсу класса, но и к закрытому, и всем деталям реализации. Таким образом friend работает по принципу «все или ничего» и «все» может быть слишком много. Например, когда есть класс Facade и несколько клиентов Client1, Client2, то может потребоваться предоставить каждому клиенту доступ только к определенному набору методов, причем каждому клиенту к своему набору, не предоставляя доступа к деталям реализации. Для решения такой задачи в C++ есть все возможности. В этой статье я расскажу про две идиомы Attorney-Client и Passkey и как их использовать с нулевыми накладными расходами.
Читать полностью »