<rmcreative>

Продолжаю публиковать интересное из недели backendsecret. В этот раз про OpenSource и проектирование.

Про OpenSource

OpenSource — не халява, а совместная разработка.

В OpenSource главное не демотивироваться. Как и везде, негативные отзывы публикуют, а вот позитивные — практически никогда. Чем больше проект, тем больше негатива. «Зачем нужен Yii, если есть X» спрашивают меня с того самого момента, когда я начал им пользоваться.

Вообще я всякого наслушался про свой OpenSource. И «product of Satan» и «this bullshit not working» и «it is sick». Иногда мне всё-равно на такие комментарии потому как я знаю, что фреймворк многим помогает, но иногда настроение такое, что задевает. Но за годы как-то привык...

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

Про проектирование и архитектуру

Надёжность внешних систем

При работе с внешними API всегда предусматривайте ситуацию, когда API не работает.

Ограничения

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

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

Перевод сообщений

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

markdown и WYSIWYG

Работающих с контентом в вашей системе очень легко обучить вместо WYSIWYG использовать markdown. markdown проще рендерить единообразно, удобней хранить и делать diff.

Это на опыте Осло, Мюнхена и Москвы. На Воронеже не проверял.

Если контент редактируется часто и множеством редакторов, конфликты придётся разрешать. Один из вариантов — мёрж и с markdown он проще. Я как-то реализовывал это путём хранения контента прямо в отдельном git-репозитории.

Я не говорю что WYSIWYG не может быть приятным, но утверждаю, что с markdown проще и меньше сюрпризов.

Монолит и микросервисы

Хороший монолит не хуже микросервисов. Плохие микросервисы с нечёткими границами гораздо хуже монолита. Basecamp — самый ярый пример успешного монолита за который топят. Также бывший Stay был ничего так. В сервис там были вынесены только ручной автоскейлинг AWS и пережатие картинок на golang.

Кеширование

Инвалидация кеша не даром считается одой из сложнейших задач программирования наряду с именованием. Утонуть в ней очень легко. Кешируйте только когда оптимизации перестали помогать.

Про выбор фреймворка

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

Про legacy

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

Про паттерны

А вы знали что Active Record вполне удовлетворяет S из SOLID?

• Think you understand the Single Responsibility Principle?
• Doesn’t active record violate SRP and OCP?

Про авторитеты

Не стоит слепо верить написанному даже если это написал Мартин или Фаулер. Всегда спрашивайте себя "почему". Если не можете дать ответ, или кто-то ошибся (бывает) или стоит изучить предмет дискуссии глубже.

Пример. Посыл «если вы ошибаетесь — вон из профессии и никакая статическая типизация вам не поможет». Мягко говоря, перегибает.