Пару лет назад я работал в SaaS-компании, которая страдала от всех возможных проблем, связанных с разработкой программного обеспечения. Код был настолько сложным, что внесение простых изменений занимало месяцы. Все проектные задачи и границы проекта оценивались только руководителем. Разработчики не понимали, какую проблему они решают. А когда не знаешь, чего ждет заказчик, многое из того, что делаешь, оказывается бесполезным. Команда не знала, что предложить заказчику. Все были очень разочарованы...

Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб. 

С тех пор прошло два десятилетия. Возникает вопрос - релевантны ли эти принципы до сих пор?

Перед вами перевод статьи Дядюшки Боба, опубликованной в октябре 2020 года, в которой он рассуждает об актуальности принципов SOLID для современной разработки.   

Недавно я получил письмо с примерно следующими соображениями:

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

Принцип подстановки Лисков давно устарел, потому что мы уже не уделяем столько внимания наследованию, сколько уделяли 20 лет назад. Думаю, нам стоит рассмотреть позицию Дена Норса о SOLID - “Пишите простой код”

При написании нового метода или сервиса мы стараемся его максимально абстрагировать от внешних зависимостей, чтобы новый функционал реализовывал только заложенную ему логику. Об этом, собственно, нам и говорит один из принципов SOLID - Принцип единственной ответственности (single responsibility principle).

Я постоянно встречаю код, где если у метода больше двух входных аргументов, добавляется условный (array $args), что влечет за собой реализацию проверки наличия ключа, либо она отсутствует и тогда увеличивается вероятность того, что метод может закрашиться в рантайме.

Возможно, такой подход в PHP сложился исторически, из-за отсутствия строгой типизации и такого себе ООП. Ведь как по мне, то только с 7 версии можно было более-менее реализовать типизацию+ООП, используя strict_types и type hinting.

Привет, меня зовут Алексей, я системный архитектор e-commerce платформы Lamoda, и в этом посте — мое представление о том, чем на самом деле занимается ИТ-архитектор, какие вопросы решает в ежедневной работе и за что несет ответственность.

С начала 90-х ИТ-сфера сильно эволюционировала, и роль архитектора (я не буду говорить о профессии, потому что считаю, что как таковой ее у нас нет) развивалась вместе с ней. В 2021-ом перед ним стоит задача куда шире, чем проектирование. Он как архитектор зданий, которому нужно не просто построить условный дом, но и вписать его в окружающий контекст, включить в существующую экосистему. Архитектор принимает решения о важных вещах, выступает катализатором изменений, которые нужны проекту. Он использует нарративы, описывая, как должны выглядеть системы и какие паттерны использовать, чтобы команда могла их одобрить и реализовать

Статья написана по мотивам моего доклада на митапе. В нем я рассказываю историю того, как мы взяли и не распилили монолит на микросервисы, и что сделали вместо этого.

На тот момент наша команда работала над приложением, начало которому было положено еще в 2009 году не искушенными в архитектуре студентами. К 2018 это уже был типичный big ball of mud (большой ком грязи), или, этакий «монолит-копролит», как выразился один наш коллега. Думаю, многим знакомо.

Привет, Хабр!

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

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

Как вы думаете, что делают рекрутеры, когда видят "Alexandr, NOT OPEN FOR WORK"? Правильно, пишут "Алексей, рассматриваете вариант работать в X?" Я обычно игнорирую это, но тут мне предложили попытать счастья с Яндекс.Лавкой, и я не смог пройти мимо - интересно было, смогу ли я устроиться куда-нибудь, когда введут великий российский файерволл. К тому же за последние 3 года я проходил только два интервью, и мне показалось, что я не в теме, что нынче требуется индустрии. Блин, я оказался и вправду не в теме. И вы, скорей всего, тоже - об этом и статья.

Генри Форд чуть не прогорел на своей фразе про пятьдесят оттенков черного. General Motors стала предлагать разноцветные модели Chevrolet, Pontiac, Buick, Oldsmobile и Cadillac — и не прогадала. Глядя на это, даже упрямый Форд изменил свое мышление  — и разработал новый Ford A, вернувший его на автомобильный Олимп. Бывают времена, когда парадигма мышления должна стать новой — ибо человек умирает тогда, когда перестаёт меняться ©Генри Форд. 

Пришло время и для разработчиков. Command Query Responsibility Segregation (CQRS) и Event Sourcing (ES) уже не миф — они реально работают. Конечно, не для всех задач — как и классический черный цвет Форда, PHP никуда не исчез и нужен по-прежнему. Но теперь уже есть задачи, где мы встречаемся с CQRS и ES чаще, чем нам кажется. Антон Шабовта на PHP Russia 2021 расскажет, как смена парадигмы и взгляд с другой стороны помогают разработчикам. А перед конференцией мы расспросили Антона подробнее о его новых взглядах на разработку, PHP и, конечно, о CQRS и ES.

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

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

Решение писать будем на php.

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

Поэтому появился авторский текст, написанный, преимущественно, на основе моих собственных представлений. Он проверен по материалам википедии – там есть общий таймлайн в серии статей (этот откроется на 1957, наверху можно выбрать конкретный год), есть обзорная английская статья, которая, на мой взгляд, не раскрывает логику развития, а говорит о фактах, и есть статьи, посвященные отдельным языкам. Статьи по отдельным языкам как раз включают не только его описание, но и логику создания и развития языка. Но – изолированно от других, и простая сборка не даст целостной картины, а наоборот, будет содержать противоречивые фрагменты. Зато эти статьи позволяют проверить, насколько твои представления соответствуют реальной истории, и поправить их – что я и проделал.

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

Мою предыдущую статью «История IT. Когда компьютеры были большими…» мы завершили концом 80-х, когда произошло два знаменательных события. Во-первых, появился ООП и объектный язык C++. А во-вторых, появились персоналки, и это принципиально изменило задачи, стоящие перед IT-разработкой.

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

Главное изменение в том, что персоналки сделали компьютеры доступными небольшим компаниям. Потребовались системы автоматизации бизнес-процессов, которые сильно отличаются в разных компаниях. Типовую систему сделать сложно: сейчас такие системы уже есть, например, 1C, а в то время их не существовало. Как раз эту задачу помог решить ООП. Эту часть истории развития IT и концепций, которые тогда появились и до сих пор используются, я расскажу в этой статье.

Здравствуйте, меня зовут Дмитрий Карловский и я… тот ещё токсичный перец. Недавно я источал свои альфа-флюиды на Альфа-банк. Ребята в ответ поступили достойно, и не стали атаковать меня в личку объяснениями, как сильно я не прав, а завели задачу на гитхабе. И даже что-то пофиксили, сделав часть моих претензий несостоятельными. Но не ту часть, где SSR портит всё.

Время утекло, пыль улеглась, и тут история получает продолжение: недавно ко мне обратился продюсер контент-студии Хабра с предложением пропесочить их Торт. Что ж, расчехляем вентилятор!

Принципы объектно-ориентированности