Дисклеймер: этот текст меня заставило написать практически полное отсутствие вменяемых материалов по данной теме на русском языке. Этому не учат в вузах, об этом молчат самоучители PHP и официальный мануал, хотя это самый важный момент при разработке программы - создание архитектуры. Плохая архитектура может убить ваш проект, так что он никогда не увидит свет. Хорошая архитектура даже при плохом коде, а кто из новичков пишет хороший код, способна творить чудеса. Итак, поехали. Разработка архитектуры должна начинаться в тот момент, когда вам в голову пришла идея "хочу сайт такой-то" или кто-то вложил идею "нужен сайт такой-то". Большинство разработчиков сразу приступают к написанию кода, причём даже не того, какого нужно. Прежде чем писать код, вооружитесь листочком, вордпадом, вордом, райтером или даже вашим редактором кода и выполните пару шагов. Шаг 1. Постановка главной задачи Архитектура разрабатывается сверху вниз. Что это значит? Это значит, что вы продумываете главные подсистему прежде чем приступить к более низкоуровневым. Многие программисты начинают разработку сайтов с роутеров, подключения к БД, обработки ошибок, что приводит к необходимости переписывания их кода в будущем или обильной вставке костылей в код, как только они наталкиваются на то, что не смогли предусмотреть. При разработке архитектуры об этом вообще думать нельзя. Это не единственный подход, но по опыт знаю, что самый оптимальный для тех, кто не чувствует себя, как рыба в воде среди паттернов проектирования или вообще ничего про них не знает. Итак, вам нужен блог, интернет-магазин, сайт стоматологической клиники. Определитесь, что на вашем сайте самое главное, ради чего всё затевается. Для блога - это, очевидно записи. Для магазина - товары. Для сайта поликлиники - услуги. Уже можем написать код, с которого мы и начнём разработку сайта: Код (Text): class записи { } или class товары... или class услуги{} Это ваша главная подсистема управления записями/товарами/услугами. Сразу же можно написать, чем именно она будет управлять. Код (Text): class запись { } или class товар... или class услуга{} Шаг 2. Определить, что ваша система умеет делать Мы создали главную подсистему "записи". Следующий шаг определить, что она будет уметь, чему мы хотим научить наш сайт. Очевидно, она должна уметь создавать записи, удалять записи и получать записи. Забудьте, что вы пишите код сайта, забудьте про пользователей, url-адреса, оформление страниц. Работайте с голыми данными: строками, числами, массивами, объектами. Код (Text): class записи { public function создать_запись() {} punlic function удалить_запись() {} public function получить_запись() {} } Шаг 3. Понять, с чем имеем дело. Что такое запись? Что такое услуга? Что такое товар? Для вас - это просто совокупность данных. В третьем шаге определяем, что это за совокупность. Не стремитесь предусмотреть всё, что понадобится когда-то в будущем. Берите самый-самый минимальный набор. Для этого мы и строим архитектуру приложения, чтобы в будущем её было легко нарастить. Очевидно, запись - это заголовок и текст записи. Услуга - название, описание и цена. Товар - тоже самое, что услуга. Компьютер - не очень умное создание, по сравнению с человеком, поэтому ему всегда необходим какой-то уникальный код, чтобы он среди множества записей узнал именно ту, которую вы хотите. Это либо порядковый номер (id), уникальный для каждой записи или некое строковое значение столь же уникальное. Значит наша запись - это идентификатор записи, заголовок, текст. Больше нам ничего не нужно. Шаг 4. Определение необходимых знаний. Теперь нам нужно для каждого действия понять, что системе нужно знать, чтобы его выполнить. Для действия создать_запись нужно знать заголовок и текст записи. Внутренний идентификатор нужен только компьютеру, поэтому пусть сам его и придумывает, какой больше нравится. Для действий удалить_запись и получить_запись нужно знать тот самый идентификатор записи, который был присвоен записи при создании. Код (Text): class записи { public function создать_запись($заголовок, $текст) {} punlic function удалить_запись($идентификатор) {} public function получить_запись($идентификатор) {} } То, что получилось называется интерфейсом вашего класса/модуля/подсистемы. Шаг 5. Определение результатов. Также, как мы узнали необходимые знания для выполнения того или иного действия, нужно придумать, чем эти действия будут оканчиваться. Если у компьютера всё получилось, то создать_запись - будет создана новая запись, а мы получим её идентификатор. удалить_запись - будет удалена конкретная запись, а мы получим сообщение 'ok' получить_запись - получим нужную запись Если у компьютера чего-то не получилось, то создать_запись - будет выброшено исключение удалить_запись - будет выброшено исключение получить_запись - будет выброшено исключение Для всех ситуаций, когда что-то не получилось поведение программы должно быть одинаковым во всех модулях/классах/подсистемах вашей системы. PHP предоставляет всего два варианта: trigger_error и throw new Exception. Можете придумать свой, но не стоит изобретать велосипеды, пока вы ещё не научились ездить на существующих. throw new Exception - самый оптимальный вариант. Читайте раздел "исключения" в официальном мануале. Шаг 6. Снова с начала В шаге первом, кроме создания системы управления записями, мы создали ещё класс и самой записи. class запись {} Для неё нужно сделать тоже самое, те же самые шаги 1-5. Сразу пишу код. Если вы всё сделали правильно, то у вас должно получиться что-то похожее. Код (Text): class запись { public function получить_идентификатор() {} public function получить_заголовок() {} punlic function получить_текст() {} public function изменить_заголовок($новый_заголовок) {} public function изменить_текст($новый_текст) {} } Шаг 7. Пишем код. Теперь, когда всё создано можно приступать к кодированию. Если вы знакомы с PHP никаких проблем у вас не возникнет. Заключение То, что у вас в итоге получится, в страшной аббревиатуре MVC скрывается под буквой M. Я не учёл много нюансов, их хватит на десять таких же статей, но базис для вашей разработки уже есть. Это в любом случае лучше, чем мешать PHP с HTML в одном файле или непродуманно плодить кучу функций по ходу разработки. C M разобрались. Что касается V и C. Это тема для других статей. Поэтому вкратце. Если вы достаточно сообразительны, то другие статьи вам и не понадобятся. C - это место, в котором система реагирует на действия пользователя. Вот там и нужно думать, что будет делать пользователь. Захотел пользователь создать запись в блоге, заполнил форму создания, а у вас уже всё готово, чтобы выполнить его команду. Захотел, прочитать запись и снова вы выполняете его просьбу в одну строчку. Там, главное понять, что он попросил. V - изучите любой шаблонизатор: Smarty или Twig. Много споров есть про то использовать шаблонизаторы или нет, убедительных доводов с той и с другой стороны. А вы не верьте никому на слово. Убедитесь сами стоит их использовать или нет, просто попробовав использовать. Для веб-разработчика непростительно не уметь пользоваться шаблонизаторами, даже если его религия против их использования. Выношу на суд общественности. Ещё на Хабре выложу чуть позже. Больше нигде.
ну вы исходите из постулата о том, что класс сущности первичен. А это вкусовщина. Надо об этом сказать в предисловии, а то закидают.
Сейчас много самоучек и мало кто добросовестно учится в институтах. В большинстве случаев все эти курсы а) чисто теоретические (как у меня было), забываются на следующий день после сдачи экзаменов; б) загромождены техническими терминами, что делает их скучными и непонятными в условиях реальной жизни; в) ведутся аспирантками, которые кроме как в дипломе и строчки кода не написали, или профессорами 70-х годов, которые последний раз программировали на перфокартах. У меня был профессор, который вряд ли знал, что такое MVC, рассказывал какую-то фигню про АСУ полётами вертолётов. Скука смертная. Я написал, что это не единственный подход, но самый оптимальный для новичков. Для меня оно, как откровение было, когда впервые узнал. Сразу всё упростилось. До этого писал в том порядке, как программа на сервере исполняется. От низкоуровневых операций к высокоуровневым. Достоинств других подходов я в веб-разработке не вижу. Для игр, может быть, разве что.
так если самоучке сложно осилить термины и продолжать помнить после экзаменов теорию, может программирование ему нафиг и не нужно? А тот препод с перфокартами 100% имеет больше опыта чем у тебя и сможет осилить MVC, но их ставят на теорию алгоритмов, а не на теорию ООП. Ты молодец что написал текст, но было бы хорошо посоветовать например книги к прочтению или откуда ты брал информацию.
Опытный программист !== хороший преподаватель. Умение преподавать - объяснять сложные вещи простыми словами. Другой навык. Про книги - хорошее замечание, но, как я написал, на русском языке подобных материалов мне не встречалось. Английский я не настолько хорошо знаю, чтобы книги читать. Всё познал на собственном опыте и замечаниям более опытных коллег. Достойную книгу знаю только одну: Стив Макконнелл "Совершенный код". Но вопросы проектирования там тоже рассмотрены без примеров. Я лично без примеров обучаться не умею. Мне нужна практика. Поэтому эти главы прошли мимо меня. Кстати, набросайте список литературы по этим вопросам, если знаете. С удовольствием почитаю и буду рекомендовать новичкам.
Бремя доказательства постулата лежит на постулирующем. "Самый оптимальный" очень размытая формулировка. Лучше сначала плюсы/минусы, а потом типа авторский вывод - подходит для новичков. Существует несколько типов мышления, и для некоторых такой подход не катит никак и ни в какую. Обычно никто об этом не задумывается, и тупо спорят по кругу. Стоит заранее обозначить, что мол для людей, которые начинают строить дом с крышы и видят всю концепцию своего сайта и результат сразу -- это подход приятный. Для людей, которые не изучив всю доступную теорию, не напишут даже строчки - им лучше читать про MVC и начинать с контроллера... Некоторым лучше по шагам снизу, некоторым сверху. Я порой пишу то, что больше топырит в данный конкретный момент -- сумма работы-то не меняется. Порой пишешь по нескольку часов, а то и дней, ни разу не запуская. Основные типы это практик и теоретик. Практику лучше сначала прям с хтмл начинать, а теоретику с ассемблера. Дельная мысль.
Реальный мир сложнее. Приходит паренёк устраиваться на работу. Глаза горят, видно мечтает именно об этом, надо брать. А он ни хрена не знает, кроме тегов HTML, расширения mysql и пары встроенных функций. Учился по самоучителю. Приходится тратить время и учить, учить, учить, чтобы вырастить из человека программиста. На реальные проекты его кидать нельзя, а зарплату платить нужно. Нужен самый-самый быстрый старт в адекватную разработку. Я предложил вот такой вот. Других - не знаю. Начинать с фреймворков - никогда не научиться программировать. Это как есть уже пережёванную кем-то пищу. К фреймворкам приходят, а не начинают с них.
только начал читать С.Макконнелла "Совершенный код", так там тоже идёт речь о планировании того, как это всё должно выглядеть. что это нужно придавать значение если не столько же, то даже больше, чем самому написанию кода.
это когда ты понимаешь, что планируешь. Планировать от балды пальцем в небо так же важно, как нифига.
зря ты отправил, не написав того, что я говорил. Плюсы/минусы это маст хэв при публикации статьи в XXI веке.
117 добавили в избранное. Это хорошо. На хабре не умеют отличать материалы для начинающих от материалов для экспертов. Плюсы/минусы новичкам не нужны. Им нужна прямая дорога без необходимости делать выбор в тех вопросах, в которых они ещё не разбираются. Вы когда общаетесь со специалистом в области, в которой ничего не понимаете, доверяете ему. Если врач будет сравнивать два лекарства и предлагать вам сделать выбор, вы не сможете выбрать. Вопрос будет одним: а что лучше?
Period, логика, зачем на веру брать, это не аксиома из математики, а алгоритмы которые имеют параметры. У многих новичков каша в голове, и они не хотят читать теорию с практикой.
Не знаю как другие, я часто использую хабровское "в избранное" как закладку, чтобы почитать статью когда-нибудь потом (и реально никогда не возвращаюсь). Ну просто понравился заголовок и текст до ката — xyякc в избранное и дальше пошел серфить
у тебя очень радикальная и вкусовая статья. Это вообще неприемлимо для статьи такой направленности и глубины.
Учат, автор, еще как. У нас даже на зачете были задания по технологиям программирования, мол, запилите абстрактно архитектуру системы, обслуживающей сотовую связь и покажите юзкейсами, как будет обрабатываться звонок и отправка смс. За 30-40 минуток
Как указывалось выше, тему изучает целая наука. И называется она Информационная архитектура. И конкретно информационной архитектуре, включая её применению в веб-разработке обучают и в вузах. Теме посвящено не мало литературы. Вот неплохие примеры: Л. Розенфельд, Питер Морвиль. Информационная архитектура в Интернете. A Practical Guide to Information Architecture by Donna Spencer
А что, если я скажу, что разработка от низкого уровня к высокому более верная в силу того, что сразу формируется основа? Дом с крыши не строят. Необходимость переписывания и дописывания этой основы, разумеется, будет. С костылями или без - зависит от того, как эта основа была заложена. Предусмотреть все и сразу нельзя, но, если что-то нужно, залез, дописал, вытянул наружу, пользуешься. Именно для этого и продумывают изначально пресловутую архитектуру. Чтобы было, вокруг чего танцевать. При проектировании любой системы, важно учитывать такие параметры как "расширяемость" и "гибкость". Первый отвечает за то, на сколько легко будет дописывать систему, в случае чего. Второй - насколько мягко будут изменения приняты, и насколько просто будет пересмотреть целые ее фрагменты. Это все закладывается еще на стадии имено предразработки. Проектирование системы - это не кодинг. Это квадратики, стрелочки, кружочки, абстракция, по образу которой будет строиться и развиваться сам проект. Добавлено спустя 6 минут 40 секунд: Статья, если честно, ни о чем. ИМХО. Про архитектуру там ни слова нет. Про проектирование тоже. Обычная стихийная разработка, которая, в итоге, закончится тем, что все надо будет переписать с нуля, с учетом ошибок. Не написано, что такое хорошая архитектура, что такое плохая, что такое промышленный метод разработки, что такое ремесленный. Не написано, что вообще такое - архитектура. Написано, что нужен главный класс, которому будет подчиняться еще один класс. И как-то они будут связаны еще с чем-то, наверное. Но об этом не надо думать. А потом пункт 7 - КОДИТЬ.
Аналогия неверная. Дом строят с готовым пониманием, кто в нём будет жить. Одна семья, две, три, может это общага или дом престорелых. Только с высокого уровня начинают. Как и любую технику. Сначала определяют потребительские параметры, что будет уметь, а не как будет реализовано, потом уже под них разрабатывают железо и корпус. Почему программы должны быть исключением? Ну, судя по вашему тексту, вы достаточно хорошо разбираетесь в теме, по крайней мере, в терминологии, поэтому и кажется, что ни о чём. Ну это как самоучитель по пользованию виндой читать. Скучно и ни о чём. Статья пытается решить конкретную задачу: дать тому, кто только вчера сел за PHP хоть какое-то представление о проектировании. Меньше дров наломают, больше качественного кода в мире будет. Глушить терминологией - нафиг надо. Я считаю хорошо решает поставленную задачу, даже уже на опыте вижу это. Это не мастер-класс, это первые шаги. Может в идеале, хорошо обложиться целой библиотекой по компьютерным наукам. Но в реальном мире покупают один самоучитель и начинают сразу херачить код... А я потом отлаживаю его или расширяю
В том и соль, что читал "как если бы вчера только сел", и ничему этот текст меня не научил, кроме того, что в ООП-приложениях есть такое понятие, как иерархия классов. А если я скажу, что архитектура вооооооообще никак не связана с ООП? Архитектура - это не то, как называются классы и что они делают. Это формальное описание компонентов системы, с описанием связей, последовательности передачи управления. Компонентами системы, в первую очередь, являются те ее части, что составляют базу для работы самого приложения. Класс records - не база. Нет, в тексте нет бреда. Но суть проектирования в том, что оно проводится еще ДО того, как в системе будут определены классы, ДО того, как вообще появится какая-то конкретика. Сначала абстрактно. Есть, грубо, служебная часть системы, есть пользовательская. В служебной то-то, связано так-то, в пользовательской то-то, между собой общаются так-то. Каждый фрагмент служебной части устроен так-то, а фрагмент пользовательской так-то. Такие-то правила унификации. Потом, в процессе разработки, какие-то решения будут пересматриваться, дорабатываться, часть - радикально. НО, чем корректнее была заложена абстрактная основа, тем легче будет эти доработки проводить, включая момент с радикальным пересмотром каких-то моментов. Это как строить дом - начинать надо не с выбора типа оконных рам, а с плана. К сожалению, подход вида делать echo $_POST['moya_zapis']; и оплетать ее кодом по принципу "а сейчас мне нужно это, допишу-ка где-то тут" - это стихийная разработка. Именно она, увы, и ведет к нагромождению костылей в будущем. Именно она херит, со временем, поддерживаемость и гибкость. Как-то так.