Очень краткий ответ - это не патч на имунную систему (и вообще не патч). Вакцина, как и почти всё, что как-либо попадет в ваш организм, нормально оным "переваривается" и приводит к нормальным для организма последствиям.
"Патчи" пытается ставить коронавирус (как и любой другой вирус).
Если вы не можете пару дней поработать почти без сна и сохранить при этом адекватность - это ваша проблема.
Я, пока был молодой, бывало, по нескольку дней в таком режиме работал. А однажды даже три недели так отпахал ("рабочий день" получался по 30-40 часов с редкими короткими перерывами на сон, потом домой отоспаться, и снова на работу). И таки успел в срок сдать внезапно свалившийся проект, и даже премию за то от руководства получил.
Как по мне, так важнее не спецификация языка (хотя плохо, если язык ограничивает разработчика), а сам подход.
Каждая парадигма наиболее хорошо описывает определённый круг задач. Например: ООП хорошо моделирует бизнес-домен Императивно хорошо описывать пошаговые алгоритмы Декларативно удобно описывать задачу Функционально - математику.
Использование неподходящей парадигмы приводит к сложности понимания и анализа, а также модификации при изменении исходных условий.
Наоборот, совмещение позволяет получить максимум выгоды от каждого подхода. Например, в одной из систем, которую я разрабатывал, декларативно описаны валидации, проверки прав, стандартные контроллеры (там контроллер часто содержал только одну строку кода, в которой указывался маппинг входящего запроса на бизнес-сущность, выполняемая операция и маппинг на то, что надо отдать в результате) и т.п. Императивно были описаны шаги бизнес-логики (например, создание заказа подразумевает около десятка шагов на верхнем уровне, а каждый шаг - ещё одна функция в императивном стиле). Функционально были написаны расчётные алгоритмы и валидаторы. И всё это удобно сочеталось с ООП-классами, которые всё это реализовывали.
Проблема с логикой и аргументацией прямо с самого начала. И камаз-ы и зил-ы бывают очень разные, так что водитель самосвала может легко освоить другую модель, а вот изучивший реакт в ангуляр так сходу не зайдёт.
Да, JS знать надо, о уровень требуемых знаний зависит от реальных задач. И если у меня сайт на ангуляре, я лучше в команду возьму того, кто знает ангуляр и ранее решал схожие задачи, чем того, кто будет рисовать собственный фреймворк.
А вот если мне потребуется что-то экзотическое на фронте - буду искать профильного спеца по JS, а с фреймворком как-нибудь разберёмся.
а где найти эти зоны самообслуживания и нужных специалистов? У меня в ближайшем Перекрёстке нет касс самообслуживания. И табличку с финальным кодом они куда-то задвинули..
персоналу тоже нужно время, чтобы привыкнуть к инновации
Вот только я, пользуясь экспресс-сканом, хочу упростить себе жизнь, а не усложнять. И пока я не уверен, что смогу спокойно выйти из магазина с оплаченными товарами - я вряд ли буду им пользоваться.
И это не считая таких проблем, как товары 18+, невозможность купить пакет для покупок и уж не помню, что там с покупкой неупакованной выпечки.
Т.е. приложение и вообще IT-часть в целом норм, но сервис для пользователя сложен и неочевиден.
Ещё 5 копеек про маржу… Все ведь понимают, что +100% от тысячи это меньше, чем +20% от миллиона?
Так что плач про низку маржу тут не к месту. Это норма, иметь низку маржу при очень высоких ценах.
Хуже другое — хорошо живущий бизнес с такими ценами позволяет задирать цены всей цепочке поставщиков, а реальное качество услуг зависит в большей степени от мастерства и желания мастера. Характерный пример — когда хороший врач поставил пломбу в дешёвой клинике и она продержалась 20 лет, а аналогичная пломба из дорогой клиники прожила чуть более 5.
Во-первых, это не научное исследование, цель другая.
Во-вторых, сам метод другой. Там длинный опросник/интервью, и повторение — это когда большая часть ответов начинают повторять ранее полученные. Грубо говоря, если все новые полученные анкеты на 75% и более повторяют уже имеющиеся, то, видимо новые крохи информации придётся слишком долго искать. Тут уж важнее корректно определить группу опрашиваемых.
Меня как-то остановил сотрудник гибдд сразу после пешеходного перехода и спросил, что это я не пропустил пешеходов, которые собирались переходить с противоположной стороны дороги… Я объяснил, конечно, что посмотрел на них, убедился, что они прямо сейчас не начинают переходить и вообще пропускаю меня, потому и проехал переход без остановки… Но знаете, если до вас вдруг докопаются по этому поводу, оных пешеходов в свидетели вряд ли удастся призвать, а потому лучше не рисковать.
В моём опыте — все варианты были хороши :)
Например, из недавнего: переписывал я ядро системы, которая была кривеньким монолитом, и где из любой щели лезли прямые запросы в базу. Получилось собрать вместе SOA + SOLID + AOP. На верхних слоях были только бизнес-сервисы, а на нижних в основном были именно Entity Services. И было это хорошо :)
В примере подразумевалось либо наличие сервиса-оркестратора (на беке), либо логика живет как отдельные сервисы.
Так в том то и дело, что примеры должны быть релевантны задаче.
Я, вот, не могу вспомнить ни одного магазина, где прямо с фронта идут запросы к Entity… Всё работает через бизнесовые сервисы.
Да уж, вспоминая про «две главные проблемы в России», понимаем, с дорогой тут ещё ничего так, а вот представитель второй проблемы со смартфоном в руках наглядно демонстрирует свои способности создавать проблемы.
И вообще по жизни, и на дороге все должны быть адекватны… А пока что, то по переходу стрёмно переходить, то перед переходом приходится во все стороны смотреть, даже если для пешеходов светофор красный, а у тебя зелёный.
Ну… Может иногда get и лишний, но ещё реже стоит следовать другим рекомендациям, а уж совсем не следует делать подмен вида fruitsCount -> fruits.
Во всех мне известных нотациях fruits — это коллекция/перечисление того или иного вида. И я совершенно точно хочу понять смысл функции по её названию, если это вообще возможно (бывают случаи, когда без документации никуда). Для примера, с fruits мне придётся как минимум посмотреть на возвращаемый тип, и это точно зря потратит моё время.
Примерно такая же ошибка в большинстве приведённых советов.
Отдельно про контекст и память. Тут аргументация вообще ясельная. Вот скажите, вы когда книги или статьи читаете, может уловить смысл фразы длиннее 7 слов? А смысле текста длиннее 7 фраз? Я думаю, что вы с этим справляетесь вполне успешно. Название переменной — это вообще всего лишь слово в тексте программы. Да, составное, да, возможно новое, что требует чуть больше внимания при прочтении, но сложность равно такая, как при чтении составных слов — главное чтобы структура слова была корректна, все корни известны и чтобы оно передавало правильный смысл.
Так что этой проблемы нет. А вот разгадывать, что именно значит то или иное название в той парадигме, которую вы предлагает, совсем не хочется.
Про Doctrine не знаю, у меня другой техстек. Но для того, чтобы ORM не грузила всё по отдельности был метод, указывающий ORM, какие ещё сущности объединить в один запрос, и в итоге получался запрос с пачкой join-ов. Если всё сделать аккуратно, то и запрос не слишком сложный, и работает быстро.
Что ж я делал не так, когда на БД с несколькими десятками таблиц, кучей связей разного типа и ORM получал 1-3 запросов к БД на один запрос к API? И да, со сложными фильтрами, сортировками и пагинацией. И на локальной машине один запрос к API тратил меньше секунды? Что же я забыл?...
А, вспомнил что-то... Ну там, типа, анализ сценариев использования, индексы разные под разные сценарии, view для наиболее сложных мест, аккуратное использование ORM, чтобы она осиливала всё, что нужно, уложить в один внятный запрос, от которого не бросает в дрожь, ну и всякое прочее по мелочи....
Нет, реально, что это за ORM, которая каждый раз в базу лезет как в лабиринт? 300 запросов, да ещё в структуре из 6 таблиц?? Я даже не могу представить, как это...
Очень краткий ответ - это не патч на имунную систему (и вообще не патч). Вакцина, как и почти всё, что как-либо попадет в ваш организм, нормально оным "переваривается" и приводит к нормальным для организма последствиям.
"Патчи" пытается ставить коронавирус (как и любой другой вирус).
Если вы не можете пару дней поработать почти без сна и сохранить при этом адекватность - это ваша проблема.
Я, пока был молодой, бывало, по нескольку дней в таком режиме работал. А однажды даже три недели так отпахал ("рабочий день" получался по 30-40 часов с редкими короткими перерывами на сон, потом домой отоспаться, и снова на работу). И таки успел в срок сдать внезапно свалившийся проект, и даже премию за то от руководства получил.
Сейчас хватает только на один хакатон :)
Не, не зайдёт. Более того, слишком часто готовые спецы по JS городят свой огород вместо использования фреймворка.
Доходит до смешного - спец по бэку порой лучше осваивает фреймворк, чем крутой js-ник.
Как по мне, так важнее не спецификация языка (хотя плохо, если язык ограничивает разработчика), а сам подход.
Каждая парадигма наиболее хорошо описывает определённый круг задач. Например:
ООП хорошо моделирует бизнес-домен
Императивно хорошо описывать пошаговые алгоритмы
Декларативно удобно описывать задачу
Функционально - математику.
Использование неподходящей парадигмы приводит к сложности понимания и анализа, а также модификации при изменении исходных условий.
Наоборот, совмещение позволяет получить максимум выгоды от каждого подхода.
Например, в одной из систем, которую я разрабатывал, декларативно описаны валидации, проверки прав, стандартные контроллеры (там контроллер часто содержал только одну строку кода, в которой указывался маппинг входящего запроса на бизнес-сущность, выполняемая операция и маппинг на то, что надо отдать в результате) и т.п.
Императивно были описаны шаги бизнес-логики (например, создание заказа подразумевает около десятка шагов на верхнем уровне, а каждый шаг - ещё одна функция в императивном стиле).
Функционально были написаны расчётные алгоритмы и валидаторы.
И всё это удобно сочеталось с ООП-классами, которые всё это реализовывали.
Незачётный PR...
Проблема с логикой и аргументацией прямо с самого начала. И камаз-ы и зил-ы бывают очень разные, так что водитель самосвала может легко освоить другую модель, а вот изучивший реакт в ангуляр так сходу не зайдёт.
Да, JS знать надо, о уровень требуемых знаний зависит от реальных задач. И если у меня сайт на ангуляре, я лучше в команду возьму того, кто знает ангуляр и ранее решал схожие задачи, чем того, кто будет рисовать собственный фреймворк.
А вот если мне потребуется что-то экзотическое на фронте - буду искать профильного спеца по JS, а с фреймворком как-нибудь разберёмся.
а где найти эти зоны самообслуживания и нужных специалистов? У меня в ближайшем Перекрёстке нет касс самообслуживания. И табличку с финальным кодом они куда-то задвинули..
Вот только я, пользуясь экспресс-сканом, хочу упростить себе жизнь, а не усложнять. И пока я не уверен, что смогу спокойно выйти из магазина с оплаченными товарами - я вряд ли буду им пользоваться.
И это не считая таких проблем, как товары 18+, невозможность купить пакет для покупок и уж не помню, что там с покупкой неупакованной выпечки.
Т.е. приложение и вообще IT-часть в целом норм, но сервис для пользователя сложен и неочевиден.
Так что плач про низку маржу тут не к месту. Это норма, иметь низку маржу при очень высоких ценах.
Хуже другое — хорошо живущий бизнес с такими ценами позволяет задирать цены всей цепочке поставщиков, а реальное качество услуг зависит в большей степени от мастерства и желания мастера. Характерный пример — когда хороший врач поставил пломбу в дешёвой клинике и она продержалась 20 лет, а аналогичная пломба из дорогой клиники прожила чуть более 5.
Во-вторых, сам метод другой. Там длинный опросник/интервью, и повторение — это когда большая часть ответов начинают повторять ранее полученные. Грубо говоря, если все новые полученные анкеты на 75% и более повторяют уже имеющиеся, то, видимо новые крохи информации придётся слишком долго искать. Тут уж важнее корректно определить группу опрашиваемых.
В моём опыте — все варианты были хороши :)
Например, из недавнего: переписывал я ядро системы, которая была кривеньким монолитом, и где из любой щели лезли прямые запросы в базу. Получилось собрать вместе SOA + SOLID + AOP. На верхних слоях были только бизнес-сервисы, а на нижних в основном были именно Entity Services. И было это хорошо :)
Так в том то и дело, что примеры должны быть релевантны задаче.
Я, вот, не могу вспомнить ни одного магазина, где прямо с фронта идут запросы к Entity… Всё работает через бизнесовые сервисы.
Проблема не паттерне, а в его неуместном употреблении.
И вообще по жизни, и на дороге все должны быть адекватны… А пока что, то по переходу стрёмно переходить, то перед переходом приходится во все стороны смотреть, даже если для пешеходов светофор красный, а у тебя зелёный.
Во всех мне известных нотациях fruits — это коллекция/перечисление того или иного вида. И я совершенно точно хочу понять смысл функции по её названию, если это вообще возможно (бывают случаи, когда без документации никуда). Для примера, с fruits мне придётся как минимум посмотреть на возвращаемый тип, и это точно зря потратит моё время.
Примерно такая же ошибка в большинстве приведённых советов.
Отдельно про контекст и память. Тут аргументация вообще ясельная. Вот скажите, вы когда книги или статьи читаете, может уловить смысл фразы длиннее 7 слов? А смысле текста длиннее 7 фраз? Я думаю, что вы с этим справляетесь вполне успешно. Название переменной — это вообще всего лишь слово в тексте программы. Да, составное, да, возможно новое, что требует чуть больше внимания при прочтении, но сложность равно такая, как при чтении составных слов — главное чтобы структура слова была корректна, все корни известны и чтобы оно передавало правильный смысл.
Так что этой проблемы нет. А вот разгадывать, что именно значит то или иное название в той парадигме, которую вы предлагает, совсем не хочется.
Что ж я делал не так, когда на БД с несколькими десятками таблиц, кучей связей разного типа и ORM получал 1-3 запросов к БД на один запрос к API? И да, со сложными фильтрами, сортировками и пагинацией. И на локальной машине один запрос к API тратил меньше секунды? Что же я забыл?...
А, вспомнил что-то... Ну там, типа, анализ сценариев использования, индексы разные под разные сценарии, view для наиболее сложных мест, аккуратное использование ORM, чтобы она осиливала всё, что нужно, уложить в один внятный запрос, от которого не бросает в дрожь, ну и всякое прочее по мелочи....
Нет, реально, что это за ORM, которая каждый раз в базу лезет как в лабиринт? 300 запросов, да ещё в структуре из 6 таблиц?? Я даже не могу представить, как это...
В ваших вариантах смысл иной получился.
Соглашусь, Желязны прекрасен, а пересказ ужасен.
Вся прелесть читать фантастику - саму понять мир, описанный автором.
У Желязны миры полные и глубокие. Есть целая "серия" миров с сильными отсылками к той или иной земной мифологии/религии.