Pull to refresh
1
0
Вадим @mrAvenger

Java/Php programmer

Send message

Большая часть алгоритмов уже так или иначе реализована из коробки в яве, вам просто нужно понимать как они работают, в этом плане си будет неплох, а студенты не будут пытаться скопипастить собственные реализации алгоритмов в своих проектах, используя вместо них встроенные. И не будет вопросов типа, есть же функция x которую я могу использовать, зачем мне писать свою функцию y в 20 строк кода

Пример, так себе, это можно сделать и в вашем случае, и никто не говорил что так делается в моем случае, вы все равно не сможете сделать бизнес логику на 100% прозрачной, а время на это потратите неимоверное.
В одном из проектов, у нас куда больше 200 таблиц, более того, он работает с 7 разными базами данных и имеются связи как меж. таблицами одной базы так и меж таблицами разных баз данных. Тем не менее, у меня нет сложных запросов, а приложение работает быстро. Так же оно работает с разнообразными хранилищами типа s3, ftp, sftp и яндекс.диска. Так же есть очереди задач, Task Scheduling, прикручный elasticsearch, websocket сервер для real-time взаимодействий(на node.js общается с сайтом через бродкасты). Интеграциями с разными рекламными API для сборов статистики и управления рекламой, дашборд с аналитической информацией и многое другое, кол-во контроллеров не считал.

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

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

Есть такие.

Да, например в сущности новость, перед сохранением генерируется slug если название было изменено.

ЗЫ: На самом деле, вы можете написать хоть 10 слоев абстракций для общение с фреймворком, вы можете сказать что это дает вам неимоверный профит и возможность в любой момент сменить фреймворк, но вам все равно придется менять часть кода. Я же использую другой подход, мой код интегрируется с фреймворком, у меня нет никаких слоев меж ним и бизнес логикой, это безусловно имеет один минус — обновления проходят не так гладко, как в вашем случае, хотя, у вас проблем возникнут тоже. В моем случае используются практически все возможности фреймворка, когда мне их не хватает, что то даже модифицируется, в этом кстати Laravel преуспел как никто другой, а вы пытаеться от них отказаться в силу того, что в дальнейшем можете сменить фреймворк на другой.

Мне довелось поработать к на стартапах, так и в ентерпрайзе, на стартапе ваш способ так себе, потому что требует некотрых временных затрат на архитектуру, а в ентерпрайзе вам врятли кто то позволит через 4 года успешной работы на фреймворке Х перейти на фреймворк Y без крайне везких причин.

1. Как правило, достаточно сервиса, на самом деле любой лишний слой, добавляет сложность, а управление сложностью, очень важно для большого проекта.
2. При чем тут разница меж ними? Вы используете Laravel? Пользуйтесь предложенным подходом, он работает. Не нужно к метле педали прикручивать.
3. Если вы стремитесь в одном проекте совместить все паттерны сразу, то я вас тоже, огорчу, это так не работает.

Суть моего сообщение в том, что, не стоит недооценивать технологии не попробовав ее сполна, а потом говорить что я использовал паттерн1, паттерн2 и паттерн3 как на всех своих старых проектах в новом проекте на Laravel и он мне не понравился :) Это называется: «в чужой монастырь со своим уставом»
Ну куда, зачем Laravel не для этого придумали. На самом деле, я сталкиваюсь с разработчиками (такие есть и в комментариях) которые я пару раз правил код в Laravel и он вообще имеет не правильную архитектуру и вообще давайте не юзать Eloqent, навернем три слоя абрстракции сверху и будем радоваться жизни.
На самом же деле для небольших проектов достаточно ничего не мудрить, а просто писать код как вам предложили (даже если вы супер мего крутой Senior Software Engineer) и побольшей части для сайта заказа пиццы никакие Сервисы даже не нужны.

Все эти современные стандарты и крутые абривиатуры, на самом деле всех бесит что Laravel ломает их, к примеру:
someControllerMethod(int $id) {
    $pizza = Pizza::findOrFail($id);
    return view('pizza.show', ['pizza' => $pizza])
}

Или, о боги, даже так:
someControllerMethod(Pizza $pizza) {
    return view('pizza.show', ['pizza' => $pizza])
}

И что же, он найдет пиццу, а если не найдет у юзера высвититься красивая 404 ошибка (из коробки, Карл, просто установил laravel написал 10 строк кода и оно работает!)

А нам предлагают, делать так:
class PizzaRepository {
// какие то 100 строк кода
}
class PizzaService {
// какие то 100 строк кода
}
someControllerMethod(PizzaService $pizzaService) {
    $pizza = $pizzaService->find($pizza);
    if (!$pizza) {
         throw new SomeHttpException('Pizza not found...');
    }
    
    return view('pizza.show', ['pizza' => $pizza])
}


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

У меня довольно много проектов на Laravel, есть и одиночные, есть и с небольшими командами 3-6 человек, и пока мы не сталкивались с тем что у нас что то пошло не туда, с самого начала пути (есть проекты долгожители, которые живут с 3 версии Laravel, сейчас он уже на версии 5.5) мы стараемся просто использовать ту парадигму которую предлагает Laravel.
И все это время читаю на разных форумах об архитектуре Laravel что Eloqent слабоват и не позваляет писать сложные запросы, красиво. На самом деле, решение простое, не писать сложные запросы, использовать простые связи, избегать вложенности и писать код с удовольствием. У вас много сложных запросов? Вы где то свернули не туда. Уже прошли те времена, когда считалось крутым одним запросом вытащить пол базы данных.
А как же Java + Spring?
Мне, вот, тоже аукнулось, ну что сказать, пошел на заочку… В основном это бюрократия, как правило чтобы куда то перебраться (туда где потеплее) нужен хотя-бы баколавр.

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

Практики наказаний 0, что бы быть отчисленным из ВУЗа, нужно так не хило постараться (из своего личного опыта, и из опыта знакомых ребят), более того так же дела обстоят и со школами, как и собственно с колледжами.

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

После общения с одним из профессоров ВУЗа, вылезает такая статистика что ребята, которые хотя-бы что то могу и знают (речь про IT) просто сваливают с 3 курса и идут работать (об этом ниже), ну оно и понятно, как сказано где то в комментах, остальная часть просто сидит и ждет чего то с неба.

Касательно работы же в IT, на данный момент довелось проводить собеседования в одной из московских компаний(несколько лет назад) и сейчас, в СПб:
Выходцы из вузов, обычно приходят с требованиями зарплаты, что позавидуешь, но в итоге оказывается что человек отсидел 5 курсов в модном вузе и вот, на деле ничего не стоит, а самое забавное что идти в джуны или стажоры ребята просто не хотят.

Незаконченное высшее / заочка / самоучки — подают куда большие надежды, готовы показать свои проекты (с самоучками веселее, находятся индивиды которые кидаю вызов, мол берите меня на самую низкую ставку и я вам докажу(такие редкость, но своего добиваются))

Притом «название» ВУЗа особой роли не играет, в СПб много легендарных выходцев из ИТМО, на деле точно такой же разброс есть те кто старается и есть те кто просто сидит. (у нас есть один забавный пример, человек учившийся на «преподавателя» в ИТМО сейчас работает успешно программистом)

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

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

Laravel поддерживает php7 и 5.6, все что ниже уже давно «протухло», не выпускаются даже фиксы по безопасности: http://php.net/supported-versions.php

Я думаю если на проект вброшено аж 5ppl команда, то она следит за безопасностью продукта и уже давно должна была напинать под зад сисадмину для перехода на новую версию.

Хотя это уже все придирки, да и в общем то… я сейчас на должности Java программиста, так что мне грех Php обсуждать :)
Переходил с 4.2 -> 5.0, с 5.0 -> 5.1, с 5.0 -> 5.2 в принципе если внимательно это делать, то даже на объемный проект уходит не так много времени.

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

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity