Защита вашего PHP-приложения: лучшие практики

Здесь представлен небольшой список для начинающих разработчиков, который покажет, что надо учесть для сохранения безопасности вашего приложения, например:
✔️Проверка ввода
✔️Предотвращение SQL-инъекций
✔️Управление сессией

Топ-10 архитектурных стилей и паттернов: шпаргалка для разработчика, основанная на статье в блоге ByteByteGo System Design Alliance.

1. Layered
2. Component-Based
3. Service-Oriented
4. Distributed System
5. Domain-Driven
6. Event-Driven
7. Separation of Concern
8. Interpreter
9. Concurrency
10. Data-Centric

Семь принципов хорошего программиста

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

Тут как раз ведущие подкаста «РАДИО-Т» обсудили каждый из принципов (01:08:43-01:55:35). Залетайте и слушайте👇

1️⃣ DRY (Don't Repeat Yourself)
2️⃣ KISS (Keep It Simple, Stupid)
3️⃣ YAGNI (You Ain't Gonna Need It)
4️⃣ SLAP (Single Level of Abstraction Principle)
5️⃣ SOLID
6️⃣ Law of Demeter
7️⃣ Law of Conservation of Complexity

🎧 Слушать

#подкасты

Отличная серия видео о паттернах и практиках в программировании от Авито Тех

https://www.youtube.com/watch?v=149Hdpqx3Gc&list=PLknJ4Vr6efQHvhvlGcBSD4KHa4ekAn0DS

Julia Evans сделала всем подарок и заопенсорсила песочницу для nginx конфигов

https://jvns.ca/blog/2023/07/08/open-sourcing-the-nginx-playground/

Вы еще не пользуетесь rector? Тогда мы идем к вам!

Способ уменьшения боли при рефакторинге для обновления (да и не только, там тысячи сценариев для анализа и исправления кода).

Подробности тут https://habr.com/ru/companies/oleg-bunin/articles/720216/

Понимание PHP-FPM: полное руководство

В этой статье изучается мир PHP-FPM, изучая его функции, преимущества и то, как он может повысить производительность приложений на основе PHP.

Хорошая статья об организации прокси (шины данных) между клиентами и kafka от Ozon
https://habr.com/ru/companies/ozontech/articles/749328/
И еще недавняя статья от Авито об их реализации https://habr.com/ru/companies/avito/articles/726564/
Мы же в Zoon используем kafka-pixy с небольшими доработками https://github.com/zoonru/kafka-pixy

Да, в PHP тоже нужно следить за памятью
https://habr.com/ru/articles/748352/

Когда будет сделано

Ключевой контринтуитивный вопрос в планировании не «сколько проект делается в днях», а «когда будет сделано». У меня ушел день на понимание разницы в свое время. Сегодня был первый раз когда я смог дать такой обоснованный ответ с данными.

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

Чем более опытный профессионал тем больше буфера заложено в оценку. Потому что лучше выкатить раньше, чем протянуть срок. Здесь кроется первая ошибка. Если вы не допускаете проскальзывания сроков, то ни о каком точном планировании речи быть не может. Вы постоянно будете добавлять буфер, чтобы успеть наверняка. В английском есть идиома to sandbag — дословно — огораживаться мешками с песком. Чтобы защититься от наводнения или пуль.

Точное планирование, как и любое предсказание дается со степенью уверенности:

 — 85%, что мы выкатим проект к указаной дате.
 — Клиент вредный, давай по 95% посчитаем. Сколько надо еще времени

Как получить оценку, да чтобы еще с разной степенью уверенности. Не просить же инженера выдумать такое распределение?

Выдумывать не нужно. Все необходимое у вас уже, скорее всего есть. 1) Вам нужно знать сколько тикетов в неделю закрывает команда. Для этой статистики нужно брать проектные тикеты, а не все подряд, типа багфиксов. Такой статистики нужно как минимум за 7 прошлых недель. 2) Дальше вам нужно знать сколько тикетов предстоит сделать. Важно, чтобы тикеты были нарезаны в разумном диапазоне и не отличались на 500% друг от друга. 3) Вам нужно знать, сколько всего людей будет работать на проекте минимум и максимум.

Вот и всё.

Если вы хотите улучшить качество предсказания, то желательно добавить 1) время, которое вы тратили на тикеты в прошлом (lead time) и 2) расхождение с планом в прошлых проектах. Иногда начинаешь проект на 10 задач, а заканчиваешь с 40.

Эти данные загружаем в симулятор Монте-Карло. Этот симулятор я подсмотрел в рассылке для менеджеров в Амазоне. Сам симулятор работает прямо в браузере и никуда ваши данные не отправляет.

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

[иллюстрации так же в комментариях]

Таблица вероятности.

График распределения вероятности.

По моему опыту заинтересованным лицам и парировать нечем. Данные выглядят очень убедительно и взяты не с потолка, а из статистики работы команды.

В моем случае 100% совпали с оценкой программиста, только дата была далеко дальше дедлайна и нас гарантировано бы начали уговаривать придумать дату ближе к дедлайну. Крыть бы нам было нечем.

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

Не откладывайте на потом, как это сделал я. Вам нужно всего 7 недель данных. Попробуйте в понедельник, хоть прямо на том проекте, который у вас уже в процессе.

Пост: https://teamleadtalks.com/koghda-budet-sdelano/

Вступайте в сообщество.

Код-ревью: cookbook от Google
- Цель код-ревью - убедиться, что код со временем улучшается.
- Рецензенты должны одобрять CL, если он улучшает код.
- Не существует идеального кода, есть только лучший код.
- Рецензенты не должны требовать от автора полировки каждой строчки CL.
- Рецензент должен стремиться не к совершенному коду, а к постоянному совершенствованию.
- Не следует использовать многопоточность, если она может вызвать deadlock или race condition.
- Рецензент должен быть благожелательным, объяснять свою мысль и указывать на проблемы.
- Рецензент должен быть полезным, но не давать детальных инструкций или писать код за разработчика.

https://habr.com/ru/articles/737012/

Конспект книги «Создание микросервисов»
• Создание микросервисов: идея, преимущества, недостатки.
• Микросервисы: особенности, преимущества, недостатки.
• Разделение монолита на части: причины, проблемы, решения.
• Тестирование: виды, особенности, рекомендации.
• Мониторинг: важность, особенности, рекомендации.
• Безопасность: принципы, решения, рекомендации.
• Масштабирование: вертикальное, горизонтальное, кеширование.
• Обнаружение сервисов: DNS, DNS-серверы, API-шлюзы.
• Документация: важность, связь с кодом, примеры.

https://habr.com/ru/articles/499386/