Comments 5
Из того, за что взгляд зацепился при беглом просмотре
функция query() - очень хорошо.
функция fetch_array() - очень так себе, пришита к классу $connect белыми нитками. И по сути это такая страусиная политика, поскольку объект mysqli_result всё равно протекает из вашей абстракции. Надо или не изображать умное лицо, а писать по-простому $result->fetch_array(), или - если делать по уму - то сделать свой класс $dbResult, который инкапсулирует работу с mysqli_result и будет логично вызываться, как $row = $dbResult->fetchArray();. Смена кейса нужна, чтобы не путать этот объект с оригинальным mysqli_result
empty($_COOKIE['tmpsid'])) OR (!isset($_COOKIE['tmpsid']))- это масло масляное, вместе их писать никогда нет смысла. Прочтите хотя бы один раз описание empty в мануале. И в целом там какая-то дичь, почему-то условия дублируются. По уму нужно только два - isset и регулярка.$hash = md5(ip().time()); подделывается влёт. Не надо экономить на спичках, надо сгенерить нормальное случайное значение через random_bytes() и записать его в базу
в целом лучше разделить класс Admin на два - модель и контроллер, чтобы второй в своей работе использовал методы первого, а не работал с базой напрямую.
"Все наименование полей и таблиц собираются из формы, а так же: тип данных, поле с уникальным значеним, обязательно поле к заполнению" - такой GraphQL на коленке, наверняка состоит из инъекций чуть более, чем весь. В итоге размазали работу БД между моделью и клиентом. Нормальный такой MVC.
В целом, как я и писал, это материал для Тостера, а не для Хабра. Если в с первой статьёй вас решили поддержать, то эта вряд ли будет в плюсах. С другой стороны, фидбека вы соберёте полную панамку.
Я бы на вашем месте перестал писать велосипеды, а взял микрофреймворк (рекомендую https://fatfreeframework.com/ с плагином https://github.com/ikkez/f3-cortex чтоб не мучаться с написанием запросов). Микрофреймворк убирает кучу велосипедов и при этом не диктует вам никаких условий.
Для UI я взял бы EasyUI https://www.jeasyui.com/ а чтоб не писать ручками весь javascript можно использовать мой враппер https://github.com/Vladzimir/phpEasyUI
Хорошее предложение, но ему ещё рано. Вы вспомните себя на этом этапе. Поймите, он не мучается. Он офигевает от возможности писать SQL запросы. Ему это ещё не надоело. Да и с элементарным синтаксисом SQL он ещё очень на вы. Вот когда он его освоит, а писать однообразные запросы надоест - тогда и подпихивайте ему свой ORM, и он будет его с не меньшим энтузиазмом осваивать, при этом понимая, какие запросы получаются в итоге. А сейчас если ему насильно втюхать, то получите очередную обезьяну с пишмашинкой.
Автор, мы все с чего то начинали когда-то. И всегда стыдно смотреть на своей первый код. Но! Просто совет на будущее: где есть деньги (оплаты, остатки, расчёты, выставление счетов, отчёты и т. д.) всегда ооочень внимательно тестируй.
Интерфейс это хорошо, но как показывает практика к любому интерфейсу привыкают, а вот несходимость дебета/кредита - можно и на деньги встрять.
Почему то менеджеры не особо любят включать мозг и полностью доверяют цифрам на экране. В итоге любые наезды на них заканчиваются тыканьем пальцем в экран и полностью отрицание своей виныс криками: "Это все программа виновата!" Но, если их ЗП зависит от процента продаж, то они первые все сами себе пересчитают и сами же первые тебе на твой баг покажут.
В итоге. Про покрытие тестами конечно рано ещё говорить, но банально перед любыми правками хотя бы иметь заранее просчитаными хоть на бумажке парочку клиентов стоит, и всегда сверятся, не поплыли все расчёты.
Удачи в работе!
Кодстайл соблюдаете?
CRM для автошколы, часть 2