Skip to content

Latest commit

 

History

History
121 lines (89 loc) · 8.56 KB

File metadata and controls

121 lines (89 loc) · 8.56 KB

Привет! Если ты тут, то тебе, видимо интересно, как разрабатывать проекты правильно и грамотно.
Безусловно путей множество и все они очень ситуативные, но есть общие моменты которые лучше всегда соблюдать.

Первое, что стоит упомянуть - это заветы "Чистого кода" и здравого смысла.

Многие из этих вещей я осознал сам, а в дальнейшем получил подтверждение в книгах.

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 объектов и других сервисов.