> Добрый день. Решил создать сайт школы в формате сайта-визитки на чистом PHP.
> Столкнулся с тем, что для меня проблематично разбить эту задачу на
> подзадачи, т.е., банально, трудно понять с чего начать. Очевидно, что первоначально
> это должна быть верстка, но хотелось бы понять и более "локальные"
> задачи. Посоветуете какой то выход из этой ситуации?1) собираем и компонуем материал как это все должно выглядеть. Можно в обычном ворде. Определяемся с каждой страницей что и где у нас должно быть. В общем делаем простые макеты (чисто текст и картинки + описание ссылок и функционала).
2) делаем карту сайта (лучше на бумаге или в том же ворде). Это в общем похоже на оглавление.
3) Верстка: гуглим "botstrap шаблон для учреждения образования" ну или подобное
4) Выбираем php инструмент по вкусу. Это может быть laravel(или другой фрэймворк) или cms (joomla, wordpress). Самый интерес это api на laravel и frontent на nuxt(это SSR для vue) + все это в Docker (4 месяца копаний и вы готовы к трудоустройству в web studio на junior), ну или js fullstek.
5) Если вы хотите все таки самостоятельно разраббатывать а не использовать готовое, то используйте по максимуму уже готовые инструменты (composer, npm) и стандарты PHP (psr 4, 7). Окружение (т.е. всякие php, mysql, nodejs, nginx) только в Docker и только в Linux (ну ладно ладно, согласен на virtualbox в vagrant). Помните: разработка под web (не вестка и не дизайнерство!!!!) на винде, всегда подкидывает пусть и небольшие но лишние проблемы.
6) При разработке помните все есть блог и все есть CRUD.
7) НИКОГДА не разрабатывайте собственные костыли для авторизации. Взломают и присунут (а что и куда, не хочу даже говорить).
8) А если все таки это разовая задача и вы не связываете свое будущее с разработкой, то все таки лучше взять cms. Но согласен, свое (даже чисто в развлекательных целях), делать гораздо интереснее. К тому же навык программирования (даже минимальный), никогда лишним не будет.
9) а также используйте GIT. Пусть даже локально (без github) и в master-ветке. Но используйте. Вы даже не представляете скоко геммороя вы избежите при этом.
Не ну я понимаю, что мои рекомендации слишком размытые. Но тут сложно что-то еще посоветовать. Ну может быть только еще один нюанс:
В разработке инструмент часто не отличим от собственно решения задачи - и то и другое есть код. Соответственно представьте что вам нужно просверлить дырку. Вероятно вы купите для этого дрель или возьмете ее на прокат или просто попросите у знакомых. Но ВЫ НЕ БУДЕТЕ ДЕЛАТЬ ДРЕЛЬ. А даже если и сделаете что-то похожее на нее, качество будет несопоставимо с заводским продуктом.
Но в разработке очень часто люди, вместо того что-бы сверлить дырки, делают дрели. И это еще пол-беды, но эти самописные дрели используют в собственных проектах. И в результате часто получается "взрыв дрели". Эти дрели кстати называют "велосипеды" и "костыли".
Кроме того размер кода инструментов и кода решения задачи (так называемой бизнес-логики) может достигать соотношения: 99 к 1. Это означает что вы можете много дней, недель, месяцев делать свой движок блога(что как раз и являеться инструментом), который все равно выйдет кривым косым и падающим, вместо того что-бы взять тот же laravel, изучить за пару дней его основные моменты (миграции, маршрутизация, работа с бд, безопасность, авторизация, тестирования, фронтент компоненты и интеграция c webpack). Т.е вы потратите не меньше месяца на то что можно сделать не напрягаясь за неделю.
Поэтому лучший выход для начинающих это изучать процесс использования гоотовых компонентов. В том же PHP вы неизбежно столкнентесь с необходимостью понимания PSR и composer, а во фронтентде с webpack и его использованием в таких монстрах(в хорошем смысле) как react и vue.
Да даже когда вы достигнете уровня мидла или сеньора, так ли уж появиться необходимость в разработке собственного инструментария, если сейчас (ну по крайней мере в web) 99% основного инструментария(именно готового кода инструментов, библиотек, фрэймворков) уже существует и собственно ваша основная основная задача это сборка проекта из готовых кирпичей(фрэймворков, библиотек) путем смазывания их цементом бизнес-логики.
