@maks78945

Чем плохо написание кода функциями?

Доброй ночи, пишу небольшую систему по компании, поскольку познания в php не сильно большие, пишу код функциями, к примеру при загрузке страницу запрашиваю функцию, она получает данные с бд, производит с ними манипуляции и возвращает их, а я уже работаю с этими данными. Если же это действия по нажатию, запрашиваю функцию через ajax.

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?
  • Вопрос задан
  • 205 просмотров
Пригласить эксперта
Ответы на вопрос 5
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Проблема масштабируемости и расширяемости кода приложения.
Пока у Вас один тип объектов - можно всё писать и функциями (и хранить всё в массиве).
Но потом - придётся всё переписывать на классы и т.д.
Ответ написан
Комментировать
ThunderCat
@ThunderCat Куратор тега PHP
{PHP, MySql, HTML, JS, CSS} developer
Зачем нужен ООП?
Кратко зачем ооп вместо функций:
1) Снижение сложности кода(да, звучит странно, но на самом деле именно так и есть - сложные вещи пишутся 1 раз, а далее вы пользуетесь практически предложениями естественного языка и описываем реально существующие манипуляции с реальными объектами, например $user->getName(), $image->rotateLeft()...)
2) Инкапсуляция - все что делает объект изолированно внутри одного инстанса, вы работаете по сути с отображением реальных объектов в цифровой мир(+ этот объект может быть сколь угодно сложным внутри, наружу он смотрит простыми методами для возможности операций над ним).
3) Снижение затрат памяти - классы подгружаются только в необходимом объеме и в нужно месте, в процедурном подходе все функции грузятся сразу.
4) Локализация кода - всегда логика одной сущности доступна в одном месте, не размазана по функциям и коду. Это такой нехилый бонус к инкапсуляции, и при рефакторинге вам не надо переписывать кучу кода, если объект был изначально правильно построен, максимум поменять немного логику внутренней обработки данных.

Про работу в команде я вообще молчу, модульность разработки позволяет много плюшек, от непересечения кода, до приоритетов конкретных задач под разработчика с большим опытом в каком-то конкретном направлении.

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?
Почему нельзя?
Оно работает?
Оно решает проблему бизнеса на сейчас?
Бизнес устраивает решение которое "будет работать только здесь и сейчас, а стоимость погашения технического долга и расширения будет равна написанию приложения с нуля, но это будет потом"?
Если все ответы - "да" значит все не так уж плохо на сегодняшний день, и билет на само в порядке, по крайней мере пока вы работаете там.
Но я бы серьезно задумался о будущем в плане развития.
Ответ написан
Комментировать
SerafimArts
@SerafimArts
Senior Notepad Reader
Если код пишется именно функциями, а не процедурами, то никаких проблем (в т.ч. с масштабируемостью) особо не будет. ООП в данном случае лишь поможет снизить сложность кода, т.к. композиция функций сложно читаема.
Ответ написан
Комментировать
Digiport
@Digiport
PHP рулит
Это ни хорошо, ни плохо. Просто существуют разные парадигмы - ООП и процедурная. Они могут использоваться как порознь, так и совместно Вопрос удобства и читаемости кода.
Ответ написан
Комментировать
inoise
@inoise Куратор тега PHP
Solution Architect, AWS Certified, Serverless
Писать так код не плохо. Плохо это то что судя по вашим же словам, вероятнее всего, у вас там дыры в безопасности размером со сверхновую, а также поддерживаемость этого на уровне плинтуса) а так, ничего - продолжайте)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы