Архитектор – это звучит… Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа «системный архитектор» или там «программный архитектор». Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу «архитектор информационных систем и программного обеспечения». Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело – это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.

А раз оно есть – значит зачем-нибудь нужно! А нужно чтоб как-то указать на необходимость главного элемента мозаики – архитектуры. А раз нужен элемент, то за него, конечно, должен кто-то да отвечать. А раз должен, то вот и появляется такая должность.

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

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

Декорирование функций - это, наверное, самая сложная среди базовых и самая простая среди продвинутых фич языка Python. С декораторами, наверное, знакомы все джуны (хотя бы в рамках подготовки к собеседованиям). Однако, крайне мало разработчиков пишут их правильно. Особенно принимая во внимания тенденции последних нескольких лет к аннотированию всего и вся. Даже популярные open-source проекты (если основная часть их кода была написана до 2018 года) вряд ли дадут вам примеры декораторов, отвечающих всем современным требованиям к коду.

Так давайте разбираться!

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

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

Что делать, если ценности клиента для вас очень важны, но при этом вам приходится работать в компании, чья внутренняя культура этого не приветствует?

11 лет своей жизни посвятил Amazon (2009-2020 гг.), а затем еще 4 года проработал в Google (2020-2024 гг.). В обеих компаниях я встречался и работал с людьми, которые искренне заботились о клиентах, однако сами культуры при этом разительно отличались.

Сейчас вы прочитаете увлекательную историю моего превращения из разработчика в тимлида. Это было долгое путешествие со множеством шагов назад, которое всё же закончилось уверенным шагом вперёд. Устраивайтесь поудобнее, берите попкорн… Поехали!

Велосипед

Что бы вы сказали, если бы вам потребовалось срезать косты вашей команды разработки в два раза? А если бы пришел босс и потребовал делать в два раза больше той же командой? Обычно интуиция нас подводит и мы в ответ на эти вопросы делаем не то, что нужно - в итоге только ухудшаем ситуацию. Самое интересное, что значительно улучшить результаты можно потратив относительно небольшие усилия - что же это за бесплатный сыр такой? Как это связано с релизами? От какого важного элемента Agile мы заодно отказываемся? Ответы на эти вопросы я попробую дать в своей статье.

Нет, конечно же, не убивает.
То, что мертво, умереть не может: доля линукса на десктопах колеблется около 2% уже много лет, и не имеет тенденций ни к росту, ни к падению, изменяясь на уровне статистической погрешности.

Как выглядит захват рынка конкурентоспособным продуктом, можно видеть на примере, например, Chrome: за 10 лет рост на 70%. Или Android: за 5 лет рост на 75%. А вот у Linux рост пол-процента в год, несмотря на то, что он, например, лучший из существующих вариантов для использования в качестве национальных/государственных ОС.

Так в чем же дело? Почему несмотря на все старания, Linux, который стал стандартом де-факто на встраиваемых устройствах, работает на подавляющем большинстве серверов, целиком захватил рынок суперкомпьютеров, Linux, над которым работают сотни компаний и десятки тысяч людей... практически не используется на обычных компьютерах и ноутбуках?

Причины этой ситуации, как ни странно, те же, что сыграли роль в популярности Linux на серверах: unix-way, "Философия Unix": "Пишите программы, которые делают что-то одно, и делают это хорошо, и имеют возможность получать и принимать данные через текстовый интерфейс (потому что он универсален)".

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

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