Плюсовику нужна организационная помощь в PHP

Обычно это вообще простыня и всё. Заголовочных файлов (если ты имеешь ввиду .h) нет. IDE, по идее, тебе подскажет, есть функция или нет.

Средствами IDE (или * с плагином)? Ну и слишком жирные у тебя классы
Кстати, почему на php есть же много другого хорошего.

IDE, по идее, тебе подскажет

Ну я по-старинке в vim-е пишу...

Т.е. единственный выход это комментарии?
Блин. Это не очень-то удобно.

Ну и слишком жирные у тебя классы

Ой, да ладно.
600-700 строк да 2 десятка методов.
Но этого объёма уже хватает чтобы запутаться...

Угу. Лично мне тоже IDE не подсказывает, но я всё помню. Может быть ты неправильно готовишь классы?.. В них редко есть смысл пихать 1500 методов. Хотелось бы конкретики какой-то, что именно ты делаешь?

Есть еще всякие там системы документирования и так далее, которые автоматом собирают инфу о фукнциях по определенным образом оформленным комментариям над ними (уверен, ты в курсе). Но это как-то не очень к месту.

P.S. Правда, я и в CPP знал, что лежит в моем классе и IDE по сути не особо была нужна.

Ну я по-старинке в vim-е пишу...

бугага, выкидывай уже хакирские подходы, бери symphony2 и труби на нем

еще IDE не забудь с автодополнением и phpdoc

У меня просто проект в замом зачаточном виде, поэтому часто приходится метаться от одного класса к другому — то там чего-то не хватает, то какой-то метод логичней таки перенести в другой класс.
Поэтому состав классов (не говоря уже о точном имени и списке параметров ф-ций) в голове держится хреново.
Ну да хрен с ним.
Просто мелкое неудобство. В масштабе моего кода не принципиальное.

Тогда просто забей. Все равно, имхо, проще менять что-то в одном файле, а не в двух (.cpp и .h). Тупо быстрее.

К слову, рекомендую сразу погуглить про то, как делается MVC в PHP, от кучи головной боли избавит. ;) Если это твой первый проект. Веб, он... Особенный. Например, те же классы. В отличие от обычного софта, PHP генерит страницу и умирает. Поэтому некоторая специфика. Ммм, представь одноногого мальчика, который хочет поиграть в песочнице с другими детишками, лол.

Но этого объёма уже хватает чтобы запутаться.

это и означает «слишком жирные»

Почитал про ПХПшное ООП. Всё такое.
И тут вопрос: есть ли в ПХП аналог сишных заголовочных файлов?

Нет, здесь немного другой принцип работы

А то классы растут и я начинаю уже теряться а есть ли такая-то функция в классе или нет...

Ты возможно пишешь в своей манере системного разработчика, которая не подходит PHP. Если у тебя такие классы - ты явно ошибся в выборе архитектуры. В PHP существует множество документации, описывающей как разработать приложение, чтобы оно не умерло сразу после запуска.

Как это принято разруливать в ПХП?

С помощью встроенных возможностей любой PHP IDE. Самые популярные: Eclipse PDT (Zend Studio), NetBeans, PHPStorm (JetBrains)

Или вы просто в комментариях перечисляете все методы?

Да, в формате PHPDoc. Это считается бест практис и очень полезно для той же самой эвристики (многие IDE, включая PHPStorm делают частичный статический анализ кода, не давая тебе загнать себя в угол).

Я тут размахнулся на достаточно большой проект на ПХП.

Тогда первое что надо сделать - подобрать подходящий фреймворк. Я предпочитаю Yii (сейчас доступна Yii2 Alpha, если планирует стартануть через несколько месяцев - имеет смысл ее взять, как раз релизнется стейбл где-то там), можно рекомендовать Symfony2, Laravel, Zend, Kohana. У них разные парадигмы по работе с БД (ORM vs DataMapper) и в целом много различий, стоит подобрать подходящую.

В основном, для веб проектов сейчас почти все фреймворки используют паттерн MVC, предъявляя вполне конкретные требования к каждому компоненту и классу (причем подход внутри MVC может быть очень разным, к примеру Yii vs Symfony). Твои классы просто не могут получиться при правильном выборе фреймворка.

Если ты продолжишь кодить в vim и без ORM и фреймворка, варианта всего 2, никакого мифического третьего нету, даже не думай:
1. накодишь говнокода, который не заработает;
2. если оно хоть как-то заработает - значит ты нам соврал про «достаточно большой» проект.

умирает

И не говори.
Огромное количество расчётов приходится производить каждый раз при запросе.
На Си я просто выделил бы память и засунул туда результаты.
Для ПХП, правда, я нашёл такую штуку как memcache — не уверен, что это правильно, но вроде работает...

И не говори.
Огромное количество расчётов приходится производить каждый раз при запросе.
На Си я просто выделил бы память и засунул туда результаты.
Для ПХП, правда, я нашёл такую штуку как memcache — не уверен, что это правильно, но вроде работает...

Вполне правильно. Для PHP есть несколько кеширующих бэкендов, мемкеш немного не для этого предназначен, но можно использовать. В основном для твоей задачи используется (в зависимости от конкретной проблемы) либо MySQL, либо APC.

Надо аккуратно все далать и следить за доступом к данным от разных пользователей и т.д.

memcache

Некоторым CMS не помогает ничто, например Bitrix'у. Когда я его последний раз видел, его километровый запрос в БД жрал 2 секунды. Кошмар полный, в общем. Поэтому важно писать нормально, Но это приходит со временем. memcache, суть, это как на жирного нгатянуть корсет - он все равно внутри жирный.

В отличие от обычного софта, PHP генерит страницу и умирает.

Вы фундаментально не правы.

Так работает Apache и NGinx в конкретной схеме обслуживания веб приложения.

На PHP можно писать стэндэлон скрипты, демоны и все что хочешь, которые не будут умирать после дисконнекта. Само собой, для этого не подходит фронтенд типа апача, чья задача обслужить коннект и все прибить.

либо MySQL, либо APC

Шта...

На PHP можно писать стэндэлон скрипты, демоны и все что хочешь, которые не будут умирать после дисконнекта.

В курсе. Зачем? Товарищ сишник. Писал бы демон, писал бы на Си. Logic, bitch!

Некоторым CMS не помогает ничто, например Bitrix'у. Когда я его последний раз видел, его километровый запрос в БД жрал 2 секунды. Кошмар полный, в общем. Поэтому важно писать нормально, Но это приходит со временем. memcache, суть, это как на жирного нгатянуть корсет - он все равно внутри жирный.

Здесь не хочу спорить, это неблагодарное дело. Вы мне все равно не поверите. Я сертифицированый битриксоид и работаю с ним в целом около 5 лет плотно, со всеми редакциями, включая кластерные и корпортал. Скажу две вещи:

1. Я ненавижу битрикс. Внутри он ужасен.
2. Вы не правы. Вы просто не умеете его готовить. Битрикс может работать быстро, когда за него берется умеющий человек.

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

В курсе. Зачем? Товарищ сишник. Писал бы демон, писал бы на Си. Logic, bitch!

Это вопрос к товарищу. Зачем-то же выбрал PHP, мог бы и на сях порт открыть и отвечать. Может человек хочет новый опыт получить, кто его знает.

либо MySQL, либо APC

Шта...

Какой вопрос? Возможно у нас недопонимание.

Автор не указал что он вычисляет. Если это параметры сессии какие-то, их можно загнать в MySQL или куку, если что-то юзероиндивидуальное и громоздкое - можно поместить в кеш APC, он обычно быстрее memcache. Вариантов много.

Я сертифицированый битриксоид и работаю с ним в целом около 5 лет
1. Я ненавижу битрикс. Внутри он ужасен.

В принципе, на этом моменте уже всё понятно, но я таки спрошу...

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

Может и не умею, не мне судить. Дело было года 4 назад, точно не помню. Я поставил в шаблон стандартный (!) компонент логина/регистрации пользователя. Все начало лагать. Начал дебажить. Выяснилось - чтобы получить тупо инфу о пользователе, Bitrix фигачит просто километровый запрос в базу. Километровый! Без шуток. Срочек на 15, наверное, с кучей вложенных подзапросов, объединений. Я навсегда запомнил тот шок, когда увидел.

Подчеркну, что это «из коробки». Если под «готовить битрикс» вы имели ввиду - «переписывать запросы за разработов», то да. Но что я сделал не так? То есть я не менял ничего, просто поставил компонент в шаблон.

Вещи принципиально разные - одно база данных, другое кеш. Вот я и удивился. Про «загнать временные данные в MySQL» я уже подумал, но имхо это говно-код. Может я и не прав.

Может и не умею, не мне судить. Дело было года 4 назад, точно не помню. Я поставил в шаблон стандартный (!) компонент логина/регистрации пользователя. Все начало лагать. Начал дебажить. Выяснилось - чтобы получить тупо инфу о пользователе, Bitrix фигачит просто километровый запрос в базу. Километровый! Без шуток. Срочек на 15, наверное, с кучей вложенных подзапросов, объединений. Я навсегда запомнил тот шок, когда увидел.

Я вас уверяю, этот запрос не прописан там и строится кверибилдером налету. Он проверяет очень много данных.

Битрикс изначально разрабатывался как ДОКУМЕНТНЫЙ ОРМ поверх реляционного, тогда еще не было монгодб и noSQL как такового в паблике. Почти любая сущность в нем - это набор таблиц и связей, тот же юзер раздербанен на 10-15 таблиц в среднем (в зависимости от редакции) + несколько вариантов прав доступа (ролевой и мандатный) + если вы делаете расширяемые поля - они идут как EAV сущности.

Но ваша проблема решается правильной расстановкой индексов в БД и всего-лишь. Сейчас (где-то с 12 версии, а вы на 8-10 тогда были) он в админке указывает какие индексы стоит добавить и прочее. Кеширует что нужно. С 12 версии у них появились наконец highload инфоблоки, основанные на noSQL (собственно то, что битрикс и воплощает сам по себе), в 14 версии у них новый движок d7, из которого выбросили много мусора и в целом он сильно шустрее + запросы строит грамотнее.

Так что время идет, он развивается и более чем юзабелен. Я его даже рекомендую в качестве средства быстрой разработки сайтов, особенно магазинов, так как с 1С потом не будет проблем.

Вещи принципиально разные - одно база данных, другое кеш. Вот я и удивился. Про «загнать временные данные в MySQL» я уже подумал, но имхо это говно-код. Может я и не прав.

Вы правы, тут просто очень абстрактный разговор. Сишник в первый раз, особенно начитавшись мануалов для новичков, вполне может начать с реализации стека и сохранения его в txt файл. Поэтому я пытаюсь засветить побольше технологий, чтобы побудить человека поизучать и пошевелить мозгом. Это его спасет позже.

Но ваша проблема решается правильной расстановкой индексов в БД и всего-лишь.

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

Да, к слову, сильно он шагнул вперед с того дня, когда я его видел последний раз.

есть ли в ПХП аналог сишных заголовочных файлов?

Нет. Но можно, например, описывать интерфейсы в подключаемых файлах.

А то классы растут и я начинаю уже теряться а есть ли такая-то функция в классе или нет...

Хорошая декомпозиция, небольшие однозначные классы, унифицированная система именований методов. Если этого мало, то всякие phpDocumentor и аналоги + IDE.

Komodo Edit рекомендую. Тыкаешь его мордой в проект, начинает работать автодополнение. Есть навигация по классам и функциям в файле. Можно как-то еще по открытым файлам, но мне это не надо.

Ну я по-старинке в vim-е пишу...

бугага, выкидывай уже хакирские подходы, бери symphony2 и труби на нем

Это ортогонально. Я, вообще, в mcedit пишу. Но уровень абстракции на моём фреймворке такой, что Symphony выглядит чем-то крайне низкоуровневым, требующим в 10 раз больше работы. Собственно, 2/3 решений вообще на голом YAML могут описываться. В крайнем случае — переменными класса.

И, наоборот, можно (и полезно) на наворочанных IDE писать на голом PHP.

А я согласен с Плюсовику нужна организационная помощь в PHP (комментарий)

последним абзацем

Огромное количество расчётов приходится производить каждый раз при запросе.

При правильной организации практически все расчёты всё равно привязаны к запросу. Зато бонус — память не течёт :)

Кстати, можно посмотреть на фреймворк Phalcon. Там основная работа по обработке запроса на Си написана. На PHP уже только прикладная логика.

Для ПХП, правда, я нашёл такую штуку как memcache

Лучше Redis. Производительнее и надёжнее. А так — да. Если какие-то тяжело создаваемые объекты, то их удобно в быстром key-value хранить.

Битрикс изначально разрабатывался как ДОКУМЕНТНЫЙ ОРМ поверх реляционного, тогда еще не было монгодб и noSQL как такового в паблике. Почти любая сущность в нем - это набор таблиц и связей, тот же юзер раздербанен на 10-15 таблиц в среднем

Что забавно, я 10 лет назад начинал делать также. Но уже лет 8 назад, как только полез в высокие нагрузки, понял ущербность подхода и принципиально перекроил подход к организации «документного ORM». Старый вариант, правда, до сих пор поддерживается в Legacy, но, к счастью, на нём осталось всего пара объектов в паре проектов, так что со временем снесу и забуду как страшный сон :D

Что же до кеширования, самый грамотный подход, ИМХО, это кеширование в статическом HTML. А всякая персональная пользовательская динамика — через AJAX.

Некоторым CMS не помогает ничто, например Bitrix'у. Когда я его последний раз видел, его километровый запрос в БД жрал 2 секунды.

Ты просто не умеешь его готовить. Понимая суть можно вытворять интересные вещи. Только надо меньше читать документацию и больше смотреть в код. Мне попадались сайты грамотно в принципе сделанные, но фильтр товаров генерил запрос который вешал на 20 минут базу. Чуть-чуть прикладываем мозг и вот уже этот запрос выполняется полсекунды. Реальная история успеха между прочим...

А я согласен с

Ну так в моём сообщении примерно то же самое, только вывернутое наизнанку. В том смысле, что если голый PHP, то IDE нужен, конечно. Просто IDE обычно сильно ограничивает разработку, поэтому лично мне удобнее mcedit, который есть на каждой удалённой машине + очень высокий уровень прослоек, которые берут на себя всю работу по связи компонентов и вычислению массы подразумеваемых параметров. «Machines should work; people should think» © IBM

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

Пол-секунды на запрос — это ужасно :)

1. Я ненавижу битрикс. Внутри он ужасен.
2. Вы не правы. Вы просто не умеете его готовить. Битрикс может работать быстро, когда за него берется умеющий человек.

Люто плюсую оба пункта. Причем, что интересно, чем дальше тем ужаснее. Взяли финализировали методы половины классов в ядре... Нахера? Увидели новое слова в PHP и давай его лепить на все что под руку попадется.

Против 20 минут это вин.

Мне попадались сайты грамотно в принципе сделанные, но фильтр товаров генерил запрос который вешал на 20 минут базу.

В битриксе ты не сам запросы в базу пишешь. Можно, конечно, послать битрикс и сделать свой фильтр, но это уже не битрикс. Всю его суть в том, что «сделать сайт из коробки». И это действительно удобно, я вообще проникся идеей инфоблоков и т.п. Но для высоких нагрузок он не очень, имхо.

С 12 версии у них появились наконец highload инфоблоки, основанные на noSQL (собственно то, что битрикс и воплощает сам по себе)

4.2 С 14 версии хайлоад инфоблоки появились и таки никаким NoSQL там не пахнет - оно все там же в мускуле валяется, просто каждый инфоблок теперь отдельная таблица и все его своейства эта поля этой единственной таблицы. Можно сказать, наконец таки разрабы сделали то, что надо было сделать в самой первой альфе.

Я его даже рекомендую в качестве средства быстрой разработки сайтов, особенно магазинов, так как с 1С потом не будет проблем.

И снова 4.2 - они обязательно будут если 1С хоть чуть-чуть допилена руками.

В битриксе ты не сам запросы в базу пишешь.

Нет, не сам. Но когда я знаю КАК эти запросы строятся и КАК именно хранятся данные в базе, это дает мне некоторую власть над ситуацией. Те же свойства в фильтре я могу дернуть по их коду, а могу по ID, и в некоторых случаях это очень многое меняет. Собственно в описанном так и было.

Можно прогонять по коду доксигеном

4.2 С 14 версии хайлоад инфоблоки появились и таки никаким NoSQL там не пахнет - оно все там же в мускуле валяется, просто каждый инфоблок теперь отдельная таблица и все его своейства эта поля этой единственной таблицы. Можно сказать, наконец таки разрабы сделали то, что надо было сделать в самой первой альфе.

Ну не совсем 4.2. Highload инфоблоки появились в D7, а оно было уже в версии 12 и включалось созданием пустого файла в папке битрикс. Эти инфоблоки строятся поверх ORM, которая поддерживает noSQL. Причем сейчас оно хоть и в MySQL, но у нее есть интерфейсы по принципу работы noSQL, оракл об этом объявляла года 4 назад еще.

То о чем вы говорите было и ранее, в настройках обычных инфоблоков есть галочка «хранить свойства в отдельной таблице»

И снова 4.2 - они обязательно будут если 1С хоть чуть-чуть допилена руками.

Зависит от того, что допиливали. Само собой, если пилили - придется и тут пилить, но человеку, который хочет начать свой бизнес и создать свой первый интернет магазин - это не важно.

И тут вопрос: есть ли в ПХП аналог сишных заголовочных файлов?

для чего это?

фактический аналог в ПХП: include/require, все файлы считаются скриптами, но как правило содержат определения класса/интерфейса (по сущности на файл) и/или просто файл с произвольным содержимым кода.

Ну не совсем 4.2. Highload инфоблоки появились в D7, а оно было уже в версии 12 и включалось созданием пустого файла в папке битрикс. Эти инфоблоки строятся поверх ORM, которая поддерживает noSQL. Причем сейчас оно хоть и в MySQL, но у нее есть интерфейсы по принципу работы noSQL, оракл об этом объявляла года 4 назад еще.

Прямо по каждому предложению ответ один - было и есть не значит работало и используется. Разве для получения данных из хайлодов используется эти интерфейсы (если честно я еще не смотрел даже - пусть шишек понабивается достаточно другими ))) )?

То о чем вы говорите было и ранее, в настройках обычных инфоблоков есть галочка «хранить свойства в отдельной таблице»

Ну и снова 4.2 же. Хранение свойств в отдельной таблице не означает, что туда же перекочевывают все поля инфоблока и элементы начинают хранится отдельно. ВСЕ элементы всех инфоблоков все равно хранятся в одной единой таблице. В отличии от хайлойдов где каждый блок == реально отдельная таблица. Я даже уже предвижу как куча разрабов начнет пилить магазины с использованием только хайлодов и доведет количество таблиц в базе до неслыханных масштабов, куча всего, что ложилось на плечи API откачует в чистый PHP (при чем в половине случаев прямо в код страниц, а не компонентов), все станет колом и снова будет повод пнуть битрикс за то, что он тормозной.

Зависит от того, что допиливали. Само собой, если пилили - придется и тут пилить, но человеку, который хочет начать свой бизнес и создать свой первый интернет магазин - это не важно.

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

Как это принято разруливать в ПХП?

по классу на файл - в основном «соглашения» PSR (см. php-fig.org) Соответственно, в конечном итоге все разруливается автозагрузчиком классов. Никаких require_once/include_once для загрузки классов - все делается с помощью spl_autoload

Или вы просто в комментариях перечисляете все методы?

когда как - но меня больше устраивает doxymacs,php-mode,yasnippet, helm + некоторые дополнительные плагины и концепция git ls-files. Есть еще PDT,Netbeans.

Извини, а зачем ты взял эту каку? Вроде, PHP-онли хостинги отошли в прошлое. Или ты у макскома машину времени спёр?

Ну я не знаю как на плюсах без геморроя писать под веб.

И тут вопрос: есть ли в ПХП аналог сишных заголовочных файлов?

ты точно сишник? Знаешь зачем в сишечке заголовочные файлы?

А то классы растут и я начинаю уже теряться а есть ли такая-то функция в классе или нет... Как это принято разруливать в ПХП? Или вы просто в комментариях перечисляете все методы?

есть include_once("xxx.inc"). Весьма желательно, что-бы в каталог с этими файлами ни у кого не было доступа кроме апача (на чтение, и только), и разработчика.

Ну я по-старинке в vim-е пишу...

открой для себя cscoope и прочее такое. В vim'е это тоже можно. Ещё vim знает искароппки ВСЕ функции php.

Ну, я, собственно, тоже не знаю, ибо предпочитаю Haskell, но народ хвалит http://www.webtoolkit.eu/.

Для веба «сгенеристь страничку и умереть» стандартное поведение. Долгоживущая бекэндовая логика это скорее экзотика всё-таки.
Кстати ТСу возможно будет проще и эффективнее писать именно таким, долгоживущим, образом.

То что ты хочешь называется «интерфейсы» и имеет почти тот же синтаксис и семантику, что заголовочные файлы у крестоподобного

http://php.net/manual/ru/language.oop5.interfaces.php

Но для того, для чего ты хочешь это использовать, обычно никто это не использует. Потому что специально для решения таких проблем сделаны IDE.

Обрати внимание на PSR'ы: https://github.com/php-fig/fig-standards/tree/master/accepted

Возможно там есть ответы на то, что ты еще не спросил, но скоро спросишь =) В частности, о модульности и загрузке модулей.

За тыщу рублей в год можно купить PHP-шаредхостинг, который будет держать приличные нагрузки. За те же деньги можно купить впс максимум на 3 месяца, и не факт что он выдержит хоть какие-то нагрузки