Толстый Лорри, погугли все выпиливают галп в пользу npm скриптов. Он не решил проблем, а только создал новые. Вместо того, чтобы напрямую использовать какую-нибудь утилиту нужна обвязка для неё в виде плагина, который написан сторонними разработчиками и может быть в полурабочем или заброшенном состоянии. Выходит новая версия утилиты, но использовать не можешь потому что плагин не совместим. Сидишь ждешь пока починят, что может никогда не произойти и даже пулл риквест не примут. Вместо того, чтобы писать код и не думать обо всем этом разработчик борется с этими плагинами костылями.
Также если погуглить англоязычные ресурсы, то можно узнать, что уже несколько лет проекты собирают обычными npm скриптами, а не сборщиками. Разработчики наигрались в полурабочие/заброшенные плагины, когда инструмент для решения проблем сам превращается в проблему. Давно пора отказаться от лишней прослойки и не предлагать её к изучению.
Этот поисковик уйдет в историю как рамблер. Невозможно вечно использовать алгоритмы индексации 1999 года. У яндекса всё хорошо только с проталкиванием всяких яндекс браузеров через пиратский софт. С остальным не очень.
Алексей Майрин, причуды и странности есть в любом языке. Их сотни и тысячи. Их изучение это не программирование. Нормального работодателя интересуют навыки проектирования и с какими архитектурными решениями знаком человек. Если человек имеет такие знания, я его оторву с руками даже если он никогда не писал на нужном языке программирования вместо велосипедиста который сумел овладеть только синтаксисом языка. Первый с синтаксисом ознакомится за несколько дней и будет готов закрывать задачи. С ним можно разговаривать на одном языке об архитектуре проекта. Второй будет способен только производить не тестируемый спагетти-код и раздражать всю команду. Его знания причуд языка никак не помогут в борьбе с техническим долгом. Первый же поймает эти причуды в авто тестах или ему подскажут более опытные коллеги при код-ревью.
Если бы мне задали этот вопрос на собеседовании, я бы ушел. Логичнее было бы тогда сразу спросить, как работает event loop в javascript и этот вопрос отпал бы сам собой. Но держу пари интервьюер сам этого не знает, поэтому способен только излучать идиотские вопросы о которых случайно узнал на каком-нибудь хабре.
spaceatmoon, вы и с примером кода ничего толкового не посоветуете. Это будет локально. Вырвано. Не систематизировано. Бесполезно. Невозможно спроектировать систему не имея навыков проектирования. Сколько не анализируй код. Многие не понимают, где бизнес код, где инфраструктурный, как это делить и почему. Многие на PHP пишут интуитивно. Результатом такой деятельности является спагетти-код. В книге Implementing domain-driven design есть решение по проектированию от начала и до конечного результата.
Сергей Горностаев, если проект выстрелил выпиливать надо не орм, а обе эти базы в первую очередь. Они вообще не под веб создавались и использовались тут из-за отсутствия альтернатив.
Антон Спирин, так и не должны. Если посмотреть примеры реализации многоуровневой архитектуры, можно заметить, что приложение проектируется вообще без учета фреймворка. Фреймворк можно добавить в самом конце. Фреймворк превращается просто в способ заставить приложение работать по какому-либо протоколу.
Денис, ну какая-то методология все равно необходима. Есть альтернативы например SUIT она выросла из БЕМ. Посмотрите соглашение об именовании css стилей. Отлично сочетается с компонентами React, Angular, Vue. Используется в Twitter, BBC Three.
Даже разговаривать не будут. Какой кретин купит проект с нулевым оборотом от школьника со знаниями php и mysql. Который 100% нужно переписывать с тотального нуля. Чел уже нафантазировал себе распределенное приложение. С кучей данных. На не распределенной mysql. На кроне.
Сейчас, сейчас. Только денвер поставлю. И будем продавать.
DevMan, где в вопросе фигурирует "далекий от программирования"? Спрашивают про профессии где не нужно писать код. Тестировщик проверяет билды по чек-листам. Архитектор ПО это про принятие ключевых проектных решений и ни слова про написание кода. Если уж упорствовать, то не согласиться можно разве что по поводу dba, что ему иногда придется иметь дело с каким-нибудь SQL кодом. Всё же основная задача dba это администрирование, а не написание кода. Да и декларативный sql не стоит приравнивать к какой-нибудь императивной джаве. Странно, что вас смутил dba и тестировщик, а вот системный администратор нет. Последнему то например поболее кода придется писать, чем первым двум. Не все тестировщики пишут приемочные тесты. Лишь малая часть от общего количества. Да и те, что пишут тесты делают это опять же при помощи декларативного программирования.
Код собственно пишет программист и может быть девопс. Это очевидно. Остальные если и пишут что-то, то эпизодически.
Григорий Хримян, одноклассники изначально вроде на php написал один разработчик. Когда проект взлетел, они наняли опытную команду java разработчиков и переписали весь проект заново. Видимо это было дешевле, чем вкладываться в поддержку существовавшего кода. Можно примерно тем же путем идти. Сделать прототип. Потом если взлетит выбросить и сделать заново.
Всё это можно повесить на репозиторий, чтобы код не мержился если его цикломатическая сложность превышает 10 или до тех пор пока ругается статический анализатор кода. Это конечно не гарантирует, что программист будет писать понятный для других код. Но хотя бы запретит ему городить кучу вложенных условных конструкций или какой-нибудь подобной лапши. Можно добавить метрики на количество строк кода, чтобы не получались вот такого уродства в 4,7 тысяч строк кода.
Это немного поубавит пыл особо ярых индусов, которые привыкли писать на php как на ассемблере. Еще бы неплохо затребовать метрику покрытия кода тестами не меньше 70%. Но чем больше требований, тем выше шанс что быдлокодер сольется, а хорошему программисту и платить нужно хорошо. Еще и найти его не простая задача. Особенно среди php разработчиков.
Можно никакие метрики не вести и нанять самого дешевого быдлокодера за 20-30k. Но когда он уйдет, придется искать разработчика на поддержку его спагетти за 200k. Цифры образные. Суть в том, что затраты будут расти экспоненциально.
Григорий Хримян, проблема с одним разработчиком в том, что если он пишет спагетти-код, то только он в нем и может разобраться. Когда он уходит оказывается, что довольно трудно найти ему замену на дальнейшую поддержку этого спагетти-кода. Тем более за те же деньги, которые платили предыдущему, т.к. порог сложности для нового разработчика многократно возрастает. Начинается текучка с регулярностью в один два месяца. В итоге проект практически останавливается в развитии. Поэтому и желательно внедрять код-ревью. Но имея одного разработчика так увы не получится.