Evgeny Novoselov

Во-первых, гипотеза лингвистической относительности утверждает, что чем больше языков знаешь, тем гибче и богаче твой логический аппарат. По своему опыту могу сказать, что это правда. Например изучение Lisp'ов существенно расширило мои возможности в других языках. Но мой опыт и мнение не так авторитетны, как авторов всемирно известного бестселлера "Программист-прагматик" - Эндрю Ханта и Дэвида Томаса, которые пишут: «Изучайте по крайней мере один новый язык ежегодно. Разные языки решают одни и те же проблемы разными способами. Изучив несколько разных подходов, вы сможете расширить свой кругозор и не погрязнуть в рутине.»

Во-вторых, рано или поздно профессиональный рост java-программиста, например, неизбежно приводит его к необходимости глубоко понимать работу компилятора и виртуальной машины, а это невозможно без знания C++, на котором они написаны.

В-третьих, java-программист свободно лазающий за ответами в исходники JVM, способный дебажить сборщик мусора, писать JNI-библиотеки и использовать Compiler API для метапрограммирования имеет больше предложений работы и более выгодные условия.

Вы - описали роли пользователя.
Хотите - создать роли ACL (access level system), понижающие действующие привелегии.

Сначала создайте ACL под все роли пользователей, что Вы описали (USER_ACL, MODERATOR_ACL и т.д.). Это таблица с привелегиями (битовая "маска" со степенями двойки): 1,2,4,8,16,32,64 и т.д. Сумма этих значений даёт число, однозначно определяющее ACL для доступа к различным функциям.

Затем - создайте различные BAN-наборы (ACL по тем же кретериям).
BAN_CHAT, BAN_EDIT, BAN_DELETE, BAN_REOWNER и т.д.

И из действующего *_ACL вычитаете BAN_*.

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

Аналогично, пример подключения bootstrap:

assets/dashboard/js/dashboard.js

var $ = require('jquery');
require('bootstrap');

assets/dashboard/scss/dashboard.scss
@import "~bootstrap/scss/bootstrap";

webpack.config.js

var Encore = require('@symfony/webpack-encore');

Encore
    .setOutputPath('public/assets/')
    .setPublicPath('/assets')
    .cleanupOutputBeforeBuild()
    .enableSourceMaps(!Encore.isProduction())
    .addEntry('js/dashboard', './assets/dashboard/js/dashboard.js')
    .addStyleEntry('css/dashboard', './assets/dashboard/scss/dashboard.scss')
    .enableSassLoader(function(sassOptions) {}, {
        resolveUrlLoader: false
    })
    .autoProvidejQuery()
;

module.exports = Encore.getWebpackConfig();

Что теперь делать - незаню.

Взять учебник.

$ javac Untitled-1.java
$ java HelloWorld

В версии 3.3 присутствует PSR-4 service discovery и autowire и autoconfigure опции которые автоматически регистрируют сервисы, резолвят зависимости и конфигурируют теги
Вот код, который за это отвечает: https://github.com/symfony/symfony-standard/blob/3...

Я бы рекомендовал использовать эти возможности, они сильно ускоряют разработку. Из минусов: проседаение в скорости генерации страниц в дебаг режиме из-за перегенерации контейнера.

Фреймворки, библиотеки и плагины для верстки сайта.

1. Bootstrap - самый популярный HTML, CSS, и JS фреймворк в мире для разработки отзывчивых, mobile-first проектов в вебе.

2. slick - Адаптивный слайдер для сайта

3. Owl Carousel 2 - красивый, отзывчивый карусельный слайдер

4. Fotorama - плагин для создания галереи на сайте

5. MagnificPopup - плагин для создания модальных окон

6. FancyBox - построениe всплывающих окон

7. Mmenu - мобильное меню


8. bxSlider - отзывчивый jQuery-слайдер для контента


9. Fullscreen Slit Slider - слайдер с интересной анимацией

10. parallax.js - эффект Parallax

Первая 10-ка

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

DiDom: https://github.com/Imangazaliev/DiDOM

+ высокая скорость работы (сравнение с другими парсерами)
+ хорошая дока
+ большое количество поддерживаемых селекторов
+ самое главное - тесты

Простой пример:

$document = new Document('http://www.example.com/', true);

echo $document->first('title::text');

Чуть посложнее - парсим все ссылки:

$links = $document->find('a[href]::attr(href)');

var_dump($links);

Еще сложнее - получить адреса всех ссылок-картинок:

$links = $document->find('a[href]:has(img)::attr(href)');

var_dump($links);

Другие варианты:
- Symfony DomCrawler
- Zend Dom Query

недавно тоже нужна была статистика, вот написал класс.
может поможет...

class yandex{

	const CLIENT_ID = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx';
	const CLIENT_SECRET = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx';
	const COUNTER_ID = '00000000';

	public static function getStat(){
		$token = self::auth();

		if($token){
			return self::getData(
				'https://api-metrika.yandex.ru/stat/traffic/summary.json?id='.self::COUNTER_ID,
				['Authorization: OAuth '.$token]
			);
		}
	}

	public static function auth(){
		if (!isset($_GET["code"])) {

			//здесь проверим токен в базе, иначе будем отсылать на получение кода

			Header("Location: https://oauth.yandex.ru/authorize?response_type=code&client_id=".self::CLIENT_ID);
			die();
		}

		//делаем запрос для получения токена
		$result = self::postKeys("https://oauth.yandex.ru/token",
			[
				'grant_type'=> 'authorization_code',
				'code'=> $_GET["code"],
				'client_id'=>self::CLIENT_ID,
				'client_secret'=>self::CLIENT_SECRET
			],
			['Content-type: application/x-www-form-urlencoded']
		);
		
		if ($result["code"]==200){
			$result["response"]=json_decode($result["response"],true);
			if(isset($result["response"]["access_token"]))
				return $result["response"]["access_token"];
			else
				return false;
		}else{
			return false;
		}

	}

	public static function postKeys($url,$peremen,$headers) {
		$post_arr=array();
		foreach ($peremen as $key=>$value) {
			$post_arr[]=$key."=".$value;
		}
		$data=implode('&',$post_arr);

		$handle=curl_init();
		curl_setopt($handle, CURLOPT_URL, $url);
		curl_setopt($handle, CURLOPT_HTTPHEADER, $headers);
		curl_setopt($handle, CURLOPT_SSL_VERIFYPEER, false);
		curl_setopt($handle, CURLOPT_SSL_VERIFYHOST, false);
		curl_setopt($handle, CURLOPT_POST, true);
		curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);
		curl_setopt($handle, CURLOPT_POSTFIELDS, $data);
		$response=curl_exec($handle);
		$code=curl_getinfo($handle, CURLINFO_HTTP_CODE);
		return ["code"=>$code,"response"=>$response];
	}

	public static function getData($url,$headers) {
		$handle=curl_init();
		curl_setopt($handle, CURLOPT_URL, $url);
		curl_setopt($handle, CURLOPT_HTTPHEADER, $headers);
		curl_setopt($handle, CURLOPT_SSL_VERIFYPEER, false);
		curl_setopt($handle, CURLOPT_SSL_VERIFYHOST, false);
		curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);
		$response=curl_exec($handle);
		$code=curl_getinfo($handle, CURLINFO_HTTP_CODE);
		return json_decode($response,true);
	}
}
$stat = yandex::getStat();

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

Использование интерфейса, в данном случае. позволяет нам писать только реализацию работы файловой системы, а бизнес-логика, работающая с файловой системой никак не меняется, она знает, что в любом случае файловая система реализует интерфейс FileSystemInterface и может без опаски использовать методы этого интерфейса.

Таблицы принято называть в единственном числе. Например, если там хранятся товары, то будет называться товар (product). Обычно пользуются переводчиком, ибо за "tovary" или "dvizhenie" просто хочется убить проектировщика.
Со связанными таблицами поступают просто: ссылки на них указывают в стиле имя_таблицы_id, например user_id.

Например, есть небольшой блог, у которого будут авторы и теги.

post
- id
- title
- content
- author_id

author
- id
- name

tag
- id
- name

post_to_tag
- post_id
- tag_id

Вот хороший ответ и еще статья.

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

Например, для RSS-читалки вроде https://feedly.com/ CMS использовать нет никакого смысла.