Crash

Ок, представим что вы настроили подобный механизм (хотя очевидно что это сделано не просто так), и теперь у вас есть предположим пользователи с номерами 10 и 11. У каждого из них есть некоторые данные, которые привязаны к этому пользователю по id. Теперь мы удаляем пользователя под номером 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

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

Что ж - тогда нужно столкнуться. Мидл отличается от Джуна не некими "мистическими знаниями", а опытом решения не стандартных задач.

Что касается используемых фреймворков вами - чем раньше перейдете на Symfony - тем быстрее вырастите. Безусловно, для своих задач yii - не плох, но это средне-маленькие проектики, для больших - это скорее плохой выбор, чем хороший (экспоненциальное разрастание моделей в случае больших команд - это убийственная практика). Kohana на пару с CodeIgniter - вообще учат тому, как писать не стоит((

Собственно чего я набросил на kohana?
1. Фреймворк не должен меняться, и не должен быть "в перемешку" с вашим кодом. Слишком велик соблазн что-то поменять во фреймворке. Как следствие - обновление части кода с фреймворком усложнится.
2. Явная инициализация всех подсистем проекта при загрузке. Зачем? Велика вероятность, что вообще все что там на каждый запрос не нужно.
3. Больше автолоада богу автолоада. Есть принятые стандарты PSR-0 и PSR-4, используйте их. Поймете зачем нужны неймспейсы. А кукули типа My_Very_Perfect_Controller - это практика 2000-х.
4.

<?php defined('SYSPATH') or die('No direct access allowed.');

Эта защита имеет смысл только в случае, если ваш код в публичном доступе, чего вообще-то быть не должно. По хорошему в публичном каталоге должен быть только один исполняемый php файл index.php
5. Статика - это путь к бесконтрольной связности проекта. Код с ее использованием тяжело поддается тестированию и изменению.
6. ActiveRecord для больших проектов - это самоубийственная практика, увы. Передавая модель куда-то вы передаете не только данные, но и подключение к БД. Как следствие код, который со всей силы не должен иметь возможность делать запросы к БД - может это делать и будет.

Почитайте на досуге Попросили проверить код, на что смотреть нужно?

Самое сложное во фрилансе, не языки и технологии.

• Умение продавать себя в толпе конкурентов. Это самое сложное. Есть много высококлассных специалистов, сидящих на среднем окладе. Они тупо не могут себя продать даже в другую компанию, а не редко и боятся менять привычное место.
  
• Умение грамотно составить или согласовать ТЗ. Так что бы проблема заказчика решалась в оговоренные сроки и бюджет. А не перерастала в вечнострой с кучей доделок и переделок с базовым бюджетом. Когда обе стороны уже ненавидят друг друга. Ибо работая в офисе разработчиком, всё это ведут менеджеры и тим лиды, а вам спускают конкретные задачи. Вам же придётся научиться понимать, что хочет клиент, не разбирающийся в программировании, говоря то или это. Научиться понимать и предлагать те решения, которые будут ему актуальны с учётом технологий и отказывать в том, что сделать не реально. Находить компромиссы, но опять же, объясняя почему так или иначе.
  

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

А технологии, языки. Это уже второстепенно. Главное развиваться. Ибо в попсовом PHP можно делать большие проекты и быть специалистом с большой стоимостью часа или на редком python/java сидеть и быдлокодить мелочь за копейки. Главное не метаться, а развиваться и расти, беря более сложные и более длинные проекты. И брать их не с "поддержкой", а с возможностью постоянного развития. Задачи "в стол", не интересны. А вот задачи на перспективу, на развитие. Это уже интересно. Ибо "в стол" это как правило теория(придумали, сделали, забыли). А развивающиеся, это практика на реальных условиях, когда в процессе приходится много менять (менять бизнес модель, менять архитектуру из-за возросших нагрузок, менять технологии).

Эх, дружище. Я бы не стал писать ещё один ответ, семнадцатый по счёту, если бы ты своей историей не напомнил меня самого 10 лет назад.

Ты упёрся в то, что называется "потолок". Это такое состояние, при котором нельзя улучшить существенно доход, просто делая больше, чем ты делал до этого.

Я объясню.
Когда человек молодой, у него мало опыта, но много энергии и он хватается за всё подряд и преуспевает именно за счёт своей энергии. В это время его главная задача - набраться опыта.
По мере взросления у человека уменьшается энергия и увеличивается опыт. И вот, в один прекрасный день, его преимуществом становится не умение делать то, что ему скажут, а опыт, благодаря которому он сам может говорить людям - как правильно. Проще говоря, тебе не будут платить за то, что ты делаешь то, что скажут. И, поскольку твоя энергия теперь ниже, тебе будут платить даже меньше, чем некоторым малолеткам.

Тебе теперь должны платить за опыт. А это значит, что ты должен вырасти из программиста в архитектора. Из подчинённого в руководителя.
Я знаю, как всё твоё нутро сейчас этому сопротивляется.
Но такова жизнь. Я вижу, что ты хочешь больше, и это хороший знак.
И тебе придётся меняться. Других вариантов нет.

Так что же делать конкретно?
Вот несколько вариантов.
1. Если ты уже работаешь где-то, поговори с руководителем. Возможно, ты знаешь, как можно улучшить тот продукт, над которым ты работаешь. Предложи ему дать тебе несколько джуниоров, которым ты мог бы давать задачи, чтобы под твоим руководством продукт стал намного круче.
2. Если ты не работаешь или планируешь ливнуть с работы, присмотрись к фрилансу. Но не рассматривай фриланс в РФ. Это грустно. Подтяни базовый инглиш и пробуй брать небольшие заказы на апворке или фриланс.ком. твои 50 тыр - это всего 800 долларов. За неделю вполне можно заработать. Не сразу, конечно.
3. Подумай, как свои знания ты можешь упаковать в законченный продукт. Не смотри как что продаётся. Поверь, даже очень простая мелкая утилитка или плагин очень скоро даст тебе плоды и ты поймёшь, что бесцельно тратил время, сидя в офисе, отдавая 90% ценности своему начальнику.

Это регулярное выражение: ^(.+)\.(\d+)\.(css|js)$

^ — начало строки
( ) — то, что внутри скобок, отдельно попадёт в переменные $1, $2, .. $N
. — любой символ
+ — определяет количество предшесвтующего ему: «1 или несколько»
.+ — один или несколько любых символов
\. — буквально точка обыкновенная, point vulgaris, без спец. значения
\d — цифра. \d+ одна или несколько цифр
(css|js) – или "css" или "js"
$ — конец строки

Таким образом эта регулярка совпадёт, скажем, со строкой
/css/main.min.682375227.css и заменит её строкой без числа:
/css/main.min.css

Наверное, так борются с кэшированием в браузере. В HTML можно писать с любым числом, и браузер подумает, что это что-то новое. А сервер всегда отдаст один и тот же main.min.css, какой там у него есть.

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

(new class {
    public function log($msg)
    {
        echo $msg;
    }
})->log("hello");

в основном так и есть.
бизнесу насрать на наши модели и архитектуру, ему надо деньги делать и ещё вчера.

если вылизывать архитектуру со старта - никогда не взлетишь. а когда и если взлетишь, поляна будет уже засеяна другими, которые срать–плевали на красоту кода.

это итеративный процесс: сначала столбим делянку как-нибудь (MVP), затем так и живём или приводим её в порядок.

Вообще не валидируем DTO. Он нужен только для перекидывания данных из одного слоя в другой. Что с этими данными будет на той стороне уже не касается того кто его создавал: на этапе создания dto уже поздно думать что где-то данные не того допуска, так как мы их либо из базы достали или сервиса или просто сгенерировали на лету. Принимающая сторона, если нужно, может провалидировать значения перед использованием и если что-то окажется за пределами допустимых значений как-то обработать данный кейс.

В данном контексте можно вспомнить про команды и запросы для CQRS. Мы их создаем через сериализатор: на вход подается массив данных для заполнения полей в создаваемой команде/запросе и класс команды/запроса в котором через аннотации указаны параметры валидации.

Многие хейтят Php, что он медленный, старый, много утечек памяти, нет нормальной асинхронности

Та те хейтеры - студенто-школьники, которые один раз хелоуворлд написали прям в одном файле на 2м курсе не дойдя даже до ООП.

Конечно учи, если тянет в бэкенд веба, хороший язык для старта. Проектов хороших и новых куча, денег куча, работы куча(в том числе удалённой!), решений куча. Язык быстрый, любые задачи решает, асинхронность прикручивается, всё что душе угодно. Реально очень востребованный язык, никуда он не умирает и вакансий меньше не становится.
То есть это не тот язык, где страшно за будущее пока учишь его. С PHP ты всегда найдёшь первую работу. Личное имхо - только в CMS не лезь, иди по пути фреймворков, ООП, паттернов, SOLID, хорошего бэкенда в общем. Удачи!

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

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

Еще можно устроить небольшое соревнование с самим собой: с помощью какого-нибудь Resharper или CodeRush найти в проекте самый говнистый класс по какому-либо критерию (например, самый длинный), выразив его сложность в виде какой-то конкретной величины = количества строк в данном случае. И постараться во что бы то ни стало уменьшить эту цифру. Забыть о всяких хотелках юзеров, а временно сконцентрироваться только на уменьшении строк, неважно каким способом (ну лучше конечно - выносом частей в другие классы).
Мотивировать будет реально измеряемое уменьшение длины класса, когда было 1200 строк, а стало 400.
Есть и другие параметры качества кода...