https://github.com/andy87/smart-development
Рекомендации к разработке + небольшой пример.
https://github.com/andy87/smart-development
Last synced: 3 months ago
JSON representation
Рекомендации к разработке + небольшой пример.
- Host: GitHub
- URL: https://github.com/andy87/smart-development
- Owner: andy87
- Created: 2023-09-05T06:02:56.000Z (almost 2 years ago)
- Default Branch: main
- Last Pushed: 2024-07-07T10:36:15.000Z (11 months ago)
- Last Synced: 2025-01-13T06:06:20.189Z (5 months ago)
- Language: PHP
- Homepage:
- Size: 54.7 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
Привет! Если ты тут, то тебе, видимо интересно, как разрабатывать проекты правильно и грамотно.
Безусловно путей множество и все они очень ситуативные, но есть общие моменты которые лучше всегда соблюдать.
Первое, что стоит упомянуть - это заветы "Чистого кода" и здравого смысла.
> _Многие из этих вещей я осознал сам, а в дальнейшем получил подтверждение в книгах._
## 1. Всё должно быть на своих местах.
У всего должно быть своё место(своя директория/папка).
Все файлы проекта группируются по типу, к примеру:
- компоненты
- контроллеры
- модели
- шаблоны
- сервисы
- ресурсы
- текстуры
- сцены
- и т.д.
Все эти файлы обязаны быть в "своих папках", при этом если файлы в группе имеют общий тип / подтип, то они так же группируются в директории расположенной внутри корневой директории группы.
При этом большая библиотека или компонент, содержащий множество вспомогательных файлов разных групп и типов, обязан располагаться в своём собственном пространстве (в персональной директории), группируя свои файлы в подпапки по назначению.
> _Смешивать файлы разных компонентов - код кобольдов и деяние сатаны!
Становится невозможно переиспользовать компонент без геморроя, в виде вычленения файлов нужных для работы требуемого компонента_
## 2. У всех должно быть актуальное имя/название.
Имя обязано ясно и чётко донести:
- назначение _(для класса / интерфейса / примеси)_
- содержание _(переменные / свойства / константы)_
- действие _(методы / функции)_
_обязательно начинаются с глаголов: get / set / construct / add / remove и т.д._
## 3. Не оставляйте закомментированный код.
Не на будущее, не на вечер, не на пока что...
1. Вы живёте здесь и сейчас, ваш код здесь и сейчас должен быть актуальным.
2. Исправлю потом, когда-нибудь, скоро? - оно не настанет, будьте реалистами, вы живёте здесь и сейчас!
3. Большинство проектов используют CSV, там сохранится ваш код, на все потом, в будущем, когда-нибудь.
> _Если вы ещё не используете систему контроля версий, пора взрослеть!_
## 4. Соблюдайте строгую типизацию.
Она поможет определить узкие места и ошибки ещё на этапе проектирования, а не во время исполнения кода.
> _Согласитесь: лучше когда код работает, а не выдаёт ошибку за ошибкой_
## 5. Пишите тесты
Насколько это нудно и затратно по времени, на столько же это полезно!
> _Тесты - как биткоин ₿, крафтятся долго и со временем их ценность многократно возрастает._
### Эти 5 шагов подходят практически для любого проекта и многократно упрощают жизнь разработчика...
## Дополнительные рекомендации.
#### Используйте:
- PSR стандарты
- интерфейсы и абстрактные классы
- DI (Dependency Injection).
#### Используйте Паттерны проектирования.
Обязательно ознакомьтесь с такими паттернами как:
- MVC
- ActiveRecord
- ORM
- Singleton
- Factory
- Command
- Service Object Architecture
- Observer
- и т.д.
Комбинируйте паттерны.
#### Реализуйте методы и функции, возвращающие значения, а не изменяющие объект.
Это позволит легче тестировать, а так же избежать ошибок.
#### Передавая в метод / функцию большое кол-во аргументов (> 3), замените их на объект _(приоритетнее)_ или массив.
Это позволит легче расширять функционал, упростит чтение и понимание кода.
#### При проектировании проекта, разделяйте бизнес логику, логику представления и логику обработки запроса.
Методы сервиса не должны содержать логику представления или обработки запроса, так же как и методы контроллера
не должны содержать бизнес логику.
#### Когда проектируете проект, старайтесь представить его как набор компонентов, которые могут быть пере использованы в других проектах.
#### Если вы используете фреймворк / библиотеку / компонент, старайтесь использовать их на 100%, а не писать свои решения.
#### Не закладывайте много логики в шаблоны, лучше всё это вынести в контроллеры или сервисы.
#### Добавляйте к методам и функциям аннотации и комментарии раскрывающие подробности.
#### Ведите документацию к проекту, она поможет вам и вашим коллегам легко разобраться в проекте быстрее.
#### При проектировании Фасадов для работы с API:
- старайтесь разделять логику работы с API и логику обработки данных
_методы API должны возвращать только данные, а обработка данных происходит в другом месте(сервисы/провайдеры)_
- указывайте ссылки на документацию к API в аннотация к методам и функциям
#### При разработке проекта используйте .env файлы для хранения конфигурации проекта.
# Пример разработки проекта.
В директории `app` приведён небольшой пример "странички"
Которая использует следующие паттерны:
- MVC
- Service Object Architecture
- ModelView
- Repository
- Active Record
- ORM
## MVC
Используется паттерн, который разделяет бизнес логику, логику `view` и логику обработки запроса.
Т.е. шаблон содержит только вёрстку и минимум логики, контроллер содержит только логику обработки запроса.
## ModelView & Service Object Architecture
В `actions` методах контроллера собирается `Resource`(ModelView).
Значения для свойств `Resource` берутся из `Service` объектов, которые в свою очередь берут данные из `Model`
объектов и других сервисов.