Привет! Если ты тут, то тебе, видимо интересно, как разрабатывать проекты правильно и грамотно.
Безусловно путей множество и все они очень ситуативные, но есть общие моменты которые лучше всегда соблюдать.
Первое, что стоит упомянуть - это заветы "Чистого кода" и здравого смысла.
Многие из этих вещей я осознал сам, а в дальнейшем получил подтверждение в книгах.
У всего должно быть своё место(своя директория/папка).
Все файлы проекта группируются по типу, к примеру:
- компоненты
- контроллеры
- модели
- шаблоны
- сервисы
- ресурсы
- текстуры
- сцены
- и т.д.
Все эти файлы обязаны быть в "своих папках", при этом если файлы в группе имеют общий тип / подтип, то они так же группируются в директории расположенной внутри корневой директории группы.
При этом большая библиотека или компонент, содержащий множество вспомогательных файлов разных групп и типов, обязан располагаться в своём собственном пространстве (в персональной директории), группируя свои файлы в подпапки по назначению.
Смешивать файлы разных компонентов - код кобольдов и деяние сатаны!
Становится невозможно переиспользовать компонент без геморроя, в виде вычленения файлов нужных для работы требуемого компонента
Имя обязано ясно и чётко донести:
- назначение (для класса / интерфейса / примеси)
- содержание (переменные / свойства / константы)
- действие (методы / функции) обязательно начинаются с глаголов: get / set / construct / add / remove и т.д.
Не на будущее, не на вечер, не на пока что...
- Вы живёте здесь и сейчас, ваш код здесь и сейчас должен быть актуальным.
- Исправлю потом, когда-нибудь, скоро? - оно не настанет, будьте реалистами, вы живёте здесь и сейчас!
- Большинство проектов используют CSV, там сохранится ваш код, на все потом, в будущем, когда-нибудь.
Если вы ещё не используете систему контроля версий, пора взрослеть!
Она поможет определить узкие места и ошибки ещё на этапе проектирования, а не во время исполнения кода.
Согласитесь: лучше когда код работает, а не выдаёт ошибку за ошибкой
Насколько это нудно и затратно по времени, на столько же это полезно!
Тесты - как биткоин ₿, крафтятся долго и со временем их ценность многократно возрастает.
- PSR стандарты
- интерфейсы и абстрактные классы
- DI (Dependency Injection).
Обязательно ознакомьтесь с такими паттернами как:
- MVC
- ActiveRecord
- ORM
- Singleton
- Factory
- Command
- Service Object Architecture
- Observer
- и т.д.
Комбинируйте паттерны.
Это позволит легче тестировать, а так же избежать ошибок.
Передавая в метод / функцию большое кол-во аргументов (> 3), замените их на объект (приоритетнее) или массив.
Это позволит легче расширять функционал, упростит чтение и понимание кода.
При проектировании проекта, разделяйте бизнес логику, логику представления и логику обработки запроса.
Методы сервиса не должны содержать логику представления или обработки запроса, так же как и методы контроллера
не должны содержать бизнес логику.
Когда проектируете проект, старайтесь представить его как набор компонентов, которые могут быть пере использованы в других проектах.
Если вы используете фреймворк / библиотеку / компонент, старайтесь использовать их на 100%, а не писать свои решения.
Ведите документацию к проекту, она поможет вам и вашим коллегам легко разобраться в проекте быстрее.
- старайтесь разделять логику работы с API и логику обработки данных
методы API должны возвращать только данные, а обработка данных происходит в другом месте(сервисы/провайдеры) - указывайте ссылки на документацию к API в аннотация к методам и функциям
В директории app приведён небольшой пример "странички"
Которая использует следующие паттерны:
- MVC
- Service Object Architecture
- ModelView
- Repository
- Active Record
- ORM
Используется паттерн, который разделяет бизнес логику, логику view и логику обработки запроса.
Т.е. шаблон содержит только вёрстку и минимум логики, контроллер содержит только логику обработки запроса.
В actions методах контроллера собирается Resource(ModelView).
Значения для свойств Resource берутся из Service объектов, которые в свою очередь берут данные из Model
объектов и других сервисов.