Что не так в коде (можете сделать краткое код ревью)?
Прохожу собеседования в различных IT компаниях на джуна.
Вот код проекта, который я отправил в качестве примера своего кода. Его забраковали ревьюверы компании.
Скажу прямо - в вакансии был не сильно заинтересован, поэтому отправил "что было".
Код писал быстро, для рабочих задач. Никакой фильтрации данных, подготовленных запросов, композера, фреймворков, шаблонов ООП, стандартов PSR, форматировании кода и т.д.
.
Если фильтрацию данных и подготовленные запросы ещё можно назвать существенной проблемой, то в остальном каких то проблем, на уровне кода джуна не вижу. Всё работает, все просто, что ещё от джуна надо?
Можете сделать краткое код ревью и сказать, что в этом коде совсем плохо?
ну хотя бы автоформатирование применить в IDE можно было?
Можно. Работал и в шторме и в саблайме и в вс коде.
Скажу прямо - мне стандартное форматирование режет глаз.
Я не понимаю зачем нужны пробелы. Я вижу их как лишнее.
В позиционирование скобок/кода относительно вложенности я не вижу особого смысла т.к. редактор и так подсвечивает парные скобки.
А если большая вложенность (там где форматирование должно помочь), то скорее всего код некорректен, не продуман, слишком запутан.
Я понимаю, что скорее всего без форматирования мой код забракуют, потому что так положено.
То написал как есть.
Недавно смотрел выступление лидов про код стайл. В некоторых компаниях нет единого стандарта и каждый программист (в плане форматирования) пишет код по своему. В результате возникали холивары - чей кодстай лучше.
А потом они внедрили какую то софтину и теперь их код форматируется автоматически при пуше в гит.
Евгений Иванов, такое мировоззрение нужно менять. Если, конечно, хотите стать программистом и устроится в нормальную контору.
Вы отрицаете устоявшиеся стандарты. Это бессмысленно, потому что в итоге вы их примете.
Вы не понимаете, а может и не знаете новых возможностей языка. Но почему-то уверены, что они – лишь признак "современности" кода O_o
Вы не понимаете преимуществ строгой типизации. Более того, вы скорее всего даже не задумывались почему ее стали внедрять в язык. Но при этом уверены, что типизация не нужна.
Ну и напоследок, сами ответьте на вопрос: при прочих равных, какое из двух тестовых будет для ревьюера привлекательнее – ваше без форматирования, или Петино, но с адекватным форматированием?
Такие стандарты, скорее всего, не приму (после C# точно нет).
Но писать по "стандартам" придется лишь потому, что так принято - в этом смысле вы правы.
Традиционное или пиши как большинство или не работай с большинством.
2)
Вы не понимаете, а может и не знаете новых возможностей языка.
Про новые возможности php 8 читал здесь
многие нововведения напоминают синтаксический сахар. Что то сильно нового, сильно нужного и обязательного, особенно для уровня джуна, не увидел. Может не туда смотрел.
3)
Вы не понимаете преимуществ строгой типизации.
Я работал c C# и Delphi. И я действительно не понимаю, зачем в PHP ввели строгую типизацию, не убрав не строгую. Обычно языки подразделяются на языки со строгой типизацией и не строгой.
По моему мнению, строгая типизация дает лучший контроль над типами значений (например, аргументы метода), улучшает производительность за счет выделения памяти под конкретный тип данных, уменьшает количество неявных преобразований - что снижает ошибки программиста и возможную потерю точности.
Как и писал выше - если рынок/заказчик хочет писать так (со строгой типизацией) и он платит, буду писать так.
Любой каприз за их деньги. И в данном случае я только за такую типизацию.
Но я пока не, что в крупных проектах так пишут. В видеороликах, мануалах от мидлов и лидов я ещё ни разу не видел использование строгой типизации.
Ну и напоследок, сами ответьте на вопрос: при прочих равных, какое из двух тестовых будет для ревьюера привлекательнее
Ошибку понял - большинство требует, надо писать как требует.
Вы сами и ответили почему заброкали, но ещё добавлю, что ваш код написан с натяжкой на php 7.0
Серьёзно? Уже этого достаточно.
Ну и вообще написан ваш код в стиле 2010 годов, и вообще ни какого форматирования. Вы прямо кричите этим кодом, что вам похер на ревьювера и его глаза, ну вот ревьювер сам вас и послал на 3 буквы.
Композер, PSR, и строгий стиль php (с типами данных) - это обязаловка. Никто больше не пишет новые проекты через ректальный язык программирование php5 (да и старые тоже).
Спасибо за ответ.
1) Про php 7.0 что вы имели ввиду? Новые версии регулярно выходят и использовать их фишки только ради современности...
2) "строгий стиль php (с типами данных) - это обязаловка" - я пока нигде такого не видел. Сейчас открыл YII2 - нет строгой типизации данных. Да и зачем в PHP это?
Евгений Иванов,
Новые фишки php - это давно стандарт всех языков. Поэтому их нельзя называть "фишками". За исключением конечно сахара.
Yii2 это устаревший фреймворк которые 4 год не может родить новую версию. Практически уже никто не делает новые проекты на Yii2. Вместо yii2 берут ларку сейчас.
А вот все современные фреймворки используют типизацию, да не везде у них указана в файлах строгая - т.к поддерживают обратную совместимость, но сам тип данных уже возвращают и указывают все. Можете сами убедится откройте Symfony. А так как на компонентах Symfony построены все фреймворки, то можно сказать что все современные фреймворки используют по крайне мере тип данных. И даже Yii3 будет это делать.
1) PSR. Названия функций - это одно из первых что увидит тот кто будет проверять. Они как минимум должны быть с маленькой буквы.
2) Отступы, а точнее их отсутствие. Самому то глаз не режет это? Я бы тоже не стал смотреть.
3) Мешанина из кода. Всех интересует знаешь и понимаешь ли ты что такое патерны и mvc а тут им и не пахнет даже.
Никакой фильтрации данных, подготовленных запросов, композера, фреймворков, шаблонов ООП, стандартов PSR, форматировании кода и т.д.
Мне не понять зачем это написано. Основные стандарты PSR соблюдаются в голове без какой либо постподготовки. Человек с опытом так просто не напишет.
Спасибо за ответ.
1) PSR. Названия функций. - да это так, не соответствует стандарту.
Но от стандарта PSR отошли многие крупные компании. В каждой фирме свой стандарт оформления кода.
Имена методов я написал в CamelCase C# стиле, что иногда делают многие разработчики.
Неужели это так важно для ревьювера - только PSR и всё?
2)
Отступы, а точнее их отсутствие. Самому то глаз не режет это?
Если честно - нет.
Я знаю, что стандарт PSR предполагает 4 отступа, перенос скобки и т.д.
Но мне режут глаз отступы т.к. приходится обращать на них внимание, что отвлекает от кода.
Обычно много отступов при большой вложенности. Отступами выделяют открывающую и закрывающую скобку цикла, метода, класса - размещают их на одном уровне.
Но современные редакторы и так подсвечивают парные скобки.
Если в коде большая вложенность - это скорее всего плохой, запутанный код.
3)
Мешанина из кода. Всех интересует знаешь и понимаешь ли ты что такое патерны и mvc а тут им и не пахнет даже.
Почему? Шаблоны есть. Модель в виде БД есть. Контроллеры для работы с БД и вывода в шаблон есть.
Всё есть.
1. код выше www рут
2. Ctrl+Shift+L и убрать все красное / в идеале и желтое
ПхпШтор рулит
3. все же Composer & PSR
но главное https://phptherightway.com/
прочитать/осознать
Про форматирование, конечно, верно пишут, но если про него забыть (очень оно не стандартное, но я бы не сказал, что прям какое-то нечитабельное), то просто беглым взглядом:
1) Нет ООП (а это сейчас обязательный стандарт), попытка выдать за ООП набор статических классов делает только хуже, пишите уж лучше честно процедурно.
2) SQL-инъекции! Да и весь блок работы с СУБД чтото ужасное. Куча бесполезного, реконнекты при каждом запросе...
3) ТТУК, если конечно вообще подразумевался mvc, и контроллер это index.php.
4) Вместо автолоадера просто подключение всего и вся. Хотя по факту в php сейчас стандарт - composer.
В общем и целом я разбираюсь в ООП, изучал ООП по С# и понимаю вашу претензию. Обычно её формируют как - "программист использует ООП, но пишет в процедурном стиле".
Но ООП в скриптовых языках, как я понимаю, и есть использование статики. Во всех фреймворках очень много обращений к статическим методам. Да, иногда создают экземпляр класса.
Мне сложно создавать объекты в языке, где срок жизни скрипта ограничен.
реконнекты при каждом запросе
Я не могу создать подключение к бд 1 раз и хранить ссылку на него. Скрипт завершился - память отчищена. Это не десктопное ПО, где программа работает, пока её не закрыл пользователь.
2)
SQL-инъекции!
Знаю. Так и написал TODO фильтрация данных. Ну и нужны подготавливаемые запросы.
3)
ТТУК, если конечно вообще подразумевался mvc
Я прочитал несколько статей по MVC и посмотрел много видео. И так до конца и не понял, что есть MVC.
У каждого MVC - свое. У каждого модель и контроллер что то свое.
У одних больше логики в модели, у других в контроллере. Одни не любят толстые контроллеры, другие наоборот. Реализация данного паттерна мне не до конца понятна.
Я считаю, что Модель - это БД, вид - это шаблон, контроллер - это файл/группа файлов которые отображают данные из модели в шаблоне и изменяют состояние переданное из шаблона (пользователь кликнул по кнопке) в модели (БД).
4) Исправил, но возник новый вопрос, который чуть позже напишу.
Но ООП в скриптовых языках, как я понимаю, и есть использование статики. Во всех фреймворках очень много обращений к статическим методам. Да, иногда создают экземпляр класса.
Мне сложно создавать объекты в языке, где срок жизни скрипта ограничен.
Нет, ООП - это оперирование объектами, статика - это не объекты. Без разницы скриптовой язык или нет. Без разницы какой срок жизни скрипта. Что значит "сложно писать"?
Я не могу создать подключение к бд 1 раз и хранить ссылку на него. Скрипт завершился - память отчищена. Это не десктопное ПО, где программа работает, пока её не закрыл пользователь.
Да, но не для каждого же запроса создавать новый коннект.
Знаю. Так и написал TODO фильтрация данных. Ну и нужны подготавливаемые запросы.
Видел, но для борьбы с SQL-инъекциями надо использовать подготовленные выражения. А фильтрация SQL с подставленными данными бесполезна.
Я прочитал несколько статей по MVC и посмотрел много видео. И так до конца и не понял, что есть MVC.
У каждого MVC - свое. У каждого модель и контроллер что то свое.
У одних больше логики в модели, у других в контроллере. Одни не любят толстые контроллеры, другие наоборот. Реализация данного паттерна мне не до конца понятна.
Я считаю, что Модель - это БД, вид - это шаблон, контроллер - это файл/группа файлов которые отображают данные из модели в шаблоне и изменяют состояние переданное из шаблона (пользователь кликнул по кнопке) в модели (БД).
Есть различные модификации, конечно. Но, модель - это не БД, это вообще вся логика приложения. Толстые контроллеры, сами по себе это не плохо и не хорошо, это показатель того, что скорее всего есть ошибка. Толстые контроллеры появляются чаще всего там, где в них запихнули логику, а это чревато проблемами, поэтому они еще и "уродливые". Когда будете писать разное взаимодействие с пользователями, например добавите еще и API, сразу будет понятно почему не нужно в контроллерах держать логику.
Средний
