Луна над Бирючим островом

, photo · life

Остров Бирючий был островом 90 лет назад. Теперь он не остров, а всего лишь продолжение Федотовой косы. Но согласитесь, «остров» звучит намного интереснее (и дороже), чем «коса».

2012. Моменты

, photo · life

Нашёл архив своего старого инстарграм аккаунта, которого уже давно нет. Получился классный набор картинок-моментов из 2012-го года.

Музыкальные находки

, music · finds

Southern Shores — приятная лёгкая игровая электроника, под которую хорошо работается. Интересные мелодические решения.

Время N

, music

Аквариум / Время N

У БГ вышёл новый альбом. Называется «Время N». Альбом получился грустный, немного мрачноватый и напряжённый. Но хороший конечно.

Матерные слова в текстах БГ случались и раньше. Но очень редко и незаметно, где-то в куплетах. Навскидку могу вспомнить только «Электрический Пёс», там есть такое: «И во всем, что движется, видят соперниц, Хотя уверяют, что видят блядей.»

Во «Времени N» случилось необычное для БГ: в припеве, в заглавное песне и сразу «Время наебениться». Да и альбом назван собственно так же: Время N — это Время Nаебениться. Даже в совковое время такого с БГ не случалось, хотя время было непростым. Использование матерных слов как бы говорит нам, что других слов у автора не осталось, только матерные. Похоже, что по ощущениям БГ настали смутные и сложные времена. Сложнее, чем были в Совке.

«На ржавом ветру» — в ту же копилку про смуту («было украдено даже солнце поутру»).

«Песни нелюбимых» — молитва.

Самая красивая песня, конечно же «Прикуривает от пустоты». Текст изумительный, магическая аранжировка.

Про Чайф и БГ

, music

Подумалось, что я не могу слушать альбомы Чайфа, которые вышли после «Шекогали», то есть после 2000-го года. Эти альбомы меня не вставляют. Я вырос, постарел, стал другим немного. А музыка Чайфа в 21 веке так и осталась музыкой 90-х. Звучание, смыслы, настроение, интонации. Старые записи я люблю, пою песни при возможности. Я к ним привык, это память первооткрытий акустического рока в школьные годы, память о беззаботной и зажигательной студенческой жизни. Если бы я послушал «48» или «Оранжевое настроение — IV» в году 98-м, это возможно были бы мои любимые альбомы. Но слушать сейчас я их не могу, скучно, старо.

В меньшей степени, но так же я могу сказать и про ДДТ. Не интересны они мне.

Другое дело Гребенщиков и его Аквариум. С удовольствием слушаю всё новое, что он выпускает. Что-то нравится, что-то забывается. Но все равно интересно. Его музыка современная, не застряла в 80-х или 90-х. Она изменяется во времени примерно с такой же скоростью, с какой развивается мой музыкальный вкус.

Вот две записи БГ из последних, которые меня тронули.

«Прикуривать от Пустоты» — совершенно гениальные стихи.

Девочка или мальчик?

, life

Почему в одних семьях рождаются девочки, в других мальчики? У меня есть теория, которая это объясняет.

Photo by Robert Collins on Unsplash

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

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

Напряга нет, всё спокойно, не спеша, есть хоть какая-то стабильность — это мир. В таких семьях рождаются девочки.

Теория хорошо подтверждается на всех моих знакомых. Вот например, Николай. Съёмные квартиры, жена доучивается, неопределённость с работой, срочная свадьба. Коля не сдаётся, борется за хорошую жизнь, напрягается. Конечно же родился мальчик. Прошло восемь лет. Появилось своё жильё, стабильная работа, гараж с машиной, пивное брюшко. Жизнь начала течь в спокойном русле. Родилась девочка.

«Война» или «мир» это не что-то внешнее, наружу может никак не проявляется. Это внутреннее состояние. Внутренний дискомфорт и борьба с ним — война, внутренний комфорт и лень - мир. Война и мир в семье могут меняться со временем.

Краткое руководство по кофе

, life

Сохраняю себе короткий конспект замечательного «Руководства по кофе» Михаила Озорнина.

Coffee on the table, photo by Nathan Dumlao

Что такое кофе

Кофе — это тропическая ягода. Есть два сорта кофе: арабика и робуста. Арабика обычно вкусней, все равно это не гарантия. Ягоды могут собирать вручную и механически. Вручную собирают более внимательные к кофе фермеры: это лучше, но дороже.

Обработка

Есть два способа обработки: сухой и мытый. Сухой более сладкий, мытый — более чистый, кислотный. Кофе сухой обработки помечается в магазинах как «сухой», «нат» или «натуральной обработки».

Обжарка

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

Помол кофе

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

Приготовление

Способы заваривания делятся на эспрессо и альтернативные. Эспрессо дает плотный, насыщенный вкус. Альтернативные обычно получаются легче. Простые способы для дома: турка, мока, френч- или аэропресс, для офиса: френч- и аэропресс.

Эспрессо

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

Напитки из эспрессе

Рецепт:

  • 17 г кофе, помол «под эспрессо».
  • за 20—25 секунд экстракции получить 40—45 грамм напитка. В зависимости от зерна, обжарки и помола пропорции могут быть немного другими.

Турка

Кофе, приготовленный в турке (джезве), популярен на «востоке».

Рецепт:

  • 16 г кофе, помол «под турку» — как женская пудра, но не в пыль и не до стадии муки. Подушечки пальцев должны чувствовать отдельные крупинки кофе. Обжарка «под турку» — светлей, чем для эспрессо. Зерна кофе не должны блестеть, они должны быть матовые на вид.
  • 160 мл воды комнатной температуры.
  • Как готовить:
    • Засыпьте кофе в турку и залейте водой. Если турка больше 200 мл, то кофе лучше перемешать.
    • Поставьте на плиту греться. Если используете песок, то закопайте турку на ½ или ⅔ в песок.
    • Снять кофе нужно будет как только поднимется пена и кофе начнет «заворачиваться» внутрь. После этого кофе готов. Иногда советуют опустить и поднять пенку 3 раза. Делать это не нужно, будет только хуже (это мнение Марины Хюппенен, — чемпионки России по приготовлению кофе в турке).

Мока

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

Рецепт:

  • 18 г кофе, помол «под гейзерную кофеварку» — чуть крупнее эспрессо. Обычно для моки больше подходят эспрессо-смеси и моносорта средней обжарки, светлая обжарка может не раскрыться полностью.
  • 200 мл воды, ее лучше предварительно погреть.
  • Как готовить:
  • Налейте воду в резервуар внизу, лучше наливать сразу горячую воду, так кофе будет меньше греться на плите, ему это вредно. Осторожно, заворачивайте кофеварку через полотенце, нижний резервуар будет горячим.
  • Засыпьте кофе в тарелочку, но не утрамбовывайте как для эспрессо. Скрутите вместе части кофеварки.
  • Поставьте кофеварку на максимальный огонь. Как только кофе начнет выходить, уменьшайте газ почти до минимума, но не выключайте совсем.
  • Как только кофеварка начнет сильно брызгаться, и вверх будут выходить пузыри — снимайте с плиты, кофе готов. Перелейте его в чашку, чтобы он не грелся в моке.

Френч-пресс (кофе-пресс)

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

Рецепт:

  • 16 г кофе крупного помола (чуть крупней сахара-песка). Светлый кофе можно молоть чуть мельче, чем темную обжарку.
  • 256 мл воды, соотношение вода:кофе во френч-прессе обычно равно 16:1.
  • Как готовить:
    • Засыпьте кофе в кофе-пресс.
    • Воду, нагретую до 95°, залейте в кофе-пресс. Чтобы получить воду 95° нужно выключить чайник когда после нитей пузырьков при начале шума. Я делаю проще: кипячу и даю остыть 1—1,5 минуты.
    • Перемешать один раз и оставить на 4 минуты. В процессе приготовления больше мешать не нужно.
  • Через 4 минуты снять ложкой пенку, опустить фильтр и слить кофе из кофе-пресса. Если кофе не слить, то он будет продолжать завариваться и станет очень горьким.

Аэропресс

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

Рецепт:

  • 15 г кофе, помол мельче сахара, средний между френч-прессом и эспрессо.
  • 200 мл воды, нагретой до 95°.
  • Как готовить:
    • Вставьте бумажный фильтр в крышку аэропресса и пролейте фильтр кипятком. Это нужно, чтобы убрать привкус бумаги.
    • Поставьте аэропресс вверх ногами и засыпьте в него кофе.
    • Залейте 200 мл воды и один раз перемешайте, закрутите крышку с фильтром.
    • Через 1 минуту переверните аэропресс, поставьте на кружку и поршнем вылейте кофе в кружку.
    • Поршень должен идти с заметным усилием, существенно больше, чем у френч-пресса. Помол кофе правильный, если поршень выдавливается за 20-25 секунд.

Воронка (v60, hario)

Воронка, она же пуровер, она же харио. Для приготовления вам понадобится больше инструментов, чем для других способов заваривания. Кроме самой воронки и бумажных фильтров понадобится чайник с тонким носиком (gooseneck kettle), который дает тонкую постоянную струю и позволяет налить нужное количество воды и нужное место воронки. Кофе в воронке получается легкий, без примесей, с очень чистым и ярким вкусом.

Рецепт:

  • 12 г кофе, помол мельче сахара, средний между френч-прессом и эспрессо.
  • 200 мл воды, после закипания перелить в чайник с тонким носиком.
  • Как готовить:
    • Вставьте бумажный фильтр в воронку и равномерно смочите горячей его водой (не из расчета тех 200 мл). Это нужно, чтобы убрать привкус бумаги.
    • Засыпьте смолотый кофе в воронку и сделайте в нем небольшое углубление.
    • Налейте в лунку воды, чтобы скрыть весь кофе, должна получиться кашица. Аккуратно размешайте кашицу ложкой. Засеките время с момента вливания воды.
    • Через 30 секунд начните аккуратно выливать воду из чайника, стараясь не лить в одну точку, чтобы не пробить дырку в кофе. Подождите, пока вся вода опустится вниз и перелейте кофе в чашку.
    • Вы все сделали правильно, если 200 мл воды проливаются за 2,5—3 минуты. Если быстрее, то нужно молоть чуть мельче, если медленней — чуть крупней.

Кемекс

Кемекс — это стеклянная колба в форме химической пробирки. Хочется пошутить, что это кофе для химиков, но это не шутка. Кемекс придумал доктор химических наук Питер Шлюмбом в 1941 году.

В отличие от воронки харио в кемексе есть желобок вдоль края. Когда вода льется в колбу, она вытесняет воздух, который выходит по этому желобку. Ещё этот носик помогает аккуратно вылить кофе из кемекса.

Сифон

Ещё один химический сосуд для приготовления кофе. Состоит из двух колб, соединенных стеклянной трубкой. Работает почти как гейзерная кофеварка. Пар от кипящей воды внизу давлением поднимает воду вверху, где она заваривает кофе. По мере остывания внизу создается вакуум и уже заваренный кофе засасывается обратно.

Итоги 2016-го

, life · music · dev

На работе

Уже больше двух лет я работаю в команде, которая развивает, внедряет и поддерживает e-commerce движок. Этот год по-моему стал переломным. Проект начал выбираться из sql-болота, в которое его долгое время погружали. Держать самые важные функции в хранимых процедурах очень не удобно: нет версионности, тяжело отлаживать, трудно синхронизировать и деплоить. Медленно, но уверенно наш критический код передвигается их хранимых sql-процедур в c#-код.

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

Очень помогла книжка Егора Бугаенко «Elegant Objects». Мы поняли наконец, что public static — это адское зло, с которым нужно бороться изо всех сил. Маленькие простые классы рулят, они легко тестируются и поддерживаются.

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

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

Закрыли с партнёром Домовед. Очень важный проект, которому мы уделили много времени и который многому нас научил. Проект постоянно стабильно рос. Мы были вверху поисковой выдачи по запросам «… без посредников». Мы проверили несколько интересных гипотез и убедились в том, что люди готовы платить за объявления без посредников. В конце концов свою квартиру я нашёл на Домоведе. Чтобы проект жил, над ним нужно постоянно работать. Свободное плавание тут не катит. Два года назад разработка остановилась, а год назад стало понятно, что разработка вряд ли продолжится. Чтобы не было стыдно за проект, мы его просто закрыли. Итог за 2013-2015 годы примерно такой: расходы — 36 000 грн, доходы — 16 000 грн. Потерь совершенно не жалко, это было интересно и круто. Спасибо, Домовед!

Музыка

Я уже больше года подписчик Google Play Music и практически всё слушаю там. Слушалось очень много и очень разного. Попытался разобраться в хип-хопе. Услышал и полюбил Мгзавреби. Вспомнил и много раз послушал альбом «Goddess in the Doorway» Мика Джаггера и «Alone in the Universe» от ELO. Нашёлся Hiatus c классным альбомом «Ghost Notes» и Mokhov c «Magic Times». Ну и много-много всего, регулярно оставлю ссылки в твитере.

2017

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

Про управление командой разработчиков

, dev · management

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

Будьте осторожны с высокими показателями

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

Поощряйте продолжительное улучшение продукта

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

Поощряйте право собственности на код

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

Распознавайте лидеров

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

Следите за ложными системами показателей

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

Отдельные рабочие места

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

Поощряйте эксперименты

У большинства компаний нет огромных денежных ресурсов, чтобы дать 20% рабочего времени под экспериментальные проекты как у Google. Эксперименты, тем не менее, периодически следует поощрять и поддерживать. Разработчики программного обеспечения не лишены хороших идей и имеют особый опыт, а соответственно у них хорошее чутье касательно приложений, которые могут быть улучшены и расширены.

Позволяйте сотрудникам уходить

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

Всегда выполняйте небольшие просьбы

Ваш сотрудник хочет монитор побольше? Купите. Они хотят определенную клавиатуру? Купите. Они хотят работать из дома каждую среду и это их личное требование? Разрешите. Они хотят Мак вместо ПК? Дайте им его. Даже если у них постоянный поток запросов, который кажется никогда не закончится, никогда не говорите им нет, кроме одного случая: если вы уверены, что эта маленькая просьба появится у всей фирмы и это действительно будет слишком сильно сказываться на бюджете.

Отмените годовые и полугодовые отчеты

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

Вы не лучше ваших сотрудников

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

Не делайте возврастную скидку

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

Обобщение

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

Конспект книги «Elegant Objects»

, books · dev

Егор Бугаенко написал полезную книгу про ООП. Я её прочитал и сделал для себя короткий конспект.

Современное ООП не правильно приготовлено, оно больше похоже на процедурный стиль потому, что выросло из него. Проблема больших программных продуктов — maintainability (ремонтопригодность, поддерживаемость). Решить помогает чистый стиль ООП — очень маленькие классы, immutable объекты и прочее.

Не использовать -er в именовании классов

Manager, Controller, Formatter — плохие имена плохих классов. Класс должен отражать не то, что он делает, а то, кто он есть.

Один главный конструктор в классе

Все остальные конструкторы его вызвают. Так есть единый код создания объекта, который легче поддерживать.

Конструкторы не должны содержать выполняющий код

Конструкторы только создают/инициализируют объект, вся полезная работе происходит в методах.

Делайте классы как можно мельче

Инкаплируйте максимум 4 объекта. Такие классы легче поддерживать и тестировать.

Всегда используйте интерфейсы

Интерфейс — это задокументированный контракт, который класс будет выполнять. (Спорно)

Методы-билдеры именуйте существительными

Например: string content(File file), int sum(int, int)

Методы-манипуляторы именуйте глаголами

Например: void paint(Color color), void write(string s). Такие методы не должны что-то возвращать, всегда void.

Методы возвращающие булевый тип именуйте прилагательными

Например: bool empty(), bool negative().

Не используйте константы

Они добавляют связи между классами, а это плохо. Вместо констант нужно делать классы, которые имплементируют работу с этими константами. (Спорно)

Делайте объекты не изменяемыми (immutable)

Такие объекты лечге поддерживать и отлаживать. Есть если объект должен изменить своё внутренне состояние, значит нужно создать и вернуть новый объект с новым внутренним состоянием. Плюсы такие:

  • объект всегда остайтся самим собой, нет identity mutability,
  • failure atomicity — ошибки не влияют на внутреннее состояние объекта, он всегда остайтся собой,
  • нет сайд-эффектов,
  • нет null в полях, всё должно быть проинициализировано в конструкторе,
  • потокобезопасность — много потоков могут пользовать объект без синхронизаций,
  • маленькие и простые классы — трудно сделать immutable класс в 5000 строк.

Пишите тесты вместо документации

Плохой код вынуждает писать документацию к нему. Простые маленькие классы не нуждаются в документации. Хорошо написанные юнит тесты для класса и есть его документация.

Не используйте моки, используйте фейки.

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

Максимум 5 публичных методов в классе

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

Не используйте статические методы

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

Не используйте utility классы, хелперы

Это обычно не классы, а набор процедур. Это очень частый антипаттерн в ООП.

Не используйте синглтоны

Немного лучше, чем utility класс. Но без него можно. Не используйте их. Объект не должен трогать ничего кроме своих инкапсулированных свойств. Все остальное объекту нужно передавать в конструкторе.

Функциональное программирование

Оно конечно хорошее, но ООП более выразительное и мощное потому, что имеет не только методы (функции), но и объекты.

Не принимайте NULL-аргументов

Это избавляет от проверки на null. Null - это из мира компьютеров, а не из мира объектов.

Be loyal and immutable, or constant

Коротко не скажешь, нужно читать.

Не используйте геттеры и сеттеры

Объекты в ООП не просто структуры данных. Структура данных прозрачная, а объект — черный ящик. Структурв данных пассивная, объект — активный. Геттеры и сеттеры нарушают целостность объекта, он становится не иммутабельным.

Используйте new только во вторичных конструторах

Для создания объектов по-умолчанию.

Избегайте проверки и приведения типов

Reflection — это хороший инструмент для плохих программистов.

Никогда не возвращайте NULL

Лучше выбрасывайте исключение. Fail fast — чем раньше вы упадёте, тем быстрее вы найдёте ошибку. Вариант: возравращать объект специального класса: class NullUser implements User.

Не ловите исключения, которые вы не должны ловить

Пусть они улетают выше, fail fast.

Используйте вложенные исключения

Словили исключение, выбрасывайте новое с хорошим описанием ситуации и вложенным словленным исключением.

Одного типа исключений достаточно

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

Используйте RAII

Получение некоторого ресурса неразрывно совмещается с инициализацией, а освобождение — с уничтожением объекта.

Все записи</p>