Comments 733
Можно писать исключительно на typescript и быть fullstack
- Сложно найти технологию, которая везде считается приемлемой.
- Я писал про фуллстек, а вы мне про сеньор бекенд. Ок.
2. В статье же об этом речь. И, пожалуй, требование знать sql ко всем бэкендщикам относится.
- Python, Go, Java отличные технологии, но тоже не всея руси.
- Я не спорю, что чем больше технологий знаешь, тем лучше. Но использование SQL тоже не обязательно. Есть ORM, есть NoSQL базы данных.
Мой первый комментарий не ставит под вопрос другие технологии, но NodeJS + TypeScript (JavaScript) впервые дали возможность быть FullStack и писать только на одном ЯП. Тем самым упрощая процесс профессионального роста.
Поправьте меня если я неправ, но Razor — это по сути шаблонизатор. На нем клиентскую логику вы не напишете.
Чего только в наше время не выдумают: Blazor — Full-stack web development with C# and WebAssembly
сеньором во фронте не станешь
А каким критериям должен удовлетворять уровень человека что бы можно было именовать его сеньором?
Наверно, надо уметь писать асемблерные вставки :)
Обычно сеньор отличается от мидла лучшей проработанностью решения (на тестировании всплывают только миноры) и понятностью мышления (поскольку человек знает предметную область он использует наиболее простые и логичные методы решения, следовательно код легко понять в целом, а часто и в нюансах).
Мидл же может наворотить пачку костылей. Просто потому, что хуже знает систему и предметку, плюс часто хочет показать что «я вот так умею».
Ну и сеньор менее заметен в офисе, но более заметен в баг-трекере)
Хотя фулстеком того кто пользуется только ими назвать сложно.
Во-2, сеньор бэкенд программист обязан знать как минимум sqlb ещё одну технологию, например, java или python.
Зачем сеньору-то знать другую технологию? Он же не джун.
Не все приложения требуют использования триггеров. Я и не писал, что typescript на все случаи жизни.
Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.
Так можно до бесконечности продолжать. Например у вас в проекте должен быть ИИ, а нейросеть вы строить не умеете. Вы уже не fullstack.
Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
При решении любой задачи можно использовать различные подходы. Можно использовать решение проверенное временем от профессионалов (например, реализация триггеров Oracle Database), а можно взять и реализовать их самостоятельно. Можно и Web-серверы и СУБД реализовывать самостоятельно.
Люблю, да. Особенно вижу категоричные суждения или оперирование общими оценочными категориями типа "грамотней" без указания критериев :)
Когда бизнес молодой и развивается, ему важно как можно быстрее и проще провалидировать жизнеспособность своей модели. В этих условиях, человек-оркестр, способный в одиночку запилить и бэк, и фронт, намного выгоднее двух крутых специализированных бэк/фронт разработчиков.
Другое дело — когда бизнес уже захватил основную часть аудитории, и начинается борьба за оптимизацию и увеличение конверсии. Тут нужен тюнинг перформанса и все остальное в таком духе, и нужны узкие спецы.
Проблема узких спецов на старте — часто они сходу начинают оптимизировать под будущий «хайлоад», когда вообще не факт что бизнес вообще взлетит.
Но всё решают зависимости. В триггере мы можем обработать данные из той же БД, довольно шустро и без особых рисков.
Но если, при изменении записи, нам надо взять данные не из DB, и как-то их по хитрому обработать… Тут возможно имеет смысл спроектировать слой над базой данных, а консистентность сохранить за счёт транзакционности и прямых рук. Это может оказаться, быстрее, надёжнее и даже проще реализовать.
Но, кмк, нам намекают, что то, что можно сделать в триггере, лучше сделать в триггере. Например записать лог изменения записи, или поддержать волшебным образом денормализацию «на лету». И плодить хитрое решение на технологии, которую лучше знаешь, а не на той, на которой от тебя ждут решение… По моему это подготовка будещего мазохизма, притом не своего, а того, кто будет поддерживать твою систему «если что».
Если от тебя ждут решения на конкретной технологии, то надо его как-то делать или сообщать, что не можешь. Но часто такие нюансы как реализация логирования остаются в лучшем случае на усмотрение команды, а и одного разработчика.
В триггере мы можем обработать данные из той же БД, довольно шустро и без особых рисков.
Проблема же в цене поддержки. Если бизнес-логика размазана по триггерам и хранимкам дб — это очень печально. Просто sql очень плохой язык с точки зрения промышленного программирования, вот и все.
Ну тут есть вариант: бизнес логика собрана в триггерах и хранимках. И на это может быть много причин. До сих пор.
Кроме того, на триггер можно возлагать стандартные процедуры. Я уже упоминал логгирование, также принудительная генерация ключей в оракле, что бы исключить косоруков вручную ставящих id. Вообще да, триггер место для выстрелов в ногу, и много чего можно выносить на уровень приложения или хранимок.Но это не значит, что от триггеров надо отказываться принципиально.
И опять же начало спора было о том, что для разных случаев разные инструменты. И знание вариантов инструментов нелишне.
PS. Sql в богатых расширениях(транзакт sql, pl/sql) это отличный язык для промышленного программирования. Просто нужно понимать какие, задачи решать на нём. Вы же не будете для построения статистики тащить 50 таблиц по миллиону записей на клиент) И пре и, пост обработку данных для некоторых операций проще делать хранимкой
Можно ведь и не в СУБД хранить, а в файлах и всю логику держать на клиенте (вообще всю базу сразу отправлять на клиента, включая данные всех пользователей, а уж клиент будет делать выборку). Вполне можно реализовать, но мало кто назовёт это правильным.
FullStack хорош для запуска первой версии продукта или для небольших фирм. Когда требуется не "грамотная реализация", а реализация в принципе. По мере роста проекта уже требуются более узкие специалисты.
А статья, если честно, ни о чем. Типа, если вы будете изучать технологии А, Б, В, то никогда не изучите технологию А также глубоко, как человек, который изучает только технологию А. Это очевидно.
Вот с этим абсолютно согласен. Уверен, что множество разработчиков в принципе никогда не станут Senior разработчиками даже если будут изучать хоть всю жизнь одну технологию.
Код проще тестировать и поддерживать. Да и случаи замены базы, хоть и довольно редки, но все-равно случаются.
pgxn.org/dist/plv8/doc/plv8.html
не совсем ts, но можно его при желании сбоку прикрутить :)
А можете привести пример триггера в какой-нибудь СУБД (SQL Server, MySQL, PosgreSQL, Oracle Database) на TypeScript?
Есть же достаточно распространенное мнение, что использование триггеров (и вообще дергание скл руками) — code smell. В такой парадигме неумение использовать тригеры — конкурентное преимущество.
Уметь в SQL проще и продуктивнее чем уметь в ORM, разве нет?
Зависит от ситуации.
SQL, конечно, хорош в плане перформанса, но:
- не всегда в принципе скорость запросов — бутылочное горлышко.
- код на SQL, мягко говоря, не слишком удобен в плане поддержки.
В общем, как и всегда — есть разные задачи, есть разные инструменты, а серебряной пули нет.
код на SQL, мягко говоря, не слишком удобен в плане поддержки.просто надо использовать нужные инструменты для его поддержки. Если использовать хранимки, то в коде не будет запросов, все запросы в хранимках на сервере, к примеру для mysql есть интсрумент как DbForge, который позволяет писать, отлаживать, сопровождать хранимки. делать рефакторинг, и много ещё чего.
не всегда в принципе скорость запросов — бутылочное горлышко.трудно не согласиться, но если есть возможность — надо ей пользоваться — к примеру поля даты можно уже в запросе привести у нужному виду, числа сформировать с нужными разделителями разрядов.
Если использовать хранимки...
Если она будет ровно одна, то, возможно, не стоит.
к примеру поля даты можно уже в запросе привести у нужному виду, числа сформировать с нужными разделителями разрядов.
… однако, если у вас уже есть подсистема, которая форматирует данные, в том числе полученные не из БД, то этого делать не нужно. Особенно если там все по-взрослому, с подтягиванием настроек пользователя, определением региона, учетом смещений часовых поясов и всего такого.
ИМХО, спор про то, на чем правильно делать то или это в абстрактном проекте — беспредметный.
- Как язык SQL плох, но без него никак. Он динамический, имеет громоздкий синтаксис и на 90% состоит из весьма нудного бойлерплейта. Читать — легче. Понимать — ещё легче.
- Переписывать всю БЛ на хранимки, как предлагают некоторые горячие головы, равносильно отстреливанию себе в упор всех конечностей.
- Хорошие ОРМ значительно удешевляют разработку. Но чтобы уметь ими пользоваться, нужно по мимо ОРМ знать SQL.
- Даже с самой хорошей ОРМ писать SQL всё равно придётся.
- Использовать nosql только потому, что лень учить SQL или разбираться с ОРМ — такая же дичь, как и писать всё на хранимках, чтобы не учить условную java. Нужно учить CAP теорему и разбираться, когда использовать nosql 1) допустимо 2) приемемо 3) оправдано. Вопросы не тривиальные практически всегда.
Я сам вообще стараюсь хранимки использовать по минимуму. Понятное дело, что иногда они дают важный буст производительности, особенно учитывая, что ORM не серебрянная пуля и часто генерят диковатые запросы. Спросил не с целью «о, если мне еще юнит-тестов там подвезут, все буду на скулях писать», а с вопросом в духе «а чо, в мире есть проекты, где хорошо уживаются CI/CD, TDD и хранимки?» Потому что у меня на проекте они уживаются, но с очевидностью первое берет верх.
просто надо использовать нужные инструменты для его поддержки. Если использовать хранимки, то в коде не будет запросов, все запросы в хранимках на сервере, к примеру для mysql есть интсрумент как DbForge, который позволяет писать, отлаживать, сопровождать хранимки. делать рефакторинг, и много ещё чего.
Я в эти сказки не верю после того, как столкнулся с развитием продукта построенного в основном на SQL. Боль заключается в том, что если на типичном бекендском языке можно разбить 2000 строк на 40 групп по 50 строк с дополнительным оверхедом в 200 строк, то на sql оверхед составляет ближе к 500-1000 строк. И это делает нецелесообразным попытки написать хороший код. Соблюдать DRY почти невозможно. Увы, SQL не имеет средств для нормального реюза кода. Т.е. развивать код на SQL можно только до определенных пределов.
В другой продукте использовались хранимки на SQL, но гораздо меньшие и более конкретные. И это было счастьем. За исключением того, что все хранимки стали выглядеть автоматизируемыми. Туда явно напрашивалась абстракция. Но существующие инструменты (ORM) слишком сильно были заточены под паттерн «хуяк-хуяк» и были малопроизводительными. Хранимки оказались наименьшим злом на тот момент.
SQL-скрипты не версионируются в Git?
и дамп и восстановление.
слияние — в ide -выбор в меню, выбор базы источника, выбор базы приёмника — сравнение — галочками отметить что слить — enter, итого секунд 30.
из практики — ни о каких сотнях в день речь не идёт…
дамп делается не всей базы а только выбранного -структуры, данных или отдельных выбранных элементов.
каждому разработчику лучше иметь свой экземпляр базы, (лучше на своей машине) со своим набором даннх(они могут быть элементарно перенесены как с базы продакшена, так и с любой базы разработчиков)
при слиянии отображается разница между базами-по каждому элементу как структуры так и данных.
отладка также происходит в ide, хранимки можно отлаживать по шагам (запрос в хранимке -это один шаг).
написали хранимку сохранили — выполнили — увидели результат. можно отдельно отлаживать запрос тогда и сохранять не надо просто написать — запустить — увидеть результат. и уже потом вставить в хранимку.
А сотня изменений в команде из десяти разработчиков за день создаётся легко.
— скорость разработки
— возможность параллельной (или псевдопараллельной) работы над десятками фич или над несколькими фичами, затрагивающими много одних и тех же таблиц
— автоматическое разворачивание и обновление локально и на удалённых серверах
Причём даже с только с таблицами возникают ситуации, когда приходится предупреждать всех разработчиков, что собираешься, например, переименовать поле.
Я не чураюсь хранимок или триггеров, но для переноса в них части логики мне нужны очень веские основания. Главное — неперенос сделает работу какой-то конкретной фичи неприемлемо медленной для пользователей или заказчика. Но перенос для меня всегда оптимизация, которая делает систему быстрее за счёт уменьшения скорости разработки, её удорожания, ухудшения поддерживаемости и масштабируемости.
Причём даже с только с таблицами возникают ситуации, когда приходится предупреждать всех разработчиков, что собираешься, например, переименовать поле.это будет в любом случае, если есть необходимость изменить структуру базы. Но используя IDE субд это делается просто — везде где надо поле переименовывается а в зависимых запросах можно добавить as «старое_имя» и в коде никаких изменений вносить не надо…
в этих ide и прочий рефакторинг делается просто.
Я не чураюсь хранимок или триггеров, но для переноса в них части логики мне нужны очень веские основания. Главное — неперенос сделает работу какой-то конкретной фичи неприемлемо медленной для пользователей или заказчика. Но перенос для меня всегда оптимизация, которая делает систему быстрее за счёт уменьшения скорости разработки, её удорожания, ухудшения поддерживаемости и масштабируемости.Из практики — возможности хранимок увеличивают возможности, к примеру хранимки могут возвращать несколько результсетов, при добавлении записи в одну из связанных таблиц сразу добавляется и в другую… что сокращает обращений к базе. ну и, не маловажный фактор, защита данных, и полная защита от инъекций. Если не использовать специализированные ide для работы с базами — то это трудно и накладно, но ведь и никто не пишет проекты в блокноте…
я принял как стандарт — даже простейшие запросы оборачивать в хранимки — самое огромное преимущество — огромная быстрота быстрота их написания любой сложности и огромная быстрота отладки. написал — запустил — увидел результат. ни компиляции кода, ничего. даже в том же хибере, даже если ide помогает написанием запроса — то увидеть результат — надо сделать кучу действий. как минимум запустить какой-нибудь тест. В ide субд — только запустить на выполнение…
А вы правите код непосредственно хранимки или какого-то скрипта CREATE OR REPLACE…?
try (Connection con = dataSource.getConnection(); CallableStatement proc = con.prepareCall("{call хранимка1(" + param + ")}");) {
rs = proc.executeQuery();
rs.next();
userSession.getBasicRemote().sendText(rs.getString("av"));
} catch (SQLException | IOException ex) {
ex.printStackTrace();
}я написал вызов и обработку, в param набор передаваемых данных(вариантов прередыи несколько — выбор — повкусу и месту), на этом работ с java закончена.Открываю ide dbFogge и работаю с нужной хранимкой.
Я работаю непосредственно с хранимкой, всю остальную работу за меня делает ide. при запуске она спрашивает о сохранении хранимки и формочкадля ввода параметров(достаточно ввести один раз, в дальнейшем просто подвердить), иногда мне это надоедает я открываю запрос из храники (в том случае если хранимка состоит из одного запроса) в новой вкладке и просто запускаю его (предварительно организовав входные параметры(если они нужны :) )
добившись правильной и быстрой работы хранимки — сохраняю её. Всё. Никакой синхронизации.
если кто-то изменил что-то в базе, в огромном большинстве случаев в коде ничего менять не надо. Достаточно открыть хранимку она закричит о несоответствии чего-либо, просто её поправить, главное чтоб она возвращала «правильные» названия полей и их количество. Ну а — правильность данных в этом случае — это уже по месту. Чисто теоритически хранимка может представлять (на какомто этапе разработки) из себя заглушку, которая просто делает такое
select 0 as поле1 1, 'xxxx' as поле2 from table
union
select 3 as поле1 1, 'rrr' as поле2 from table;этого достаточно чтоб отладит код. а специалист по субд может отладить хранимку(добавив к имени префикс)
И как быть, если в базе что-то поменялось (например, таблица переименована кем-то), а хранимку не открывал? Или переименование таблицы реплицируется на все базы всех разработчиков и не только таблицы, но и её использование в хранимках? IDE для той же Java начнёт ругаться об ошибках с тем что-то не так вызывается, как только получит код, а не дожидаясь его закрытия или, тем более, запуска.
Как минимум нужно синхронизировать параметры и результат. Переименовали столбец (или что там) av в хранимке, нужно переименовать его и в Java коде.ничего подобного делать не надо, достаточно использование алиас (as ) и всё. у вас в коде будет постоянное имя поля.
И как быть, если в базе что-то поменялось (например, таблица переименована кем-то), а хранимку не открывал?я говорю о ide dbFogre (Devart, у этой фирмы есть ide для популярных субд) при переименовывании возникает вопрос о применении рефакторига — и изменения вносятся во все места где встречается место для смены имени таблицы, хранимки, вью, функции, использование as избавит от смены имен полей в коде.
можно использовать каждому свой экземпляр базы, и по завершению работы над куском задачи сливать в «общую».
этот процесс наглядный, простой, удобный…
при сливании показываются все отличия, так что сделать ошибку трудно.
хранимки поддерживают комметарии в коде.
больше напоминает какую-то крутую админку к базе,не просто крутую, а ОЧЕНЬ КРУТУЮ да, это не инструмент разработки приложений, а инструмент разработки запросов, функций, вьюшек, хранимок. Инструмент полноценной работы с базой
Слияние баз, о котором вы говорите — это генерация нового дампа, в котором можно посмотреть отличия с предыдущим, генерация скрипта миграции или реальное слияние, типа подключились с дев-машины к проду и запустили синхронизацию локальной базы с продуктовой?это всё в одном. Есть два пункта «слияния» -для структуры и для данных. как результат — генерируется скрип, который можно посмотреть, а можно и запустить.
подключаете ide к проду и к свой базе, сливаете необходимые данные и тестируете у себя на реальных данных.
можно делать «резервную копию» — я так резервировал базу с клиента — 14гиг в зипе.
все запросы можно строить в гуи,
не идеальный, но отличный редактор для написания, с подстановкой, подсветкой кода, есть форматирование кода.
есть «проводник» в котором перечислены все элементы, можете выбрать таблицу и увидите что от неё зависит, выбираете хранимку и видите от чего она зависит.
наверно единственно чего не хватает — это работы с гит, но у них есть глосовалка и этот пункт набирает голоса.
Ребята активно развивают продукт, активно откликаются на замеченные баги.
Так вот, BigDflz прав (а вы все же зря спорите) в той части, что он про tool for database — это вполне можно назвать «IDE для базы данных» либо «сильно крутая админка».
Да, весь функционал по работе с БД присутствует.
www.jetbrains.com/datagrip/features
P.S. Конечно, BigDflz вел речь о «другом» продукте, но они из одной ниши.
P.P.S. Про саму концепцию «как писать» — я вмешиваться не хочу… у меня лично позиция, как и у вас, но BigDlfz я так же понимаю.
Всему свое место )))
Можно ведь делать в пару кликов выгрузку того же ddl и «в базу» лить скрипт. По крайней мере JetBrains гордится своим продуктом (на пустом месте?).
дак вопрос в чём?
в преимуществах работы с хранимками или то что работа с базой «плохо версионированна»?
если у вас текст запроса в коде, то при изменении имени поля в базе, разве не надо искать все вхождения этого поля по всем файлам проекта? Тогда как инструмент рефакторинга в IDE это сделает во всех хранимках, а чтоб не копаться в коде достаточно использовать алиасы в коде хранимке.
Повторюсь несколько. Я использую все обращения к базе через хранимки, в запросах(которые в хранимках, я использую алиасы, это позволяет избежать зависимости от названия полей, таблиц в коде основного софта. если кто-то внешний изменит имя поля, в IDE есть рефакторинг, который найдёт все использованные имена и предоставит возможность их переименовать и сделает это автоматом в всей базе. в коде все останется по прежнему. Это как бы «подобие json» для обмена данными между базой и кодом. Чего нет при использовании запросов написанных в коде софта. когда я занимаюсь отладкой хранимки (в большинстве случаев — это простой селект) я правлю только текст хранимки и проверяю его работу, какие данные он выводит, как работает, смотрю план запроса. Это происходит быстро. Код софта при этом не трогается. Я могу проверить как работает код сделав хранимку-заглушку. Отладив хранимку(запрос в ней) проверяю как работает всё вместе и код и выборка данных. Ни каких 100+ вариантов хранимки мне не нужно. в хранимке можно комментировать любой фрагмент, в любом месте.
если надо хранить варианты, для этого есть команда продублировать. и в базе будет сделана копия элемента(хранимки, вью...)
для нормальной разработки лучше иметь у каждого свой экземпляр. базы.
Обычно использование хранимок воспринимают как перенос бизнес-логики в базу, но это не всегда так, хранимки — это разделение работы.
Вы написали вызов хранимки, перечень параметров, список возвращаемых полей, и этого достаточно что специально обученный DBA сделал оптимальный вариант обработки данных. Чего нельзя сделать при написании кода запроса в основном коде. DBA делает своё дело — вы своё. Это как разделение фронт-енд — бэк-енд, только добавляется бэйз-енд.
P.S. я как раз фронт и бэк не разграничиваю строго, даже если они в разных репах лежат.
Я знаю контору в которой в одном проекте 900+ хранимок mssql, и все работает, развивается.
900+ хранимок — это проект уровня гостевой книги по размерам, такой можно разрабатывать как угодно и на чем угодно, проблем не возникнет.
Что если хранимок будет 900+ сотен?
Что если хранимок будет 900+ сотен?тут уже нет разницы 900 или 900 сотен, они не запариваются над их количеством. только и всего.
тут уже нет разницы 900 или 900 сотен, они не запариваются над их количеством. только и всего.
То есть проект не поддерживается? Написали и выкинули?
проекту уже более 10 лет.
900 хранимок за 10 лет? То есть, по сути хранимки в проекте практически не используются?
То есть, по сути хранимки в проекте практически не используются?Придирки не приветствуются! Если вы думаете, что за 10 лет только добавляются — значит вы не поддерживали проект длительное время, как правило большая часть подвержена изменениям, причём очень частым — требования и законы меняются постояноо. и добавление не столь сложная задача как изменение существующего.
```sql
PROCEDURE simpleproc (OUT param1 INT) BEGIN
SELECT COUNT(*) INTO param1 FROM t;
END
```
и какой-то вотчер, который любые изменения в этом файле «маппил» бы на базу, сам анализируя, какую команд(ы) конкретно запускать, например DROP при удалении файла и CREATE при создании. Ну и все прелести современной разработки типа навигации по именам, автозаполнения, обнаружения ошибок без обращения к базе и т. п. Чтобы поднимать базу мне приходилось только для тестов (так же в файлах лежащих) и отладки, а код мог спокойно писать без базы.
У меня нет ваших проблем, ваших страхов, я использую хранимые процедуры по-полной и наслаждаюсь их возможностями.
Не нравится — не ешь, но зачем кричать, что это не вкусно?
В целом зависит от задачи. И ОРМ придумали как раз для упрощения и увеличения продуктивности.
Конкретно по триггерам: blog.kloud.com.au/2018/01/30/cosmos-db-server-side-programming-with-typescript-part-4-triggers
А можете привести пример триггера в какой-нибудь СУБДДа мы уже поняли что вы обожаете триггеры в бд и везде их пытаетесь сувать, не думаю что это характеризует вас как «Senior developer»
Вы об этом?
могу попробовать уйти в управление
Вы знаете, то о чем Вы написали и есть путь в управление.ИТ Архитектор это и есть профессиональный дилетант.Знающий много технологий и "прокладывающий путь" проекту.
Конечно, если архитектор делает фичи сам а не делегирует их более узкоспециализированным разработчикам,- может получится лажа.Архитектор строительный я думаю тоже может заштукатурить стену… но профессиональный штукатур сделает это лучше. Но штукатур не сможет быть архитектором.
Мне нравится разделение по уровню ответственности:
Джуниор — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.
Миддл — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.
Сеньёр — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.
Насчёт «бизнесу нужны фуллстеки» — здесь есть нюанс. Бизнес разный бывает. И именно фуллстеки нужны обычно там, где человек по факту занимает несколько вакансий. То есть, в небольшом бизнесе или в стартапах. Не говорю, что там работать это плохо — это тоже может быть интересно, в особенности на начальных этапах, когда ты только познаёшь, чем хочешь заниматься.
Но если бизнес большой, а продукт сложный — здесь нужны достаточно узкие специалисты. И, к сожалению, просто нельзя одновременно быть сениор разработчиком фронта, бэка, мобилки, девопсом и архитектором СУБД (у меня был такой опыт, но я не могу покривить душой и сказать, что я был хотя бы миддлом сразу во всех областях сразу). Просто потому что технологии сейчас развиваются с большей скоростью, чем человек может их освоить. Опять же, «освоить» это не значит «прочитать анонсы». Это значит — попробовать вживую. Да, можно хорошо разбираться в 2-3 технологиях, но дальше начинается деградация знаний, и ты действительно становишься универсальным миддлом. Я от этого в какой-то момент устал и ушёл. И очень доволен таким решением.
Хотя я не говорю, что соседние стеки знать не нужно. Я считаю, что сениор должен обладать как минимум полноценным пониманием взаимодействия компонентов своего продукта и умением его отладки — хотя бы чтобы знать, где возникают проблемы, а не вопить, что они «на другом конце». Но понимать тонкости — уже излишне и слишком трудоёмко. Нужно честно признать, что ты развиваешься в конкретном направлении, а в остальных ты в лучшем случае миддл. Затем принять это и не комплексовать. Всегда найдутся люди, которые в чём-то разбираются лучше — поэтому мы и работаем не в одиночку, а командой.
У нас узкая специализация. Один пришивает карман, один - проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть? И они — не портные, они — подмастерья.Узкие специалисты нужны редко и ненадолго. Если нужен человек по конкретному интерфейсу SoС — его можно позвать на конкретную задачу. А нужны именно full-stack — спроектировать схему, развести её, спаять, отладить электрически, запустить SoC, потом RTOS, потом приложение.
Это должна быть очень крупная фирма, чтобы позволить себе держать специалиста по RS-485 или RS-232. И очень много разных платформ, чтобы у него был фронт работы.
Ну и потом, узкий специалист не может нормально отлаживаться. Ио работу кода мы отлаживаем осциллографом, а проблемы в железе ищем кодом.
Так что сеньор — это full stack, а «мастера по пришивке пуговиц» — джуны. Для того и было придумано разделение труда и узкая специализация — чтобы заменить десяток сеньоров сотней джунов.
А ещё у меня сложилось предвзятое мнение, что чем лучше человек понимает схемотехнику и внутренности МК, тем хуже у него код для этих самых МК
Хуже — это по каким параметрам? По количеству ошибок, по читаемости, по стабильности кода за 10 лет? Когда у вас для отладки только светодиод и осциллограф — есть смысл писать надежно и просто. То есть весьма-весьма дубово. Но это достоинство, а не недостаток.
Хуже — по поддерживаемости. В основном я видел спагетти код. При этом после двухмесячного перерыва в работе автор кода не мог понять что, как работает. SOLID, DDD, что это такое?
Если код надёжный и просто — то это замечательно, вот только для меня простота — это не отсутствие работы с указателями или каких-то хитрых вещей, а возможность прочитать совершенно незнакомый код и понять, как он работает. И в этом как раз помогает и SOLID, и другие идеи.
А на стороне софта… у RS-485 есть терминаторные резисторы. Ну как настраивает резисторы обычный программист? Посмотрел осциллографом, поставил — и тест на сутки. Если больше одного сбойного байта за сутки — менять номинал. А узкий специалист сразу ставит нужный резистор.
SOLID — это все-таки С++. Простой и читаемый код — это обычный Си, близкий к ассемблеру. См. драйвера linux — они довольно хорошо написаны.
P.S. У нас в конторе есть всего один узкий специалист — это технический писатель по ГОСТ.
Зачем вы в каждое обсуждение пихаете свою предметную область с отсылкой к "а у нас вот так, и поэтому весь мир должен думать так же"?
BTW, SOLID — это не про С++ и принципы можно и нужно использовать и в не ОО-языках тоже.
А про SOLID в не ОО-языках — расскажите или ссылку дайте.
Все принципы, кроме подстановки Лисков можно применять к процедурным и функциональным языкам, просто надо думать в чуть более широком смысле. Например, SRP — функция должна иметь конкретную зону ответственности. Interface segregation — подразумеваем интерфейс в широком смысле, не ключевое слово, а API. И так далее.
Просто нафига очевидные вещи называть громкими словами?
Принцип подставки Лисков говорит об отношениях между типами и подтипами, как это вы его используете в Си?
onexit — это обычные коллбеки.
Очевидные вещи:
1) очевидны не всем;
2) очевидны по-разному;
Что и демонстрирует ваше непонимание очевидных другим вещей.
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.
Вот на callback и на weak-функциях оно и делается. Базовый тип — вывести информацию Специализации — вывести на RS32, на RS32 через ПЛИС, на CAN, на MIL-STD-1443b…
onexit — как раз нормальный пример. Базовый тип — выполнить финализацию. А специфические подтипы делают конкретные вещи.
В принципе группа weak-функций или callback дает вполне функциональную замену ООП. Даже с наследованием (можно выставить свою функцию на callback и в ней вызвать то, что было на callback раньше.
Короче вы спорите со мной непонятно о чём. Если вы сделали в Си псевдо-наследование — честь вам и хвала. И это даже больше подтверждает моё утверждение. Если вам просто хочется поговорить, так и скажите, а не прыгайте с темы на тему.
JFYI, постоянные упоминания деталей ваших реализаций не делает вас круче, равно как и не даёт дополнительной информации собеседнику.
Инженер: Если работает так как надо, то дальнейшие улучшения не требуются.
Программист: Если результат не оптимален, то не будет работать как надо.
У первого цель — рабочая программа.
Цель второго — не ломающаяся программа.
Другое дело когда проект большой, сложный и массовый. Вот у меня сейчас проект — это кодовая база на несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом. Поэтому тут и SOLID, и юнит тесты, и blackbox тесты, Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.
Все-таки разделение труда — это главное достижение человечества.
Разделение труда (в пределе — конвейер) придумано, чтобы привлечь к работе низкоквалифицированный персонал. Брукс хорошо доказал, что увеличение численности не ускоряет разработку (если 9 беременных женщин собрать вместе, ребенок через месяц не родится), наоборот, в его конкретном случае, увеличение численности в 10 раз разработку замедлило.
Поэтому вопрос в экономике. Нужна эффективность производства — делаете конвейер с сотней программистов. Нужно качество — обходитесь всего несколькими сеньорами.
несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом.Поржал. Зачем это отлаживать на МК? Разработка и отладка 99.9% идет на windows. Да, приходится делать имитаторы и писать переносимый код. Но на windows отлаживается все, кроме очень специфичного для МК кода. Потом перенос на linux, потом — на МК.
У меня был проект с доступным временем на отладку на реальном стане — 2 часа в месяц (130 тысяч строк кода). Ничего, справился без отладки.
Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.Ну и я таких терминов как SIL и HIL не знал. Но мы их применяли почти 20 лет назад. Как-то не сложно было независимо их изобрести.
Так вот этот товарищ усиленно не хотел разбираться в том, чем будет управлять програмирумый им ПЛК и как этот ПЛК, собственно, функционирует. Типа, мое дело писать код, ваше дело предоставить мне алгоритмы и заставить железо работать, либо алгоритмы вытрясайте у технологов.
И вот настал тот последний проект, который мне в той фирме посчасливилось доводить до конца, от конструкторской документации и почти до пусконаладки. Система ответственная, для нефтехимпрома, контроллеры отказоустойчивые, вероятность отказа 0.(0)1%. Нарисовал схемы, собрали шкафы на сборочном участке, собрали стендики-эмуляторы сигналов, закупили калибратор за бешенные бабки для настройки аналоговых каналов. Начался этап тестирования софта, я подаю сигнал 4...20 мА, имитируя работу датчика, программист смотрит, что пришло, подгоняет единицы измерения — ток в паскали, мм, кубометры и прочее. Подаю я, значится, сигнал, яжпрограммист ждет, что там будет уровень в емкости 1 метр, а уровень то скачет немного, шумит младшими битами 12-битный АЦП в ПЛК. И тут возникает «шум АЦП» со стороны яжпрограммиста: ты что это, подлец и диверсант, делаешь, я ж прошу выставить уровень в емкости 1 м, а ты какого рожна выставляешь то 0.99, то 1.01 м, ты мне вынь да положь 1.000м, как я с буду программу отстраивать на работу с такими данными? Чуть я заикнуля про необходимость фильтрации, аппартаной или программной, как «шум АЦП» начал усиливаться, что это я лезу не в свое дело, мое дело должно быть маленькое, обеспечить нормальное функционирование техники, а не учить программистов работать, что это за препирания с начальством, да и вообще таким специалистам тут не место.
1. В ТЗ учесть всех нюансов невозможно, много интересных моментов вылазит на следующих этапах, а ТЗ уже утверждено заказчиком и переделке не подлежит.
2. ТЗ пишется исполнителем (да, те самые отделы технических и программных средств), поэтому относятся к нему, как к формальности — отдельному пункту бюджета поекта. Таким образом, утвержденное заказчиком ТЗ является, прежде всего, документом, который в дальнейшем отсеивает необоснованные притязания заказчика к исполнителю по функциям и задачам системы. И уж во вторую очереди исполнитель обращается к собственноручно составленному ТЗ, чтобы посмортеть, а как же на самом деле надо реализовать ту или иную вещь. Возможно, в других отраслях заказчик приходит к исполнителю с готовым ТЗ, но у нас все наоборот.
3. Фильтрация сигналов таки была прописана, это стандартный шаблонный пункт (да, мы используем предыдущие наработки в дальнеших проектах, не пишем «код» каждый раз с нуля).
4. В модулях AI фильтр встроенный есть, на этапе работы с железом (в момент испытаний же!) стало ясно, что его возможности не удоволетворяют требованиям точности. Если железячники о причинах проблемы догадались сразу и тут же предложили метод решения, то яжпрограммист пошел по пути наименьшего сопротивления. Зачем создавать себе работу, если можно свалить проблемы на соседний отдел?
Да черт с ним, с АЦП, это одна из историй, создавшая проблемы ровно на 2 рабочих дня, с учетом совещания у начальства (любую незначительную проблему выноси на повестку дня на планерке — n-ое правило ватокатства).
Еще одна история из этого же проекта. Алгоритмы, по которым должна функционировать система, разрабатывались в одном ЭнскГИПроКакойтотампромышленности, разрабатывались в виде, так сказать функциональных диаграмм (дикая смесь FBD и LAD), но в отрыве от соответствующих стандартов. Возможно, авторы листали лет 30 назад справочную литературу по Ремиконтам. Ну не суть, в принципах работы создаваемой системы разобраться можно — что контролировать, что, когда и с какими задержками и блокировками включать. На изучение этой документации техотдел потратил 2 месяца, и потом все на пальцах объяснил программистам, описав алгоритмы в текстовом виде, заодно нашел множество нестыковок, косяков и прочего. Но, в ходе общения с Заказчиком, представителями ЭнскГИПроКакойтотампромышленности пришли к заключению, что «проект уже давно утвержден (лет 6 назад как), переделывать его никто не будет, это деньги и время, делайте как есть, на месте разберемся». ОК, раз есть такой приказ, яжпрограммист использует алгоритмы как руководство к действию, пишет программу.
Тут поджидает засада. Проектировщики алгоритма знать не знали о стандартах IEC, о том, какие контроллеры будут использваться, какие там есть билиотечные функции. Напоминаю, что в IEC имеются таймеры, типа TON, TOF, TP. Проектировщики алгоритма предполагали одно поведение таймера, стандарт предполагает другое поведение. Яжпрограммист реализует структуру программы в точном соответствии с алгоритмом (проект же утвержден, что я буду отходить от него?), в итоге программа не работает. ОК, копья ломаются, АЦП шумит, проблема решается не без крови (потребовалось добавить к таймеру дополнительно RS-триггер, но в алгоритмах, хоть и предполагается такое поведение, явно это не указано!).
Поехали дальше, следующая засада. Используются ПЛК двух типов, стандартные, для неответственной системы РСУ, и Safety для системы ПАЗ. Если стандартные контроллеры имеют широкую библиотеку функций, то Safety не дадут вам выстрелить в ногу, даже если очень нужно, поэтому библиотека функций урезана по самое небалуй. Проектировщики алгоритма этих тонкостей учесть не могли, т.к. им все равно, на каком железе это все будет работать. Программист об этом знает, но алгоритмы же утверждены! Итог? Опять неработающая программа.
И все это в условиях вяло текущего дедлайна, со спецификой особо опасного производства, где любое нарушение технологии — катастрофа.
Как ни странно, в российских реалиях обычно называют фуллстаком не того человека, который полностью знает один некий стек от фронта до бэкенда — а того, кто знает несколько стеков.
А насчёт необходимости узких специалистов «редко и ненадолго» — это просто неправда с потолка.
Где-то ненадолго нужен администратор Oracle 11g? Или, может, Java разработчик? Может, SQL аналитиков нанимают на месяц? Или где-то ищут одноразовых специалистов по машинному обучению?
«A Full-Stack Web Developer is someone who is able to work on both the front-end and back-end portions of an application»
Фулстэк — это тот, кто может работать как над бэкэндом так и над фронтэндом. Просто сейчас масса разработчиков, которые могут только angular, или только мобильные формы лепить, или только сервисы пишут последние 20 лет. Проблема с такими разработчиками, что комманду из таких невозможно нормально нагрузить работой. Всегда кто-то простаивает.
отладить электрически, запустить SoC, потом RTOS, потом приложение.
Вполне допускаю, что у вас не так, но из моего личного опыта разработчики такого широкого спектра «и железо и программы и жнец и на дуде игрец» пишут такой отвратительный код, что жалко глаза. Наблюдается какой-то поразительный шовинизм вида «мы тут Железку создали, что там какой-то код», из чего следует некоторая узость взглядов в сфере разработки ПО и отвратительный нечитаемый и неподдерживаемый код.
Я полагаю, схемы, сделанные программистами, тоже не без недостатков :)
Разумеется. Так о том и речь, что универсальная вещь делает всё, но делает всё хуже, чем специализированные по отдельности. Так и со специалистами — к вопросу о fullstack.
Конкретно с «железячниками» не раз сталкивался с отношением к вопросу — см. выше — «мы сделали железку, это 99% успеха, осталось только программку накидать, это фигня, за вечер управимся». Получается так себе. Лучше, конечно, чем если наоборот — написать программу, а потом «за вечер» накидать плату, но тем не менее. Т.е. здесь раз за разом встречаю отношение к программированию, как к игровой области, где нет никаких профессиональных стандартов, неважен опыт и навык, нет технологий разработки и этим может заниматься каждый с улицы. Да, порог вхождения, пожалуй, ниже, чем в «железо», но проблема остается.
Например, тут вон недавно механический map-reduce на перфокартах пролетал…
А уж багаж знаний творит и вовсе чудеса).
Программиста может погубить только возрастная болезнь мозга, все остальное трудно но преодолимо (даже отстуствие зрения к примеру =) )
Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
Нормальный фронтендер не затащит на фронт то, что нужно делать на бэке.
Плохой разработчик сделает и то и то и другое вне зависимости от того, узкий он специалист или fullstack.
Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.Ключевое слово — Нормальный. Но таких ужасающе мало, и к сожалению, я таких не встречал. Хотя в своей «частной» области сеньёры…
Да и в своей области не всегда красиво выглядят. Есть примеры когда ругают код, а предлагают такое, что добавляет и кучу кода и время выполнения. Как яркий пример использование шаблонизации — да, чисто внешне вроде красиво, как копнёшь… нужно сделать то, сё, пятое, десятое… а в итоге за всем этим скрыто простое построение строки, которое можно сделать просто и наглядно в в несколько строк кода, а не в нескольких файлах. и будет работать а разы быстрее.
Если код работает, отвечает функциональным требованиям к системе — он уже не фигня объективно.
как правило один код может отличаться от другого на не большое время работы — но таких кусков кода может быть много — в итоге система может либо тормозить, либо быстро работать — выбор за тобой
Порой вполне оправданно. То что в бд делается через 9 джойнов на коде бэка можно сделать простым кодом — намного дешевле и по времени выполнения и по оперативке, даже на не самом быстром яп бэка.
Другой пример — когда для улучшения скорости бэк хранит часть данных базы в своих структурах данных чтобы не бегать в нее за каждым чихом. Очень важно если нам нужно отвечать на запросы не медленнее икс миллисекунд. В этом случае кстати бэк плюсовым.
Есть еще нюанс. Да, на стороне sql многое делается сильно проще и эффективнее (даже, когда надо 9 джойнов, то почему бы не задействовать кеши СУБД с отполированным годами кодом, написанным суровыми системными программистами вместо своих велосипедов, к тому же, можно materialized view или триггеры и поддержание +1 таблицы устроить).
Проблема как правило лежит в другой плоскости. Код бека легко покрыть тестами, он будет в рамках паттернов и ооп, он версионируется без костылей, он не требует миграционных скриптов, его проще переиспользовать. Кроме того, вариант "одна субд с мин нагрузкой + куча стейтлес воркеров" идеально масштабируется. Версии воркеров тоже можно обновлять нода за нодой. Также, если речь идет о лицензионном mssql/oracle, которые лицензиуются за ядра cpu, то может быть дешевле нагрузить 3 ядра на сервис хосте, чем одно на машине с субд;)
С другой стороны если грамотно построить структуру субд, грамотно написать запросы/хранимки — может и не потребоваться масштабируемость.
Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным. Именно поэтому в т.н. BigData описание вычисления присылают в хранилище данных, а не данные из хранилища присылают исполнителю вычисления.
Разве что в описанном случае запрос вышел очень неоптимальный, но при этом с крайне низкой кардинальностью по данным в итоге. Тогда да, обработка в лоб действительно может быть быстрее. С другой стороны, уверен, что перестроенный и оптимизированный запрос всё равно выиграет.
Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным.
Это больше на демагогический постулат походит. Ну или на "кодерско-оптимизаторский" (хотя не факт, что на практике будет быстрее, если СУБД у нас толком не масштабируется, а апп-серверы сотнями можно поднимать). Инженерный подход подразумевает не только техническое, но и экономическое обоснование.
hadoop.apache.org/docs/r1.2.1/hdfs_design.html
Уж поверьте, как кодер я был бы только рад унести логику обработки данных из «холодной, безразличной» и требующей многословных запросов базы данных (где, например, попытки переиспользовать код обычно натыкаются на ощутимые тормоза ввиду переключения контекстов между SQL и PL) в уютный для меня любимый язык программирования. Но сетевой доступ к хранилищу не может происходить по путям бесконечной ёмкости, а значит, чем больше работы я сделал вдали от данных, тем больше данных было передано по сети. А это вещь ненадёжная и медленная.
Я не исключаю что в каких-то системах такой подход может не работать и сервер базы загружен на 98%, но с другой стороны, если мы можем поднять сотню аппсерверов (для чего, кстати? вручную делать join'ы и закат солнца до кучи?), то почему мы не можем поднять «клон» для чтения, к примеру? Или поделить данные между несколькими базами, для начала, а склеивать уже результат от полученный от одинакового запроса к разным базам?
Никакая не демагогия, вот отсюда беру, обратите внимание на пункт “Moving Computation is Cheaper than Moving Data”:
Там же никакой аргументации не приведено. Точно так же можно заявить, что лучше данные обрабатывать там, где они будут непосредственно использоваться, т.к. тогда мы сэкономим на передаче данных к клиенту.
Пример: рендер изображения в сетевой игре происходит на клиенте, а не на сервере
Плохой пример: если изображение это данные, то их совершенно правильно не передают с сервера, вместо этого клиенту передаётся описание вычислений, необходимых для получения правильных данных (поток событий в матче).
С другой стороны, в ММО, опять, же не передают все данные из базы на клиента, дабы клиент сам определился, какие из них ему действительно нужны и сделал необходимые вычисления. Переводя на язык СУБД, в таком случае вся фильтрация и join'ы произведены на сервере (в базе данных), клиенту приходит только проекция. Когда такая схема нарушается по любой причине, появляется возможность сжульничать — например, убрать «туман войны» в стратегии (применимо только для стратегий с сервером-арбитром правда, обойтись без дупликатов данных в P2P играх, насколько я знаю, пока не получалось ни у кого).
Так мы вроде и обсуждаем здесь случай, когда данных много? Иначе зачем для их хранения нужна база данных? Малые объёмы можно держать и в оперативной памяти где-нибудь.
А ваше «был бы только рад» намекает на то
… что я уже взвешивал несколько раз возможность "вытянуть всё и на месте разобраться в коде". И ни разу это не оказалось приемлемой стратегией. Более того — несколько раз мне приходилось такие подходы из кода вычищать калёным железом, так как в раунде PSR-тестирования выявлялось сильное падение отзывчивости системы, и причиной были именно, закаты солнца вручную на сервере вместо написания нормального запроса в базу данных.
В исходной формулировке с уточнениями, правда, выходит, что запрос «хавал» очень много ресурсов сервера БД, а малое количество данных так не делает.
Кстати, в C# запросы к данным в памяти и к данным в БД могут строиться одинаково и декларативно (см. linq).
Кстати, в порядке просвещения меня: может ли LINQ сделать такую отдельную загрузку для малых таблиц и потом использовать эти таблицы в проекциях без настоящего join'a на стороне БД? Хотя бы в теории?
Даже если они часть предиката, все равно варианты "подключить, проверить и забыть" и "подключить, проверить и запомнить" дают разные требования к памяти. Пренебречь им нельзя, потому что это целый дополнительный столбец в результатах запроса.
Кстати, в порядке просвещения меня: может ли LINQ сделать такую отдельную загрузку для малых таблиц и потом использовать эти таблицы в проекциях без настоящего join'a на стороне БД? Хотя бы в теории?
LINQ такого не может, ибо это всего лишь язык запросов. А вот Entity Framework нечто подобное умеет, если пару хелперов написать. Вот изменения трехнедельной давности (полсекунды выиграл, однако):
public static void AttachFromCache<T>(
this DbContext ctx,
IEntityCacheService cache
) where T : class
{
var set = ctx.Set<T>();
foreach (var item in cache.GetAllItems<T>())
{
set.Attach(item);
}
}Пренебречь им нельзя
Ну почему так категорично. Предикация и проекция — две операции, которые не так чтобы близко были связаны между собой. Для малых кардинальностей, логически, есть возможность оптимизировать запрос так, чтобы этот столбец был "Ленивым" и вычислялся вообще прямо перед "Show" каждой строки (в последний момент), что будет ценно как раз при ограничении по памяти, т.к. позволяет при вообще не хранить в столбце значения — только "рецепт" и кеш-таблицу. Оптимизация менее применима при наличии сортировки по такому столбцу, но не снимается полностью даже в этом случае.
Про LINQ: Там в картинке явно указывается в тексте запроса, что, что некие сущности следует брать из кеша.
Не то чтоб это было плохо само по себе, но требует телодвижений в каждом use-site. Впрочем, принципиальную возможность это уже доказывает, следовательно, где-то должен быть способ то же самое делать более централизованно. Благодарю за просвещение.
Это типичная ситуация когда в тяжелом запросе есть джойны с кучкой мелких справочников.такие справочники кэшируются в субд и подключаются результирующему select в самом конце. и нет никакой необходимости их загружать в код. Правильное написание селекта только и всего.
Вот и есть ответ на все претензии к работе с базой — прогер не может правильно записать/переписать select. Происходит попытка заменить возможности субд своим кодом, который явно не может быть лучше чем код обрабатывающий запрос в субд.
Что займет меньше места: 100 записей вида «число+строка» и 10000 чисел — или 10000 записей вида «число+строка»?
То, что запрос возвращает только нужные данные, еще не означает что они не дублируются.Странное утверждение — если требуется — будут и дубли, не требуется — дубли убираются — в селекте за это отвечает 1 слово.
А меньше займу место правильно выбранные данные. Зачем отправлять 10000 чисел? когда можно сформировать запрос, чтоб он вернул 100…
У меня справочник наименований товара содержит 100 000 наименований — по-вашему я должен все эти наименования держать в памяти? чтоб вывести накладную из 20 позиций…
Да вы можете сэкономить(только что сэкономить?) и держать в памяти этот справочник, и при формировании чего-либо для отправки клиенту подставить из мапы/листа/хэша, но это ни есть экономия ни памяти, ни времени работы. При подстановке нужны множественные обращения к этому хранилищу справочника, это код, это время…
и Ещё вопрос Запрос возвращающий 10 000 записей — это не правильно поставленная задача, соответственно и решение не верное. Если вы хотите отправить все 10 000 клиенту и чтоб он их сортировал, фильтровал — если вы так делаете…
это не означает дублирование записи, это только то, что некоторые поля имеют одинаковое значение
Один фиг если не пересылать по сети одинаковые значения — будет сэкономлена пропускная способность. Или вы и в это не верите?
но вы должны вернуть id этого значения, чтоб потом вывести юзеру не id а само наименование, а эти id также будут «дублироваться», если следовать вашему утверждению
id занимает намного меньше байт
У меня справочник наименований товара содержит 100 000 наименований — по-вашему я должен все эти наименования держать в памяти?
Я выше уже писал, что для разных объемов данных оптимальные решения — различные. У нас тот справочник о котором идет речь содержит меньше сотни записей и никогда не будет сильно расти.
Да вы можете сэкономить(только что сэкономить?) и держать в памяти этот справочник, и при формировании чего-либо для отправки клиенту подставить из мапы/листа/хэша, но это ни есть экономия ни памяти, ни времени работы. При подстановке нужны множественные обращения к этому хранилищу справочника, это код, это время…
Ну, вообще-то, у меня почему-то экономится и память, и время работы. Возможно, вы просто не умеете писать код.
и Ещё вопрос Запрос возвращающий 10 000 записей — это не правильно поставленная задача, соответственно и решение не верное. Если вы хотите отправить все 10 000 клиенту и чтоб он их сортировал, фильтровал — если вы так делаете…
Если дофига задач где требуются большие выборки. Как пример — экспорт данных или ETL. Если вы не только ни разу с ними не сталкивались, но и представить себе их не можете — вы не такой опытный админ СУБД как пытаетесь показаться.
Один фиг если не пересылать по сети одинаковые значения — будет сэкономлена пропускная способность. Или вы и в это не верите?пропускная способность гигабитной локальной сети?
Ну, вообще-то, у меня почему-то экономится и память, и время работы. Возможно, вы просто не умеете писать код.а у меня просто нет необходимости экономить — просто не требуется память.
Если дофига задач где требуются большие выборки. Как пример — экспорт данных или ETL. Если вы не только ни разу с ними не сталкивались, но и представить себе их не можете — вы не такой опытный админ СУБД как пытаетесь показаться.Согласен, но ваши же слова Я выше уже писал, что для разных объемов данных оптимальные решения — различные.
У нас тот справочник о котором идет речь содержит меньше сотни записей и никогда не будет сильно расти.но подставляя эти значения в коде — вы увеличиваете код. Мелочь, но я просто использую поле, которое мне вернула база — И нету даже этой мелочи, что вас.
та же субд может сделать ETL в нужном формате прямо в файл(при необходимости) или из результсета сразу выгружать по месту и для этого в 99% случаев нет необходимости доп обработки данных. Mssql может даже транспонировать данные… Даже если данных будет 1 000 000 нет необходимости выгружать их в память — субд организует правильную отправку результатов в код.
У меня справочник наименований товара содержит 100 000 наименований — по-вашему я должен все эти наименования держать в памяти?
Хранить 100 000 наименований (или даже 1000 000 наименований) в памяти намного эффективнее, чем каждый раз СУБД дергать.
При правильной настройке субд все нужное кэширует
Если субд что-то закешировало, то вам все равно придется делать запрос, а это обычно использование сети, а использование сети — очень затратная операция. Если ваши данные просто лежат в памяти, то к базе вообще не надо обращаться.
Кроме того, универсальный кеш субд заведомо менее эффективен чем конкретный кеш на клиенте.
Сетевое взаимодействие с базой никогда не будет быстрее прямого обращения к оперативной памяти.с одной стороны да, но с другой субд специально заточена на обработку данных, с использованием кэша, индексов и прочего. и ваша попытка эмулировать работу базы очень проигрывает.
база ищет по индексам — для этого у неё есть специальные таблицы, специальные механизмы, алгоритмы. в вашем же распоряжении мапы/хеши, они явно уступают методам баз.
использование сети — очень затратная операция.это было актуально в начале 90-х когда сеть была на BNCконнекторах, сейчас уже оптикой никого не удивишь даже в квартиру. у нас предлагают 500мбит во внешний инет, а уж в нормальных конторах локальный трафик есть 10Гбит.
Была статья про .stackoverflow.com как у них всё устроено — куча серверов, и ни одного упоминания про сетевые затраты.
и ещё есть много систем с хорошей памятью и достаточным количеством ядер — и все в одном места и приложение и субд — так вот там нет никаких затрат на сеть все через память.
Если ваши данные просто лежат в памяти, то к базе вообще не надо обращаться.смотря для каких целей. таблицы могут быть по 10+ гиг и вы всё это будете держать в памяти? Ещё раз — даже если у вас нет ограничения на память, то вы все равно не сможете конкурировать с по работе с данными ни с какой субд.
у любого приложения есть драйвер, который поддерживает пул соединений с базой, и любое обращение к базе стоит очень дешево.
Кроме того, универсальный кеш субд заведомо менее эффективен чем конкретный кеш на клиенте.кэш в базе не просто таблица, а также индексы, и поиск данных идет с помощью индексов(при правильной организации данных, их индексирования, правильного составления запроса)
если следовать вашим рекомендациям — для ускорения надо однажды из файла прочитать в память и работать с памятью, и никаких таблиц не надо, и всех разработчиков баз разогнать.
тут www.youtube.com/watch?v=HP1Sa2HtRPM&index=74&list=PLH-XmS0lSi_yn4pCZVOHqWaqQ9trMpyLI&t=5m22s
говорится, что засунуть 2ТБ в память — легко!
* это НЕ против Вашего комментария, а скорее — в дополнение))
я читал про систему, что для выключения которой требовалось 8 часов — всё шло на сохранения на диски…
mayorovp
Вынужден вас расстроить, но все эти «специальные механизмы» БД проигрывают обычной хеш-таблице в памяти.так тогда давайте исключим все субд как тормоз и всё будет летать. и само понятие субд запретим…
так тогда давайте исключим все субд как тормоз и всё будет летать. и само понятие субд запретим…
… и это будет даже правильным решением! При условии что данные неизменяемые и помещаются в оперативную память.
1. СУБД — универсальное решение, применяемое для данных, которые, в общем случае, в оперативную память не влезают;
2. СУБД рассчитаны на длительное и надежное хранение данных, да еще и ACID вынь да полож;
3. разработчики СУБД предполагают, что их решением будут пользоваться тогда, когда простые способы уже не помогают.
Вопрос: почему тогда разработчики субд не используют такое?
индексы как-бы примерно таким образом и работают.
Даже для сохранения в памяти они использую таблицы
Что удивительного в том что реляционная база использует реляции а не что-то другое? В целом нет никакой проблемы хранить данные в jsonb с ключем, будет та же хэшмэпа. Но только если вам прям в памяти нужно дешевле будет redis использовать. Он опять же может только ключи в памяти хранить, если вдруг у вас все в память не помещается.
А ещё разработчики SQL РСУБД активно используют хэш-индексы, которые при полной загрузки в память и индекса и таблицы, как думаете чем являются?
Вынужден вас расстроить, но все эти "специальные механизмы" БД проигрывают обычной хеш-таблице в памяти.
а уж в нормальных конторах локальный трафик есть 10Гбит
Сетевые задержки измеряются в милисекундах, а не в гигабитах
и ещё есть много систем с хорошей памятью и достаточным количеством ядер — и все в одном места и приложение и субд
Прощай, масштабируемость!
Что за механизмы в базе, что уступают получению указателя из хеш-таблицы в памяти процесса?
это было актуально в начале 90-х когда сеть была на BNCконнекторах, сейчас уже оптикой никого не удивишь даже в квартиру
Какая разница оптика или не оптика? Сама отправка запроса по сети уже работает дольше, чем запрос к кешу в памяти.
смотря для каких целей. таблицы могут быть по 10+ гиг и вы всё это будете держать в памяти?
Естественно, речь идет о случаях, когда вы можете себе позволить держать все в памяти.
кэш в базе не просто таблица, а также индексы, и поиск данных идет с помощью индексов(при правильной организации данных, их индексирования, правильного составления запроса)
Именно по-этому кеш бд и является настолько неэффективным.
Именно по-этому кеш бд и является настолько неэффективным.ты об это разрабам mssql, mysql, oracle скажи, научи уму-разуму, а то пишут всякую фигню, обманывают народ…
А ты хоть знаешь для чего индексы нужны?
Какая разница оптика или не оптика? Сама отправка запроса по сети уже работает дольше, чем запрос к кешу в памятиСама жизнь яяляется признаком смерти…
Естественно, речь идет о случаях, когда вы можете себе позволить держать все в памяти.гы-гы-гы
когда твоя «база» — один хэш и все — это твоя область деятельности?
ты об это разрабам mssql, mysql, oracle скажи, научи уму-разуму, а то пишут всякую фигню, обманывают народ…
Они-то в курсе обо всем, им ничего говорить не требуется.
гы-гы-гы
когда твоя «база» — один хэш и все — это твоя область деятельности?
Ну, какбэ выше и обсуждалось, что в таких случаях, когда (… оговорки… и можно делать выборку из памяти) то быстрее не общаться с сервером БД. Вы влетели со своими «разоблачениями» без учета оговорок.
Выборка из памяти — это не работа сданными.
если вы посмотрите планы выполнения запроса — то увидите, на что влияют индексы и во сколько раз они сокращают выборку данных.
и приплетать свои оговорки — это просто не профессионально.
Непрофессионально — не исходить из заданных критериев, чем вы и занялись.
если вы посмотрите планы выполнения запроса — то увидите, на что влияют индексы и во сколько раз они сокращают выборку данных.
Вы опять не учитываете указанные оговорки и спорите сам с собой о чем-то своем. Удачи.
со своей выборкой вы не опередите работу базы со всеми сопутствующими ей затратами.
Конечно же, опередит. Он получит результат еще до того, как ваш запрос до базы дойдет.
Я не об административном, когда решил заказчик или начальник. Собрались разработчики и решили, что c ОРМ проект быстрее запустится и проще его будет поддерживать и развивать. Ну или единственный разработчик, который хоть знает об альтернативах так решил :) А за использование всей мощи СУБД придётся заплатить усложнением поддержки, замедлением (ну или удорожанием) разработки, усложнением развёртывания. Конечно это всё можно обосновать красивыми словами, но с точки зрения кода (а не его эффективности) это глупо :)
За неиспользованием все мощи субд придется заплатить масштабированием
Можети привести пример как вы платите масштабированием за хабирнейт? Хабернейт это всего лишь дополнительная нашлепка, которая помогает замапить данные в объекты. Т.е. если у вас бэкэнд на жаве, с большой вероятностью вам и так придется это делать, а с хабернейтом код просто будет чище.
потому как для него надо много классов/файлов для простого изменения
Ну как бы нет, если у вас много кассов/файлов в изменении, то значит это уже не простое изменение. Т.е. опять если вы мапите результат квери в жава объекты без хабернейта, то изменения в базе спровоцируют изменения в коде, причем изменения как в коде мапинга так и в объектах, а с использованием хабернейта только в объектах.
P.S.
Понятное дело, что за использование универсальной библиотеки вы всегда немного платите производительностью, но если на этом зацикливаться так можно и на с++ все писать. Когда я только начинал с хабернейтом, я тоже от него плевался по началу. Но после того как я в нем разобрался он оказался не так уж и плох.
Для запросов и их результатов ORM подходит куда меньше, хотя бы потому, что не позволит просто так пойти и высчитать среднее, бегущую сумму или какой-нибудь изврат с оконными функциями — а это обычно самые интересные данные с точки зрения заказчика.
bulk import благо не самая распространенная задача. Да и для конкретного кейса можно придумать что-то поинтереснее.
В целом ORM нужны там где у вас OLTP (OnLine Transaction Processing). То есть берем чуть-чуть данных (агрегат, границы бизнес транзакции, DDD), делаем с ними что-то и записываем.
Чтение и т.д. — для этого проще делать отдельно выборки через SQL. Тут не только с точки зрения производительности сколько с той точки зрения, что модели данных для чтения и записи нужны обычно разные.
Собственно вы сами в конце про разделение представлений говорите.
прежде всего избегание vendor lock
то есть мы избегаем лока от одного вендора за счет лока на другого вендора (Надеюсь вы не пишите свои ORM).
Задача ORM не абстракцию от базы вам предоставить, а мэппинг данных организовать, из реляционной модели в ваши in-memory структуры. При этом у вас может быть тотальная завязка на нюансы конкретной СУБД. Дальше все больше про разделение ответственности (изменения персистенса не должны влиять на бизнес логику, но думать что при смене СУБД вам код не придется писать — глупо).
как версионирование и развертывание.
на самом деле нет. Все это тоже можно мигрировать и версионировать, и обратную совместимость схемы между деплоями никто не отменял (потому что вы не можете абсолютно одновременно, без даунтайма выкатить одинаковые версии схемы и кода)
Плюс требуют от разработчика дополнительных компетенций
Если подумать то объем знаний необходимых для работы с каким-нибудь nhibernate сопоставим с объемом знаний для работы с процедурами. Да, это сильно разный опыт, и стоит ориентироваться на рынок труда (а он такой что я ни тот ни другой вариант бы не доверил большинству)
в каких-то весьма высоконагруженных приложениях.
Обычно оправдание — тотальное разделение ответственности и контроль за данными, секьюрити политики и т.д. Производительность — сомнительный довод. Да и процедуры будут ограничивать вас по горизонтали (хотя кто его знает).
p.s. Если что — принципиально не использую процедуры/тригеры для бизнес логики и пока не встречался с юзкейсами где это все дает очевидные преимущества. Но полагаю такие кейсы есть. Не подумайте что я там фанат таких вещей.
но это внешний компонент
Почему? Можно ли воспринимать скажем версию JVM как "внешний компонент"?
У меня вещи типа база данных это внутренний компонент. Я поставляю код как готовую инфраструктуру (предположим через докер). И я регламентирую что нужно для того что бы код работал.
У меня был один кейс когда мне была выгодна смена субд прозрачная — у заказчика был тот самый вендор лок на оракл, и ничего другого они юзать не могли. И выяснилось это через 3 недели посте старта проекта. Но там и проект примитивный.
Так что нет, сегодня завязка на конкретную СУБД это данность на хоть сколько нибудь серьезном проекте.
Вы же не переживаете что выбрав определенный язык программирования вы как бы тоже создали себе вендор лок?
Задача ORM — реализовать слой абстракции в виде хранилища объектов с реляционными отношениями между ними.
Тогда было бы не O/RM (Object-relational mapping) а Object-Relation Abstraction какой. Задача ORM — исключительно мэппинг одного в другое. И при том что две эти модели данных (основанная на реляциях и ваши in memory структуры) сильно различаются, то и мэппинг мы можем сделать в ограниченном наборе сценариев (всему виной такая вещи как референсы, которые выражены сильно по разному)
Хм… я могу одновременно задеплоить разные версии воркеров, которые будут реализовывать разние версии API
это как UI, попробуйте такое с бизнес логикой провернуть. И не важно будет в тригерах она или в коде. Ну либо ваши две версии воркеров должны реализовывать совместимость на уровне бизнес процессов. Что как бы… можно провернуть и с тригерами.
но я не вижу способа задеплоить одновременно несколько разных версий SQL-триггрер.
Я не вижу необходимости в этом. Но вообще зависит от вашей СУБД. В PostgreSQL подобное можно хитро замутить со схемами.
А в чем тут проблемы с ORM? Вовсе не обязательно, чтобы все пользователи ходили к СУБД под одним пользователем.
Это больше про загоны с отслеживанием изменений. Ну знаете, есть задачи в рамках которых изменение одного символа требует проверки со стороны каких-то контролирующих органов. А потому вам хочется вот это что-то очень изолировать от всего дабы менялось пореже и не влияло на циклы релизов.
Такое можно и с кодом провернуть (здрасте микросервисы).
Тот же Highload
Я уже упоминал тут что в хайлоад врядли тригеры и процедуры хорошо ложатся ибо вы ограничиваете себя скейлингом по вертикали. Горизонтальный уже сложнее.
На всякий случай повторю, а то может быть вы не заметили — я НЕ использую тригеры и процедуры для бизнес логики и категорически против этого на своих проектах. Опять же я категорически против так же называть ORM "решением всех проблем", есть и другие способы дела делать.
Чем меньше зафиксированных зависимостей пришлось затащить в проект — тем лучше.
Меня не покидает ощущение что мы говорим о разных вещах. Что бы небыло недопонимания, давайте так.
Вы согласны что зависимость все равно есть? А это значит что мы не можем просто поставить "другую субд" и все будет гарантировано работать, то есть может потребоваться дополнительная работа.
Ну или расскажите про свои проекты. Ибо я не могу вспомнить ни одного проекта где мы гарантировали бы стабильность работы софта при смене скажем postgres на mysql.
У вас вообще нет контроля за окружением? Коробочные решения? Десктоп? Просто это довольно важно понимать, ибо задачи могут быть чуть другие.
Я просто не очень верю в волшебное "зависимости есть но я могу махнуть палочкой и вжух уже имплементация другая". То есть да, изолировать зависимость — понимаю и согласен. Но ORM — это не про "устранение зависимости от конкретной базы", это не ее первоочередная задача. Абстракцию вы уже сами делаете (шаблон Repository например).
Что мешает работать и тем и другим параллельно?
ничего, просто два процесса. И да — формирование email-а это представление. Независимый процесс. Запускайте сколько хотите. А вот если ваш "коркер" бизнес процессы будет разруливать, то вам уже важно что бы бизнес процессы реализованные в версии 1 и версии 2 были совместимы.
Что мне мешает запустить комплект новых воркеров
А что мешает добавить код в имеющийся воркер что бы тот сам стал считать в нужный момент по другому? У вас же по любому будет какой-то код который будет принимать решение какому из воркеров трудиться когда. Или вы руками планируете переключать?
Ради суперзадачи "использовать триггеры во что бы то ни стало?"
Нет, просто я не очень понимаю зачем может понадобиться две версии одного тригера одновременно выкатывать. Два тригера. Или две процедуры. Если очень хочется.
Пример со схемами — просто говорю что есть механизмы. Если говорить не про тригеры и процедуры, а просто про схему базы, то оно вам и с ORM поможет (удобно при zero downtime. Как пример можете глянуть как вот тут делают).
Вот как раз тут через ORM все чудесно решается.
речь идет не о тех изменениях. Это про изменения логики/кода.
Через Entity lifecycle events.
если вы вешаете на них бизнес логику — сочувствую тем кто будет поддерживать ваш код в будущем. Эти вещи предназначаются для персистенс логики всякой веселой.
т.к. отслеживание изменений в ORM обычно из коробки
Только если ваша ORM имеет внутри unit of work. Это маленький процент ORM и в целом они обычно очень сложные. Не ну как, если понимать что магии там нету и разбираться как оно работает)
Я в последнем проекте просто кидал сообщение в менеджер очередей
А у меня вообще event sourcing
в PostgreSQL в триггкре доступна информация о пользователе, выполнившем транзакцию
Тригер будет запущен из под того же пользователя, из под которого идет подключение. Ну то есть соответственно помимо тригера вам надо будет еще аутентификацию на пользователей СУБД перевести. А вот это уже оч херово скейлится.
Скажем у меня на проекте HIPAA и мне нужно не только трекать кто чего подправил, но и кто чего посмотрел. Настолько что мол мне надо трекать кто в какое время в результате поиска каких пользователей увидел.
Подобное я ни в коем случае не буду делать ни на тригерах ни на ORM. У меня сверху подсистема которая коллектит ивентики эти и потом балк инсертом записывает.
и можно ли к каким-то внешним службам обратиться, типа RabbitMQ или Redis?
Там есть notify через который можно замутить pub/sub. Например — штуки типа postgraphile используют для того что бы апдейты на клиент в сокеты пихать.
Но они что, правда не работают в кластерах и при шардинге?
Тут больше вопрос в бизнес логики и можно ли эту логику на шарды разбить.
Опять же, у меня опыта такого тоже нет, просто из всех проектов которые приходилось видеть основной юзкейс был именно в том что бы жестко ограничивать доступ к данным (когда самое критически важное лежит процедурами, все данные жестко разбиты какими-нибудь row based security и т.д.). Ну и те же микросервисы, где можно ввести те же ограничения, уже могут выйти дороже. Но опять же всякое бывает. Иногда критически важную подсистему можно выделить отдельно и будет как бы монолит + внешняя система которая не меняется без согласования с контролирующими органами (какие-нибудь PCI DSS)
Подозреваю что вы пользуетесь либо Доктриной либо Чем-то вроде гибернейта, ну тогда в целом мы используем одни и те же инструменты.
разница лишь в том что вот все эти «богатства» это про persistence а не про бизнес логику. И да, я помню как я сам завязывал на всякие вычисления чейнджсетов бизнес логику — это прямая дорога в ад на любом маломальски сложном проекте.
Ну и еще раз — вы сами предлагали посмотреть на вещи «по другому». Например — event sourcing вполне себе компромисный вараинт, который позволяет вам крутить вертеть вашей моделью данных как угодно.
ORM и DBAL не синонимы и не вложенные множества. Отсутствие vendor lock в случае универсальной ORM лишь бесплатній бонус, если вам нужен маппинг, и огромній оверхид если нужна абстракция от диалекта SQL.
Что опять же подразумевает сеньорские знания в случаях отличных от самых тривиальных :)
ORM — она (он?) такая же реляционная как СУБД под ней.
реляционная в смысле орудует реляционной алгеброй (ну там картежи данных, предикаты) или в каком смысле вы употребляете это слово?
Должен ли это понимать джун? Я думаю да.
Понимают ли? думаю нет. Для подавляющего большинства джунов ORM это волшебная коробка которая просто работает. Более того — это довольно распространенное мнение. Вот выше тоже вещают про то что ORM это абстракция от базы. А если оно абстракция — значит про базу знать не обязательно.
которые отрабатываются по уже загруженным данным
и джойны там есть? Или чисто проверка условий? Ну мол реляционная алгебра это все ж чуть интереснее чем фильтрация коллекции.
Опять же — главное пожалуй отличие — отсутствие ссылок и возможности однонаправленные one-to-many связи делать (у вас на стороне many fk что делает его зависимым от one)
Ну и за счет всех этих нюансов и появляются кучи плюшек по оптимизации. А так можно просто key-value хранилище сделать и индексы строить, никто не мешает. Объектно-ориентированные базы были, сейчас вот есть документно ориентированные (или мой любимый объектно/реляционный постгресс)
но это все через корень агрегата идет. То есть в целом — можно заменять реляционную базу на документно-ориентированную и получить в целом такой же результат.
> ну ORM — это все же не RDBMS
прикол то в том что если у вас есть RDBMS то ограничения этой модели будут просачиваться сквозь вашу ORM (если она общего назначения, типа гибернейта). Те же one-to-many там кастылем разруливаются, что бы эмулировать однонаправленность связи.
забавные штуки, которые позволяют строить запросы, которые отрабатываются по уже загруженным данным
Расскажите подробнее, пожалуйста. Какие группы запросов поддерживаются — произвольные, или только фильтрация по PrimaryKey? Если произвольные запросы, то чем обеспечивается доказательство, что из базы уже всё прочитано в память, и в базу лезть не требуется?
Просто если здесь только фильтрация по PrimaryKey, то такие штуки по факту являются банальным кэшем, и ввиду этого абсолютно не забавны. А вот если там поддержка произвольных запросов (и не просто кэширование результатов) — то это да, интересно неимоверно.
А если в запросе при этом есть сортировка по соседнему атрибуту, то кэш я вообще не имею права использовать (исключение — кеш содержит результаты запросов по ключу из текста самого запроса, и даже в этом случае не всегда).
Да, это может работать если клиенту возможно скармливать данные по кускам, как, например, Flux<T> в реакторе. Тогда при запросе можно быстро выдавать из кэша что есть, и если этого не хватило — выдать уже из базы данных. Так можно сильно уменьшить время первоначального отклика на запрос, если отклик на запросы клиентов часто содержит повторяющиеся данные.
К сожалению, плохо будет работать сортировка — в общем случае, в любой момент остаётся шанс, что в базе находится некий элемент, который по данному критерию ниже, чем начало кешированной страницы.
Промышленная разработка софта отличается от идеальной разработки софта. Решения принимаются в различных условиях и всегда с неполными данными. Грамотная архитектура недостижима, когда приходишь в проект в любом случае видишь говно.
Пример с БД и бэком может быть обусловлен тысячей причин, начиная с "спроектировали БД, потом появились новые требования" заканчивая "для возможности будущей миграции с SQL на NoSQL (или наоборот) принято решение вынести логику на уровень Бэка".
То же самое с фронтом: ВК например отправляет через AJAX на фронт сразу куски готового HTML, в то время как стандарт — это JSON. Даже если условия изменились, и сейчас какое-то решение выглядит глупым, вполне возможно что оно принято в других условиях и сейчас это тупо ДОРОГО переделывать.
Глупость кода, таким образом, в 95% случаев не глупость, а стечение обстоятельств, недостаток рефакторинга и ошибки в архитектурных решениях, принятых в условиях дефицита информации, которых было невозможно избежать. А в оставшихся 5% случаев допускаются как "фулстеками" так и "частичниками".
И кстати, опять же с точки зрения архитектуры, "частичникам" гораздо проще сохранить консистентность слоев. Если ты знаешь свои границы — через них так просто не перейдешь.
А вот если ты пишешь сверху донизу, то вот тут как раз очень просто поместить логику "не туда", куда ты поместил аналогичную логику в прошлый раз. Да, может быть это дает какой-то эффект, но убивает архитектуру кода и ее консистентность.
Когда знаешь свои границы…, но чаще бывает важнее знать что и где выгоднее выполнить. Это важно ещё на стадии разработки.
Вот упоминание json… все считают стандарт… но это лишняя, как минимум двойная работа. Ajax — даже на новые разработки его втыкают, когда уже есть websocket.
Дорого переделывать — а кто оценивает? фуллстек? или «узкий специалист»?
Судя по вашему комментарию вы очень далеки от процессов разработки софта, я уж не знаю как:
В любом Agile окружение "разработка" и "поддержка" трудно отличимы после первого же цикла, а после MVP это вообще уже одно и то же.
Никогда не "выгоднее" выполнить что-то не там где надо, потому что с кодом работают люди, и им надо писать его так, чтобы можно было его поддерживать. Иначе бы все в мире писали на ассемблере, потому что это "очень выгодно".
json — лишняя, двойная работа? Вы о чем вообще??? Ajax заменяется веб-сокетом? Серьезно?? Наверное именно поэтому в GraphQL спецификации есть И Ajax И websocket? Я уже молчу о том, что по вебсокету обычно все передают json...
Дорого переделывать — обычно оценивает бизнес. Потому что он платит деньги. И это важно понимать любому разработчику… Если говорить про конкретных людей — CTO, Архитектор, ТехЛид, ТимЛид. Люди с кругозором на весь используемый стек.
json — лишняя, двойная работа
1 Преобразование данный в json
2 Пребразование json в html (рассматриваем веб проекты)
все это можно заменить на сервере простым «серверным рендерингом» преобразованием данных а hyml. на клиенте html строка вставляется в дом 1 строкой кода.
Ajax заменяется веб-сокетом? Серьезно??элементарно на все 146%, без всяких проблем, что и делаю с момента появления websocket, без использования ajax.
Я уже молчу о том, что по вебсокету обычно все передают json...Очень важное слово «обычно»,(раньше обычно ездили на телегах...) можно просто передать html, будет просто и наглядно и быстро. Я видел как запаковывают html в json вместе с другими с другими данными, но это отрыжка из прошлого, когда использование ajax требовало режима запрос-ответ, т.е. на один запрос только один ответ. Технология websocket позволяет отойти от этого. Чем я и пользуюсь.
Мало того, websocket позволяет снизить нагрузку на сервер. позволяет отображать данные в реальном масштабе времени. Есть проекты где по ws предаются данные с arduino, пишутся в базу и отображаются в виде бегущего графика у клиента, и все это в реальном времени с минимальной нагрузкой на сервер…
2 Пребразование json в html (рассматриваем веб проекты)
В большинстве новых проектах на "хайповых" технологиях преобразования в html нет, преобразование идёт в DOM
В большинстве новых проектах на «хайповых» технологиях преобразования в html нет, преобразование идёт в DOMне будь голословным приведи варианты этих хайповых технологий
не будь голословным приведи варианты этих хайповых технологий
React, Angular, Vue, KnockoutJS, Svelte, Ember… Честно говоря практически всё, что вы только сможете найти в области SPA. При этом oldschool подход формирования кусочков HTML на стороне backend продолжает использоваться в более простых задачах. Чем проще продукт, тем меньше ему нужно заморочек с frontend. Большая часть вебсайтов в сети будут себя прекрасно чувствовать вовсе без JS, используя только HTTP + HTML + CSS + JS.
.innerHTML='html_строка_таблицы'
Очень странно, что вы умудряетесь совмещать в своих проектах такие вещи как WebSocket (штука крутая, но нужна оооочень ограниченному числу проектов) и .innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.
React, Angular, Vue, KnockoutJS, Svelte, Emberэто всё фантики, я же просил код, пример.
штука крутая, но нужна оооочень ограниченному числу проектовэто просто потому что многие не умеют её готовить. проще по-старинке ajax…
.innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.а что тут такого? на сервере готовлю html строку и на клиенте вставляю, просто, быстро, наглядно. Есть что-то более проще — воспользуюсь.
это всё фантики, я же просил код, пример.
Что именно вас интересует? Внутри этих библиотек используется DOMAPI (appendChild, createElement, setAttribute & etc...). Вам ссылку на MDN? Или ссылку на те места где эти методы используются в недрах этих библиотек? Или ссылку на те места где вы их руками в своём коде пишете? Если последнее, то в том то и суть, что руками вы это пишете только совсем уж в исключительных случаях. Библиотека\фреймворк делает это за вас в оставшихся 99%. Вы работаете над данными и взаимодействиями между ними.
это просто потому что многие не умеют её готовить. проще по-старинке ajax…
Нет. Полным полно людей умеющих готовить WS. Да и библиотек хватает (socket io, atmosphere, ...). Просто не нужно оно в 95+% случаев. Это один из множества инструментов, который вы приняли за серебряную пулю.
а что тут такого?
Ничего плохого в использовании каменного зубила нет. Просто непродуктивно это для больших и сложных frontend-проектов. Поэтому уже больше 5-и лет для сложных задач используют различные реактивные вещи. Правда более простыми я бы их не назвал, погружаться в эти технологии придётся долго и трудно. Это существенный пласт знаний, без которых сегодняшняя разработка серьёзных фронтенд приложений просто немыслима (ооочень дорого).
По сути это всё настолько объёмный пласт знаний, что по первой это может вызвать кровоизлияние в мозг. Шучу. Все эти webpack-и, babel-и, JSX-ы, React-ы, PostCSS-ы и тысячи других баззвордов — это реалия современного фронтенд рынка.
(appendChild, createElement, setAttribute & etc...)это всё теже перепевы innerHTML, и конечно я их использую в тех местах где нужно, innerHTML я привел как самый элементарный, показательный вариант.
Нет. Полным полно людей умеющих готовить WS. Да и библиотек хватает (socket io, atmosphere, ...). Просто не нужно оно в 95+% случаев. Это один из множества инструментов, который вы приняли за серебряную пулю.это хорошая новость., что есть люди, умеющие их готовить, но для меня это не серебрянная пуля, просто это универсальная технология позволяющая полностью заменить ajax, и отказаться от множества поддерживаемых технологий.
Для меня это элементарный механизм, как и хранимки, поэтому я считаю это одним из простейший кирпичиков для построения систем.
это всё теже перепевы innerHTML, и конечно я их использую в тех местах где нужно, innerHTML я привел как самый элементарный, показательный вариант.
Вы их используете. А мы нет. В этом суть. Мы не орудуем каменным зубилом. Им орудуют используемые нами инструменты. Это сложно объяснить в двух словах.
P.S. Ну и есть огромная разница между innerHTML= и производительной работой с DOM.
Ну и есть огромная разница между innerHTML= и производительной работой с DOM.
Не флейма ради, а объективности для: разница есть, в разы. В IE (включая 11) и Edge* innerHTML = ... гораздо быстрее appendChild. В WebKit с точностью до наоборот.
Всплакнём, господа гусары...
* По данным на год или около того назад, с тех пор не проверял.
nohuhu речь идёт о другом. О том, что innerHTML заменяет весь DOM-блок целиком. А современная тенденция заключается в переиспользовании существующего DOM-а. Т.е. с одной стороны весов у нас полное удаление и пересоздание всего звена, а с другой — добавить новое, поправить существующее, убрать лишнее. Я об этом.
github.com/JonHappy/JonHappy.github.io/tree/master/inner
в консоли сравните время
во сколько раз отличается мой innerHTML= и ваша «производительная работа с DOM. „
GEThttps://jonhappy.github.io/inner/хром
[HTTP/2.0 304 Not Modified 56ms]
t1: 3мс inner:46:13
t3: 4мс inner:51:13
t2: 11мс inner:81:13
t1: 3.31298828125ms
t3: 13.749267578125ms
t2: 65.237060546875ms
для сервера формировать html и json — затраты одинаковые
для клиента — есть разница и по времени и по количеству кода.
И есть еще одна ерунда: код выполняется в среде, которую вы не контролируете. Так что даже преимущество по скорости конкретной низкоуровневой реализации не гарантируется. Скажем, выкатил Google крупное обновление для Chrome — и ой. С них станется, я помню, они как-то раз системные select'ы сломали (все жутко тупило и жрало ресурсы без всякого JS). А фреймворки как раз нужны еще и для того, чтобы не думать о всевозможных подводных камнях и особенностях конкретных версий конкретных браузеров на конкретных системах. И не заниматься занудной работой по воспроизводству экзотических багов. Да, в абсолютных цифрах это решение, возможно, не будет «быстрым, насколько только возможно». Но оно будет оптимальным по стоимости, поддерживаемости и, в том числе, быстродействию. А на низкий уровень надо лезть, только если на быстродействии поставлен отдельный акцент и когда проблемы с ним действительно заметны.
во сколько раз отличается мой innerHTML= и ваша «производительная работа с DOM. „
Так вы ж неправильно "производительную работу с ДОМ" делаете. Надо менять существующие ноды, а не создавать новые.
BigDflz, по ссылке я вижу бенчмарк, который сравнивает поэлементное создание цельного куска DOM двумя способами. При этом innerHTML= в 3-4 раза быстрее. Как это согласуется с тем, что я писал выше? Нормально согласуется, так и должно быть. А что должно быть в вашем бенчмарке, если предположить, что вы в коем веке начали прислушиваться к тому, что вам пишут? Должно быть сравнение, скажем единичного setAttribute(td, value) и цельного innerHTML = tableHTML. Т.е. сравнение одной крошечной операции и одной крайне тяжеловесной. Бенчмарк при этом не нужен, т.к. очевидно, что 1 точечная операция будет легче на несколько порядков. Именно это и есть производительная работа с DOM. Не формировать цельные куски DOM-а "руками", чтобы "наверняка" покрыть все изменения разом, а обновлять точно и по месту, ровно то, что нужно обновить. Причём не "руками", а автоматикой.
И что характерно, я ведь об этом писал вам в личку, писал сюда, даже ссылки приводил, что почитать. Но вы упорно гнёте свою линию, считая, что мы не понимаем вас, и не слушаете, что пишем мы. Какое-то одностороннее общение.
BigDflz не надо писать мне в личку. Я уже просил вас перестать это делать.
Вы серьёзно считаете, что я настолько глуп, что для того чтоб сменить атрибут буду использовать innerHTML? У меня в голове не укладывается, как можно спутать области применения innerHTML и setAttribute(td, value)…
Я заметил, что в вашей голове очень многое не укладывается. Не только это :)
P.S. я понимаю, что с каждым вашим комментарием у всё меньше и меньше прав на хабрахабре, и есть ограничения на комментарии. Но я тот тут причём?
И снова мне в личку пишет наш неутомимый товарищ:
из-за того что на хабре нельзя высказывать и защищать своё мнение, из-за минусующих…
не хотите чтоб в личку — не минусуйте, дайте высказываться открыто.
Ух. Какой-то хабра-терроризм :) Призываю Boomburum
To BigDflz — карму всегда можно обнулить (вкладка reset в настройках профиля, правда, воспользоваться можно лишь однажды).
это всё теже перепевы innerHTML,
Это не перепевы, это прямой способ формировать DOM. А innerHTML — это способ запустить парсер, который распарсит строку и сделает из неё DOM. Концептуально ничем не отличается от json, разве что парсер куда-то проще.
Особенно учитывая то, что шаблонизаторы BigDflz тоже не использует и рендерит html конкатенацией :) Ну тут сильно запущенный случай, я не думаю что есть смысл что-то объяснять.
не думаю что кто либо в библиотеках это используетесли не думаешь, не стоит об эом писать. innerHTML такой же метод как и appendChild, createElement, setAttribute & etc..., только он меняет полностью содержимое родителя, а не часть его. то что я делаю из кода — можно элементарно сделать и из консоли браузера. Если посмотришь внимательно что делают известные fw — то увидишь, что они так же используют «серверный рендеринг», только из-за свойст ajax посылать один ответ на запрос пакуют в json сформированную (отрендеренную) на сервере html строку и дополнительный (при необходимости ) набор данных.
что шаблонизаторы BigDflz тоже не использует и рендерит html конкатенацией :)да будет известно, что под фантиком шаблонизации скрывается та же самая конкатенация. А так называемый рендеринг html (серверный рендеринг) ни что иное, как формирование html строки путем конкатенация строк, содержащих тэги html и пользовательских данных.
Для ознакомления что может javasript делать прошу ознакомиться learn.javascript.ru/search/?query=%D0%B2%D1%81%D1%82%D0%B0%D0%B2%D0%BA%D0%B0&type=article
Если послать клиенту json с данными, то необходимо преобразовать сначала в в какой-либо массив/объект, а потом из него в цикле произвести вставку поэлементно в dom, либо сформировать туже строку html и её вставить через innerHTML.
Ваши ангуляры и прочие фантики ничего другого не делают.
По быстродействию — для сервера равносильно что формировать json или html — и то и другое работа со строками, их конкатенацией, скрытой под фантиком шаблонизации или простым сложением строк.
На клиенте же есть разница — простая вставка inerHTML(или ей подобные) или преобразование из json в объект, а потом уже из объекта в inerHTML(или ей подобные)
Ваши ангуляры и прочие фантики ничего другого не делают.
Вы несёте полнейшую чепуху, и похоже не имеете ни малейшего представления о том, как работают все эти "фантики". Ей богу, ну прекратите. Это ж даже не смешно. На дворе 2018г.
перечисли что может ангуляр, и не может js?
Я с вами на "ты"? С каких пор?
Вопрос в высшей степени нелепый. Angular это JS фреймворк. Он на нём написан. Вопрос просто не имеет смысла.
Комментарий выше был про то, что все эти фантики работают на стороне клиента и никаких строчек в HTML не склеивают. На стороне JS нет необходимости формировать HTML из строк. Работа происходит на уровне объектов.
Серверный же рендеринг этих фантиков — явление достаточно редкое. Там тоже работа внутри "фантиков" происходит с объектами, а не строками. Строка собирается уже из объектов на самой самой финальной стадии. И это всё скрыто от разработчика в недрах библиотек.
А так называемый рендеринг html (серверный рендеринг) ни что иное, как формирование html строки путем конкатенация строк, содержащих тэги html и пользовательских данных.
В конечном счёте, если речь идёт именно о серверном рендеринге (который зачастую отсутствует как класс), то да, сборка итогового HTML это сборка строки, которая отправляется клиенту назад по HTTP.
Однако, имеет существенное значение, как эта строка была сформирована. Если вы эти, пардон, руками формируете, склеивая строки в вашем коде явным образом… пример:
<div class="<?= htmlspecialchars($type.$some) ?>"><?= $title ?></div>, то это привет каменный век. Мезозой. Если же у вас там какой-нибудь шаблонизатор, то вы ни строчки конкатенации сами не пишете. Вы используете дополнительный готовый уровень абстракции, который значительно упрощает работу, уменьшает количество багов, повышает уровень безопасности (большая часть XSS отпадает, как класс).
Шаблонизаторы внутри себя эти самые строчки и склеивают, да.
Правда я ещё раз сделаю акцент на том, что раз уж мы говорим про AJAX, WS и прочее, то у нас, как правило, почти всегда, нет никакого серверного рендеринга. Совсем. Вот прямо ни строки. Сервер передаёт нам только данные. А с HTMLDOM работает уже клиент (JS). И клиент никаких строчек не склеивает, т.к. незачем. У нас ведь есть DOM и полноценное API к нему. И даже этими методами мы не пользуемся почти, т.к. это делает дополнительная прослойка — фреймворк.
Более того, может отсутствовать классический шаблонизатор типа PHP :), а на стороне сервера собираться поэлементно полноценный DOM (или virtual DOM), который рендерится в "outer/innerHtml"
Оказалось, что наш друг вовсе не PHP-ер, он JAVA-ер, и конкатенирует HTML "руками", за счёт огромной портянки цепочек .append(anything). Код вида:
StringBuilder s = new StringBuilder();
s.append("<div ").append(" id='").append(id).append("'><span>").append(/* и так далее */);Собирает такие кусочки HTML на сервере по любому поводу (по сути любое изменение DOM) и отправляет на клиент через webSocket-ы (прямо как есть, строкой), а на той стороне jQuery-like портянка с innerHTML. Мотивация: все эти фреймворки очень медленные, а у меня вот как всё быстро и удобно. о_О. И это на задачах в стиле "вывести редактируемую табличку на корпоротивном сайте" (не какой-нибудь hyper-high-load).
habr.com/company/ruvds/blog/339148
medium.com/devschacht/peter-chang-break-down-isomorphic-and-universal-boilerplate-react-redux-server-rendering-8fd0ec4a8512
ru.stackoverflow.com/questions/528390/%D0%97%D0%B0%D1%87%D0%B5%D0%BC-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BD%D1%8B%D0%B9-%D1%80%D0%B5%D0%BD%D0%B4%D0%B5%D1%80%D0%B8%D0%BD%D0%B3-react-js-%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BE%D0%B2
var span = document.createElement('span');
span.className = 'dataspan';
span.id = v.id;
span.style.display = 'table';
var input = document.createElement('input');
input.className = 'chbx';
input.type = 'checkbox';
input.id = 'stateCheck' + v.id;
input.name = 'status';
input.checked = v.completed;предварительно распарсив json и сделав вставку в цикле(если это, к примеру, таблица).
а можно просто вставить готовую строку html таблицы
у сервера затраты на формирования json и html строки одинаковы. а на клиенте — намного разные.
куча вариантов вставки / построения элементов dom сделано для удобства его построения
При первоначальном рендере вставить кусок html по месту быстрее, чем делать это итеративно. Это правда. Это кстати одна из причин серверного рендера — пока на клиенте всё заведётся, можно ему уже готовый кусок кода подсунуть.
Вся соль в том, что эти "fw" нужны в динамических приложениях. Там где этот DOM постоянно меняется. Довольно сложным образом. И вот тут эти самые "поэлементные js циклы", будучи правильно организованными, уделывают innerHTML, кладут на лопатки. Потому, что переиспользуются уже существующие DOMElement-ы. Теперь их не нужно уничтожать и создавать заного на любое обновление. Система сама определяет что изменилось (js-циклами со сравнениями, да) и обновляет точечно. А так как практически любая возня с DOM просто адово тяжелее этих самых вами ненавистных js-циклов, получается, что обновить точечно только то, что изменилось на пару порядков быстрее.
Причина простая — DOM сам по себе ну очень тяжёлая абстракция. И почти всемогущий CSS ещё в большей степени его замедляет. Рендер этого DOM-а очень тяжёлая операция. Так называемый reflow это то, чего стараются избегать без особой на то причины. И т.д.
Вот выделите любой dom-element в древе и пропишите в консоли console.dir($0). Поковыряйте этот объект. Там просто бездна всего. Это очень тяжёлая штука.
- Сейчас всё чаще и чаще "первоначальная страница" лежит на сервере как статический файл
index.html. И какой-нибудьnginxотдаёт его как есть. Т.е. на сервере нет рендера от слова "совсем". - Сервера, за пределами этого nginx и пачки статических файлов может не быть вовсе. Ряду приложений он вообще не нужен.
- Если же сервер используется, то обычно для двух вещей: клиент запрашивает какие-либо данные, клиент просит сервер выполнить какое-нибудь действие.
- Ответ сервера не сводится к тому, чтобы обновить DOM. Серверу вообще не интересно как устроен DOM, где там что лежит и как устроено. Это отдано на откуп frontend приложению. А ему, приложению, нужны от сервера только данные.
- Frontend приложение не сводится к одному только обновлению DOM-древа. Это, зачастую, большие сложные штуки с грудой хитрой логики. Представьте себе любое сложное desktop-приложение. Вот это оно самое, только в web-е. Внутри frontend-приложения балом правят данные и взаимодействия основанные на этих данных. И только в самую последнюю очередь там заходит речь про обновление DOM-древа.
- На фоне всех этих задач — такие тонкости как JSON.parse и обработка DOM посредством DOM-API — это одна из самых несущественных задач.
- Эта несущественная задача виртуозно выполняется теми самыми фреймворками, которые вы так люто ненавидите. Они умеют обновлять только то, что нужно, а не целиком менять большие DOM-блоки. Это гораздо быстрее.
- В итоге задача программиста сводится не к тому, чтобы заморачиваться на DOM, а к тому чтобы грамотно организовать все эти потоки данных. Всю логику по их взаимодействую между собой. Часть результатов этих вычислений выливается в DOM. Часть в логику обработки eventHandler-ов. Ну и т.д… Задач в web-е нынче несчесть.
- Т.е., надеюсь, теперь вы понимаете, что эта ваша попытка сэкономить 3 байта и 3 наносекунды за счёт избегания JSON.parse и "циклов" — это полная нелепица. Большие сложные приложения имеют бутылочные горлышки совсем в других местах. И вообще frontend-мир устроен в 100 раз сложнее, чем привычная вам схема "гонять html строки с сервера на клиент".
- Вы можете подумать, что все эти уровни абстракций и сложности нафиг не нужны, и что "я уже многие годы делаю всё в 100 раз проще и всё хорошо работает". Но будете в корне не правы, т.к. вы просто не сталкивались с действительно сложными задачами, с конкретными ограничениями по времени, когда при вашем подходе вы за равное время дай бог 1/20 успеете сделать от требуемой задачи. Да и код ваш write-only. Его архитектура не выдерживает никакой критики в долгоиграющие динамично развивающихся проектах. Сразу в утиль.
Сейчас вы наверное начнёте всё подряд цитировать, писать про медленные gmail-ы, про протекающие абстракции, про то, что "из-за вас всё и тормозит" и прочее даратьянство. Но я прошу вас этого не делать. Постарайтесь хотя бы раз прочитать, что вам пишут "дутые пузыри".
для клиента разные.
2 не надо так критично заявлять иногда надо только данные. а иногда лучше для клиента получить готовое. Если я говорю о варианте вставки в dom- то это только один из множества вариантом.
моя попытка сэкономит миллисекунды выливается в сэкономленные минуты. Мне надоело сидеть перед оператором и ждать когда у него на экране появится нужная информация. а это встречается в 99. 9 случаях.
а по использованию fw — инет переполнен вопросами, как и что сделать на том или ином fw и скорость написания на них ни чуть не быстрее, зато время выполнения намного медленнее
- Да, страницы бывают разные. Я выше уже упоминал, что для большей части WEB-а JS вообще не нужен. Читайте не по диагонали, плз.
- Причина по которой вы ждёте перед оператором минуты никак не связана с fw, и никак не связана с сэкономленными миллисекундами. Вы, как программист, ну просто обязаны это понимать. Если нет — срочно за книжки.
- Кстати да, скорость написания на "fw", в вашем случае, будет намного медленнее. Всё так. Проблема тут именно в вас. Когда ничего не знаешь, ничего не умеешь, и не хочешь учиться ― это пряма беда-беда. Вангую, что когда вам всё таки придётся освоить тот же webpack + babel, вы будете волосы на голове рвать, громко материться на полквартала и кричать про то, какие все вокруг тупые и всё переусложняют. И, что характерно, отчасти будете правы.
а на той стороне jQuery-like портянка с innerHTML.вот когда не знаешь и не понимаешь — не надо писать, выставлять своё не знание предмета. Для того чтоб вставить html не надо jquery. нудно просто 1 (ОДНУ) строку чистого javascript.
Ваши wf делают тоже самое, только все заворачивают в кучу кода, прогуглите «серверный рендеринг» ,«server side rendering», SSR.
за счёт огромной портянки цепочек .append(anything). Код вида:если ты хоть что-то знаешь в java, это хоть и не очень «красивый» вариант работы со строками — но самый быстрый. И любой шаблонизатор это использует, только скрывает это за кучей лишнего кода.
BigDflz, приглядитесь внимательнее, я ведь написал jQuery-like, а не jQuery. Это потому, что никакой принципиальной разницы между domNode.appendChild и $(selector).append я в этом вопросе не вижу. Ручная работа с DOM.
Да и про StringBuilder и принципы его работы я в курсе. Я много про что в курсе, вы за меня не переживайте.
А упёртости у вас хоть отбавляй ;)
Я много про что в курсе, вы за меня не переживайте.я рад за Вас, о том, что Вы в курсе, вот только по высказываниям так не скажешь.
А упёртости у вас хоть отбавляй ;)«Упертость» — это так теперь называется защита своего мнения?
Создаётся впечатление, что многие причисляющие себя к синьёрам, просто мыльные пузыри. Которые используют fw, а что там у них внутри и понятия не имеют. Говорят о невозможности сохранять версий хранимок в гит, когда всё это давно реализуют админы этих субд, (бэкапирокание субд проработано досканально). Говорят о недостатках языка, тормознутости на примере своего написания и использования кучи лишнего…
говорят о портянке цепочек append, а сами, не понимая того, используют их в более ужасном виде в шаблонизаторах. Если б шаблонизаторы были написаны на ассемблере, я б ещё мог согласиться…
Ручная работа с DOM.Зато как это круто использовать fw, который в итоге сделает тоже самое, только за более большее время. времени на написание параметров для того чтоб fw сделал нужное будет больше чем просто написать работающую строку на чистом js.
mayorovp
И главное — придется забыть про хранимки в СУБД, ибо они не умеют в нормальные двунаправленные потоки данных :-)Вот когда в субд имеешь поверхностное знание — не надо делать такие заявления. Есть такое разделение для запросов — редактируемые и не редактируемые. Так вот большинство серьёзных запросов — не редактируемые. Используя хранимки — об не редактируемости можно забыть. Я могу изменить данные в любом наборе, и для этого не надо «двунаправленных потоков»
вот только по высказываниям так не скажешь.
Если читать по диагонали, то это всегда так ;)
«Упертость» — это так теперь называется защита своего мнения?
Скорее, в вашем случае, это попытка навязать своё мнение\оправдаться, будучи с закрытыми глазами. Как в том анекдоте — чукча не читатель, чукча писатель.
Которые используют fw, а что там у них внутри и понятия не имеют.
А также это богатое воображение. Ну вот я знаю как устроены, используемые мною фреймворки по капотом. Я стараюсь не использовать вещи, которые не понимаю.
говорят о портянке цепочек append, а сами, не понимая того, используют их в более ужасном виде в шаблонизаторах.
Вот яркий пример чукчи-писателя. Вы же просто не желаете понимать, что вам пишут. Зачем пытаться понять смысл тех вещей, которые вам пытаются объяснить? Главное ведь всем доказать, что вы д'Артьяньян, а мы мыльные пузыри?
Я знаю что внутри шаблонизаторов используется конкатенация итоговой HTML строки. Я знаю как устроен StringBuilder (знаю эту структуру данных и её асимптотику). Претензий ни к append методу, ни к самому StringBuilder я не имею. А вот к вашему коду, с его использованием имею. Вот только кажется, вам ну совсем не очевидно, что с ним не так и почему его не должно существовать в принципе.
<irony>Это, конечно же, потому, что вы не "мыльный пузырь". Вы не переусложняете простые вещи. И используете самые производительные подходы. Вы не ведётесь на хайповые "fw", как это делаем мы, дутые пузыри. Мы ведь не знаем, что внутри наших fw. Нам вообще бы дворы подменять, да вот не задалось. И gmail тормозит из-за нас.</irony>
Скорее, в вашем случае, это попытка навязать своё мнение\оправдаться, будучи с закрытыми глазами.Я не навязываю своё мнение — я его высказываю, и если кого-то пугает чужое мнение — не надо трындеть, что оно не правильное.
Ну вот я знаю как устроены, используемые мною фреймворки по капотом. Я стараюсь не использовать вещи, которые не понимаюЭто хорошая новость. Я надеюсь, что и многие здесь такие, Но почему поднялся хай, по поводу серверного рендеринга? Можно сделать вывод, что только потому что многие не понимают что там под капотом у fw.
А вот к вашему коду, с его использованием имею. Вот только кажется, вам ну совсем не очевидно, что с ним не так и почему его не должно существовать в принципе.Если можете предложить что-то более конкретное — готов выслушать, но думаете, что к такому виду пришёл просто так, написал с перепоя? и что я не знаю String.format?
Чем для вас отличается конкатенация строк, их сложение и шаблонизация? простой сишный printf("Hello %s", name); для вас что?
но думаете, что к такому виду пришёл просто так, написал с перепоя
Боюсь, что нет. Просто самоуверенность и невежество в вас превалирует над всеми остальными качествами.
Если можете предложить что-то более конкретное — готов выслушать
Увы, не готовы. По сути: требования к кодовой базе и требования к производительности программы это не одно и тоже. Кодовая база оценивается по целому ряду параметров. И в условиях асимптотически равного кода приоритет, почти всегда, сдвигается к вещам, завязанным на читаемость, расширяемость, безбажность, очевидность, тестируемость, безопасноть и пр. вещам. Вы, судя по всему, считаете что "быстрое решение" всегда лучше "медленного".
Это частая проблема многих новичков в программировании, которые ухватились за мантру "производительность", и старающихся применить её где надо и где не надо. По сути вопрос в правильных приоритетах.
Увы, не готовы.А готовность отрицать почему-то всегда на готовности номер Один.
а многие уцепились за мантру «быстро написать, а там хоть трава не расти»
Всё так, есть две крайности. Вы в одной, а те кедры, что пишут асимптотически катастрофический код, в другой. Кстати не стоит думать, что вы лучше их ;) Вы просто "другой".
Кстати вам знакомо понятие асимптотика? Вы можете рассказать, как построить хеш-таблицу? Можете написать про её производительность на чтение, запись, удаление. Про амортизацию? Про то как устроено простейшее бинарное древо поиска? Про sqrt-декомпозицию? Знаете алгоритмы на графах? Если нет, то вы зря кичитесь тем, что экономите миллисекунды, в мире, где всё тормозит. Вполне вероятно, что сэкономив 2 наносекунды в одном месте, вы потеряли 40'000 в другом. А ведь там ещё всякие кеш-промахи, всякие мудрые asm-вставки, и чего только нет.
Грубо говоря вопрос производительности штука весьма не тривиальная. Требует хороших познаний в computer science. И разработчик всегда исходит из каких-то компромиссов.
.innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.
посмотрите трафик VK и внимательно разглядите что там отвечает сервер как он работает зубилом
посмотрите трафик VK и внимательно разглядите что там отвечает сервер
Посмотрел, с аякс-запросов json он возвращает.
VK, Github, Redmine и многие другие проекты, из тех, что на слуху. В основном очень старые. Счёту им нет. У меня у самого полно проектов, где задействуется это зубило (тоже все старые). Сути это не меняет. Зубило неэффективно. Но порой его достаточно. Я выше писал, что 99% сайтов в сети вообще JS не нужен. Скажем тот же github пытается быть таким условным no-JS сайтом, когда JS используется для разного рода мелочей, но любая серьёзная операция сопровождается перегрузкой. Правда не вкладки, а содержимого страницы. В желании гонять по ws\ajax туда-сюда куски HTML и выставлять их через innerHTML вы не одиноки.
SSR. Отрисовка на стороне сервера
Server-side rendering your React app in three simple steps
Angular 4 with server side rendering (aka Angular Universal)
можно ещё перечислять…
а любой «серверный рендеринг» — это вставка через .innerHTML
похоже весь мир шагает не в ногу, один вы в ногу…
можете продолжать настаивать и хаять всех, кто с вами не согласен.
Я вижу что вставка через innerHTML работает быстрее, занимает мало кода на клиенте, очень наглядна.
и если старые проекты задействуют вставку через innerHTML, значит уже давно этот вариант имеет преимущества.
А старые проекты могут быть настолько старые, что во времена их молодости других вариантов особо не было, а теперь переписывать всё дорого и это единственное что удерживает.
Я показал, что вставка с использованием большого куска в dom с использованием innerHtml быстрее чем поэлементная, поатрибутная.
Вам уже нцать раз сказали, никто поэлементно дом не строит, обновляются только те ноды, что изменились. И обновить несколько нод — значительно быстрее, чем вставить через innerHTML сотню.
Если сервер передавал просто набор json — то он бы должен был содержать и сами тэги и данные для них, потому как вставляемый кусок известен только серверу.
Теги известны клиенту и без сервера.
И обновить несколько нод — значительно быстрее, чем вставить через innerHTML сотню.я показал пример как изменяется таблица через innerHTML и поэлементно.
Теги известны клиенту и без сервера.только не известно что и где будет расположено
если изменилось содержимое div, в котором была куча разных элементов, на новую кучу уже других элементов- вы тоже будите обновлять поэлементно?
Конечно, ведь это намного быстрее.
я показал пример как изменяется таблица через innerHTML и поэлементно.
Вы показали сравнение ручного создания нод и innerHTML. Сравните теперь как обновляется одна нода и как вставляется сотню нод через innerHTML — это и будет валидное сравнение.
Еще раз — никто не спорит, что через innerHTML ноды создаются быстрее, чем "руками". Смысл просто в том, что там где с innerHTML вы создаете много нод можно поменять всего одну вместо этих многих. За счет этого и происходит выигрыш.
только не известно что и где будет расположено
Как это неизвестно? Известно, конечно же.
Конечно, ведь это намного быстрее.поэлементно быстрее?
Еще раз — никто не спорит, что через innerHTML ноды создаются быстрее, чем «руками». Смысл просто в том, что там где с innerHTML вы создаете много нод можно поменять всего одну вместо этих многих. За счет этого и происходит выигрыш.вы хоть читаете о том что пишу? я разве хоть однажды сказал, что ради одной ноды я буду менять всё? если в диве меняется таблица — это что?
Как это неизвестно? Известно, конечно же.когда тот же VK вставляет инфу клиент не знает что там будет.
Ели вы динамически меняете содержимое дива — там может быть или картинка или таблица или ещё что…
поэлементно быстрее?
Поэлементно изменить один элемент — быстрее, чем построить сотню через innerHTML.
вы хоть читаете о том что пишу? я разве хоть однажды сказал, что ради одной ноды я буду менять всё?
В случае с innerHTML у вас нет выбора. Вам с сервера пришел какой-нибудь виджет целиком, вы его целиком вставляете, несмотря на то, что изменилась в нем одна нода. Естественно, вы можете с сервера прислать данные в json (или каком-то другом формате) для одной этой ноды и ее обновить. И тогда получится ровно то, как работают современные SPA-фреймворки.
Поэлементно изменить один элемент — быстрее, чем построить сотню через innerHTML.ну не держите оппонента за дурака. Где я такое утверждал?
В случае с innerHTML у вас нет выбора. Вам с сервера пришел какой-нибудь виджет целиком, вы его целиком вставляете, несмотря на то, что изменилась в нем одна нода.Это напоминает анек: Мужик пошел утром умываться-бриться, пока вода/бритва шумели, жена что-то спросила, что-то подумала, что-то ответила… В итоге из ванной он вышел уже разведённым…
Я показал пример, что и на что как меняется. Я просил посмотреть что передаётся в json в VK… кто-нибудь посмотрел?
Я знаю все команды, что и как вставить и заменить. И уж поверьте, если я фулстек — то смогу правильно перераспределить что и где проще/быстрее формировать.
Если у меня есть таблица со сложной структурой, то мне намного проще сформировать её один раз на сервере, чем сначала json из данных, а потом из json на клиенте сформировать эту сложную таблицу на клиенте, что я вижу во многих реализациях… Если проще заменить всю строку — я заменю всю строку.
Если проще заменить всю строку — я заменю всю строку.
А если потом окажется, что строку надо по-другому форматировать, например, выделить жирным шрифтом один из столбцов — пойдете исправлять отдачу бекенда? Норм, чо. Надежно.
А если потом окажется, что строку надо по-другому форматировать, например, выделить жирным шрифтом один из столбцов — пойдете исправлять отдачу бекенда? Норм, чо. Надежно.Вот сразу видно «опытного» прогера — в одну кучу смешивает и мух и котлеты. Таблица формируется в одном месте. И отображается в одном месте и если нужно исправить — правится в одном месте. Если у вас одна таблица отображается в нескольких местах — и вы для каждого места пишете код для её формирования — меняйте во всех местах.
только не надо путать понятие «изменить» — изменить код, и изменить значение/отображение в рантайме.
Табличка хтмл с сервера клиенту
Семейство методов для вставки HTML/элемента/текста в произвольное место документа:
elem.insertAdjacentHTML(where, html)
elem.insertAdjacentElement(where, element)
elem.insertAdjacentText(where, text)
изучайте что можно вставить/изменить
В таблице из десятка столбцов и сотен строк меняется одна ячейка — что за html у вас придёт на сервер?
по месту — я могу изменить весь элемент
<td>...</td>могу только отдельный атрибут, могу только текст с ячейке. А могу и всю строку. Надо смотреть конкретно в каждом частном случае. А будет проще — и всю таблицу заменю.
Таблица формируется в одном месте. И отображается в одном месте и если нужно исправить — правится в одном месте.
Ну то есть пойдете отдачу бекенда править?
по месту — я могу изменить весь элемент
Вас не спрашивали, что вы будете менять, вас спросили, что с сервера придет. Так что?
Ну то есть пойдете отдачу бекенда править?Для вас это проблема? Для меня — нет.
Вас не спрашивали, что вы будете менять, вас спросили, что с сервера придет. Так что?с севера может придти как строка html содержащая
<td>...</td><tr><td>...</td><td>...</td>..... </tr>А также и просто данные для замены чего-либо конкретного в этой ячейке. надо смотреть по конкретному случаю.
Для вас это проблема? Для меня — нет.
Конечно это проблема, ведь фронтенд-программист при вашем подходе не сможет жирным шрифтом текст выделить.
с севера может придти как строка html содержащая
Я верно понимаю, что если в вашей таблице 100 строк то вы делаете 100 запросов, каждый из которых возвращает одну строку таблицы, каждую из которых вы создаете отдельной нодой и добавляете? Или вы склеиваете эти строки и создаете потом таблицу цельной нодой? Или вы получаете с сервера всю таблицу одним запросом, а когда надо что-то поменять — парсите ответ сервера, смотрите что изменилось и точечно изменяете нужную строку? Какой из вариантов?
Конечно это проблема, ведь фронтенд-программист при вашем подходе не сможет жирным шрифтом текст выделить.а причём здесь фронтенд-программист? Я фулстек-программист. Я сам решаю, что и где проще сделать.
Ни один из перечисленных.
Как один из примеров: есть таблица при клике по строкам её — обновляется див, который содержит ещё одну таблицу. При клике на сервер отправляется некий id, по этому id хранимка выбирает данные (~35полей, N строк) по этим данным серверное приложение строит html строку всей таблицы и передает клиенту, клиент вставляет её через innerHTML. 30 полей этой таблицы редактируемые.
Есть группа полей. При изменении поля в ней, не сервер передаётся соответствующий код, позволяющий серверу однозначно идентифицировать место записи в базу. от сервера идет ответ, который содержит среднее значение по этой группе в строке и среднее по всем строкам этого набора строк этих групп. Сервер отправляет это 2 ответами. Данные вставляются в таблицу. Для этого мне не надо парсить ни ответ ни таблицу — в сообщении от сервера есть идентификаторы куда вставить. Есть поля которые заполняются из файла .doc — в соответствующей ячейке кликается значок, загружается на сервер файл, парсится — в результате в базу записывается 7 полей и эти данные возвращаются клиенту — и просто вставляются как текст в нужные ячейки нужной строки.
Есть вариант когда при клике на кнопку с сервера приходит готовая строка таблицы, с уже заполненными data- атрибутами для идентификации изменений, вносимых в поля.
Если в моей таблице 100 строк — я из субд получаю результсет, содержащий все 100 строк и в цикле обрабатывая эти строки результсета строю html строку, которую и отправляю клиенту. мне не надо 100 запросов.
Когда я меняю значение в одной ячейке — я отправляю на сервер некий id, который однозначно идентифицирует место изменённых данных, и, в простейшем случае, после вставки в базу, сервер ничего не отвечает. Если есть необходимость — от сервера приходит ответ парсится — извлекаются «координаты» изменённой ячейки и текстом вставляются данные — Это можно трактовать как ваше: " смотрите что изменилось и точечно изменяете нужную строку"но это только один из возможных вариантов.
Это получается элементарная CRUD система.
а причём здесь фронтенд-программист? Я фулстек-программист. Я сам решаю, что и где проще сделать.
То есть работать с вашим проектом сможет только фуллстек. Это явно не плюс.
Давайте немного усложним пример — допустим, нам надо выводить таблицу в двух форматах. Первый — полный, со всеми полями, ширина по контенту, в таблице присутствует внутренний горизонтальный скролл (т.к. в экран она не влазит). Второй — краткий, отображаются только избранные столбцы, скролла нет, ширина столбцов — проценты от области. Режим переключается чекером, там же мультиселект со столбцами, позволяющий выбрать отображаемые в кратком виде столбцы.
До кучи добавим мобильное приложение, которое выводит строки таблицы в виде списка элементов с определенной версткой, естественно в этом случае в качестве данных используются только некоторые предопределенные столбцы.
Как у вас чего и сколько в этом случае сервер возвращает?
К слову при классическом SPA-варианте сервер по сравнению с предыдущим случаем (просто обычная табличка) даже трогать не придется, будет вполне достаточно одного запроса, который там и был реализован.
Если есть необходимость — от сервера приходит ответ парсится — извлекаются «координаты» изменённой ячейки и текстом вставляются данные
То есть вы вручную делаете то, с чем фреймворки прекрасно справляются автоматически.
То есть работать с вашим проектом сможет только фуллстек. Это явно не плюс.не надо делать резких выводов. всё можно разбить на части. как вдоль так и поперёк.
Давайте немного усложним пример — допустим, нам надо выводить таблицу в двух форматах. Первый — полный, со всеми полями, ширина по контенту, в таблице присутствует внутренний горизонтальный скролл (т.к. в экран она не влазит). Второй — краткий, отображаются только избранные столбцы, скролла нет, ширина столбцов — проценты от области. Режим переключается чекером, там же мультиселект со столбцами, позволяющий выбрать отображаемые в кратком виде столбцы.вариантов несколько — как формировать две различные таблицы(или N таблиц) или по условию в формировании htm строки таблицы выводить только нужные столбцы. надо смотреть по месту и выбрать оптимальный. Проблем не вижу.
До кучи добавим мобильное приложение, которое выводит строки таблицы в виде списка элементов с определенной версткой, естественно в этом случае в качестве данных используются только некоторые предопределенные столбцы.можно фантазировать сколько угодно, реальные условия/данные ограничат варианты. Будет конкретная задача — будет решение. Делать что-то универсальное — палки самому себе в колёса.
То есть вы вручную делаете то, с чем фреймворки прекрасно справляются автоматически.есть два пути либо решение задачи подстраивается под fw, либо пишется код под оптимальное решение задачи. Я выбираю второй путь — мне это не сложно. Как строятся велосипеды чтоб заставить fw сделать нужное для конкретной задачи — примеров куча.
SPA или не SPA — по большому счёту не отличается.
можно просто тем же html через inner HTML обновлять полностью body. которые брать из html файлов. а можно и как ещё.
Как аналогию могу привести 1c — нормально развивающаяся контора имеет вторую внутреннюю систему учета заточенную под свои производственные процессы(ту же 1с перепиливают под это), либо подстраивает свою работу под одну из конфигураций 1с.
первый вариант — обеспечивает развитие, второй — мучение…
Затраты на изучение чистого js html css3 равносильны по изучению fw, но с мощью wf — строятся панельные дома, а с помощью js html css3 — дворцы. Выбор за вами. Я выбрал дворцы. Мне не сложно сделать это. От проектирования проекта, до запуска продакшена. я спокойно могу разделить проект на части и отдать часть фулстек прогеру/ам.
не надо делать резких выводов. всё можно разбить на части. как вдоль так и поперёк.
Ну вот мы конкретный пример рассмотрели, и чтобы жирным шрифтом кусок текста выделить надо фуллстек-программиста звать.
надо смотреть по месту и выбрать оптимальный.
Будет конкретная задача — будет решение. Делать что-то универсальное — палки самому себе в колёса.
Ну вот видите, вам надо что-=то смотреть, какие-то проблемы решать. А в случае со SPA-подходом у вас есть один запрос к серверу, который отдает конкретно данные — и на этом все, ничего выдумывать не надо. Как эти данные отображать — ответственность клиента, сервер не трогаем. Вы не видите тут очевидного преимущества?
и на серверной стороне тоже до фига. Этот код надо написать и отладить… Ежели просто повторить вставку всей таблицы — ничего нового не требуется… А время на запрос и формирование — минимально, на код и время на клиенте — и того меньше..
Лучше просто признайте, что вам серверный рендер нравится больше клиентского — и прекращайте спор, потому что о вкусах спорить не следует.
Собственно я не спорю. Это вы спорите с fw, VK, которые используют серверный рендеринг где это выгодно и не парятся. если в вашем понимание серверный рендеринг это только первая выдача страницы, то такого понятия нет как минимум в построении страниц jsp, хотя все страницы строятся в java коде.
И да, мне это нравится, потому что возможности огромны и всё просто.
Ну и какой из вас фулстек, если вы боитесь кода на клиенте?
Это вы спорите с fw, VK, которые используют серверный рендеринг где это выгодно и не парятся.
Нет, мы спорим с тем что это априори самый лучший вариант, а все кто используют клиентские фреймворки — делают все неправильно.
Нет, мы спорим с тем что это априори самый лучший вариант,на клиенте это самый простой, наглядный, быстрый вариант.
все кто используют клиентские фреймворки — делают все неправильно.этого я не говорил, и все fw используют серверный рендеринг, там где это выгодно.
Мне просто не нравятся fw, своими ограничениями, выгоднее потратить время на изучения js, html, css. возможностей будет больше.
… позволяет снизить нагрузку на сервер ...
Как раз генерация HTML на клиенте очень-очень здорово позволяет ее снизить. Генерация HTML вообще может быть самой дорогой операцией в приложении. А если притянуть сюда, скажем, генерацию изображений, то еще и основным потребителем сети. Ну например, масштабирование/обрезка изображения перед загрузкой на сервер. Или построения графика по табличке с данными. Arduino застрелится такое сделать. И «нормальный» сервер застрелится при определенном (не очень большом) числе пользователей.
И вы почему-то смешали отчуждение уровня отрисовки (что делается, в том числе, c помощью AJAX/json) и решение проблемы большого числа запросов к серверу (websockets).
Ajax заменяется веб-сокетом? Серьезно??
элементарно на все 146%, без всяких проблем, что и делаю с момента появления websocket, без использования ajax.
Похоже на одурманенность хайпом, уж не знаю каким. Вебсокет или шмебсмокет, json или неджсон — какая половая разница, если это всего лишь транспортный протокол и текстовый формат? Когда инструмент становится фетишем — смешно же. в идеале ни фронт- ни бэк- программист вообще не должен думать о транспорте и сериализации, а должен думать о задачах бизнеса. Из ваши комментариев видно, что вы понятия не имеете об rpc фреймворках Thrift и grpc — а зря. В серьёзных проектах либо они, либо им подобные решения, которые выбирает тех.лид, затем вся команда использует явочным порядком. А вы тут втираете сказки про websocket vs ajax, тот ещё bubble effect.
Вебсокет между прочим в большинстве задач гораздо хуже ajax хотя бы уже тем, что он сложнее. А где именно и что рендерить — html на сервере или dom в браузере — это совсем уже зависит от задачи, и тут ещё более смешно кому то навязывать что-то в качестве универсального решения.
Наверное именно поэтому в GraphQL спецификации есть И Ajax И websocket?Просто для любителей старины и для совместимости со старыми наработками.
У вас очень специфическое представление как о частностях (Ajax, WebSocket, data-flow), так и в целом об front- & backend разработке.
И да использование ws меняет подход к веб проектам, тем кто привык к ajax это кажется не привычным, не правильным. Но это раскрывает огромные перспективы если понять и научиться работать с ws. У меня есть свои наработки, свои решения, которые позволяют использовать ws широко, просто, удобно.
Кажется у вас просто большой опыт с websocket, но очень специфический опыт с web в целом. Использовать webSocket вместо AJAX для большинства проектов, это как стрелять из пушки по воробьям. Воробья подстрелить можно, но зачем? Рекомендую вам ещё serviceWorkers тогда подключить, очень гармонично впишется ;) А ещё можно всё перевести на webAssembly. И не забыть сделать offlne-версию всех своих продуктов.
У меня тоже есть опыт с WS. Но мне бы и в голову не пришло тащить его в те проекты, где нет нужны в persistance connection.
Использовать webSocket вместо AJAX для большинства проектов, это как стрелять из пушки по воробьямэто заблуждение, на самом деле это намного проще чем ajax.
Рекомендую вам ещё serviceWorkers тогда подключить, очень гармонично впишется ;) А ещё можно всё перевести на webAssembly.я к этому стремлюсь. Если есть опыт — прошу поделиться.
У меня тоже есть опыт с WS. Но мне бы и в голову не пришло тащить его в те проекты, где нет нужны в persistance connection.могу согласиться, но у меня корпоративные порталы, где persistance connection как основа. С другой стороны если есть проверенные наработки с ws, почему не заменить ими ajax? и клиентская сторона и серверная получаются простыми, ни чуть не сложнее чем с ajax.
Я не буду вас переубеждать. Скажу проще вы очень сильно заблудились в своём познании web-а. Вероятно вы на 99%+ самоучка. Вам стоило бы рассмотреть возможность очной работы в крупной продуктовой компании, в команде более опытных коллег.
Хм, а вебсокеты умеют в request-response flow? Понятно, что эмулировать можно, но по дефолту?
А перестраивать всю архитектуру под двунаправленные серверные потоки данных — это намного сложнее, чем AJAX.
Никогда не считал зазорным спросить совета у более опытного разработчика в текущей технологии, не испытываю по этому поводу никаких комплексов.
Я тащусь от того, что в общем-то не ограничен языком или платформой. Ннннада .NET? Не вопрос (asp, xamarin, wpf). Запилить бэкенд на PHP? Легко. CSS к сайтику? И это тоже! Что здесь? Си и Linux? Давайте сюда, сделаем. Что это? Делфи? Воу, какой раритет! Ну ОК, давай в Делфи.
И так далее и тому подобное.
Да, я совершенно точно уступаю синьору в любой из этих платформ, в некоторых областях даже с натяжкой могу назвать себя «миддл» (а скорее «продвинутый джун»), но черт возьми… Это настолько удобно и комфортно, что даже не знаю с чем сравнить!
Можно в одиночку ненапряжно тащить некрупные проекты, не завися от других людей (и получать все деньги тоже в одного, что весьма приятно).
Ннннада .NET? Не вопрос (asp, xamarin, wpf). Запилить бэкенд на PHP? Легко. CSS к сайтику? И это тоже! Что здесь? Си и Linux? Давайте сюда, сделаем. Что это? Делфи? Воу, какой раритет! Ну ОК, давай в Делфи.
Что у вас за место работы, если приходится вот так вот скакать по технологиям? Или вы фрилансер?
Кому-то нужен крайне специфический внутренний продукт (например, ПО для расчетов ТТХ изготавливаемой арматуры в мобильничек или «микро-CAD» для расчетов прочностных характеристик всяких специфичных железяк (на этом проекте я не осилил матан, поэтому понадобилась помощь зала, хех)). Здесь обычно рулит дотнет.
Кому-то нужен специфичный сайтик (не визитка, не интернет-магазин, и не шаблон WP/Drupal/итп, такое я не беру, неинтересно). Здесь как правило PHP/JS/CSS/HTML. Если нужен специфичный дизайн, то я привлекаю стороннего покемона (с художественным развитием у меня не очень).
Иногда приходится делать продукт для интранета (с подъемом серверов, блэкджеком и прочим).
И в чужих древних разработках (пресловутые Делфи/VB/CBuilder лохматых годов) приходится покопаться — ПО написано 20 лет назад, поддержки уже давно нет, а поменять что-то нужно (чаще прикрутить что-то к чужому коду быстрее и дешевле, чем переписать заново, проекты попадаются далеко не уровня «hello, world»).
Linux — это больше хобби, но случалось несколько раз писать за деньги и под него.
Почему я, а не «команда проф. разработчиков»? Потому что малый и средний бизнес как правило не понимает 90% того, что лидеры/«эффективные менеджеры» этих команд им говорят, и (главное) не тянут по финансам.
Скажем, переговоры по «микро-CADу» с разными командами заняли в итоге 4 месяца(!) и цены на готовый продукт начинались от 5 млн (в рублях разумеется), со временем разработки в 4-6 месяцев.
Я не особо напрягаясь сделал чуть больше, чем за квартал и за миллион. При этом вечерами ведя пару мелких проектов.
Не потому, что я круче упомянутых команд, а потому, что я мог по 2-3 дня подряд ничего не писать, а ходить хвостом за инженерами, для которых этот продукт делался.
Узнавать, что им нужно, помимо унылого ТЗ, как будет удобно, как вообще это работает с их точки зрения.
В результате, как минимум треть ТЗ ушла в помойку, а процесс разработки ускорился невероятно из-за того, что отпала необходимость реализовывать ненужные фичи, которые «вроде как нужны», но на самом деле никто их никогда бы и не использовал.
В общем, такой подход к разработке — это еще один очень важный скилл в жизни fullstack :)
В среднем по больнице, к сожалению, как и любые титулы, этот скорее связан с фаллометрией и используется далеко не во благо.
Во-первых если сотрудника есть представление о разных технологиях, то по крайней мере есть возможность выбрать ту, что подходит лучше, а не лепить в очередной раз на том что умеет, но оно точно не работает. Если бизнесу нужен совет о технологии — то разработчик может его дать.
Во-вторых если может в одиночку тянуть некрупный проект — то значит не надо тратиться на лишних менеджеров, а значит на целую кучу организационных активностей (собрания о собраниях и о том как их правильно проводить). Кроме того если проект ведется одним разработчиком (лучше все-таки двумя для High Availability), то не требуется даже формальный SDLC, разве что некоторое количество инструментов.
В целом не знаю как там насчет синьора, но эти навыки по крайней мере по моей субъективной шкале стоят выше чем доскональное знание всех стандартных хранимых процедур того же Sql Server. Приоритет — это сделать софтину, а не родить инженерный шедевр.
Я не встречал спецов которые знают только Java.Обычно спец идет под стек, кругозор и умение мыслить нужными категориями — определяют.
Страшно представить сферического Java кодера который 10 лет занимается только чистой Java и Spring_ом не зная ничего о фронте.
Приоритет — это сделать софтину, а не родить инженерный шедевр.
Именно так.
Кстати, когда я начинал свой путь (это когда за деньги), то разумеется смотрел, как это делают другие корифеи.
Поначалу меня всегда удивляло, что узкоспециализированное ПО (для одного человека или небольшой группы/команды) имеет «убогий дизайн».
Ну реально, вместо лаконичного и «уже вроде как привычного» от билгейца — какое-то малопонятное со стороны нагромождение UI-элементов, хоткеев и вообще, без бутылки не разберешься (под DOS вообще были шедевры почище vi).
Однако, после нескольких попыток нести в массы «правильный» интерфейс, начало приходить понимание, что это все явно неспроста, а заточено именно под упомянутого пользователя или группу.
Первым проектом после осознания факта, что узкоспециализированное ПО должно быть в первую очередь функциональным и удобным, а только потом «красивым», была система учета/управления библиотекой (заведение с бумажными книгами) под винду (год 98й однако был).
После изменения «красивенько» на «удобненько», приложение приобрело несколько страшноватый вид, но скорость работы трех девчонок повысилось где-то в 5 раз.
Т.е. UI было сделано так, как им было удобно. Хоткеи такие, какие им были удобны. Каждое движение, каждое нажатие было максимально функциональным — от автодобавления строк, до сортировок и сохранения.
Скажем, ну кто бы мог подумать, что девчонкам удобно нажать Ctrl+T n раз (режимы сортировок) и чтобы она (сортировка) не менялась в основном окне, а всплывало поверх формы, не загораживая основной список и висело там до тех пор, пока хоткей зажат?
Да в жизни бы до такого не догадался, а девкам, подсказавшим, как им было бы удобно ну очень нравилось — кинули взгляд, ага, здесь то, а здесь то; отпустили хоткей и дальше работать. На все про все уходило в пределах 1-2с, когда при «обычной» сортировке (когда все в одном списке) приходилось листать по 10 (а то и 30с), да еще запоминать большие объемы данных, т.к. перед глазами не было предыдущих данных.
И таких нюансов при плотном контакте с будущими пользователями — вагон и две тележки сверху.
ИМХО, только такой подход реализует тезис «вам шашечки или ехать» :)
Что-то вроде того:
…
— Слух, а можно сразу две сортировки делать?
— Это как и зачем?
— Ну я вот тут смотрю, а когда переключаю, нифига не понимаю, что и откуда. Как-нить можно сразу и такую и такую?
— [сразу начинаешь думать, как перекроить UI, чтобы еще что-то влезало, на 14" с 1024х768 особо не разбежишься, а один из трех мониторов вообще в 800х600 только умеет] Ээээ… Нууу… А куда ее вставить-то тут, без того экран занят?!
— Да не надо вставлять, пусть тут [тык в экран пальцем] квадрат вылазит с ней, пока держу клавиши и все.
— Бинго!
…
Ровно как и перенести режимы сортировок на одну клавишу (слепым методом печати они не владели, т.е. куча хоткеев для одного и того же было для них не очень удобным решением).
А в таком виде (Ctrl+T) — клац = одна сортировка, клац-клац = другая, клац-клац-клац = третья…
А уж сколько денег было поднято на простецкой проге для сдачи данных/отчетов в налоговую до прихода в массы «1С Налогоплательщик» (да и после тоже, т.к. скорость внесения данных в мою поделку была без преувеличения на пару порядков выше)…
И все это благодаря тому, что кривенький и косонький UI был на самом деле выверен до последнего тыка в клавиатуру, все заточено под максимальную скорость ввода.
Закончилась лафа с этим ПО только после внедрения на предприятия и частникам всевозможных «Бухгалтерий», «Кадров», где эти отчеты формировались на автомате.
Ну как бы тогда небезопасный. Нужно тотальное модульное тестирование. Это не хорошо и не плохо, но требует от мозга изменения подхода скорее всего на test first, потому как иначе не выжить.
Замена типизации тестами — самое глупое решение, которое вообще можно себе представить. Лучше на динамике вообще не писать в таких случаях.
Это ваше личное мнение, или можете привести результаты исследований? :)
Это ваше личное мнение, или можете привести результаты исследований? :)
Исследований чего? Просто сама идея о том, что типы заменяются тестами говорит, что человек не умеет в статику. А если человек не умеет в статику — то в динамику он не умеет и подавно, до динамики его вообще допускать нельзя.
Возможно вам будет интересно: Ideology — там как раз рассматриваются эти точки зрения (что статическая типизация и тесты могут заменять друг друга)
Всё зависит от требований. Я предпочитаю тестировать логику, а не что будет, если в метод передадут целое вместо строки.
функциональные модульные тесты, чем просто формальные модульные.
ммм… не поделитесь определением? Что есть что?
Формальные тесты проверяют корректность API: принимают ли методы/функции задекларированные типы аргументов, что возвращают, что получается если передать "неправильный" тип данных, и т.д.
Функциональные тесты проверяют что код делает. Нажали на кнопку, получили результат. Тот результат или не тот? И т.д.
Официальная наука говорит
когда говорите "наука говорит" приводите источники, иначе это вы говорите а не "наука".
модульные и функциональные
то есть модульные тесты не проверяют функциональность? Ну и интеграционные тесты не являются функциональными? Чем тогда приемочные от ваших функциональных отличаются? И можно ли делать приемочные тесты не со стороны UI?
Мне кажется, что наиболее полезный подход — что-то среднее между этими двумя.
Мне нравится что вы начали комментарий с фразы "наука говорит".
Они не проверяют функциональность, они проверяют, что какие-то методы были вызваны с правильными параметрами
если они проверяют какие методы были вызваны с какими параметрами и в какой последовательности — ваши тесты дублируют реализацию и их можно в целом удалить, они пользы не несут.
слишком много знаний о внутреннем устройстве кода утекает.
Это говорит о том что дизайн нашего кода такой, что провацирует подобное. Обычно — из-за большого количества зависимостей (попробуйте перегруппировать код таким образом, что бы уменьшить количество оных).
а тестирую микросервис как black box — снаружи
Немного накину: J B Rainsberger — Integrated Tests Are A Scam
Но тем не менее, без статической типизации надо покрывать тестами намного больше, чтобы код был поддерживаемым, иначе вносить изменения очень дорого.
Мне всегда было интересно узнать, на чём основывается такое мнение у других людей, имеющих опыт с обеих сторон баррикад. Я от строго типизированных языков отошёл уже так давно, что деталей не помню; осталось только общее разочарование от строгой типизации как пресловутой красной селёдки.
Можете привести примеры, когда статическая типизация помогла вам провести логический рефакторинг когда без наличия существенного тестового покрытия? Честно не флейма ради, мне правда интересно.
Можете привести примеры, когда статическая типизация помогла вам провести логический рефакторинг когда без наличия существенного тестового покрытия?
Ну вот есть у меня сущность Х, в ней поле Y, я его переименовал на Z. В статике мне сразу все ошибки покажет (вообще говоря, в статике этот рефакторинг будет сделан автоматически даже), без каких-либо тестов.
Блин, ну вы банально пишите где-то: myobj.myMethod.
Спасибо за пример, но пока не убедительно. Я просил привести случаи, когда именно строгая типизация помогала при рефакторинге логики. Отсутствующие методы и прочие тривиальные случаи не являются адекватным примером, т.к. легко закрываются статическими анализаторами кода даже при слабой типизации, не говоря уже о тестах.
С тем, что хорошее покрытие тестами спасает от таких проблем, я спорить не собирался. Я вообще с вами не спорю, а пытаюсь (в очередной раз) узреть свет истины в строгой типизации. Пока не очень получается, т.к. все приводят банальные примеры в стиле: ну вот мне надо поле в объекте поменять, типизация меня спасёт. Чего-то более убедительного я пока не видел, а когда начинаешь копать, всё сводится к тёплому ламповому ощущению безопасности (Type safety? Отличный маркетинг).
В то же время строгая типизация ооочень сильно продвинулась за последние годы
Это всё хорошо и замечательно, но не показывает, зачем всё это нужно.
Спасибо за пример, но пока не убедительно. Я просил привести случаи, когда именно строгая типизация помогала при рефакторинге логики.
У вас был метод, который что-то вычисляет и возвращает значения типа X. Вам пришлось по тем или иным причинам поменять эту логику и при этом теперь метод может иногда бросаться наллами, типа, не получилось вычислить. Естественно, теперь везде на call site должна быть добавлена проверка на null'ы — вы меняете возвращаемый тип с X на X | null и теперь код не скомпилируется, если где-то есть непроверенные места.
легко закрываются статическими анализаторами кода даже при слабой типизации, не говоря уже о тестах.
Вы врете. Все существующие анализаторы справляются с задачей от "чуть лучше чем никак" до "ужасно" и как-либо полагаться на них нельзя в принципе.
С тем, что хорошее покрытие тестами спасает от таких проблем, я спорить не собирался.
А с типами никакого покрытия тестами не надо. Код с указанными проблемами просто не компилируется.
Это всё хорошо и замечательно, но не показывает, зачем всё это нужно.
Очевидно, за тем, чтобы не писать (и потом не выполнять регулярно) тысячи строк кода с:
Формальные тесты проверяют корректность API: принимают ли методы/функции задекларированные типы аргументов, что возвращают, что получается если передать "неправильный" тип данных, и т.д.
Естественно, теперь везде на call site должна быть добавлена проверка на null'ы — вы меняете возвращаемый тип с X на X | null и теперь код не скомпилируется, если где-то есть непроверенные места.
Спасибо, это убедительный пример. Зерно сомнений продолжает расти.
Вы врете.
Давайте на полтона ниже, хорошо? И можно не так авторитативно, меряться длиной бороды мне недосуг.
А с типами никакого покрытия тестами не надо.
Это очень распространённое мнение, но, на мой взгляд, весьма ошибочное. Смысл тестирования вовсе не в том, чтобы заменить строгую типизацию. Правильно написанные тесты выполняют как минимум три основные задачи:
а) Документирование ожиданий
б) Проверка правильности исполнения в нужном контексте (для front end, в конкретных браузерах)
в) Защиту от регрессий
Отлавливание мелких проблем с типизацией это дешёвый побочный эффект хорошо написанных функциональных и интеграционных тестов. Формальные тесты в таком случае тоже обычно излишни, т.е. писать их и так и этак не надо.
Очевидно, за тем, чтобы не писать
Это тоже очень распространённое мнение, и, на мой взгляд, настолько же ошибочное. Смотрите:
- Рефакторинг становится не только возможным, но и вполне лёгким, когда вы можете менять любой код в системе, зная что тесты будут падать, если что-то не так. И даже в тех случаях, когда компилятор пропустит.
- Наличие работающего набора тестов позволяет легко решить проблему с устранением дефектов: пишем тест, который падает без фикса, и проходит с фиксом. Со временем такие тесты становятся просто незаменимыми для учёта различных пограничных случаев при рефакторинге.
- На базе набора тестов с достаточным покрытием можно внедрить разные продвинутые механизмы динамического QA, статическим анализаторам и компиляторам просто неподвластные.
Если вы доведёте вышеизложенные мысли до логического конца, то увидите: писать тесты надо нипочему. Вне зависимости от наличия или отсутствия строгой и/или статической типизации.
А вот когда правильный упор на тестирование делается изначально, то статическая типизация оказывается… Не жизненно необходимой. Ну вот просто, зачем? Это я и пытаюсь понять.
(и потом не выполнять регулярно)
А вот это уже мелочи, извините. Вам не всё равно, что именно выполнять, компиляцию или тесты?
Это очень распространённое мнение, но, на мой взгляд, весьма ошибочное.
Речь не об отсутствии покрытия тестами в принципе, а об отсутствии покрытия тестами вида "ф-я принимает строку и возвращает число". В случае статики у вас гарантированно эта ф-я принимает строку и возвращает число, т.к. это указано в типах, если бы это было не так — код бы не скомпилировался. С-но тесты именно этого конкретного класса вам не нужны. Тесты, проверяющие логику работы — нужны, конечно.
Давайте на полтона ниже, хорошо? И можно не так авторитативно, меряться длиной бороды мне недосуг.
Окей, смотрите. Проблема даже не в том, что анализаторы плохи, проблема в том, что типичный динамикокод написан так, что его просто невозможно полноценно проанализировать. В коде просто нету достаточной информации.
Например, тот е Хиндли-милнер, когда увидит что в коде недостаточно информации, выдаст вам ошибку вывода и вам придется либо переписать код, либо дообавить аннотации. Анализатор динамики же просто вам скажет: "ну нишмогла, звиняй". По-этому можно, конечно, использовать, но надеяться на то, что они отработают правильно — нельзя. И чем больше у вас проект — тем больше будет встречаться кейсов, где анализатор обломается.
А вот это уже мелочи, извините. Вам не всё равно, что именно выполнять, компиляцию или тесты?
Тесты обычно на порядок медленнее компиляции.
Речь не об отсутствии покрытия тестами в принципе, а об отсутствии покрытия тестами вида "ф-я принимает строку и возвращает число". В случае статики у вас гарантированно эта ф-я принимает строку и возвращает число
Вот тут вы как раз и задели большую и интересную тему. Если вкратце и упрощённо: а зачем это гарантировать? Нет, погодите возмущаться, подумайте. От кода нужно, чтобы он делал что-то полезное: проценты какие-нибудь считал, или DOM элемент создал, или ещё что-нибудь. В подавляющем большинстве случаев конечный результат работы это строка. Если смотреть с этой стороны, то типы данных это не более чем внутренняя абстракция программы, инструмент для достижения каких-то целей. Почему этому инструменту придаётся такое большое значение?
Тесты, проверяющие логику работы — нужны, конечно.
Именно, в логике работы мы все и зантересованы. А проверяя логику работы, вам всё равно придётся вызывать эти функции/методы, передавать им какие-то данные, проверять вывод. Если ваша функция принимает число/строку/массив чисел, то вам имеет смысл написать тесты, проверяющие обработку результата вызова этой функции во всех этих случаях. Проверка собственно обработки типов в этом случае является побочной.
Проблема даже не в том, что анализаторы плохи, проблема в том, что типичный динамикокод написан так, что его просто невозможно полноценно проанализировать.
Моя теоретическая база могла устареть, но я откуда-то помню, что динамический код невозможно полностью проанализировать в принципе. И дело тут не в том, как он написан.
По-этому можно, конечно, использовать, но надеяться на то, что они отработают правильно — нельзя.
Вот тут, мне кажется, вы переводите вопрос в эмоциональную плоскость. Если отойти от эмоций и уверенности/обеспокоенности, то можно заметить, что динамический анализатор это такой же инструмент, как и все остальные: статическая проверка типов, тесты, и т.д. Динамические анализаторы не могут решить 100% проблем, равно как и остальные инструменты. Мы используем эти инструменты для уменьшения количества дефектов в программах, но добиться полной победы невозможно, поэтому надеяться на это тоже бессмысленно.
А с другой стороны, как всегда, вопрос стоимости того или иного инструмента. Стоимость внедрения, стоимость поддержки, ограничения — вот это всё. Плюсы против минусов.
И чем больше у вас проект — тем больше будет встречаться кейсов, где анализатор обломается.
Я очень часто слышу эту мантру: вот встретишь, мол, по-настоящему большой проект, тогда поймёшь. Давайте определимся, о каком размере речь-то идёт? Я уже приводил пример проекта на 1.5 млн строк в JavaScript. Написанных очень, очень опытными и профессиональными людьми, и весьма плотно. Это web framework, на котором построены высоконагруженные проекты, соответственно и требования к качеству кода намного выше, чем у обычного LoB приложения.
Исходя из опыта поддержки и развития этого проекта на протяжении 8 лет, я делаю вывод: не так страшен чёрт динамической слабой типизации, как его малюют. Точнее, вообще не страшен. Иногда бывают проблемы, но так редко и такие мелкие, что отказываться ради их решения от динамической гибкости было бы очень невыгодно.
Основной контроль качества на этом проекте осуществляется через тестирование. Динамический анализ только-только начал внедряться недавно (это сложная тема). Проблемы при внедрении анализатора были выявлены в основном в старом и плохо протестированном коде. Исправление этих проблем заняло день или два.
Насколько же большой проект мне нужно глубоко изучить, чтобы всё-таки дойти до точки невозврата и броситься в тёплые объятия type safety? :)
Тесты обычно на порядок медленнее компиляции.
Смотря где, могут быть и на два порядка. :) Но их всё равно гонять надо, а при грамотном подходе можно и 500,000 тестов прогнать на дюжине браузеров за 15 минут.
Вот тут вы как раз и задели большую и интересную тему. Если вкратце и упрощённо: а зачем это гарантировать?
Из такой гарантии следует, что все тесты из описанного класса будут проходиться заведомо. По-этому вам не требуется такие тесты писать (зачем писать тест, который никогда не может упасть?).
В итоге время, которые вы бы потратили на написание таких тестов, вы можете теперь потратить на что-то более полезное. На написание функциональных тестов, например.
Моя теоретическая база могла устареть, но я откуда-то помню, что динамический код невозможно полностью проанализировать в принципе. И дело тут не в том, как он написан.
Именно в том, как он написан, и есть. Если вы не используете "динамические" фичи, то код вполне анализируется.
Если отойти от эмоций и уверенности/обеспокоенности, то можно заметить, что динамический анализатор это такой же инструмент, как и все остальные: статическая проверка типов, тесты, и т.д.
Нет, не такие же. Вот выше был пример с рефакторингом, где я переименовал метод. В статически типизированном яп не возникнет такой ситуации, что чекер что-то пропустил, по-этому проверять его работу не требуется. В случае анализатора динамического яп — он вполне может что-то пропустить, по-этому его работу мне надо будет проверить руками. В этом есть существенная разница — надо ли потом руками проверять работу вашего инструмента. Фактически, мы сравниваем инструмент автоматический и полуавтоматический.
Я очень часто слышу эту мантру: вот встретишь, мол, по-настоящему большой проект, тогда поймёшь.
Это просто вопрос статистики. Если какая-то ситуация возникает в среднем на 10к строк кода, то если у вас проект размером в 1-2к строк, то, весьма веряотно, такая ситуация там и не встретится, а если и встретится- то однажды. В случае же 1кк строк кода у вас будет уже сотня таких ситуаций, весьма широко раскиданных по всему проекту.
Насколько же большой проект мне нужно глубоко изучить, чтобы всё-таки дойти до точки невозврата и броситься в тёплые объятия type safety? :)
Статическая типизация — это рпосто инстурмент. Такой же как, например. Тестирование. Если человек не умеет использовать тесты, вы никак ему не объясните, зачем они нужны. Тут ситуация аналогичная — чтобы понимать, зачем нужна стат. типизация, надо уметь ее использовать. Тому, кто ее использовать не умеет она не нужна. Точно так же как тесты не нужны тому, кто не умеет их писать.
С этим никто не спорит. Вопрос в том, какого типа тесты надо писать.
Я уже где-то выше писал: на мой взгляд, формальные тесты API бессмысленны для динамических языков со слабой типизацией. А именно формальные тесты (проверка типов входных/выходных данных) всегда и вызывают такую бурю эмоций у апологетов статической типизации.
Ну вы ведь понимаете, что упёрлись рогом в красную селёдку?
Когда я пишу на хаскеле, я не пишу юнит-тесты. Вообще. Совсем. Они мне не нужны.
Писать или не писать юнит-тесты это вопрос расплывчатый, зависит от проекта. Я знаю много примеров проектов, совершенно никак не закрытых автоматизированными тестами, и знаю много примеров к обратному. Всё зависит от стоимости дефекта и его исправления.
Я пишу тесты типа «если весь интерпретатор целиком получает на вход такую строчку, то на выходе будет такой результат». «Если мой анализатор на вход получает такой код, то он должен выплюнуть такое предупреждение». Это тесты уровня спеки.
Я не знаю специфики вашего проекта, но то, что вы описываете, может быть либо юнит-, либо интеграционными тестами.
Собственно, да, такие тесты и есть спека на всю систему целиком.
Если ваша система предназначена к использованию как единое целое, без разбивки на отдельные части, то это как раз и будут юнит-тесты. См. определение.
Ничего, что ошибки компайл-тайма в языках со статической типизацией выдают статические анализаторы?
Речь шла об анализаторах динамических ЯП. Мне казалось, что это из контекста совершенно ясно.
Вы не правы, они весьма существенно отличаются. Как в плане решаемой задачи и предъявляемых требований, так и в плане того, как работают.
Вроде, выше написал, чем. Инструменты решают разные задачи, разными способами. Скорее, надо задавать вопрос — что у них вообще общего? По сути — ничего.
При этом конкретный набор правил, касающихся типизации, может быть у анализатора динамического языка типа PHP или JS жёстче чем у анализатора (встроенного в компилятор) статического языка типа C.
Но как контр приме можно привести скажем python, который позволяет вам определить тайпинги для всего на свете. Или flow, который справляется с этим даже лучше.
Да, в языках типа ruby все будет плохо со статическим анализом, и обычно все ограничивается банальным линтингом.
У меня нет особо задачи вас убеждать.
Да я в общем-то и не просил меня убеждать. Я попросил привести пример и пояснил, зачем спрашиваю.
Программируйте больше на современных языках (не на Java) и сами всё поймете. F# возьмите или Kotlin хотя бы.
С Java я не работаю, равно как и с F# или Kotlin. Нет практических задач на них по основной специальности, а инвестировать 5 лет вечеров в изучение ненужных мне языков просто для того, чтобы может быть понять прелести строгой типизации, это как-то странно было бы. У меня столько времени нет.
То, что вы спрашиваете — довольно очевидные вещи для тех, кто писал на разных языках. Не очень интересно на спичках объяснять азы про всякие про рефакторинги вроде change method signature.
Спасибо, мне не надо объяснять азы. Я их вполне неплохо знаю. :) А вещи, о которых я спрашиваю, как раз не очевидны, иначе я бы не спрашивал.
Заметьте, кстати, что в самом большом динамическом поле JavaScript пришли и вкрутили язык с очень продвинутой системой типов: TypeScript.
Это ни о чём не говорит, кроме того, что большому количеству людей очень неуютно без тёплого лампового type safety.
И это в области, где все хипстеры кричали, как им не нужны никакие системы типов...
Хм. Давненько меня в хипстеры не записывали. :)
А с другой стороны, я и не кричу вовсе. Просто у меня есть многолетний опыт работы со слабо типизированными языками, в т.ч. 8 лет опыта работы с кодовой базой в 1.5 млн строк на JavaScript. И этот опыт мне упорно твердит, что никакой сильной боли и проблем от отсутствия строгой типизации я не припомню. Но всё же червячок точит, может просто я чего-то не понимаю? Вот и пытаюсь просветлиться, пока безуспешно.
Спасибо за беседу.
Мне обычно 2-х недель хватает, чтобы начать и еще 2-х чтобы прочувствовать язык.
Ну вот считайте, что я такой слоупок, мне не интересно галопом по Европам. А для глубокого понимания, анализа отличий, и, самое главное, осознания преимуществ тех или иных решений нужно не просто почитать документацию и покодить демки на уровне todo list, а ещё и шишек набить на реальных взрослых проектах. Которых на Java/F#/Kotlin у меня нет, а у вас вроде есть, поэтому я и спросил.
Те, кому это интересно изучают (инвестируют) не потому что нужно, а потому что интересно. И там есть, что изучать.
С чего вы решили, что мне нечего изучать? :) Список того, что мне хотелось бы попробовать и поковырять, гораздо длиннее списка того, что я уже знаю. Но вот ни Java, ни F#, ни Kotlin в этот список не входят, как и многие другие языки со строгим типизированием, хотя скорее вне зависимости от оного. Просто не интересны.
Кроме того, проблемы понимания это не решит: в Java нельзя обойтись без строгого типизирования, и сравнивать не с чем.
Я вот не знаю примера языка с опциональным строгим типизированием, чтобы можно было попробовать так и этак и сравнить. Поделитесь?
Ой, забыл спросить, как у человека пишущего на JsvaScript 8 лет: Как там вас бомбит от пропоузалов по private fields?
Да вообще не бомбит, точно так же, как и от TypeScript и многих других вещей. Кому-то надо, они пилят. Меня это не обязывает все эти фичи использовать. :)
Не приходит мысль о том, что в других языках такой проблемы нет и не было никогда? Почему бы это? Как вы думаете?
В каких именно других языках? Их много разных. Вот, скажем, в очень модно-популярно-строго-типизированном Python их тоже нет. Точнее, даже хуже: private fields как бы есть, но в виде уродливого хака в компиляторе.
Плохой язык, получается? Или просто культура/подход/методология другая? Почему бы это, как вы думаете?
Честно сказать, я не совсем понял ваш посыл про Питон. В нём типизирование строгое/динамическое, но совершенно не опциональное.
Понятия действительно смешаны, mea culpa. Прочитал ваше сообщение по диагонали и увидел то, что хотел увидеть, вместо написанного. Прошу пардона. :)
Если применить мою логику к вашему изначальному сообщению, то получается, что речь идёт об опциональной статической типизации (и не обязательно строгой). А это как раз, скажем, JavaScript + Flow. Надо попробовать.
А полезные для себя мысли я всё же вынес, так что спасибо за беседу.
В 2018-м и на языках с динамической типизацией можно писать почти как на статической, если настроить статанализатор на выдачу ошибок типизации. А типы можно задавать тремя способами:
- тот же вывод типов
- аннотации в комментариях
- синтаксисом обычно используемым для динамической типизации (
function sum(int $a, int $b): int {}— пример для PHP, который традиционно считается языком со слабой динамической специализацией, но сейчас всё больше стандартных средств её усилить внедряется, и даже обсуждается возможность опциональной статической типизации в процессе компиляции, чтобы при обнаружении заведомых ошибок типов во время компиляции сразу бросать ошибку, а не дожидаться пока поток управления дойдёт до места ошибки, собственно в некоторых местах это уже реализовано, например, при ошибках наследования или имплементации интерфейсов)
Все смешалось в доме Облонских: стеки, языки программирования, доменные области. Не понятно на счет чего именно из этого вы пишите.
Вот только одно не смешалось — неизменно неправильное написание программистами слова «пишИте».
народ разошёлся по Scala'ам, Kotlin'ам и Clojure'ам
Никто никуда не разошелся, основная масса как сидела на Java, так и сидит. Посмотрите на вакансии, все станет понятно. Из перечисленного только Котлин пока имеет перспективу и держится на хайпе. И тут тоже в основном из-за Андроида, где до недавнего времени была Java 6. Пик интереса к Scala уже прошел и по сути осталась только одна область (big data), где Scala — почти стандарт. Надеюсь, что с выходом версии 3, интерес к ней снова появится. Ну, а на clojure как сидели энтузиасты, которых немного, так и сидят.
К слову, пример со Scala очень показательный. Язык очень интересный сам по себе (в вашей терминологии «не говно»), но, в то же время, его очень сложно использовать в большом проекте. Во-первых, на нем одно и то же можно написать сильно по разному (в стиле Java+ и в стиле Haskel с линзами и монадами), во-вторых, создатели языка периодически кладут прибор на обратную совместимость и все ломают. Вот и получается, что когда в проекте более десятка разработчиков, то выбирают старую многословную и тупую Java.
Лично общаюсь с разработчиками из Amazon — Scala там процветает в сервисах.
Это ничего не значит, потому что в Google, Amazon и т.д. практически на любом не слишком уж маргинальном языке пишется куча всего, по-этому и го процветает, и скала процветает и куча чего еще процветает — это все будут истинные утверждения. Вопрос в том, сколько это все составляет в процентном отношении от цельной кодовой базы всех существующих сервисов.
Ну я спрашивал про кодовую базу.
У кого?
У программистов. У этих людей — которые код пишут, понимаете?
А им откуда знать? Они какой-то свой код пишут для каких-то сервисов, над которыми работают именно они. А для сервисов, над котоырми они не работают — они код не пишут. Логично же? Естественно, если разработчик пишет код для того одного из сотни сервисов, для которых была выбрана скала, и потом его же (как человека, который умеет в скалу, логично же?) переводят на второй такой проект — он вам и скажет, что, ага, у нас тут скала повсюду. Потому что, действительно, он только со скалой и работает.
Хотите через 10 дней спрошу еще на re:Invent в Лас Вегасе, ну чтобы вы были спокойны…
Спросите, в виде: "сколько всего в амазоне за все время было написано сервисов, сколько из них было написано на скале".
Ну а то, что Google'овский Android перешел с Java на Kotlin и так понятно…
При этом Google завернул Scala для Android, хотя Typesafe (Lightbend) активно предлагали ее Google. И по большому счету, правильно сделали, для Android нужен простой и понятный язык, а не язык для тренировки мозга.
Вы пробовали на котлине писать? После него возвращаться на джаву очень больно, и то, что дизайн — говно становится чуть более очевидным.
Я не доказываю, что она мертва. Где я такое говорил?
Хм, смотрите
когда они поняли что надо пилить фичи, то уже было слишком поздно — народ разошёлся по Scala'ам, Kotlin'ам и Clojure'ам.
Делаем нехитрые умозаключения. Народ разошелся по котлинам, значит на Java никого не осталось.
Народ в смысле — программисты с которыми я знаком и поддерживаю отношения.
Ясно, так себе статистика.
на чем пишет свои сервера Twitter?
Напишите название или ссылочку, интересно. Все из того, что видел, как правило, является оберткой поверх netty, который, о боже, написан на богомерзкой Java.
Не до конца понимаю ваш посыл: все, кто работаю в Twitter'а — не программисты? Или очень плохие?
Вы его вообще не поняли. Посыл такой. В твиттере как и в других больших компаниях есть зоопарк технологий. Кроме этого, есть проекты, которые пилятся под свои нужды по разным причинам. Грубо говоря, нужна админка для чего-то, в которую будут ходить десяток человек в день. Людям дали свободу, люди запилили фреймворк на коленках и выложили в github. При этом тут же на этом фреймворке появляется штамп «ого, он используется в Твиттер», как именно обычно не уточняется. Дальше этот проект может быть и правда успешным и уйти в массы, а может так и остаться проектом под конкретные нужды. Посмотрите на Google, они открывают и хоронят проекты постоянно.
То вы документацию найти не можете
Где я это писал? Я писал, что она хреновая, а не что ее нет. Посмотрите документацию Spring или Play — вот пример хорошей документации и комьюнити.
Это как бы не очень нормальное поведение.
Это ровно тоже самое, как и на основе информации о своих знакомых (которые ушли из Джавы) делать выводы о всей индустрии. Специально написал в вашем стиле, чтобы вы почувствовали что несете.
Дизайн Java — говно, сколько бы вы ни называли его «стабильным и надежным»
Вы читаете сообщения? Или просто повторяете мантру? Я нигде не писал про дизайн Java, зачем вы мне это пишете уже не в первый раз?
Поэтому, с точки зрения количественного сравнения — по вакансиям, по количеству денег в индустрии, скала-стартапы выглядят не просто маргинальными нищебродами по сравнению с джава-миром, а находятся где-то на границе погрешности измерений.
Теперь поговорим за качество. Ну и зачем мне технология, где минорный апдейт случается раз в три года и при этом ломает обратную совместимость? Тулов по сравнения с джавой… обнять и плакать. Зачем искать редких сложно-заменяемых специалистов с зарплатой на 30% выше рынка, если за эти же деньги можно нанять 3 легко заменяемых аутсорсера из индии/восточной европы, которые (под присмотром тимлида/архитектора) будут перформить как минимум не хуже? А код при этом будет написан со всем известными со школьной скамьи паттернами, в которых элементарно разобраться, вместо этой скала-зауми с ФП и с кастомными операторами «ЖОПА», для которых нужно phd, чтобы разобраться.
Таким образом, с точки зрения бизнеса, выражаясь вашими же словами, скала выходит очень дерьмовая технология и больше годна для почёсывания своего ЧСВ, нежели для достижения бизнес-целей.
Скала хороша только если жить где-то в Тель Авиве, Нидерландах или Берлине, где реально есть выбор работы на Скале. 3 года писал на Скале, захотел работать по удаленке и уехать из богатого на хайтек района — пришлось вернуться на Джаву. А теперь как ответственный за проект я тоже буду бояться выбрать Скалу; я то на ней быстро напишу, а вот людей в команду не найду.
"Java сидит на берегу реки и с философским прищуром смотрит как мимо проплывают трупы всяких #"
Программирую на Scala, C# и F#. На Java не пишу более двух лет.
После этого люди в круге начали аплодировать. А если серьезно, то и что? Я не пишу на C# уже лет 7-8 и ни разу не пожалел, но это тоже ничего не доказывает.
когда они поняли что надо пилить фичи, то уже было слишком поздно.
MS с .net долгое время игнорировало Linux и нормальную кроссплаформенность, преследуя корпоративные интересы, пока носом не уперлась в тот факт, что большинство серверов, увы, не на винде. Сейчас делаются очень правильные шаги, но много времени упущено.
Главное никогда не признавать ошибок.
Язык это же не только синтаксис, а еще инфраструктура, коммьюнити, инструменты и т.д.
Так вот я и говорю: хорошие программисты не хотят писать на Java — они увидели, что можно в Scala и в Kotlin и всё — они потеряны для Java. И все коммьюнити не может ничего без основных контрибьюторов.
это как то… как то уж очень категорично
хорошие программисты не хотят писать на Java — они увидели, что можно в Scala и в Kotlin и всё — они потеряны для Java
Года 3-4 назад прошел два курса Одерского по Scala, написал на ней домашний проектик, который до сих пор работает, хотел было устроиться на Скалу по работе, но не получилось. Спустя несколько лет успокоился и теперь от предложений на Scala отказываюсь, пишу на Java. От Scala осталось одно разочарование, о котором писал выше. Котлин тоже немного попробовал. Да, неплохо, но и не настолько хорошо, чтобы ради синтаксических плюшек менять работу (тем более вакансий на котлине совсем мало пока). Может, правда, я не очень хороший программист, поэтому не потерян для Java.
Вангую правильную потребность в Kotlin через год-два по всей России.
Котлин — говно. Много косяков в дизайне. Не взлетит, даже не надейтесь. Ни в России, ни где-либо еще.
Много косяков в дизайне. Не взлетит, даже не надейтесь.
Простите, а какой язык из уже взлетевших может похвастаться идеальным дизайном без косяков?
Это я к тому, что качество дизайна может быть и влияет на успех языка, но точно не является определяющим фактором.
Простите, а какой язык из уже взлетевших может похвастаться идеальным дизайном без косяков?
В том и смысл, что они уже взлетевшие. Так что новому языку надо конкурировать с существующими решениями, а не в вакууме. Например, те же плюсы в 2018 умерли бы не родившись.
И кстати, чем дизайн Котлина по вашему мнению хуже, чем у существующих решений? Какие там страшные косяки?
Например, те же плюсы в 2018 умерли бы не родившись.Не подскажите, кто бы занял их место?
Когда я придумал термин ООП я не имел ввиду C++ (с) Алан Кей.
Ну и если мы говорим про провославное ООП и Rust: https://github.com/actix/actix
Наследование данных
composition over inheritance и все в таком духе.
Интересный момент — даже Страуступ признает что добавление protected в плюсы было ошибкой (очень легко неявное поведение организовать, всякие LSP нарушить, контракты сломать)
А без protected стэйта мы можем ограничиться наследованием об абстрактных классов без состояния (ибо если там приватный стэйт — скорее всего лучше вообще вынести это дело как зависимость, опять же композицией/агрегацией).
Опять же, идеям "ооп" в плюсах лет больше чем это самое ООП существует (Хоар классы описывал задолго до того как Алан Кей сказал кому то что он "ООП делает")
Lisp более ОО чем C++.
виртуальные деструкторы
Именно деструкторы? И именно виртуальные?
Зачем вам деструкторы, если за вас компилятор расставит где почистить ресурсы, высвободить память и т.д.
composition over inheritance и все в таком духе.Не знаю, я нашел обсуждение на хабре, из него вытекает, что в rust'е есть наследование поведения, но не данных: habr.com/post/309968/#comment_9805712
Зачем вам деструкторы, если за вас компилятор расставит где почистить ресурсы, высвободить память и т.д.А как же неуправляемая память? Возьмите OpenGL: текстуры, буферы, шейдеры — все они создаются в видео-памяти — вряд ли rust будет ее разруливать сам. Ну и опять же, чтобы не вызывать всякие file.close(), socket.close() и т.д. Или как там дела с этим обстоят?
но не данных
поясните что вы имеете ввиду. Мне кажется что для вас "расширение данных" это просто расширение структуры. Что-то типа сишного варианта:
typedef struct foo {
int a;
} foo;
typedef struct bar {
struct foo;
int b;
} bar;Нужно все же понимать о чем вы говорите, пока не понятно. Ибо "наследование данных" это какой-то процедурный концепт.
А как же неуправляемая память?
Она как раз неуправляемая, в том смысле что за всем следит компилятор. задайте явно вашим файлам и сокетам скоуп жизни и компилятор сможет определить когда вам больше не нужен ресурс и сам все закроет и сам все почистит.
Ну и да — деструкторы в rust все же есть
Уже взлетел, в России и мире все андроид-разработчики на него переходят.
А вы про какое табло?
Я про табло реальных вакансий. Хайп хайпом, это нужно, это попытка совершить прогресс и все такое, но в сухом остатке, в суровой реальности, востребованным остаются в основном уже опробованные языки и технологии. И так будет очень долго, потому что конечный потребитель, заказчик прежде всего умеет считать деньги. А ЯП выжившие после конца хайпа, могут запросто занять одну, какую-нибудь узкую нишу. И вполне себе там жить.
Никогда не интересовались, как получилось, что Java стала таким говном? А мне это очевидно (как и то, что Java — говно, как язык)
«Начали за здравие, закончили за упокой».
Вот Вы обвиняете Java в том, что к ней не так быстро прикручивают новые идеи. Легко обвинять экосистему которая плодотворно развивается с конца 90-х годов, на которой написаны сотни тысяч _ПО НАСТОЯЩЕМУ_ больших бизнес приложений. Это уже часть мира, без которй не прожить. Большая «Экосистема» должна быть обратно совместимой как минимум. Новые ЯП с новой семантикой как раз и появляются по причине того, что ЯП ставшие стандартами отрасли не могут позволить себе менять кардинально свой стандарт на каждый новомодный чих и пых.
Я использую java с 2002...03 года. Я использовал реализацию comet уже тогда, когда слово «web-socket» еще не слышал практически ни один фронтендщик, да собсно говоря и node.js еще не было. Я уже делал реальные проекты и бэка и фронта только на java и они до сих пор работают. Представьте себе на сервере с 2гигами памяти, 1 ядром и db на нем же.
Поэтому, когда я писал про берег реки, поверьте, я писал о личном опыте. Много воды утекло с тех, а java есть и еще очень долго будет. Просто потому, что это реально удачный ЯП. Просто потому, что она заставляет соблюдать высокий стандарт разработки. Просто потому, что выстрелить себе в ногу на java достаточно проблематично. Даже если какому нибудь джуну очень захочется.
А новые языки всегда будут. И адепты нового языка будут говорить, что Scala это прошлый век, что она не реализует новые идеи.
Хайп всегда проходит, остается сухой остаток. Вопрос его количества. И у java он один из самых больших за последние 20..30 лет.
А еще мне кажется, что если некто, скажем, будет сваливать по месяцу 4 раза в год, не показывая при этом экстраординарной производительности остальное время, его очень быстро попросят на выход.
Всё становится гораздо проще, если понимать особенности местного законодательства, а именно, Калифорнийского. Накопленный и неотгулянный отпуск надо оплатить при увольнении (неважно, по чьей инициативе) -> расходы * на высокую текучку кадров -> дорого. Если отпуск нелимитированный, то он не накапливается, следовательно, при увольнении компания ничего не должна. Профит.
Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте» так не делают.
А зачем в тайпскрипте абстрактные классы если ими нельзя пользоваться? В чём сакральный смысл понятия
Потому что в тайпскрипте» так не делают.?
(Простите за профанство, сам не тайпскриптер)
Можно пользоваться, но пользуются редко (тк на джаваскрипте так тоже никто не делает).
Однако, называть это профанством я бы не стал. И прям выносить приговор квалификации разработчика — тоже не стал бы.
Вот есть у вас 2 модуля, A и B, один зависит от другого. Как сделать инверсию зависимостей в какой-нибудь Java? Добавим интерфейс в модуль A и B его будет имплементить, направление зависимостей уже меняется. Как это делать в TS? Примерно так же, только имплементить интерфейс не нужно. Типы либо сходятся либо нет.
И в целом как и в случае с Java необходимости в абстрактных классах практически нет (опять же после появления возможности объявлять дефолтное поведение в интерфейсах). И в целом в java как по мне абстрактные классы представляют ценность только для обратной совместимости.
И это типа хорошо?
хорошо или плохо — не очень то инженерные понятия.
то надо пересобрать все клиенты, чтобы проверить, что типы сходятся. Не так ли?
все так, на уровне одного модуля все с типами хорошо, на уровне другого — не сходятся. Но на практике все не столь уж плохо что бы отказываться от преимуществ подобной "утиной типизации в компайл тайме".
Опять же, тут думаю стоит еще учитывать особенности системы модулей, которые сильно уменьшают риски от вот таких вот изменений (явно прослеживаются зависимости модулей, что позволяет отследить по иерархии зависимости все что надо на всякий случай протайпчекать)
Хз, как в этом тайпскрипте всё, но я утиной типизации уже по уши наелся в темплейтах C++ и не отказался бы от тайпчекинга до мономорфизации, а не после, например.
В TS если делать полный тайпчек сразу, то не будут нормально работать mapped и conditional types, т.к. чтобы тип проверить, его надо сперва сконструировать, если конструкции выражать сразу в исходном типе то для простых вещей, котоыре сейчас делаются в две строки, придется писать тонны type-level кода. Так что в итоге там процесс мономорфизации с процессом чека сильно перемешаны, по сути это один процесс.
Не, поймите, я сам иногда мечтаю об анонимных неявных тайпклассах в хаскеле.
Наверное, вы хотите просто записи с Row Polymorphism.
Стало как-то утино и хрупко: если я меняю код реализующего интерфейс, то надо пересобрать все клиенты, чтобы проверить, что типы сходятся.
А жалко что ли? Пусть пересобирается, я пека покупал не для того, чтобы он стоял.
В данном случае, класс с реализацией — и есть контракт.
Но и интерфейс отдельно выделить не мешает никто, если хочется.
Если вам важно заранее проверить что ваш класс удовлетворяет интерфейсу — то ключевое слово implements никто не отменял.
«дайте немного времени на беглое чтение спеки, и я готов работать с этим говном
Я, конечно же, сделал вид, что просто мои коллеги — бездарные идиоты. Обычно это помогало, но в этот раз остался осадок.
Чем сильнее человек ведет себя как высокомерна задница по отношению к другим людям — тем тяжелее ему потом признавать свою не правоту.
Часто такое встречал у свежеиспеченных «молодых» CTO и архитекторов (знаете, такие типажи, которые во всех публичных местах добавляют себе подпись CTO?) )
Ну а дальше — в дополнение к комплексам и отсутствию воспитания, биология делает свое дело: когда уровень энергии падает — офисный мачизм превращается в бездну рефлексии.
Осознай и прими что ты «не самый умный» и как писали выше: это всё ерунда — «плюнуть и растереть».
Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте» так не делают.Можно подробнее? Что не так с абстрактными классами тайпскрипта?
Мой самоприсвоенный скилл «Я научился быстро учиться» оказался неправдой.Не согласен. Многие сразу отказываются что-то там делать на основании, что они этого не знают. Я вот не отказываюсь, даже наоборот. Но сразу предупреждаю о том, сколько времени понадобится на изучение, и что именно я смогу после этого сделать.
Да и вообще, когда переходишь на новое место, с языком и технологией обычно разобраться проще всего. Сложнее — с фреймворками, если их не видел. А больше всего занимает понять то, что написано до тебя. Тут как раз сеньерность и помогает больше всего, т.к. если уж видел какой-нибудь хитрый паттерн, даже на другом языке, то сразу его узнаешь и время на дебаг и понимание сэкономишь.
Актуально не только для кода. В принципе человек может учить все, главное правильно структурировать знания. Затем появляется вопрос о качестве этих знаний. Как только задаешься этим вопросом то понимаешь одно… ты ничего не понимаешь и знаний у тебя практически нет. Думаю именно с этой точки начинают развиваться хорошие квалифицированные специалисты.
И еще, очень важно уметь признавать свои ошибки, а не винить всех в «непонимании».
Автору спасибо, статья понравилась)
Я Full Stack и, наверное, вы правы, что я не очень глубоко знают каждую технологию в отдельности, но это касается больше фреймворков, чем самих языков, так как языков очень мало и их спецификация не так сильно меняется. Мои проф языки: php и javascript, вспомогательные: nodeJS, C#
Как видите проф языка, только 2, если вы считаете, что это много — то это грустно, надо больше кушать Омега 3 ;-)
Так как я не ориентируюсь на галеры, то я не изучаю все фреймворки, конкретно сегодня я работаю исключительно с Angular и PhalconPHP. То есть по одному фреймворку на язык. То есть всего 2 фреймворка, что тоже очень мало.
Базы данных — только Mysql и больше ничего. Я не говорю, что другие базы плохие, это просто мой выбор.
Получается, я Full Stack, но я не стремлюсь знать все, я ограничиваю себя и не расширяю навыки по инструментам, если мне нужен будет Java специалист — я его найму, если Python — тоже могу нанять, но в своих технологиях я эксперт. Конечно, всегда есть кто-то лучше.
То что я Full Stack помогает мне консультировать клиента и решать его бизнес процессы, вы думаете Менеджер может это с легкостью сделать? А кто будет решать какие технологии использовать?
Более того, на массовом рынке Back end очень простой, это по сути разработка API, подключиться к mysql и отдать json — что тут сложного?
— Более того, будучи Full Stack, что вам мешает улучшать одну технологию, а другие технологии для базовых вещей? Вы же понимаете, что 80% рынка просит самый простой функционал, на беке — это REST API и это уже на столько избитая тема, что она уже просто автоматизирована.
Например, так как я Full Stack, я смог написать Sprite генератор для SVG файлов на NodeJs, чтобы запускать из под Gulp. Кидаешь все SVG в одну папку и код генерирует html c очищенным от стилей svg и так же генерирует отдельную страницу, которая предлагает copy/paste svg use — теперь можно svg спрайтить недумая без рутины. Front End так не может ) и много таких вещей.
Своим подчиненным я всегда говорю, что веб разработка — это не Rocket Science и хватить ныть )
— Хотел бы заметить, что шкала навыков очень широкая, и один специалист узкого направления может проработать так лет 10 и быть хуже Full Stack в своей же спецификации, а может и лучше раз в 10, все это частные случаи.
Утверждать, что Full Stack сразу хуже узких спецов — ошибочно, у меня вот по тестам Upwork — top 10% в PHP Advanced, интересно, остальные 80% это кто? А кто те, кто круче меня? Full Stack или Back end )
— Пора понять, что жизнь сложна и хватит высокомерно оценивать людей терминами и ярлыками. Вам нужна другая метрика, например деньги или репутация, значимость.
Фулстек, говорили они. Сейчас я успокою всех переживающих фуллстеков и дам возможность почувствовать себя глубокими профессионалами. Я называю себя дилетантом широкого профиля. Чем мне приходилось заниматься и что я знаю, где-то больше, где-то меньше:
- C# (WinForms, MVC, немного WPF).
- Сюда же к вебу классическое: HTML, CSS, JS. На всякие реакты посмотрел одним глазом, но опыта практического нет
- C++ неплохо, но знаний и опыта в разной хардкорной и не очень темплейт-магии не достает
- Android (Java и один маааленький проект на Kotlin)
- Микроконтроллеры
ArduinoAVR ATmega и STM32 - Околоробототехническое: ROS, компьютерное зрение (посредственно) и что-то в этом духе.
Актуальный вопрос в лоб: что выгоднее, быть вечным фулл-стек мидлом или гипер-сеньором в узкой отрасли, которая может сдохнуть в пределах пяти лет?
Быть синьор фулл стеком и не считать мнение автора из интернета абсолютной истиной.
Учите фундаменталку, «нинужные» алгоритмы и вот это вот все — и будет вам счастье.
По моему проблема просто в этом
и убедил себя, что теперь-то могу действительно всё. Я абстрагировался, мыслю в нескольких парадигмах программирования одновременно и обладаю практическими знаниями во всех аспектах профессиональной разработки ПО
вы просто застряли в развитии, а потом вынырнули и осознали жестокую реальность
В чём удобство знаний (и опыта) в нескольких направлениях — без работы никогда не останешся.
Бичевать себя что знаешь меньше чем коллега посвятивший технологии(языку) 10 лет? пффф. Не смешите.
Каждому своё (так было написано на одних воротах). Делайте то что Вам нравится и получайте от этого удовольствие. IT сфера хороша в том, что может быть хобби, за которое платят неплохие деньги. Ведь айтишниками не становятся, ими рождаются.
И вы не страдайте напрасно, найдите для себя новое направления и изучите его, раз это приносит вам удовольствие и доход )
… если ты не знаешь ни одного — еще как важен. См. Синдром Утёнка.
Мне кажется что тут налицо простая подмена понятий. Фуллстек — не объем знаний в разных (условно говоря) языках программирования. Фуллстек означает, что я знаю как оно все устроено внутри. Надо SQL базу — запросто, фронтэнд — не проблема, REST сервис — как два пальца. Desktop GUI — ой как хорошо, вообще запросто. Микросервисы на отдельных инстансах с отказоустойчивостью — легко. На асме вставочку — ну если десяток строк… С железякой какой-то нестандартной поговорить надо — запросто… Фуллстек это когда понимаешь как оно все работает отдельно и в связке. Фуллстек это знание всей внутренней кухни. А на чем все это делать (фреймвоки, языки и т.д.) — вопрос даже не второй. Если это работает быстро, стабильно и легко поддерживается. Да хоть на бейсике. Какая разница то?
Синьоры, которые застревают в рамках одной технологии обычно еще хуже, чем фуллстек разработчики.
Спасибо за статью. Я долгое время считал также как вы — старался развиваться вглубь в одной экосистеме. Потом углубился в фундаменталку и пришел к выводу что ориентация на специализации, экосистемы, языки и уж тем более фреймворки — это все от лукавого.
В программировании все суть одно и то же — одна и та же простая математика за всем. Это не какая-нибудь юриспруденция где абсолютно разный свод законов работает в разных случаях.
Наверное программирование можно сравнить с бухгалтерией, а языки/технологии с бухгалтерским софтом. Если компания нанимает бухгалтера для работы с определенным софтом, то она нанимает просто оператора этого конкретного бухгалтерского софта, а не бухгалтера. Точно также если компания нанимает фронтэнд разработчика. Только в отличии от бухгалтеров, программисты мало кому нужны — чаще нужны те самые операторы.
Я верю что название Fullstack разработчик появилось лишь как способ сказать что нужен просто разработчик ведь в IT так много названий.
Ну и напоследок, одно из отличительных качеств сеньор разработчика — это наставничество. И кажется мне специалисту узкого круга менторить за пределами его узкого кругозора будет крайне сложно, что ставит под сомнение вообще возможность существования сеньор разработчика с узким профилем.
Наверное я мало видел проектов, но точно скажу, из тех проектов, что я видел, успешными стали только те, в которых разработчик(и) не пренебрегали предметной областью. Причем один такой неуспешный проект делался одновременно с другим. В итоге после полутора лет и трат выраженных 7ми значными числами в рублях, этот неуспешный проект был поглощен тем вторым, который делался, имея в своем базисе крепкое знание и понимание предметной области. При этом команда второго проекта постоянно проводила консультации для первой команды. И поглощение выглядело как "просто 301-й редирект" (это вебпроекты были). Взять и переюзать что-либо было просто нереально.
Разобраться грамотно в предметной области — это половина успеха и половина проекта. Даже для "кодера" джуна.
Когда я только начал учиться кодить, я поверил старым мудрым засранцам с их мантрой «язык программирования не важен».
Все правильно, так оно и есть: когда Вы только-только начинаете учиться программировать, сам по себе язык программирования, с которого начинаете, не так важен. Именно это Вам и сказали когда Вы начинали. Та же Arduino была создана как платформа для обучения с пониженным порогом вхождения для новичков. Способности у каждого человека очень разные, так уж природа распорядилась, поэтому, по аналогии, русский язык может освоить любой житель планеты, но вот Александр Сергеевич Пушкин, Достоевский, Толстой, Булгаков — единственные в своем роде.
Но в IT если ты не обновляешь свои знания о технологии в течение года, ты уже не актуален.
С C++ Это тоже работает?)
Есть успеные люди, которые каждые пару лет перепрыгивают на хайповые языки и снимают сливки.
Есть фуллстеки, которые просто не могут изучить все, но в 99% этого и не требуется.
Есть экперты по направлениям, но они тоже смотрят по сторонам. Доклады по продуктам MS читают эксперты, но при этом они тыкают соседние технологии.
Правильного пути нет, есть баланс между желанием, возможностью и потребностями.
Схема:
Человеческий мозг ограничен в своих возможностях. Не слышал про людей которые в совершенстве владеют всеми языками существующими в мире, в уме умножают стозначные числа, и в деталях помнят кажду секунду своей жизни. (все это один человек)
Поэтому приходится делать выбор из множества варинатов. Емкость коробочки в которую все это складывается ограничена. Возможно у одного она 10 кубов, у другого 25. Одна коробка хранит все по полочкам, а другая в хаосе, и поиск в ней осуществляется с другой скоростью. И коробочка то не простая. Чем больше в ней лежит, тем проще туда добавлять. Похожие элементы занимают меньше места. Но все равно это очень сложно и долго.
Единственный контекст, в котором я бы согласился с заголовком — фуллстек — не источник денег.
Знание своих слабостей и сильных сторон — важнейшая черта для опытного специалиста, именно этот навык определяет, какую выгоду вы можете принести себе и проектам, с которыми вы работаете.
До тех пор, пока фуллстек(и любой другой специалист) отдает себе отчет в том, что он может сделать и в том, чего не может, это отличный путь, позволяющий сэкономить средства компании, проявить себя как основатель стартапа, архитектор или просто хороший разработчик.
Тренироваться на фуллстека — ребячество, никто не станет платить вам больше, никто не уверует в вашу универсальность, а если вы переживаете моральный кризис — "я так мало умею", его удастся исключительно усугубить.
Это навыки, которые возможно получить, работая в соответствующем окружении: пытаясь создать проект в условиях ограниченных ресурсов; руководя командой из разношерстных специалистов; увлекаясь по выходным моддингом майнкрафта и сражаясь с читерами, бесконечно читая книги и статьи от безопасности и до модных дизайнерских фич, будучи больше, чем специалистом на найм, идейным фанатом своего дела.
Фуллстек — элементарное стремление человека к созданию чего-то большого своими силами
Нужно сделать репликацию для оракла? Да. Поправить отчёт SAP'е? Да. Починить потерю пакетов в SDN с онлайн-интроспекцией? Да. Кривая метрика виртуалки в openstack'е? Да. Падают тесты в maven'е при сборке deb-пакета на jenkins'е? Да.
Но при этом он совершенно не разбирается в нюансах и деталях. Но на него есть спрос. Человек который может прийти и начать исправлять необъятное.
Несмотря на твои огромные усилия, каждый знаток конкретного языка будет с пеной у рта доказывать, что ты не достоин называться сеньором.
Может стоит меньше слушать «знатоков» языка и заниматься тем, что тебе нравится?
Если между технологиями перерыв 5 лет — то забывается многое и остается пробел в знании когда выходит новая редакция языка.
Особенно если после С++ ныряешь в TSQL через несколько лет в памяти только общие детали.
Cамые лучшие программисты — те, кто понимают, насколько ограничены их возможности. Они скромны. Худшие программисты отказываются признать, что их способности не соответствуют задаче. Характер не позволяет им стать отличными программистами. Чем усерднее вы работаете над компенсацией ограниченных возможностей своего разума, тем лучше будете программировать. Быстрота вашего развития напрямую зависит от вашей скромности.— Св. Евангелие от Макконнелла
Абстрактные классы в JS? Глупость. Надо ли для этого знания тратить 10к часов на JS? Нет.
То есть в первую было вложено 10к. Во вторую — 8к. В третью 5к. В четвертую, пятую шестую — хватит 1-2к.
Я пишу на том, на чем придётся. Но я следую коду который уже есть вокруг. Да, мой результат может быть хуже, чем если я потрачу время и объясню каждому из 5 узких спецов, чей код я правил по дороге, и они потратят время на переписывание правильным образом.
Вместо этого я потрачу немного усилий, решу проблему перетреся 5 параллельных технологий и сервисов, после чего оно уже работает как надо, а узкие спецы когда-нибудь доберутся и причешут код за мной. Если понадобится. Обычно редко требуется.
Не «идиоматично»? Зато O(N) вместо O(N^2), потому что «я пол бака и ты пол бака, вместе оно полюбому бак будет, да?» (ц) день радио.
А насчет того, что нужно бизнесу. Бизнесу нужны разработчики, которые понимают бизнес. И способность осмыслить задачу, а не просто переложить ее на циклы и условные ветвления; задать корректные вопросы, уточнить моменты — которые могут быть либо пропущенными аналистом либо вообще некорректно проанализироваными — вот что надо бизнесу.
Обширные знания в смежных областях нужны и важны (если вы только не с ЕПАМа), хотя бы для того чтобы быстро переквалифицироваться если вдруг загнётся абстрактный Яваскрипт.
Меня всегда удивляли фронтенд-разработчики, которые не знают как работает чистый Яваскрипт, как написан тот же Реакт и что он из себя представляет внутри, что надо писать в консоль сервера на Дебиане, каким образом клиент с сервером обмениваются данными, как работают браузеры, ДНС и интернет в целом и т.д.
Программисты нужны не для того, чтобы хорошо знать «TypeScript», а чтобы уметь эффективно решать проблемы. Этот навык приходит исключительно с опытом и изучением фундаментальных наук (математика, логика, алгоритмы).
В определённый момент действительно уровень абстракции повышается до нужного уровня: начинаешь думать не об абстрактных классах и синтаксисе деструкторов, а о том, как решить задачу, что дано и что требуется, как данные текут через систему и трансформируются, какие у системы состояния и инварианты.
Я изучил C# и .NET с разными областями применения (asp.net, wpf, xamarin), js/ts (react/redux, node) и убедил себя, что теперь-то могу действительно всё.
Это что ли много?
Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).
— http://norvig.com/21-days.html
Я бы добавил к этому списку языки, которые обладают выразительной модульной системой (OCaml, Standard ML) и языки, которые помогают осознать соответствие Карри—Ховарда: Coq, Agda, Idris или F*.
Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте» так не делают.
А кого волнует, что там кто делает или не делает в «TypeScript»? Надо уметь обосновать выбор дизайна. Идиоматичность дизайна является одним из факторов (к примеру, в математике никто не будет обозначать целое число буквой большой буквой S), но если преимущества (простота в поддержке, эффективное использование ресурсов, лёгкость в отладке) «неидеоматичного» решения перевешивает недостатки, аргумент «так никто не делает» выглядит довольно нелепо.
Тут все от человека зависит, кто-то упарывается в то чтобы быть лучшим специалистом по левой ноздре, но абсолютно не хочет лезть в правую, считая это не его компетенцией, а кого-то больше интересует как работает организм вцелом. Это из детства идет — одни выбирают кружок для досуга и спортивную секцию (или родители чаще всего выбирают) и ходят до победного, а другим интересно попробовать себя в разных сферах. Я вот с детства например занятий 20 точно сменил, и танцы, и автомодельный кружок, и плавание, и рисование, и литературный кружок, и много-много чего еще, а потом отучившись в одном институте понял что не мое, и совсем в другой сфере защитил кандидатскую, потратив дополнительно 7 лет. Мне интересно очень многое, и последнее что будет меня в жизни сдерживать — это какая-то классификация разработчиков. Если даже придется начинать с нуля, менять стек или даже профессию, ничего страшного нет в том чтобы не быть «сеньором» в чем-либо, главное чтобы было интересно (ну конечно если условия позволяют на эти деньги выживать). Очередной вон кризис грянет — и половина сеньоров под сокращения попадут или просто конторы обанкротятся. Меня 2 раза в жизни заставало такое дело, в 2008 (правда тогда не было никаких финансовых обязательств, и за душой тоже ничего, и терять особо нечего) и в 2014 (когда на пару лет пришлось вообще сменить профессию, чтобы тупо выжить и уже было что терять). В общем, каждый решает для себя сам чего ему нужно. Я с основной мыслью статьи не согласен совершенно категорически, однако это не означает что я ее не понимаю, просто не мое. Всестороннее развитие и возможность выбирать его вектор в каждый момент времени — это настоящая свобода для живого мыслящего человека.
Однако скольким из них посчастливилось попасть на такой проект и стать единственным незаменимым?
С бытовой точки зрения удобнее иметь широкие пусть и не глубокие познания. Чтобы можно было адаптироваться и переориентироваться в любой момент. Динамика спроса на рынке растет.
У нас сейчас даже так делают, берут одного сениора, пару мидлов и добирают джунами. Сениор и миддл приезжают на проект на пару месяцев, впитывают знания, а потом обучают команду у себя за границей — такой аутсорс и масштабирование. Т.е для рентабельности проекта нужно иметь набор низкооплачиваемых, не загруженных специфическими опытом и знаниями людей. В которых можно закачать что-то при необходимости.
Причём ты всё ещё будешь недосягаемо хуже разраба, который каждый день пишет исключительно на тайпскриптеСогласен, вот мой основной язык питон, я на нем пишу тестовые скрипты для сквозного тестирования. Я понимаю общую архитектуру нашего приложения, которое написано на яве. Я могу читать код приложения на яве, могу по стектрейсу определить где программа выкидывает ошибку, запустить дебаггер. И даже выяснить источник ошибки.
Но! Решить этот баг я просто не осмелюсь, потому что не знаком с устройством этого конкретного кода. Я не знаю какие побочные эффекты вызовет присвоение переменной в методе, я не знаю из каких разных мест этот метод вызывается и т.д. и т.п. Не имея полной картины устройства этого кода лезть в него глупо и даже, я бы сказал, безответственно.
Т.е. даже знания языка не сделают тебя автоматически разработчиком конкретного приложения. А ведь именно на это надеются кадровики? Что можно будет перекинуть человека с одного проекта на другой. Но сложность-то не во владении языком, а в продукте который разрабатывается. Конечно человек разберется со временем, но далеко не вдруг и не без посторонней помощи.
Но если мне вдруг скажут: «Алексей, сворачивай свой тестировочный лагерь — ты будешь помогать команде разработки писать приложение» — то я втянусь и наверное значительно быстрее чем человек со стороны, потому что есть общее понимание архитектуры. А с кодом можно познакомиться по ходу дела. При наличии боевых задач, обсуждать решения с более опытным разработчиком, делать код ревью, то-сё. И в конце концов точно стать не хуже среднего.
Не иди путём Спеца.
Иди Своим путём.
Как всегда: ещё один, считающий, что Web-разработкой и написанием "бизнес-логики интерфейса", разработка ограничивается.
Теперь, когда мне нужно поработать на каком-нибудь нелепом питоне
Что?
Причём, человек на полном серьёзе рассуждает о том, что "нужно бизнесу" и как подстроиться.
Зачем тогда идти в разработку? Ради бизнеса или "потому что IT — модно"? Так лучше идти в бизнес: солиднее и денег больше заработать возможно.
Фулстеки это мидл программисты и одновременно джунер архитекторы. Карьерная лесница для Фулстека не так печальна, но она будет все больше абстрагироваться от кодинга. Если же нет сил или желания становиться манагером или архитектором, то на самом деле никогда не поздно закрыться в любимой технологии и набивать руку в течении двух трех лет и сознательно игнорируя все остально. Не смотря ни на какие ухищрения манагеров заставить вас делать, что-то из всего остального. Два года для мидла более чем достаточно чтобы стать синьером. Мы становимся лучше в том чем занимаемся каждый день. Или как говорил, кажется, Брюс Ли — я не боюсь человека, который знает тысячу приемов, я боюсь того кто тысячу раз учил один единственный прием.
закрыться в любимой технологии и набивать руку в течении двух трех лет и сознательно игнорируя все остальное
Технологии за годы устаревают.
И потому, если не хотите потом заниматься легаси, имейте запасной вариант.
Для меня, когда Delphi сдох, запасным вариантом стал PL/SQL.
worldmindА человек, который по-вашему, worldmind, видит и понимает всю картину совсем не нужен?
текущая трактовка термина фуллстэк противоречит всей логике развития цивилизации, которая всегда шла по пути спеуиализации, разделения труда и получала на это профит.
Причина необходимости фуллстэка в том, что типичный проджект-менеджер управляющий сложным проектом со множеством узких специалистов, может их просто не понимать.
Что вы имеете ввиду?
рейтинг TIOBE, думаю, сами нагуглить сможете.
Вы бы сами сперва погуглили прежде чем вот так вот взять и сесть в лужу. В tiobe дельфя на 13 месте, обычно в первую десятку входит. и работы на ней более чем достаточно. Рейтинг hh отражает всего то навсего текучку кадров и количество стартапов, связанных с веб. Программисты для десктопа тоже — внезапно — нужны. А на десктопе к вашему сведению дельфя как присовывала всю жизнь java/C# по стоимости разработки и производительности (а с++-у по стоимости разработки), так и присовывает
давайте не будем устраивать здесь очередной делфисрачТак не делайте необоснованных утверждений впредь, и признайте, что сказали про delphi не подумав.
Вы так говорите, как будто 13 место — это отличный результатЭто значит что утверждение «Delphi сдох» — брехня
Не «обычно входит», а «раньше входил» (вполне заслуженно в те года, надо отметить)Год назад был на 9-м месте. Стало быть, за год всё круто изменилось. Когда рейтинг тиобе стал двузначным — делфи взял и сдох.
сейчас по умолчанию имеют веб-морду как интерфейс, а не десктопное GUI-приложение.
К чему здесь эти рассуждения и что именно вы сейчас доказывали?
И этот человек мне говорит «не делайте необоснованных утверждений». Смешно.
Истинность моего утверждения ни кто и не оспаривал чтобы мене его обосновывать
Термины уровня чотких дворовых пацанчиков на хабре. Внушает.У дворовых поцанчиков меньше бреда и каши в головах, чем у некоторых хабровчан
Изначально про «сдох» сказал не я, а хабраюзер DelphiCowboy, судя по нику, в прошлом сам заядлый дельфист (как и я, кстати говоря).То есть вы с ним не согласны? в таком случае не понятно к чему был ваш комментарий про Hh.ru и tiobe
Я все-таки просил не разводить срач, а вы его упорно пытаетесь начать.Вы что, вахтёр, бегающий по веткам комментариев в поисках срача? В таком случае поясните, по каким признакам вы его обнаружили у меня. Я отнюдь не дельфист как могло бы показаться. Но с дельфями сталкивался, и бонусы, которые они дают, знаю. В частности, про вещи, типа «treeview с данными», которые в дельфи сделаны идеально, в гопнете как-то «так». Просто кое у кого вечная паника при слове Delphi/Pascal. Меня это слегка коробит, потому и тригернуло высказывание про дельфи сдох. А вы тут же — срач…
Вам другой юзернейм, в принципе, уже ответил.
От себя добавлю:
1. Измерять что-то количеством ваканский, конечно же, можно, только выводы оно в реальности даст не те, которые вы хотели бы видеть. Т.е. можно сказать, что «по Delphi количество вакансий в Х раз меньше, чем по Y». Да и это будет ерундой, потому что нужно учитывать время, сезонность (да-да! отчеты финансовые никто не отменял), срезы и т.п. И уж точно говорить, что Delphi умер — это, мягко говоря, малограмотно.
2. В Северной Америке дельфистов разбирают моментально. Не потому, что они супер и технология крутая, а потому что в нем можно делать отчеты быстро. Что не дот-комы очень любят. А когда они еще и видят, что тот же отчет можно выкатить в виде мобильного приложения без особых на то усилий, то владельцы бизнесов плевать хотели на какой именно модной технологии оно сделано и сколько вакансий опубликовано.
3. Исходя из п.2, в той же Северной Америке часто хотят секретарей и прочих непрямых ИТ-работников со знаниями Делфи от секретарш до сейлзов. Индустрии, где любят Делфи: retail, hospitality и пр., связанное с конечным потребителем.
Ну и confirmation bias никто не отменял.
не будем устраивать здесь очередной делфисрач
А что вы хотите, чтобы было если кто-то пишет космических масштабов глупость, опираясь на собственные ощущения и российский портал hh.ru? Или, что одна технология лучше другой, например, тот же Ruby хуже Delphi, потому что он на несколько позиций ниже в рейтинге популярности языков программирования.
Технологии за годы устаревают.Смотря какие технологии. Специализация это конечно же риск, но не всегда. Например Java и С++ намного старее, но они до сих пор актуальнее всех прочих. И да, конечно, нынешняя Java и то что было 20 лет назад это совершено разные вещи. Но ведь никто не говорит, что нужно перестать изучать новое. Просто если ты развиваешься вместе с технологией, то ты всегда будешь оставаться актуальным, и при этом не выпадать статуса сеньера. Поэтому не все так печально. Не нужно делать вид, что технологии это битва на вылет, где одна технология убивает другую. Иногда такое происходит, но не потому, что кто-то кого-то убил, а потому, что технология не смогла эволюционировать достаточно быстро под новые условия, и умерла своей смертью. Пример с Delphi как раз самый яркий. Они застряли на вершине своего развития в своем славном прошлом где-то в середине нулевых, и до сих пор там топчутся. Но пока они полностью не умерли то никто не исключает вероятности их новой инкарнации. Но очевидно, что если это произойдет, то это будет совершенно новая Delphi в которой старый опыт будет уже не актуальным, и все придется начинать с начала.
Автоматизатор, ок, будь добр настрой CI, подучи Ansible, и не важно что на реализацию этой задачи ты потратишь на пару недель больше чем нормальный девопс и скорее всего родишь не поддерживаемого уродца.
Все ли менеджеры такие? Конечно нет, но я же не думаю, что автора устроит быть гавноменеджером с узкими и поверхностными знаниями и нормально разбираться только в разработке, при этом пойти сходу на понижение ЗП, а для всех других ролей в команде оставаться вечным неучем и безруким, который даже не может настроить рекламную кампанию за пару часов.
А, ну собственно к чему это я. Рассказываю, что менеджером быть сложнее, чем программистом? Нет, я не преследую цели сравнивать вообще. Это может делать человек, который и в той и в той области добился больших успехов. Я говорю о том, что фулстечность это бич не только разработчиков и убегая от нее в коде можно попасть в ловушку фулстечности в управлении
Мужик явно запутался.
Фуллстэк — это относительная характеристика, говорящая о том, что исполнитель обладает (ну или, как минимум, заявляет что обладает) всеми необходимыми компетенциями чтобы полностью разработать продукт определенного класса от начала и до конца.
- Фрилансер клепающий сайты "под ключ" — фуллстэк.
- Вебстудия делающая тоже самое — фуллстэк.
- Отделочник по найму, который делает полный ремонт квартиры — фуллстэк.
- Сторительная компания, которая делает тоже самое — фуллстэк.
А теперь внимание: Если отделочник по найму, умеет делать всё, кроме укладки керамической плиты на потолке по диагонали в шахматном порядке, то он вынужден будет нанять отдельного специалиста. Аутсорс, как сейчас модно говорить. И пока он не перекладывает заботы по поиску такого специалиста на заказчика — он всё еще фуллстэк.
Если единственное, чем вы занимаетесь, это ловите проекты на фрилансе, а потом разделяете их на задачи и делегируете эти задачи соответствующим специалистам, при этом сами вообще не программируете, то вы (внезапно) тоже фуллстэк.
А теперь что касается, Junior, Middle(?) Senior.
Понятия Junior, Middle, Senior отражают уровень компетенций (нет).
То есть: они отражают, но не совсем так как многим кажется.
Стоит ли удивляться, что джуны, которых набирают в какой ни будь гугл, хотя и не имеют практического опыта* (или имеют но мало) разработки, способны запросто заткнуть за пояс в вопросах computer scince** любого "синьора-помидора" работающего в мелкой конторе.
Это скорее ранг внутри команды, чем уровень "крутости" специалиста.
Что же касается самой статьи… Если называть вещи своими именами, то всю ее можно свести к вот такому выражению :
Стать профессионалом широкого профиля — легко, специалистом узкого профиля — сложнее, специалистом широкого профиля — почти невозможно.
* Или имеют но мало.
** Я не говорю "информатика", потому что это слово вывернула на изнанку российская система образования.
Фуллстек — это человек который знает js+фреймворк(react, sencha ...)+css и какой-то из языков backend(java, python...)+ БД+общее знакомство c devops.
Естественно, у каждого уклон свой, у меня умный java-бэк, тупой фронт; другие поднимают graph ql+ круд-плагин для постгрес, а весь код пишут на js, потому что js им удобней, БДшники все на процедурах и триггерах напишут.
Без разницы, как именно ты напишешь приложение, лишь бы быстро и качественно. Нужно задействовать по максимуму свои сильные стороны для достижения результата.
И самым спорным решением конечно будет писать приложение на реакт+жава+монга, если ты знаешь ангуляр+пайтон+постгрес.
Такое понимание нужно, чтобы решать нестандартные проблемы, которые возникают, когда абстракции начинают протекать.
А потом, всякие бестолковые конторки испортили термин.
Проблема в том, что бизнесу нужны фулстеки— Это российскому
Ты везде будешь свой, но везде среди чужих. Несмотря на твои огромные усилия, каждый знаток конкретного языка будет с пеной у рта доказывать, что ты не достоин называться сеньором. Ты станешь вечным мидлом.
Быть сеньором != знать спецификацию языка наизусть.
Как один из примеров — senior android developer несколько лет кодил под андройд и довольно успешно, потом переехал в Европу и сменил род деятельности на бэкенд разработчика на java, при этом время от времени может еще писать вещи на js, android.
Другой пример, это вообще уникум — кодил на java, потом на scala несколько лет. После этого ушел попробовать себя в роботосроении на c++, где он написал аналог монад на с++. После этого он понял, что все это не то и ушел в анализ данных, запилил стартап, закончил школу анализа данных и успешно работает в этой области.
Как было указано выше в комментариях, можно пробовать себя в разных областях, но для начала, надо стать сениором хотя бы в одно из областей и проработать 3-5 лет, а дальше уже можно задумываться о смене деятельности или нового языка, тк бывает, что через 3-5 лет понимаешь, что чем ты занимался до этого уже не удовлетворяет твоей мотивации, что задачи уже не интересные, а ты сам уже способен на большее.
Я изначально начинал как html/css верстальщик, через 1.5 года верстки сайтов различной сложности, понял, что пора бы подключать всемогущий js и вот я набрал опыта в районе 5 лет на html/css/js со всеми этими react, angular, backbone, typescript, babel и подобными приблудами. Начал пописывать на nodejs и понял, что меня уже просто тошнит от фронта и от js в целом. Далее чудом мне повезло и я перешел в ios разработчики. Сначала перенял код на objective-c, а потом полностью переписал проект на swift + rx. В итоге уже более 2х лет на ios разрабатываю. Сейчас я понимаю, что после 8 лет кодинга, я прокачался по алгоритмам, дискретке и в целом в кодинге и понимаю, что мои знания можно применять в более интересных проектах, а не просто брать дизайн, заверстать, накидать кода с анимациями и сдать проект. И да, несмотря на 2 года без js, я взял проект на фрилансе по SPA приложению и успешно его сделал от html/css с модными flex-box, postcss и cssmodules, до react+mobx. И на воспоминания скилов ушло неделя.
Как итог: через 3-5 лет у некоторых сениоров в голове возникает мысль, что он получил достаточно опыта и знаний в конкретной области и языке и появились новые знания и силы, чтобы попробовать себя в чем-то другом. Все это конечно при условии того, что разработчик постоянно развивается и познает новые вещи в мире программирования, а не просто пишет код на одном и том же и делает однотипные задачи на своей постоянной работе.
Полностью согласен с автором — на рынке труда ценятся специалисты высшего уровня. А чтобы стать таким специалистом нужно долгие годы сидеть в одной узкой сфере. Хотя, какой узкой, даже бек часто совмещает в себе несколько специалистов — программист, спец по БД, админа по поддержке серверов.
Сколько бы я, бек, не читал книжек по Linux, я никогда не стану таким прошаренным в настройке и поддержке веб-серверов как профильный админ, который годами, целыми днями, только этим и занимается.
Во-вторых, со статьи кажется, что проблема в слишком большом разбросе используемых технологий – соответственно в поверхностном подходе. Все же «фуллстэк» тоже может быть специализирован.
Как один из примеров — senior android developer несколько лет кодил под андройд и довольно успешно, потом переехал в Европу и сменил род деятельности на бэкенд разработчика на java, при этом время от времени может еще писать вещи на js, android.
Другой пример, это вообще уникум — кодил на java, потом на scala несколько лет. После этого ушел попробовать себя в роботосроении на c++, где он написал аналог монад на с++. После этого он понял, что все это не то и ушел в анализ данных, запилил стартап, закончил школу анализа данных и успешно работает в этой области.
Как было указано выше в комментариях, можно пробовать себя в разных областях, но для начала, надо стать сениором хотя бы в одно из областей и проработать 3-5 лет, а дальше уже можно задумываться о смене деятельности или нового языка, тк бывает, что через 3-5 лет понимаешь, что чем ты занимался до этого уже не удовлетворяет твоей мотивации, что задачи уже не интересные, а ты сам уже способен на большее.
Я изначально начинал как html/css верстальщик, через 1.5 года верстки сайтов различной сложности, понял, что пора бы подключать всемогущий js и вот я набрал опыта в раойне 5 лет на html/css/js со всеми этими react, angular, backbone, typescript, babel и подобными приблудами. Начал пописывать на nodejs и понял, что меня уже просто тошнит от фронта и от js в целом. Далее чудом мне повезло и я перешел в ios разработчики. Сначала перенял код на objective-c, а потом полностью переписал проект на swift + rx. В итоге уже более 2х лет на ios разрабатываю. Сейчас я понимаю, что прокачался 7 лет кодинга, я прокачался по алгоритмам, дискретке и в целом в кодинге и понимаю, что мои знания можно применять в более интересных проектах, а не просто брать дизайн, заверстать, накидать кода с анимациями и сдать проект. И да, несмотря на 2 года без js, я взял проект на фрилансе по SPA приложению и успешно его сделал от html/css с модными flex-box, postcss и cssmodules, до react+mobx. И на воспоминания скилов ушло неделя.
Как итог: через 3-5 лет у некоторых сениоров в голове возникает мысль, что он получил достаточно опыта и знаний в конкретной области и языке и появились новые знания и силы, чтобы попробовать себя в чем-то другом. Все это конечно при условии того, что разработчик постоянно развивается и познает новые вещи в мире программирования, а не просто пишет код на одном и том же и делает однотипные задачи на своей постоянной работе.
К сожалению, автор, видимо пошел по другому пути.
Простите, но знания не определяют уровень специалиста, практически в любой области.
Важет подход к решению задач, уровни абстракции, опыт и извлеченные из него практики. По сути уровень разработчика определяется тем как он мыслит.
Мы программисты решаем задачи с помощью кода. Сам код не особо важен, он инструмент. «Так не делают в… языке/фреймворке» — не аргумент. «Так мы не делаем, давайте придерживаться общих практик чтобы удобнее было писать код вместе» или «Так не стоит делать потому что с этим будут вот такие-то критичные проблемы» — это аргументы. Надеюсь разница понятна.
Синьор это не насколько детально знает человек язык, и не насколько много языков он знает, это насколько хорошо он применяет эти инструменты для решения нужных конкретных задач.
Ну это как готовясь к выступлению на конференции основное внимание уделять разминке дикции и повторять грамматику языка на котором говоришь, вместо того чтобы готовить материал.
«Я не знаю, что там за типы индексов в SQL.» — главное что вы знаете что они есть и разных типов и на что влияют индексы, а дальше просто ищем информацию и работаем. Если появится новый тип а вы об этом не узнаете вы что резко потеряете свою квалификацию?
«Бам! Забыл, когда вызывается статический конструктор в шарпах.» — о ужас, и что? провалите экзамен или собеседование где вас спросят «когда вызывается статический конструктор в шарпах»? Как это повлияет на реальную разработку на реальном проекте, одноминутной задержкой, одним запросом к гуглу или к мануалу?
«Упс! Я не могу правильно реализовать IDisposable без гугла» — та же ерунда, ну зачем без гугла, главное что вы знаете зачем это и что за собой потянет, а как реализовать можно и почитать.
«Пытаюсь мутировать стейт в реакт компоненте.» — вот это уже плохо. Хотя насколько плохо я не знаю, с реактом плохо, по нулям, но судя по контексту вы используете паттерн не по назначению и применяете его там где технологически не нужно или невозможно. Вот как раз знания чем что лучше делать и понимание как это лучше делать и определяют синьора. Архитектор поднимается на уровень абстракции выше и ему уже точно детали языка не нужны.
Простите за аналогию:
Джуниор умеет держать молоток и бить по гвоздю (иногда надсаженному).
Миддл умеет самостоятельно забивать гвозди куда скажут и часто уже понимает где они нужны, а так же и шурупы умеет вкручивать и клеем пользоваться. Может проконтролировать насколько хорошо джун забил гвозди, насадить, помочь если гвоздь согнулся.
Синьор знает куда нужно забивать гвозди и почему, а что лучше шурупами скрепить, а что склеить, а может тут стоит вспомнить старое и взяться за заклепки или наоборот попытаться использовать новейший суперклей. Понимает плюсы и минусы и области применения каждой из этих технологий скрепления материалов. Поможет мидлу указав что гвоздь вот сюда забить стоит, а вот этим 5 шурупам тут совсем не место, и джуну рассказав 5 способов зделать правильный замах молотком. Ну и главное он уже знает что результат важнее процесса, задача важнее кода, а все вокруг это не самые лучшие в мире и самые любимые молотки и лобзики а просто инструменты для создания продукта.
Архитектор знает что с чем скрепить и какой формы вырезать доски чтобы сделать этот сковречник, может это рассказать и даже нарисовать. Сам уже с трудом помнит как работать молотком или шуруповертом и чем винты отличаются от шурупов, про новейший суперклей слышал, но в его химический состав не вдавался, ограничился стоимостью, областями применения, скоростью засыхания и прочностью крепления, просто чтобы знать какие возможности он дает.
Тим лид задает настроение чтобы всем было комфортно делать этот скворечник, периодически извиняясь и обьясняя что требования к скворечнику поменялись и теперь вход нужен не круглый а прямоугольный и меньше чем был, и птичкам нужно остекление в пол. А так же ругаясь на запоротые доски и гвозди и потерянное время, и за то что крышу не успели доделать. Гвозди или шурупы не самая главная его задача но он все же был синьором и частично совмещает и сейчас, так что может то же что и синьор (но не факт что то же что и архитектор), хотя может про суперклей и не слышал, не хватило времени.
Ну продолжать можно долго. Главное что ни одному из них не нужно знать на зубок детальную информацию по гвоздям, их видам, размерам, составу, способу производства, как и не нужно знать как их красиво метать в дерево и что с помощью гвоздя и пластиковой бутылки можно сделать поливалку для мангала. Если надо все это можнно загуглить, почитать в справочнике или же это очень узкие области которые в создании скворечников не пригодяться а при создании табуретки можно и почитать опыт табуреточников, главное понимать что гвоздь острый, молоток тяжелый, скреплять материалы можно разными способами и разбираться в дереве и сопромате.
Еще раз извиняюсь за аналогию.
На каждой платформе (нечто более узкое, чем просто яп) нужно писать в соответствии с практиками платформы. Это да, важно осознавать. Так же важно понимать, что ментально работа на UI и бекенд разная: разные вещи важны. Нужно осознанно перестраиваться. Внутри одной недели делать разное с качеством сеньора не получится.
Мультимидлы хороши в аутсорсе и малых компаниях: там важно иметь реальную возможность перебросить человека с бека на фронт и наоборот. Оплачивается в таком случае не хуже сеньора, даже если вполне реальный мидл, а не мультисеньор.
Из мультимидлов получаются мультисеньоры, а потом архитекторы, т.к. им обязательно иметь кругозор.
Если человек средних способностей, то не нужно ему идти в мультимидлы, т.к. это гораздо сложнее с точки зрения «вычислительных» затрат человека, но легче с точки зрения мотивации.
Важно так же понимать, что 90% сеньоров в одной технологии особо много не знают, т.к. чем дальше учишься, тем прогресс слабее, а большинство вообще бросает это дело. Так что с точки зрения работодателя в среднем человек, который владеет несколькими технологиями гораздо лучше обучен (будет писать более поддерживаемый протестированный код с меньшим количеством багов, хотя и может что-то редко упустить в особенностях платформы), чем человек в одной технологии. Но ещё не все так считают: обычно отбрасывается «в среднем» и пытаются найти исключение.
Если вы пишете сложный системный проект вроде высокопроизводительного драйвера для СУБД — вы просто должны быть синьором в определенном языке, протоколе взаимодействия и прочих вещах. Погрузиться с головой в детали. Бывает, что на это требуются годы.
Когда вы работаете с проектом в прикладной области (екоммерс, веб, мобайл) — вы пользуетесь наработками системных кодеров и здесь скорее полезнее иметь общий кругозор и просто следовать лучшим практикам, которые принято использовать в рамках данного фреймворка, библиотеки, стека. Если кругозор уже есть, погрузиться в эти нюансы не так сложно, за пару месяцев вполне можно. На уровне миддла вы будете писать продукты примерно того же качества, что и синьор.
Выбирать можно любой путь, я бы не стал оценивать, кто круче или где интереснее работать. На этом шарике размер чека зависит не от визитки Senior / Full Stack, а скорее от сферы работы, компании и стека. На данный момент самыми дорогими техническими спецами в ИТ вообще являются девопсы.
Фуллстек может быть и джуном, и миддлом, и сеньёром. Очевидно, чтобы стать честным фуллстек-сеньёром, надо уметь каждую из входящих в «фуллстек» технологий на уровне сеньёра.
Тут, скорее, про то, что имея лычку "фуллстэк сеньора" по факту будешь соответствовать миддлу по каждой из технологий своего стэка.
Я вот считаю наоборот – «фуллстек» лычка не может превосходить минимальную «среднюю» лычку по технологиям. Но это всё сильно расплывчато, нет же никаких точных критериев оценки скиллов.
фулстэк подразумевает более широкий но менее глубокий скоуп знаний. Банально в силу того что за всем уследить вы не сможете. Да и "фулстэк фулстэку" рознь. Ну и даже если вы носите гордое звание фулстэка это не отменяет специализацию.
Например мне не составляет труда напилить какой-нибудь фронтэндик, поднять класстер серверов и т.д. но я прекрасно понимаю что моя специализация все же бэкэнд. И тот факт сколько времени я могу уделять развитию сильно сказывается на уровне "сопутствующих знаний".
Ну то есть я вижу проблему с тем что понятие "фулстэка" у всех разное. Знать все невозможно. Но оно и не нужно обычно. Достаточно знать много, а копать вглубь только при необходимости.
Один (тимлид) не знал где находится в проекте папка node_modules.
Второй — задевелопил фичу, изменив исходный код пакета в локальном node_modules и закоммитил всё это (проапдейтив .gitignore конечно же).
Случаи смешные, а ситуация страшная.
Легко.
Ну а на тему изменения серд парти — это может намекать только на то что ваши разработчики никогда не работали с менеджерами пакетов. Что странно в наши дни.
Так что нет, это вопрос не в фулстэк/не фулстэк. Знания необходимые что бы не творить такой черни на 90% проэцируются из любых других языков.
Реализовывать IDisposable без гугла — это уровень джуниора. Миддлу неплохо бы понимать, что IDisposable реализовывать вообще не надо.
Что это антипаттерн, и что в современном C# есть средства получше. Конечно, в public API нужно использовать хотя бы и антипаттерн, если это именно то, чего ждут пользователи этого API.
Но за исключением указанной выше ситуации вместо IDisposable лучше просто сделать метод Dispose(), а лучше метод с более конкретным названием. Не знаю, стоит ли такое упоминать, но класс должен быть sealed.
Конечно, раз уж мы сделали класс sealed и всегда зовём Dispose() явно, не полагаясь на финалайзер, то можно и : IDisposable подписать — просто чтобы использовать using. Но тогда появляется соблазн прикастить его где-нибудь к IDisposable, вернувшись таким образом к антипаттерну, а using на самом деле прекрасно заменяется на статический метод вроде T With<T>(Func<MyDisposableClass, T>), причём в некоторых случаях можно даже скрыть конструктор класса, оставив только этот метод.
А в некоторых случаях можно пойти ещё дальше, и вообще избавиться от класса, оставив только функцию With, которая будет выглядеть как-то так: T With<T>(Func<Resource1, Resource2, Resource3, T>)
Так как разработка сама по себе нуднятина
рисование иллюстрацийкогда нибудь тоже хочу заняться, когда программирование и математику подтяну, не зря в детстве почти год в художку ходил XD.
А пока хватает и программирования с двумя языками иностранными, даже математикой заняться не выходит)) Правда я сейчас в процессе спрыгивания на другую технологию, и это занимает от 2 до 6 часов свободного времени каждый день, когда по новой технологии на работу устроюсь может получше будет)
А вот если фонтанируете бизнес-идеями, запускаете собственные проекты и т.п., то и фулстек-разраба маловато будет! Захочется изучать журналистику, дизайн, маркетинг, экономику и еще тонну всего. И вот представляете какая депрессияи аут, когда ваш проект «не полетел»??? Вы ж не то что там, мидл! Вы вообще ноль во всем!
Вроде и портал-ценовой-агрегатор-с-биллингом-и-блекджеком полностью закодить можете, и статью можете на уровне Эксперт/Коммерсантъ, и дизайн, и экономику проекта рассчитать со всеми сопутствующими исследованиями, кеш-флоу, дисконтированием, IRR, P/E и P/B на пятилетку… Да только PM, таких порталов штук пять одновременно волочёт… Кодер его запилит за месяц, а не за год… Штатный корреспондент из Ъ таких как ваша статья по две в неделю сдаёт, а ты одну со скрипом за полмесяц… Дизайнер по пять логотипов в день стругает и по пять вариантов каждого… Аналитик венчурного фонда по 20 проектов в неделю дьюти-дилинжит… А ты. по сравнению с ними, вообще детсадовец против Крепкого Орешка! Что ж теперь, такому широкопрофилю?.. Стреляться? Нет уж! Лучше ощущать себя д'Артаньяном… просто пока у вас всего 20 пистолей в кармане, странная лошадь из Мэнга над которой все ржут, и в добавок вообще не земляк де-Тревиля и про него даже и не слышали. :))
Соболезную, что понял всё только потратив кучу собственных лет на это дело. Возможно твоя статья поможет многим заранее осознать на что они идут.
Я лично всегда кодил на том, на чем было вкайф, сначала 5 лет плюсы, потом несколько лет шарпы, потом на пяток лет двинул в iOS, сейчас второй год занимаюсь блокчейном, в каждую технологию погружась глубоко и получается в итоге довольно быстро переходить (буквально за пару месяцев). Ведь пока путешествуешь по этим областям все-равно копится огромный багаж фундаментальных знаний: структуры, алгоритмы, криптография и множество других.
Термин набрал популярность с развитием фриланса, когда 1 чел мог заменить студию и сам сделать бриф дизайн сверстать и интегрировать на кмс, и поддерживать дальше сайт, но в целом можно не только к ит применить, если челу заказывают шкаф, он сам приедет измерит спроектирует начертит выпилит и смонтирует то он тоже будет фулстек.
Ими выгодно быть, и бизнесу выгодно их нанимать когда задача условно занимает 1 человеко месяц, связано это с тем что человек в команде будет работать заведомо медление, так устроена жизнь, будут тратить время на коммуникации и максимум при гении менеджере-тимлиде можно достичь 0,9 эффективности от человека, а может быть и 0,5, то есть 2 будут работать как 1.
С другой стороны если задача будет на 10 человеко лет, то смысла заказывать её у 1 человека нет, тогда и нужны команды.
з.ы. вы лучший среди своих коллег в вашей фирме? вы сеньор. Сильно размыты эти границы квалификаций.
А насчёт тасок швыряться: это от людей зависит. В любой иерархии тасками можно швыряться.
действительно, зачем нужны лиды… к черту тогда и все остальные бирки, мы просто люди и нам хочется играть.
Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать