Когда я только начал учиться кодить, я поверил старым мудрым засранцам с их мантрой «язык программирования не важен». У меня появилась идея фикс — быть разработчиком, который может всё. Парнем, который переносит опыт использования одной технологии на другую и возносится над деталями. Но эта затея с треском провалилась.
Идея фикс — знать все
Я изучил C# и .NET с разными областями применения (asp.net, wpf, xamarin), js/ts (react/redux, node) и убедил себя, что теперь-то могу действительно всё. Я абстрагировался, мыслю в нескольких парадигмах программирования одновременно и обладаю практическими знаниями во всех аспектах профессиональной разработки ПО. Можно смело начинать высмеивать этих сорокалетних сеньоров одной технологии, которые потратили полжизни на то, что я могу постигнуть за неделю. Можно утверждать что погружение в предметную область — для болванов, которые хотят всю жизнь проработать на одном месте, тогда как я — абстрагирован от неё.
Всё вокруг одинаковое, и я увидел закономерность. Теперь, когда мне нужно поработать на каком-нибудь нелепом питоне, я говорю: «дайте немного времени на беглое чтение спеки, и я готов работать с этим говном на уровне senior. Ну что, в конце концов, там может быть такого сложного, чего я еще не видел?» Так я создал себе культ пренебрежения деталями. Пусть в деталях копошатся джуны, которые не могут в абстракции.
Пробелы в знаниях неочевидны и незаметны
Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте так не делают. Я, конечно же, сделал вид, что просто мои коллеги — бездарные идиоты. Обычно это помогало, но в этот раз остался осадок.
Репутация хорошего разраба скрывает твои пробелы как от коллег, так и от тебя самого. Ты не знаешь огромное количество критичных специфичных штук, но не видишь этого, как раз потому, что не знаешь.
Затем началась черная полоса. Фигак! Я не знаю, что там за типы индексов в SQL. Бам! Забыл, когда вызывается статический конструктор в шарпах. Упс! Я не могу правильно реализовать IDisposable без гугла. Пытаюсь мутировать стейт в реакт компоненте.
Я заподозрил, что моя абстрагированность не работает. Что технологии все-таки разные, а детали — важны. В каждой технологической экосистеме свои уникальные лучшие практики. Опыт в .NET не помешает при работе с jvm, но и не заменит его. Мой самоприсвоенный скилл «Я научился быстро учиться» оказался неправдой. Я учился не быстрее, чем все остальные. И мне потребовалось слишком много времени, чтобы это понять.
Мой скилл оказался как обоз — лебедь, рак и щука пытались тащить его в разные стороны. Я не стал автоматически сеньором во всем. Я просто стал мультимидлом, посмешищем для сорокалетних сеньоров одной технологии. И тогда я пришел к выводу, что выбирать путь фулстека — ошибка.
И тут начинается самобичевание
Проблема в том, что бизнесу нужны фулстеки. Только не такие, как я, а синьоры во всём, ребята, у которых за плечами по пять лет опыта в каждой из фулстечных технологий.
Но таких не бывает, и бизнес идёт на самообман. Они берут слабого мидла в трех крупных технологиях, и называют его senior full-stack developer. Этот титул превращает человека в самозванца и становится неиссякаемым источником комплекса неполноценности. Любой обычный разраб, который шарит в одной технологии — шарит в ней лучше. И сейчас я хорошо понимаю, что не готов на равных правах работать в команде с людьми, которые шарят намного лучше меня. Иначе уже через неделю умру от самобичевания.
Самобичевание — огромная проблема нашей индустрии, но мы ее неправильно лечим. Мы пишем друг для друга манифесты, что мы дартаньяны, а все вокруг козлы. Что девальвации сеньоров не существует, просто мы себя недооцениваем, что нам надо выкинуть скромность на помойку и поверить в свою внутреннюю богиню разработки. Что нам надо натянуть на себя шкуру высокомерия и слать подальше всех, кто в нас сомневается.
А надо-то всего лишь признать, что разработка — это сложно не только для людей извне, но и для нас тоже. Не знать что-то на данный момент — нормально. Если у тебя есть пробел, это не значит, что ты стоишь меньше денег, и тебя надо изгонять в пустыню.
Но на самых глубоких уровнях рефлексии в нас все равно остается самобичевание. Фулстеки грызут себя, что не знают технологии глубоко. Однояпные спецы — что не знают широко.
Учить вширь vs учить вглубь
Здесь старый конфликт: ты можешь изучать в глубь, а можешь вширь, но не то и другое одновременно. Я заметил такой эффект — когда начинаешь изучать новую технологию, старая становиться неинтересной. Но в IT если ты не обновляешь свои знания о технологии в течение года, ты уже не актуален.
Если хочешь оставаться фулстеком, тебе придётся заставлять себя читать релиз-ноуты какого-нибудь TypeScript, заодно ещё и пробуя их в деле — даже если не хочется. Причём ты всё ещё будешь недосягаемо хуже разраба, который каждый день пишет исключительно на тайпскрипте.
Главная проблема этого конфликта в том, что мы не знаем, как лучше. Мы-то, и особенно бизнес, хотим и так, и так. Что бы все шарили во всём, и шарили достаточно глубоко.
Что лучше, я не знаю, но знаю, каково быть на этом пути фулстеком. Тебе придется тратить намного больше времени на обучение, чем разработчикам с одним языком. Так будет продолжаться всю карьеру, но по сравнению с ними твой уровень все равно будет ниже.
Ты везде будешь свой, но везде среди чужих. Несмотря на твои огромные усилия, каждый знаток конкретного языка будет с пеной у рта доказывать, что ты не достоин называться сеньором.
Ты станешь вечным мидлом.
Я лично решил, что обратной дороги у меня нет. Я могу изучить что-то одно по-настоящему глубоко, могу попробовать уйти в управление — вот уж где нужны только поверхностные знания — но лучше останусь на своем пути и буду страдать, пока действительно не узнаю все обо всем.
Комментарии (486)
Aquahawk
12.11.2018 17:02+1Имхо хорошая концепция быть крутым в одном и примерно понимать и немного практиковать окружение.
neit_kas
13.11.2018 11:16+1Я думаю, что своё «вширь vs вглубь» можно варьировать, т.е. необязательно либо вширь, либо вглубь. Я бы сказал, что обе крайности опасны. Вширь — описал автор. Вглубь — другая проблема: сегодня ты сеньор технологии N, а завтра она выкинута на помойку (как не редко бывает в IT).
irbis_al
12.11.2018 17:04+13могу попробовать уйти в управление
Вы знаете, то о чем Вы написали и есть путь в управление.ИТ Архитектор это и есть профессиональный дилетант.Знающий много технологий и "прокладывающий путь" проекту.
Конечно, если архитектор делает фичи сам а не делегирует их более узкоспециализированным разработчикам,- может получится лажа.Архитектор строительный я думаю тоже может заштукатурить стену… но профессиональный штукатур сделает это лучше. Но штукатур не сможет быть архитектором.areht
12.11.2018 19:00+2Только управление — это прораб/PM, а не архитектор. Совсем разные компетенции.
x67
13.11.2018 01:27+1Только в крупных проектах есть и прораб и архитектор, в небольших все таки стараются совмещать (оттуда ноги и растут). И это не только в IT
areht
13.11.2018 01:54То есть мидл фулстек дев станет ещё и мидл архитектором и мидл PM?
Если честно, плохо себе представляю, что на небольшом проекте техстек будет выбирать человек, не пишущий код. Ну то есть как «не представляю» — видел, но больше не хочу.
И ведь его даже на смех то поднять нельзя.
NLO
00.00.0000 00:00НЛО прилетело и опубликовало эту надпись здесь
Milein
12.11.2018 17:34+13А надо было учиться программировать.
А надо было учиться разрабывать, а не программировать.
Хотя постойте, не так.
А надо было учиться решать проблемы бизнеса, а не разрабатывать.
Вот что вы за занудством занимаетесь? Это как на галерные лычки наяривать: «я не программист, я сениор эксперт мастер рокстар девелопер».argamidon
12.11.2018 22:02+4Понавыдумывали понятий — разработчик, девелопер, программист, кодер, инженер… и никто разницу понять не может
Stas911
12.11.2018 22:09+5Мало того — они еще и внутри этих классов норовят поделить на сеньоров-миддлов-джуниоров. Никак людям не живется без цветовой дифференциации штанов
samodum
13.11.2018 03:48+1Там есть ещё экземпляры, со своими «гуру», «джедаями» и прочими «рокстарами» от которых хочется блевать
HanryCase
13.11.2018 13:03+2Понравилось, вчера кто то из хабарожителей написал комент:
Мне нравится разделение по уровню ответственности:
Джуниор — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.
Миддл — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.
Сеньёр — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.
onegreyonewhite
13.11.2018 01:42+1Беда в том, что есть очень много людей в ИТ сфере, которые даже не поняли вашу игру слов.
beatstream
13.11.2018 16:05+2Ханин мягко улыбнулся. — Творцы нам тут на ххх не нужны, — сказал он. — Криэйтором, Вава, криэйтором.
Whuthering
12.11.2018 18:37+2Навешивание ярлыков и ваше деление людей на «кодеров» и «программистов» устарело уже лет на 20. Не смешно уже.
jehy
12.11.2018 17:24+3Да да, в какой-то момент каждый задумывается об этом.
Насчёт «бизнесу нужны фуллстеки» — здесь есть нюанс. Бизнес разный бывает. И именно фуллстеки нужны обычно там, где человек по факту занимает несколько вакансий. То есть, в небольшом бизнесе или в стартапах. Не говорю, что там работать это плохо — это тоже может быть интересно, в особенности на начальных этапах, когда ты только познаёшь, чем хочешь заниматься.
Но если бизнес большой, а продукт сложный — здесь нужны достаточно узкие специалисты. И, к сожалению, просто нельзя одновременно быть сениор разработчиком фронта, бэка, мобилки, девопсом и архитектором СУБД (у меня был такой опыт, но я не могу покривить душой и сказать, что я был хотя бы миддлом сразу во всех областях сразу). Просто потому что технологии сейчас развиваются с большей скоростью, чем человек может их освоить. Опять же, «освоить» это не значит «прочитать анонсы». Это значит — попробовать вживую. Да, можно хорошо разбираться в 2-3 технологиях, но дальше начинается деградация знаний, и ты действительно становишься универсальным миддлом. Я от этого в какой-то момент устал и ушёл. И очень доволен таким решением.
Хотя я не говорю, что соседние стеки знать не нужно. Я считаю, что сениор должен обладать как минимум полноценным пониманием взаимодействия компонентов своего продукта и умением его отладки — хотя бы чтобы знать, где возникают проблемы, а не вопить, что они «на другом конце». Но понимать тонкости — уже излишне и слишком трудоёмко. Нужно честно признать, что ты развиваешься в конкретном направлении, а в остальных ты в лучшем случае миддл. Затем принять это и не комплексовать. Всегда найдутся люди, которые в чём-то разбираются лучше — поэтому мы и работаем не в одиночку, а командой.Jef239
12.11.2018 22:43+2У Райкина была хорошая юмореска про узких специалистов:
У нас узкая специализация. Один пришивает карман, один - проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть?И они — не портные, они — подмастерья.
Узкие специалисты нужны редко и ненадолго. Если нужен человек по конкретному интерфейсу SoС — его можно позвать на конкретную задачу. А нужны именно full-stack — спроектировать схему, развести её, спаять, отладить электрически, запустить SoC, потом RTOS, потом приложение.
Это должна быть очень крупная фирма, чтобы позволить себе держать специалиста по RS-485 или RS-232. И очень много разных платформ, чтобы у него был фронт работы.
Ну и потом, узкий специалист не может нормально отлаживаться. Ио работу кода мы отлаживаем осциллографом, а проблемы в железе ищем кодом.
Так что сеньор — это full stack, а «мастера по пришивке пуговиц» — джуны. Для того и было придумано разделение труда и узкая специализация — чтобы заменить десяток сеньоров сотней джунов.buldo
12.11.2018 23:06+3По мне вы описали слегка расширенного, но довольно специализированного разработчика встроенных систем. Когда для созданной железяки понадобится мобильное приложение или сервер сбора данных — это окажется за пределами компетенций описанного специалиста.
А ещё у меня сложилось предвзятое мнение, что чем лучше человек понимает схемотехнику и внутренности МК, тем хуже у него код для этих самых МКJef239
12.11.2018 23:12Угу, любой нормальный embedчик — это fullstack. А для редких задач мы привлекаем узких специалистов. Например, привлекали спецов по CAN и по MIL-STD-1553B. Мобильное приложение, сайтик, сервер — это все из другого мира. Того, где linux — достоинство, а не недостаток.
Хуже — это по каким параметрам? По количеству ошибок, по читаемости, по стабильности кода за 10 лет? Когда у вас для отладки только светодиод и осциллограф — есть смысл писать надежно и просто. То есть весьма-весьма дубово. Но это достоинство, а не недостаток.buldo
12.11.2018 23:35+2Кажется вы меня не до конца поняли. Описанный вами embedчик-fullstack — для меня выглядит, как узкий специалист. Хотя, возможно я лукавлю и задним умом считаю логичным разделять разработку железа и его программирование примерно также, как front-end и back-end.
Хуже — по поддерживаемости. В основном я видел спагетти код. При этом после двухмесячного перерыва в работе автор кода не мог понять что, как работает. SOLID, DDD, что это такое?
Если код надёжный и просто — то это замечательно, вот только для меня простота — это не отсутствие работы с указателями или каких-то хитрых вещей, а возможность прочитать совершенно незнакомый код и понять, как он работает. И в этом как раз помогает и SOLID, и другие идеи.Jef239
13.11.2018 00:13Узкие специалисты это: «элементщик» (тот, кто компоненты выбирает), закупщик, проектировщик схем, разводчик, оформитель схемы по ГОСТ (приглашали разок), технолог производства печатных плат (консультировались), монтажник, технолог пайки… Это только по стороне железа.
А на стороне софта… у RS-485 есть терминаторные резисторы. Ну как настраивает резисторы обычный программист? Посмотрел осциллографом, поставил — и тест на сутки. Если больше одного сбойного байта за сутки — менять номинал. А узкий специалист сразу ставит нужный резистор.
SOLID — это все-таки С++. Простой и читаемый код — это обычный Си, близкий к ассемблеру. См. драйвера linux — они довольно хорошо написаны.
P.S. У нас в конторе есть всего один узкий специалист — это технический писатель по ГОСТ.zagayevskiy
13.11.2018 12:25Зачем вы в каждое обсуждение пихаете свою предметную область с отсылкой к "а у нас вот так, и поэтому весь мир должен думать так же"?
BTW, SOLID — это не про С++ и принципы можно и нужно использовать и в не ОО-языках тоже.
Jef239
14.11.2018 11:02Это просто реакция на тех, кто считает, что весь мир делает web-приложения. Поэтому и рассказываю о том, что бывает за пределами узкого мирка web-архитектуры.
А про SOLID в не ОО-языках — расскажите или ссылку дайте.zagayevskiy
14.11.2018 11:16Все принципы, кроме подстановки Лисков можно применять к процедурным и функциональным языкам, просто надо думать в чуть более широком смысле. Например, SRP — функция должна иметь конкретную зону ответственности. Interface segregation — подразумеваем интерфейс в широком смысле, не ключевое слово, а API. И так далее.
Jef239
14.11.2018 11:30Ну как раз что-то вроде принципа подстановки Лисков мы применяем в Cи-коде. Делается указатель на процедуру — и вперед. Примерно как onexit в Си.
Просто нафига очевидные вещи называть громкими словами?zagayevskiy
14.11.2018 12:46Принцип подставки Лисков говорит об отношениях между типами и подтипами, как это вы его используете в Си?
onexit — это обычные коллбеки.
Очевидные вещи:
1) очевидны не всем;
2) очевидны по-разному;
Что и демонстрирует ваше непонимание очевидных другим вещей.Jef239
14.11.2018 13:18+1Читаем определение:
Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.
Вот на callback и на weak-функциях оно и делается. Базовый тип — вывести информацию Специализации — вывести на RS32, на RS32 через ПЛИС, на CAN, на MIL-STD-1443b…
onexit — как раз нормальный пример. Базовый тип — выполнить финализацию. А специфические подтипы делают конкретные вещи.
В принципе группа weak-функций или callback дает вполне функциональную замену ООП. Даже с наследованием (можно выставить свою функцию на callback и в ней вызвать то, что было на callback раньше.zagayevskiy
14.11.2018 13:38+2Короче вы спорите со мной непонятно о чём. Если вы сделали в Си псевдо-наследование — честь вам и хвала. И это даже больше подтверждает моё утверждение. Если вам просто хочется поговорить, так и скажите, а не прыгайте с темы на тему.
JFYI, постоянные упоминания деталей ваших реализаций не делает вас круче, равно как и не даёт дополнительной информации собеседнику.
Scrayer
13.11.2018 13:03Мое видение таково
Инженер: Если работает так как надо, то дальнейшие улучшения не требуются.
Программист: Если результат не оптимален, то не будет работать как надо.
У первого цель — рабочая программа.
Цель второго — не ломающаяся программа.
moncruist
13.11.2018 13:03Как embedчик не соглашусь с вами. Железо и софт очень сильно отличается, и я еще ни разу за свою карьеру не видел человека, который был очень хорош и там, и там. Как правило, у каждого очень сильный перекос в какую-то из этих областей. Поэтому очень важна специализация каждого, чтобы выпустить качественный продукт. Конечно, если в компании два человека, делающие мелкосерийный продукт для конкретного заказчика со сроками «надо было сделать вчера», то понятно, что каждый должен уметь что-то в каждой области.
Другое дело когда проект большой, сложный и массовый. Вот у меня сейчас проект — это кодовая база на несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом. Поэтому тут и SOLID, и юнит тесты, и blackbox тесты, Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.
Все-таки разделение труда — это главное достижение человечества.Jef239
14.11.2018 10:48-3Миллион строк? Гм, простите, какой объем ПЗУ это занимает? И почему бы при таком объеме кода не использовать linux? А linux — это по моим понятиям уже не совсем embed. Ну или совсем не embed.
Разделение труда (в пределе — конвейер) придумано, чтобы привлечь к работе низкоквалифицированный персонал. Брукс хорошо доказал, что увеличение численности не ускоряет разработку (если 9 беременных женщин собрать вместе, ребенок через месяц не родится), наоборот, в его конкретном случае, увеличение численности в 10 раз разработку замедлило.
Поэтому вопрос в экономике. Нужна эффективность производства — делаете конвейер с сотней программистов. Нужно качество — обходитесь всего несколькими сеньорами.
несколько миллионов строк для МК и сотни людей. Попробуйте это поотлаживать светодиодом и осциллографом.
Поржал. Зачем это отлаживать на МК? Разработка и отладка 99.9% идет на windows. Да, приходится делать имитаторы и писать переносимый код. Но на windows отлаживается все, кроме очень специфичного для МК кода. Потом перенос на linux, потом — на МК.
У меня был проект с доступным временем на отладку на реальном стане — 2 часа в месяц (130 тысяч строк кода). Ничего, справился без отладки.
Software-In-the-Loop, Hardware-In-the-Loop, Continuous Integration и т.д. Скажи такие слова человеку из мира железа, он и не поймет что это.
Ну и я таких терминов как SIL и HIL не знал. Но мы их применяли почти 20 лет назад. Как-то не сложно было независимо их изобрести.
Int_13h
13.11.2018 07:55Был у нас на прошлой работе яжпрограммист, начальник отдела программных средств АСУ, а я, соответственно, был
сеньоромведущим инженегром в отделе технических средств АСУ. Граница раздела компетенций отделов проходила по клеммникам подключения проводов к контроллерам. Ну вот исторически так сложилось и усиленно поддерживалось руководством. Техник — не лезь в дела программеров, без тебя разберутся, а твоя задача ТЗ написать, железо подобрать, чертежи начертить, процесс сборки проконтроллировать, протестировать, смонтировать, пусконаладить и сдать. А программистам — программистово, код напишут, зальют, посидят за ноутом на пусконаладке, а ты бегай, выполняй их указания, какой датчик попинать, чтобы заработало.
Так вот этот товарищ усиленно не хотел разбираться в том, чем будет управлять програмирумый им ПЛК и как этот ПЛК, собственно, функционирует. Типа, мое дело писать код, ваше дело предоставить мне алгоритмы и заставить железо работать, либо алгоритмы вытрясайте у технологов.
И вот настал тот последний проект, который мне в той фирме посчасливилось доводить до конца, от конструкторской документации и почти до пусконаладки. Система ответственная, для нефтехимпрома, контроллеры отказоустойчивые, вероятность отказа 0.(0)1%. Нарисовал схемы, собрали шкафы на сборочном участке, собрали стендики-эмуляторы сигналов, закупили калибратор за бешенные бабки для настройки аналоговых каналов. Начался этап тестирования софта, я подаю сигнал 4...20 мА, имитируя работу датчика, программист смотрит, что пришло, подгоняет единицы измерения — ток в паскали, мм, кубометры и прочее. Подаю я, значится, сигнал, яжпрограммист ждет, что там будет уровень в емкости 1 метр, а уровень то скачет немного, шумит младшими битами 12-битный АЦП в ПЛК. И тут возникает «шум АЦП» со стороны яжпрограммиста: ты что это, подлец и диверсант, делаешь, я ж прошу выставить уровень в емкости 1 м, а ты какого рожна выставляешь то 0.99, то 1.01 м, ты мне вынь да положь 1.000м, как я с буду программу отстраивать на работу с такими данными? Чуть я заикнуля про необходимость фильтрации, аппартаной или программной, как «шум АЦП» начал усиливаться, что это я лезу не в свое дело, мое дело должно быть маленькое, обеспечить нормальное функционирование техники, а не учить программистов работать, что это за препирания с начальством, да и вообще таким специалистам тут не место.Whuthering
13.11.2018 16:08+2Типа, мое дело писать код, ваше дело предоставить мне алгоритмы и заставить железо работать
Чуть я заикнуля про необходимость фильтрации, аппартаной или программной
Тут всплывает весьма важный вопрос: а почему в предоставленном разработчику ТЗ и описании алгоритмов ни слова не было сказано про фильтрацию или сглаживание входных сигналов?
На тему «это же очевидно» и «это же надо знать» — увы, нет, как минимум потому, что нередко можно встретить модули AIn с включенным по-умолчанию фильтром, и, следовательно, если его нет по ТТХ изделия, стоит явно сформулировать требование о наличии фильтрации, а не махать руками во время пусконаладочных работ, мол, «ты должен был знать».
Так что, как говорится, «без подробного ТЗ результат ХЗ».Int_13h
13.11.2018 19:44+2Согласен, но как обычно есть несколько тонкостей.
1. В ТЗ учесть всех нюансов невозможно, много интересных моментов вылазит на следующих этапах, а ТЗ уже утверждено заказчиком и переделке не подлежит.
2. ТЗ пишется исполнителем (да, те самые отделы технических и программных средств), поэтому относятся к нему, как к формальности — отдельному пункту бюджета поекта. Таким образом, утвержденное заказчиком ТЗ является, прежде всего, документом, который в дальнейшем отсеивает необоснованные притязания заказчика к исполнителю по функциям и задачам системы. И уж во вторую очереди исполнитель обращается к собственноручно составленному ТЗ, чтобы посмортеть, а как же на самом деле надо реализовать ту или иную вещь. Возможно, в других отраслях заказчик приходит к исполнителю с готовым ТЗ, но у нас все наоборот.
3. Фильтрация сигналов таки была прописана, это стандартный шаблонный пункт (да, мы используем предыдущие наработки в дальнеших проектах, не пишем «код» каждый раз с нуля).
4. В модулях AI фильтр встроенный есть, на этапе работы с железом (в момент испытаний же!) стало ясно, что его возможности не удоволетворяют требованиям точности. Если железячники о причинах проблемы догадались сразу и тут же предложили метод решения, то яжпрограммист пошел по пути наименьшего сопротивления. Зачем создавать себе работу, если можно свалить проблемы на соседний отдел?
Да черт с ним, с АЦП, это одна из историй, создавшая проблемы ровно на 2 рабочих дня, с учетом совещания у начальства (любую незначительную проблему выноси на повестку дня на планерке — n-ое правило ватокатства).
Еще одна история из этого же проекта. Алгоритмы, по которым должна функционировать система, разрабатывались в одном ЭнскГИПроКакойтотампромышленности, разрабатывались в виде, так сказать функциональных диаграмм (дикая смесь FBD и LAD), но в отрыве от соответствующих стандартов. Возможно, авторы листали лет 30 назад справочную литературу по Ремиконтам. Ну не суть, в принципах работы создаваемой системы разобраться можно — что контролировать, что, когда и с какими задержками и блокировками включать. На изучение этой документации техотдел потратил 2 месяца, и потом все на пальцах объяснил программистам, описав алгоритмы в текстовом виде, заодно нашел множество нестыковок, косяков и прочего. Но, в ходе общения с Заказчиком, представителями ЭнскГИПроКакойтотампромышленности пришли к заключению, что «проект уже давно утвержден (лет 6 назад как), переделывать его никто не будет, это деньги и время, делайте как есть, на месте разберемся». ОК, раз есть такой приказ, яжпрограммист использует алгоритмы как руководство к действию, пишет программу.
Тут поджидает засада. Проектировщики алгоритма знать не знали о стандартах IEC, о том, какие контроллеры будут использваться, какие там есть билиотечные функции. Напоминаю, что в IEC имеются таймеры, типа TON, TOF, TP. Проектировщики алгоритма предполагали одно поведение таймера, стандарт предполагает другое поведение. Яжпрограммист реализует структуру программы в точном соответствии с алгоритмом (проект же утвержден, что я буду отходить от него?), в итоге программа не работает. ОК, копья ломаются, АЦП шумит, проблема решается не без крови (потребовалось добавить к таймеру дополнительно RS-триггер, но в алгоритмах, хоть и предполагается такое поведение, явно это не указано!).
Поехали дальше, следующая засада. Используются ПЛК двух типов, стандартные, для неответственной системы РСУ, и Safety для системы ПАЗ. Если стандартные контроллеры имеют широкую библиотеку функций, то Safety не дадут вам выстрелить в ногу, даже если очень нужно, поэтому библиотека функций урезана по самое небалуй. Проектировщики алгоритма этих тонкостей учесть не могли, т.к. им все равно, на каком железе это все будет работать. Программист об этом знает, но алгоритмы же утверждены! Итог? Опять неработающая программа.
И все это в условиях вяло текущего дедлайна, со спецификой особо опасного производства, где любое нарушение технологии — катастрофа.alsii
14.11.2018 20:32+2> 1. В ТЗ учесть всех нюансов невозможно, много интересных моментов вылазит на следующих этапах, а ТЗ уже утверждено заказчиком и переделке не подлежит.
Вообще-то у же на этапе реализации проекта может выпускаться т.н. «Исполнительная документация», которая отражает согласованные с заказчиком изменения проекта, которые были внесены на стадии его реализации. Ну то есть в проекте: «Язык программирования: BASIC, Система хранения: перфокарты», в исполнительной документации: «Язык программирования: Ocaml, Система хранения: Amazon S3» :)
jehy
12.11.2018 23:12+2У вас какое-то слишком узкое понятие узости специалиста.
Как ни странно, в российских реалиях обычно называют фуллстаком не того человека, который полностью знает один некий стек от фронта до бэкенда — а того, кто знает несколько стеков.
А насчёт необходимости узких специалистов «редко и ненадолго» — это просто неправда с потолка.
Где-то ненадолго нужен администратор Oracle 11g? Или, может, Java разработчик? Может, SQL аналитиков нанимают на месяц? Или где-то ищут одноразовых специалистов по машинному обучению?Jef239
12.11.2018 23:18Угу, у нас именно так. Подобного рода специалисты нам нужны лишь на время стыковки нашей части с тем, что пишут другие организации. Нанимали ненадолго специалиста по SCADA, чуть не наняли доктора наук по PID-регулированию, но справились сами. Насчет найма ненадолго специалиста по машинному обучению — уж думали, может быть и наймем.
boblenin
12.11.2018 23:27+4Сейчас поискал гуглом определение — вот вылезло:
«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 лет. Проблема с такими разработчиками, что комманду из таких невозможно нормально нагрузить работой. Всегда кто-то простаивает.
MacIn
13.11.2018 02:03+1отладить электрически, запустить SoC, потом RTOS, потом приложение.
Вполне допускаю, что у вас не так, но из моего личного опыта разработчики такого широкого спектра «и железо и программы и жнец и на дуде игрец» пишут такой отвратительный код, что жалко глаза. Наблюдается какой-то поразительный шовинизм вида «мы тут Железку создали, что там какой-то код», из чего следует некоторая узость взглядов в сфере разработки ПО и отвратительный нечитаемый и неподдерживаемый код.Jef239
13.11.2018 03:33я бы сказал отвратительный безошибочный читабельный и не меняемый годами код. Но общего тут только «отвратительный». :-) Правда коллега — программист, делать железо — это такое хобби-переросток.
Whuthering
13.11.2018 12:15Вот в точку. Самый адовый, запутанный и кривой говнокод почему-то встречается именно у микроконтроллерщиков и ПЛКшников, причем часто в проектах для очень серьезных применений. И отговорки везде одинаковые: «тут своя специфика», «работает — не трогай», «доделывали на пусконаладке и нет времени переписать нормально» и подобное.
cyberly
13.11.2018 13:08Я полагаю, схемы, сделанные программистами, тоже не без недостатков :) А насчет специфики — даже между специалистами по разным ЯП случается недопонимание. Скажем, кому-то сделать что-то с помощью побитовых операций — это правильное, изящное, эффективное решение. А в другом языке это будет порицаться как нечитаемое и неподдерживаемое.
Whuthering
13.11.2018 13:14Я полагаю, схемы, сделанные программистами, тоже не без недостатков :)
Безусловно. Поэтому я и топлю за четкое разделение обязанностей. Каждый должен заниматься своим делом. Анализом предметной области, технологии процессов, формулированием ТЗ — технолог/аналитик, проектированием схем, разводкой плат, подбором компонентов — инженер-электроник, разработкой архитектуры ПО, написанием кода и тестов — программист. И налаженное взаимодействие между ними. Это, кстати, к вопросу про «фулл-стеков», да :)
Скажем, кому-то сделать что-то с помощью побитовых операций — это правильное, изящное, эффективное решение. А в другом языке это будет порицаться как нечитаемое и неподдерживаемое.
Тоже верно. Поэтому я обо всем и рассуждаю немного свысока, как человек, учившийся на специальности «промышленная электроника», большую часть своей карьеры копавшийся с микроконтроллерами, ПЛК и системами автоматики, а потом увлекшийся веб-разработкой и высоконагруженными сервисами :)
MacIn
13.11.2018 20:39Я полагаю, схемы, сделанные программистами, тоже не без недостатков :)
Разумеется. Так о том и речь, что универсальная вещь делает всё, но делает всё хуже, чем специализированные по отдельности. Так и со специалистами — к вопросу о fullstack.
Конкретно с «железячниками» не раз сталкивался с отношением к вопросу — см. выше — «мы сделали железку, это 99% успеха, осталось только программку накидать, это фигня, за вечер управимся». Получается так себе. Лучше, конечно, чем если наоборот — написать программу, а потом «за вечер» накидать плату, но тем не менее. Т.е. здесь раз за разом встречаю отношение к программированию, как к игровой области, где нет никаких профессиональных стандартов, неважен опыт и навык, нет технологий разработки и этим может заниматься каждый с улицы. Да, порог вхождения, пожалуй, ниже, чем в «железо», но проблема остается.
EpeTuK
13.11.2018 08:22Не только бизнес накладывает ограничения, но и рынок труда. Я бы и рад нанять сеньор реакт дева, и одобрение сверху есть, но в моём городе (850к жителей) спецов в поиске просто нету. А переучивать джейэсников из веб-студий времени нет, быстрее самому написать.
maxzh83
12.11.2018 17:33Можно попробовать компромисс. Смотрим «в ширину», что есть на рынке. Находим «вкусное», интересное, перспективное и изучаем именно это вглубь. После нескольких лет повторяем. Правда, простым это кажется только на словах.
usego
12.11.2018 19:45+2А в 40+ проводить итерацию «Находим «вкусное», интересное, перспективное и изучаем именно это вглубь» становится уже ни разу не интересно. Молодёжь всё равно сделает это лучше.
Stas911
12.11.2018 20:18Да вот не всегда, тк покопавшись в очередной «новейшей, перспективнейшей bleeding-edge technology» часто обнаруживаешь там решения, про которые тебе рассказывали седые профессора в универе лет 20 назад, а в литературе так вообще лет 50 описано.
Например, тут вон недавно механический map-reduce на перфокартах пролетал…usego
12.11.2018 20:25Что наводит на мысли нафига тратить на это время. Вот у меня например вызывает умиление как сейчас JSники открывают для себя прописные истины, которые для нас дедов сто лет в обед пройдены. Но вот начинаю сам писать JS по современным понятиям и ощущаю себя джуном, так как требуются некоторые другие навыки, что бы связать всю эту JS лапшу вместе и это вызывает не интерес, а отвращение, так как начинаешь думать нафига терять время на ковыряние с инструментарием, который ещё переживает детский возраст. А молодёжь открывает для себя чудеса типа строгой типизации и подсказок в IDE и писает кипятком. Что нам дедам там делать, мы всё это уже видели.
Simplevolk
13.11.2018 17:01Android-разработчики недавно открыли для себя MVVM, хотя в WPF было это еще очень давно. Технологии развиваются и проходят один и тот же цикл…
Imrahil
13.11.2018 09:19не согласен) Судя по конфам седые дяденьки уделывают школьников которые только за бесплатными обедами туда и ходят на раз-два тольно на одном практическом опыте).
А уж багаж знаний творит и вовсе чудеса).
Программиста может погубить только возрастная болезнь мозга, все остальное трудно но преодолимо (даже отстуствие зрения к примеру =) )
ArsenAbakarov
12.11.2018 17:36+2да, но будучи фуллстеком вы сможете в каску поднять проект, не программный продукт конечно, но все же…
Master255
12.11.2018 17:44+2вместо того что бы рассуждать фулстак или сеньёр, лучше бы накодили, что-то толковое.
evil_random
13.11.2018 00:03+3Вместо того чтобы рассуждать о том, что автор сделал или не сделал, лучше бы комментарий толковый написали.
Nalivai
13.11.2018 16:07+4Вместо того чтобы комментарии толковые писать про комментарии бестолковые, лучше бы пирожок скушали. С малиной.
ibKpoxa
12.11.2018 17:50+2МОлодо и зелено, сам был таким, но потом понял, что это всё ерунда… титулы, должности, самобичевание, понты, плюнуть и растереть :) Это пройдёт, наверное.
Max2UP
12.11.2018 17:53Стою ровно на такой же развилке. Fullstack это самообман, которые не так очевиден пока работаешь в одиночку или в непрофессиональной команде. Но роста тут никакого. Так что путь в что-нибудь вроде Technical Project Manager.
AGARTY
12.11.2018 17:56+1Все верно. Это как RPG, если ты качаешь перса во все одинаково, то ты к концу игры будешь плох во всем. Я года 3 назад тоже схватился за голову, присел и сам себе сказал: «вот чего ты достиг, что ты умеешь?». И пошли ответы. Оказывается достаточно много, ведь 8 лет просто так без опыта не могут быть. А рас получил ответы, то задался вопросом: «что можно изменить или дополнить, что бы больше зарабатывать?». С тех пор по утрам я учусь. Всему. Старые знания я несколько раз переповторял, заново открывал книги, и уже в них находил ошибки. Я сейчас взял курс на руководителя. Это значит я должен знать все, что мне приносит прибыль, на 30% минимум. Что-то больше, что-то меньше. Но управление и маркетинг обязан знать минимум на 4-ку, т.к. там нельзя брать в процентном соотношении. И сейчас целенаправленно иду к этому.
indestructable
12.11.2018 21:15+1Все хорошо, только учить разные технологии — это не «как в РПГ». Если, конечно, не ставить целью овладение технологией ради технологии (а не ради решения бизнес-задачи).
Stas911
12.11.2018 18:02+4Быть «сорокалетним синьором одной технологии» — это тоже опасно, тк со временем начинает теряться кругозор (а так же отрастать борода и свитер). Опять же диверсификация важна как в финансах, так и в карьере. К тому же технологии имеют тенденцию наскучивать (мне по крайней мере) и редко кто, как мне кажется, хочет копаться 20 лет в одном и том же. Ну да, за 20 лет можно стать мегаджедаем Джавы или Оракла и затыкать всех за пояс на собесах, но в этом ли цель?
BigDflz
12.11.2018 18:18+3Я fullstack, я могу построить систему от 0 до акта. Когда я вижу системы написанные «частичниками» — у меня волосы дыбом встают, сколько глупого кода, лишнего… То что можно сделать в субд, делается в коде языка софта бэка. Насколько это затратно и по коду и по времени выполнения… что можно эффективно сделать на языке софта бэка — перекладывается на язык клиента… Как минимум в команде должен быть руководитель fullstack, а лучшие — вся команда из fullstack. В такой команде всегда найдутся те, кому нравится больше фронт, кому бэк, кому субд. Но такая команда сможет грамотно организовать распределение задачи на нужную область выполнения.
jehy
12.11.2018 19:10+3У вас тут подмена понятий происходит.
Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
Нормальный фронтендер не затащит на фронт то, что нужно делать на бэке.
Плохой разработчик сделает и то и то и другое вне зависимости от того, узкий он специалист или fullstack.BigDflz
12.11.2018 19:18Нормальный бэкендер знает и свой язык и SQL, и не сделает указанной вами ошибки.
Ключевое слово — Нормальный. Но таких ужасающе мало, и к сожалению, я таких не встречал. Хотя в своей «частной» области сеньёры…f0rk
13.11.2018 07:20Откуда вы такие беретесь? Умные, красивые, дартаньяны, все прям могут и при этом «нормальных» бэкендеров не встречали? Я конечно могу жестко заблуждаться, но что-то мне подсказывает, что если вы не работали с крутыми, умными коллегами и в том числе специалистами в узких областях — то вы врядли настолько офигенные, как вы о себе думаете.
BigDflz
13.11.2018 07:37К сожалению — не встречал. Наверное такие есть, не отрицаю, но практика вещь серьёзная… На моей практике людей разбирающихся в субд — мало, зато остальные считают себя спецами и городят функции субд на языке софта системы… — да, в своей области они спецы, но они не понимают, что их труд по реализации функций субд полная фигня… Ладно бы они это признавали и просили о содействии, а то ведь считают себя в этом вопросе истиной в первой инстанции. Придумывают тысячу отговорок, чтоб не использовать возможности субд.
Да и в своей области не всегда красиво выглядят. Есть примеры когда ругают код, а предлагают такое, что добавляет и кучу кода и время выполнения. Как яркий пример использование шаблонизации — да, чисто внешне вроде красиво, как копнёшь… нужно сделать то, сё, пятое, десятое… а в итоге за всем этим скрыто простое построение строки, которое можно сделать просто и наглядно в в несколько строк кода, а не в нескольких файлах. и будет работать а разы быстрее.f0rk
13.11.2018 07:51Можно уточнить, что подразумевается под «простым построением строки», конкатенация?
BigDflz
13.11.2018 08:00по большому счёту — конкатенация, только в java это, если в лоб, очень затратная операция, поэтому используется StringBuilder. В любом случае, и серверный рендеринг, и json, и шаблонизация — это построение строки.
Tsimur_S
13.11.2018 12:50Отлично, сегодня вы сделали конкатенацию строки в процедуре а завтра туда мигрирует вся логика. После этого саппорт подобного «солюшена» превращается в муки ада. Я не спорю что иногда лучше посчитать там где данные обитают чем гонять их по сети, но конкатенировать несколько строк возможностями бд это уже выше моего понимания.
VolCh
13.11.2018 10:30Вот по каким критериям полная фигня? Эти критерии важны для кого? У этих кого нет более важных критериев?
Если код работает, отвечает функциональным требованиям к системе — он уже не фигня объективно.BigDflz
13.11.2018 10:38код может работать 1 мс, а может 1минуту — оба варианта отвечают требованиям.
как правило один код может отличаться от другого на не большое время работы — но таких кусков кода может быть много — в итоге система может либо тормозить, либо быстро работать — выбор за тобойVolCh
13.11.2018 10:44Выбор не за мной, а за людьми, создающими требования. Если в требованиях «время ответа 100 мс в такой-то конфигурации железа и софта», я выберу технологии, позволяющие написать поддерживаемый код как можно быстрее и надежней без превышения этого предела. И я не буду затягивать время разработки в разы, а стоимость поддержки на порядки ради того, чтобы код работал не 70 мс, а 7.
masterspline
12.11.2018 21:30Еще, возможно, что там дело было в плохой организации совместной разработки. Фронтэндеру нужна фича вот прям щас (он фрилансер, про проект целиком даже не в курсе, но пока не доделает свою часть функционала, денег не получит), а бакендер занят своей задачей. Ну, ни вапрос — сам запилю…
boblenin
12.11.2018 23:31А кто нормального бэкэндера и фронтэндера заинтегрирует? Нормальный интегрендер? А если нормальных бэкэндеров отдел из 20 человек и столько же фронтэндеров (реальный пример из жизни — 2 отдела, один UI другой бэкэнд), то как выкатывать функциональность? Кто для кого является зависимостью? Кто определяет структуры данных? Кто определяет типы сообщений и шаблоны коммуникации? А если бизнес выдал новых требований и все, что написали в требованиях — это куча новых формочек, то что делать с бэкэндерами — увольнять? А если на следующий раз выдали кучу отчетности или биллинг переделывать — увольнять фротэндеров?
bogolt
12.11.2018 23:41+4> То что можно сделать в субд, делается в коде языка софта бэка.
Порой вполне оправданно. То что в бд делается через 9 джойнов на коде бэка можно сделать простым кодом — намного дешевле и по времени выполнения и по оперативке, даже на не самом быстром яп бэка.
Другой пример — когда для улучшения скорости бэк хранит часть данных базы в своих структурах данных чтобы не бегать в нее за каждым чихом. Очень важно если нам нужно отвечать на запросы не медленнее икс миллисекунд. В этом случае кстати бэк плюсовым.algotrader2013
13.11.2018 01:29Есть еще нюанс. Да, на стороне sql многое делается сильно проще и эффективнее (даже, когда надо 9 джойнов, то почему бы не задействовать кеши СУБД с отполированным годами кодом, написанным суровыми системными программистами вместо своих велосипедов, к тому же, можно materialized view или триггеры и поддержание +1 таблицы устроить).
Проблема как правило лежит в другой плоскости. Код бека легко покрыть тестами, он будет в рамках паттернов и ооп, он версионируется без костылей, он не требует миграционных скриптов, его проще переиспользовать. Кроме того, вариант "одна субд с мин нагрузкой + куча стейтлес воркеров" идеально масштабируется. Версии воркеров тоже можно обновлять нода за нодой. Также, если речь идет о лицензионном mssql/oracle, которые лицензиуются за ядра cpu, то может быть дешевле нагрузить 3 ядра на сервис хосте, чем одно на машине с субд;)BigDflz
13.11.2018 06:40Конечно, когда идет разговор о стоимости субд, надо выбирать стоимость/всё прочее. Но это уже административный вопрос, который накладывает ограничения на программиста.
С другой стороны если грамотно построить структуру субд, грамотно написать запросы/хранимки — может и не потребоваться масштабируемость.VolCh
13.11.2018 10:33Речь о том, что руками написанные запросы и, тем более, хранимки очень сложны в поддержке. И дороги для бизнеса.
BigDflz
13.11.2018 10:44стоимость запроса/хранимки зависит от умения владеть инструментом, для меня это не имеет значения. для меня важно суммарное быстродействие системы. система работает быстро — заказчик доволен.
VolCh
13.11.2018 10:49Заказчик доволен, когда скорость и приемлемая, и стоимость приемлемая. Суммарная быстродействие системы для него важно, но не критично, пока оно приемлемо.
anprs
13.11.2018 11:39Плюс миграция с условного оракла на условный постгрес в первом случае будет значительно больнее
BigDflz
13.11.2018 06:34Глубокое заблуждение, те же 9 джойнов выполнятся намного быстрее, чем код. Есть очень хороший пример в области jsva — Hibernate. Его любители не понимающие в субд. Это такой тормоз, такое количество лишнего кода, огромное потребление памяти. и эта прокладка использует только поверхностные возможности субд. Такие спецы, не зная субд, ытаются реализовать функции субд в своём коде, хотя всё уже реализовано в субд. А их реализация выглядит жалким подобием субд, с добавлением тормозов и ошибок. Такая реализация плохо читаема, плохо сопровождаема…
bogolt
13.11.2018 10:13Про 9 джройнов пример из жизни. Один и тот же набор данных, в двух вариантах — в одном случае 9 джойнов, в другом последовательные вызовы ко всем необходимым таблицам и последующая обработка-склейка данных в коде ( на перле ). Результат с обработкой кодом — улучшение по скорости примерно в 20 раз.
transcengopher
13.11.2018 12:55Честно говоря, звучит как рассказ про встречу с единорогами.
Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным. Именно поэтому в т.н. BigData описание вычисления присылают в хранилище данных, а не данные из хранилища присылают исполнителю вычисления.
Разве что в описанном случае запрос вышел очень неоптимальный, но при этом с крайне низкой кардинальностью по данным в итоге. Тогда да, обработка в лоб действительно может быть быстрее. С другой стороны, уверен, что перестроенный и оптимизированный запрос всё равно выиграет.bogolt
13.11.2018 13:10Хм, запрос время от времени писал в лог, что ему не хватило оперативки на выполнение и фэйлился. План не изучал.
Daemon_Hell
13.11.2018 13:54+1Так может традиционная ситуация что индексы забыли и бд поехала вычитывать все таблицы полностью?
VolCh
13.11.2018 16:58Это ведь один из достаточно логичных постулатов: работу с данными следует производить как можно ближе к данным.
Это больше на демагогический постулат походит. Ну или на "кодерско-оптимизаторский" (хотя не факт, что на практике будет быстрее, если СУБД у нас толком не масштабируется, а апп-серверы сотнями можно поднимать). Инженерный подход подразумевает не только техническое, но и экономическое обоснование.
transcengopher
14.11.2018 20:22+1Никакая не демагогия, вот отсюда беру, обратите внимание на пункт “Moving Computation is Cheaper than Moving Data”:
hadoop.apache.org/docs/r1.2.1/hdfs_design.html
Уж поверьте, как кодер я был бы только рад унести логику обработки данных из «холодной, безразличной» и требующей многословных запросов базы данных (где, например, попытки переиспользовать код обычно натыкаются на ощутимые тормоза ввиду переключения контекстов между SQL и PL) в уютный для меня любимый язык программирования. Но сетевой доступ к хранилищу не может происходить по путям бесконечной ёмкости, а значит, чем больше работы я сделал вдали от данных, тем больше данных было передано по сети. А это вещь ненадёжная и медленная.
Я не исключаю что в каких-то системах такой подход может не работать и сервер базы загружен на 98%, но с другой стороны, если мы можем поднять сотню аппсерверов (для чего, кстати? вручную делать join'ы и закат солнца до кучи?), то почему мы не можем поднять «клон» для чтения, к примеру? Или поделить данные между несколькими базами, для начала, а склеивать уже результат от полученный от одинакового запроса к разным базам?Druu
14.11.2018 22:08+1Никакая не демагогия, вот отсюда беру, обратите внимание на пункт “Moving Computation is Cheaper than Moving Data”:
Там же никакой аргументации не приведено. Точно так же можно заявить, что лучше данные обрабатывать там, где они будут непосредственно использоваться, т.к. тогда мы сэкономим на передаче данных к клиенту.
Пример: рендер изображения в сетевой игре происходит на клиенте, а не на сервере
transcengopher
15.11.2018 11:26> Пример: рендер изображения в сетевой игре происходит на клиенте, а не на сервере
Плохой пример: если изображение это данные, то их совершенно правильно не передают с сервера, вместо этого клиенту передаётся описание вычислений, необходимых для получения правильных данных (поток событий в матче).
С другой стороны, в ММО, опять, же не передают все данные из базы на клиента, дабы клиент сам определился, какие из них ему действительно нужны и сделал необходимые вычисления. Переводя на язык СУБД, в таком случае вся фильтрация и join'ы произведены на сервере (в базе данных), клиенту приходит только проекция. Когда такая схема нарушается по любой причине, появляется возможность сжульничать — например, убрать «туман войны» в стратегии (применимо только для стратегий с сервером-арбитром правда, обойтись без дупликатов данных в P2P играх, насколько я знаю, пока не получалось ни у кого).
VolCh
14.11.2018 22:47Что интересно, хотя в заглавии пункта «Cheaper», в самом пункте «much more efficient… when the size of the data set is huge». Может поэтому в кавычках? О технической оптимизации, о скорости, я уже говорил, но бизнесу нужны экономические обоснования. А ваше «был бы только рад» намекает на то, что отсутствие радости на работе нужно чем-то компенсировать, обычно деньгами :)
transcengopher
15.11.2018 11:32Так мы вроде и обсуждаем здесь случай, когда данных много? Иначе зачем для их хранения нужна база данных? Малые объёмы можно держать и в оперативной памяти где-нибудь.
А ваше «был бы только рад» намекает на то
… что я уже взвешивал несколько раз возможность "вытянуть всё и на месте разобраться в коде". И ни разу это не оказалось приемлемой стратегией. Более того — несколько раз мне приходилось такие подходы из кода вычищать калёным железом, так как в раунде PSR-тестирования выявлялось сильное падение отзывчивости системы, и причиной были именно, закаты солнца вручную на сервере вместо написания нормального запроса в базу данных.
VolCh
15.11.2018 16:46Huge — это обычно не про много, а про «немеренно». И часто ресурсы приложению выделяется столько, чтобы вся база в оперативке помещалась, если их немного, или много, но не сильно — гигабайты. Просто с экономической точки зрения обычно в сторонней СУБД хранить выгодней. Не эффективней по вычресурсам, а выгодней весь цикл жизни приложения.
mayorovp
15.11.2018 12:07Этот постулат верен только когда идет работа с большими или «средними» данными. Для мелких данных (порядка сотни записей) могут проявляться обратные эффекты.
VolCh
13.11.2018 10:39Hibernate и прочие ORM сделаны как раз чтобы улучшить читаемость и сопровождаемость кода, обычного ООП-кода. И использование ORM вовсе не значит «неумение в субд», может быть просто принято решение не использовать всю мощь конкретной СУБД, ради увеличения скорости разработки, улучшения читаемости и сопровождаемости. А если где-то вылезет нарушение нефункциональных требований по производительности, то отпрофилируют и перепишут точечно на SQL и ко критически важные части.
BigDflz
13.11.2018 11:18конечно, против административного решения не попрёшь, но цена такого решения — очень огромна. О читаемости и сопровождаемости хибера — вопрос спорный, потому как для него надо много классов/файлов для простого изменения. И опять таки для меня нет проблемы прочитать и понять запрос/хранимку. За неиспользованием все мощи субд придется заплатить масштабированием, приобретением нового, дорогого железа. Конечно это всё можно обосновать красивыми словами, но с точки зрения кода это глупо.
VolCh
13.11.2018 16:49Я не об административном, когда решил заказчик или начальник. Собрались разработчики и решили, что c ОРМ проект быстрее запустится и проще его будет поддерживать и развивать. Ну или единственный разработчик, который хоть знает об альтернативах так решил :) А за использование всей мощи СУБД придётся заплатить усложнением поддержки, замедлением (ну или удорожанием) разработки, усложнением развёртывания. Конечно это всё можно обосновать красивыми словами, но с точки зрения кода (а не его эффективности) это глупо :)
BoberCoder
13.11.2018 18:13+2За неиспользованием все мощи субд придется заплатить масштабированием
Можети привести пример как вы платите масштабированием за хабирнейт? Хабернейт это всего лишь дополнительная нашлепка, которая помогает замапить данные в объекты. Т.е. если у вас бэкэнд на жаве, с большой вероятностью вам и так придется это делать, а с хабернейтом код просто будет чище.
потому как для него надо много классов/файлов для простого изменения
Ну как бы нет, если у вас много кассов/файлов в изменении, то значит это уже не простое изменение. Т.е. опять если вы мапите результат квери в жава объекты без хабернейта, то изменения в базе спровоцируют изменения в коде, причем изменения как в коде мапинга так и в объектах, а с использованием хабернейта только в объектах.
P.S.
Понятное дело, что за использование универсальной библиотеки вы всегда немного платите производительностью, но если на этом зацикливаться так можно и на с++ все писать. Когда я только начинал с хабернейтом, я тоже от него плевался по началу. Но после того как я в нем разобрался он оказался не так уж и плох.transcengopher
14.11.2018 20:29ORM сияет обычно при записи, потому что не нужно думать, какие сущности сохранять первыми, какие вторыми и так далее. Очень сильно помогает если в схеме присутствуют циклические связи.
Для запросов и их результатов ORM подходит куда меньше, хотя бы потому, что не позволит просто так пойти и высчитать среднее, бегущую сумму или какой-нибудь изврат с оконными функциями — а это обычно самые интересные данные с точки зрения заказчика.alsii
14.11.2018 20:53+1Хм… Кто вам запрещает строить запросы используя поддерживаемые ORM аггрегатные функции?
И с чтением/записью как раз все наоборот. ORM здорово тормозит на операциях bulk import, и редко умеет делать partial write объектов. Еще проблема в том, что persistent manager перед тем как сформировать update-запрос должен понят, какие именно объекты изменились, а это при большом их количестве занимает много времени даже в RAM.
А вот как раз с чтением данных проблем как раз никаких. Потому, что запросы на чтение вы формируете сами и такие, какие считаете нужными. На этом этапе фактически работает только DBAL. А уж субстантизация полученных результатов запроса тоже зависит только от того, что вы понаписали в конструкторы и какие навешали на ваши объектв ORM-хуки. Собственно забота ORM — это сделать new, да заполнить свойства объекта.
Что же до курсоров и бегущих сумм, то это уже вообще говоря за рамками реляционной модели. Стоит ли такие вещи класть в СУБД? Не знаю… Может оказаться, что вам нужна сумма по страницам, а размер страницы зависит вообще говоря от устройства вывода.
Если у вас на все ВЦ одно АЦПУ, тогда почему бы и нет. А если у вас размер страницы зависит от размера окна браузера пользователя, то наверно это будет несколько затруднительно.
Вообще гуру учат отделять представление от модели, но может быть вы не верите во все это новомодные (для 1970-х годов) штучки…Fesor
14.11.2018 22:33> ORM здорово тормозит на операциях bulk import
bulk import благо не самая распространенная задача. Да и для конкретного кейса можно придумать что-то поинтереснее.
В целом ORM нужны там где у вас OLTP (OnLine Transaction Processing). То есть берем чуть-чуть данных (агрегат, границы бизнес транзакции, DDD), делаем с ними что-то и записываем.
Чтение и т.д. — для этого проще делать отдельно выборки через SQL. Тут не только с точки зрения производительности сколько с той точки зрения, что модели данных для чтения и записи нужны обычно разные.
Собственно вы сами в конце про разделение представлений говорите.alsii
15.11.2018 14:25bulk import благо не самая распространенная задача. Да и для конкретного кейса можно придумать что-то поинтереснее.
Whom how. У меня информация от контрагентов поступает в виде файлов в разных форматах, с нетривиальной структурой, и что самое ужасное непостоянной структурой и часто неконсистентными данными (опечатки, вручную сформированные записи, проблемы с кодировками и т.п.), и все это нужно целый день импортировать, импортировать, импортировать.
Неконсистентность помянута потому, что в случае неконсистентных данных приходится применять всякие нечеткие критерии поиска, которые часто базируются на заведомо консистентных данных уже находящихся в БД. И это одно из самых нелюбимых мной мест в коде. Пререписывать все это на SQL… Боже упаси!
Fesor
15.11.2018 18:42> У меня информация от контрагентов…
Сейчас бы по одному кейсу статистику по индустрии проэцировать. Импорт данных может быть, но чаще всего это импорт части данных а не всех. Да, есть исключения, как и проекты где вообще нет bulk import.
tgregory
13.11.2018 16:06ORM скорее сделаны для того чтобы объектную модель натянуть на реляционную, при некотором сходстве двух моделей они всё же разные, так получилось, что реляционные БД намного более популярны чем объектные, а в языках программирования у нас объектная модель.
Crandel
13.11.2018 12:51База данных не всегда одна на приложение, может быть микс из sql и какой-то монги для метрик.
alsii
13.11.2018 18:12+2Использование ORM — это прежде всего избегание vendor lock. От СУБД в этом случае требуется только стандартный SQL, без всяких «фирменных» дополнений. И менять их (СУБД) можно практически на ходу.
Плюс хранимые процедуры и особенно триггеры усложняют такие вещи, как версионирование и развертывание. Плюс требуют от разработчика дополнительных компетенций, что автоматически сужает количество кандидатов и увеличивает их зарплату.
Я думаю, что с точки зрения бизнеса такое оправдано только как последнее средство в каких-то весьма высоконагруженных приложениях.Fesor
13.11.2018 20:38+3прежде всего избегание vendor lock
то есть мы избегаем лока от одного вендора за счет лока на другого вендора (Надеюсь вы не пишите свои ORM).
Задача ORM не абстракцию от базы вам предоставить, а мэппинг данных организовать, из реляционной модели в ваши in-memory структуры. При этом у вас может быть тотальная завязка на нюансы конкретной СУБД. Дальше все больше про разделение ответственности (изменения персистенса не должны влиять на бизнес логику, но думать что при смене СУБД вам код не придется писать — глупо).
как версионирование и развертывание.
на самом деле нет. Все это тоже можно мигрировать и версионировать, и обратную совместимость схемы между деплоями никто не отменял (потому что вы не можете абсолютно одновременно, без даунтайма выкатить одинаковые версии схемы и кода)
Плюс требуют от разработчика дополнительных компетенций
Если подумать то объем знаний необходимых для работы с каким-нибудь nhibernate сопоставим с объемом знаний для работы с процедурами. Да, это сильно разный опыт, и стоит ориентироваться на рынок труда (а он такой что я ни тот ни другой вариант бы не доверил большинству)
в каких-то весьма высоконагруженных приложениях.
Обычно оправдание — тотальное разделение ответственности и контроль за данными, секьюрити политики и т.д. Производительность — сомнительный довод. Да и процедуры будут ограничивать вас по горизонтали (хотя кто его знает).
p.s. Если что — принципиально не использую процедуры/тригеры для бизнес логики и пока не встречался с юзкейсами где это все дает очевидные преимущества. Но полагаю такие кейсы есть. Не подумайте что я там фанат таких вещей.
alsii
14.11.2018 19:25+1> то есть мы избегаем лока от одного вендора за счет лока на другого вендора (Надеюсь вы не пишите свои ORM).
ORM — это все же библиотека. Она — часть разрабатываемого вами продукта. Вряд ли заказчик будет самомстоятельно пересобирать ваш продукт. СУБД — это тоже часть проекта, но это внешний компонент, и нет причин, кроме тех, что я упоминал к нему привязываться. Vendor Lock — не абсолютное зло, но все же зло. И причины, которые его оправдывают должны быть достаточно серьезными.
> Задача ORM не абстракцию от базы вам предоставить, а мэппинг данных организовать, из реляционной модели в ваши in-memory структуры.
Задача ORM — реализовать слой абстракции в виде хранилища объектов с реляционными отношениями между ними.
> потому что вы не можете абсолютно одновременно, без даунтайма выкатить одинаковые версии схемы и кода
Хм… я могу одновременно задеплоить разные версии воркеров, которые будут реализовывать разние версии API. Я не слишком глубоко знаю SQL, но я не вижу способа задеплоить одновременно несколько разных версий SQL-триггрер.
> Обычно оправдание — тотальное разделение ответственности и контроль за данными, секьюрити политики и т.д.
А в чем тут проблемы с ORM? Вовсе не обязательно, чтобы все пользователи ходили к СУБД под одним пользователем.
> Но полагаю такие кейсы есть.
Да есть конечно. Тысячи их. Тот же Highload, когда приходится вылизывать планы исполнения запросов и играться с тонкими настройками СУБД. Или когда это голый CRUD.
Вообще, для меня использование хранимых процедур для бизнес-логики это примерно как ассемблерные вставки в высокоуровневом языке. Можно, но если других способов нет.Fesor
14.11.2018 20:09но это внешний компонент
Почему? Можно ли воспринимать скажем версию JVM как "внешний компонент"?
У меня вещи типа база данных это внутренний компонент. Я поставляю код как готовую инфраструктуру (предположим через докер). И я регламентирую что нужно для того что бы код работал.
У меня был один кейс когда мне была выгодна смена субд прозрачная — у заказчика был тот самый вендор лок на оракл, и ничего другого они юзать не могли. И выяснилось это через 3 недели посте старта проекта. Но там и проект примитивный.
Так что нет, сегодня завязка на конкретную СУБД это данность на хоть сколько нибудь серьезном проекте.
Вы же не переживаете что выбрав определенный язык программирования вы как бы тоже создали себе вендор лок?
Задача ORM — реализовать слой абстракции в виде хранилища объектов с реляционными отношениями между ними.
Тогда было бы не O/RM (Object-relational mapping) а Object-Relation Abstraction какой. Задача ORM — исключительно мэппинг одного в другое. И при том что две эти модели данных (основанная на реляциях и ваши in memory структуры) сильно различаются, то и мэппинг мы можем сделать в ограниченном наборе сценариев (всему виной такая вещи как референсы, которые выражены сильно по разному)
Хм… я могу одновременно задеплоить разные версии воркеров, которые будут реализовывать разние версии API
это как UI, попробуйте такое с бизнес логикой провернуть. И не важно будет в тригерах она или в коде. Ну либо ваши две версии воркеров должны реализовывать совместимость на уровне бизнес процессов. Что как бы… можно провернуть и с тригерами.
но я не вижу способа задеплоить одновременно несколько разных версий SQL-триггрер.
Я не вижу необходимости в этом. Но вообще зависит от вашей СУБД. В PostgreSQL подобное можно хитро замутить со схемами.
А в чем тут проблемы с ORM? Вовсе не обязательно, чтобы все пользователи ходили к СУБД под одним пользователем.
Это больше про загоны с отслеживанием изменений. Ну знаете, есть задачи в рамках которых изменение одного символа требует проверки со стороны каких-то контролирующих органов. А потому вам хочется вот это что-то очень изолировать от всего дабы менялось пореже и не влияло на циклы релизов.
Такое можно и с кодом провернуть (здрасте микросервисы).
Тот же Highload
Я уже упоминал тут что в хайлоад врядли тригеры и процедуры хорошо ложатся ибо вы ограничиваете себя скейлингом по вертикали. Горизонтальный уже сложнее.
alsii
14.11.2018 21:28Можно ли воспринимать скажем версию JVM как "внешний компонент"?
Почему нет? Можно и ОС, и веб-сервер рассматирвать как внешний компонет, и все остальное. Чем меньше зафиксированных зависимостей пришлось затащить в проект — тем лучше.
Так что нет, сегодня завязка на конкретную СУБД это данность на хоть сколько нибудь серьезном проекте.
Не увидел серьезных обоснований. Вы просто на писали как вы привыкли делаеть это. Попробуте делать по-другому. Я уверен, у вас все получится.
всему виной такая вещи как референсы, которые выражены сильно по разному
Выражены по разному, но смысл у них одинаковый — сама природа реляционных отношений.
это как UI, попробуйте такое с бизнес логикой провернуть.
Воркеры это про UI? С чего бы вдруг? Хотя что считать UI? Если у меня воркеры e-mail формируют, и я шаблон поменял. И для нового шаблона требуются данные, которые не нужны были для старого. Что мешает работать и тем и другим параллельно? Или e-mail — это тоже UI?
Или если у меня с определенного месяца алгоритм расчета комиссий поменялся. Что мне мешает запустить комплект новых воркеров, которые будут это делать для нового месяца и параллелльно использовать старые, для предыдущих месяцев?
можно хитро замутить со схемами.
Можно. Но зачем? Ради суперзадачи "использовать триггеры во что бы то ни стало?"
Это больше про загоны с отслеживанием изменений.
Вот как раз тут через ORM все чудесно решается. Через Entity lifecycle events. Или вы полагаете, что "триггеры" бывают только в СУБД? Кстати, довольно "дешево" реализуется, т.к. отслеживание изменений в ORM обычно из коробки. и сторонние сервисы подцепляются легко. Я в последнем проекте просто кидал сообщение в менеджер очередей: "Пользователь IvanovAA поменял зарплату сотруднику Иванов А.А.". А там его уже логировали, кому следует на проверку отправляли и "завертелась карусель". Кстати, вопрос… в PostgreSQL в триггкре доступна информация о пользователе, выполнившем транзакцию, и можно ли к каким-то внешним службам обратиться, типа RabbitMQ или Redis? И желательно асинхронно, дабы не тормозить процесс.
Я уже упоминал тут что в хайлоад врядли тригеры и процедуры хорошо ложатся ибо вы ограничиваете себя скейлингом по вертикали. Горизонтальный уже сложнее.
Тут не стану с вами спорить, ибо не специалист по триггерам и процедурам. Но они что, правда не работают в кластерах и при шардинге?
Fesor
14.11.2018 23:02На всякий случай повторю, а то может быть вы не заметили — я НЕ использую тригеры и процедуры для бизнес логики и категорически против этого на своих проектах. Опять же я категорически против так же называть 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)
alsii
15.11.2018 14:12+1Наши с вами комментарии становятся все длинее и длиннее. Это верный знак, что мы движемся куда-то не туда. Я решил посмотреть куда именно, и, как мне кажется, понял проблему.
Наши подходы в принципе совпадают.
- Я не отрицаю, что иногда триггеры и хранимые процедуры могут быть полезны. Вы привели много примеров этого.
- Вы утверждаете, что ORM не панацея и не серебряная пуля. Я согласен с вами на 100%. Я вообще думаю, что "серебряных пуль не бывает".
- Мы расходимся в оценках того, какие именно особенности ORM являются их сильными и слабыми сторонами, но это во-первых все же вторично, а во-вторых сильно зависит от конкретной задачи. Можно рассмотреть 100 сферических ТЗ в вакууме, но это явно выходит за рамки дискуссии в комментариях.
Очевидно разное понимание роли ORM в проекте, сложилось скорее всего по моей вине. Мой опыт как раз ограничен "очень сложными" ORM с DBAL, UoW, Lifeсycle Events, Query Builder, Repository Pattern, Entity Collections, Criteria, блэкджеком и всем остальным. В результате у меня в коде проекта не бывает не то что хранимых процедур, а SQL вообще. Или lazy loading, или Query Builder, или Criteria.
Глупо с моей стороны было упускать из виду существование ORM as is, без всего этого "богатства". Прошу простить мне мою профессиональную деформацию.
Насчет зависимости от СУБД. На ранних стадиях предпоследнего проекта (около 15% кодовой базы) я пробовал интереса ради запуститься с PostrgeSQL вместо MariaDB. После некоторой пляски с настройками ORM все получилось. Код менять не пришлось.
Fesor
15.11.2018 18:46> Глупо с моей стороны было упускать из виду существование ORM as is
Подозреваю что вы пользуетесь либо Доктриной либо Чем-то вроде гибернейта, ну тогда в целом мы используем одни и те же инструменты.
разница лишь в том что вот все эти «богатства» это про persistence а не про бизнес логику. И да, я помню как я сам завязывал на всякие вычисления чейнджсетов бизнес логику — это прямая дорога в ад на любом маломальски сложном проекте.
Ну и еще раз — вы сами предлагали посмотреть на вещи «по другому». Например — event sourcing вполне себе компромисный вараинт, который позволяет вам крутить вертеть вашей моделью данных как угодно.
VolCh
14.11.2018 15:53+1ORM и DBAL не синонимы и не вложенные множества. Отсутствие vendor lock в случае универсальной ORM лишь бесплатній бонус, если вам нужен маппинг, и огромній оверхид если нужна абстракция от диалекта SQL.
usego
13.11.2018 20:58+3Проблема с хибернейтом не в хибернейте, а в том, что его применять необходимо правильно, что требует опыта и сениорского уровня. Чаще же к любому ORM относятся как к упрощающей прослойке с которой любой джуниор может работать, в результате и получается то, что получается.
Stas911
14.11.2018 00:44Ну и выстрелить себе в ногу там пара путяков — одно неловкое движение и он загружает в память тьму данных (по крайней мере лет 10 назад так было)
VolCh
14.11.2018 16:00+1Что опять же подразумевает сеньорские знания в случаях отличных от самых тривиальных :)
alsii
14.11.2018 19:35Хм. Вы думаете на SQL невозможно написать что-то подобное? Ошибка в условии в UPDATE… JOIN может давать очень интересные эффекты. Но гораздо более частая проблема неправильного использования ORM — это N+1 запрос.
ORM — она (он?) такая же реляционная как СУБД под ней. Поэтому использование ORM не отменяет необходимости понимания того, как работает реляционная модель данных. Должен ли это понимать джун? Я думаю да.Fesor
14.11.2018 20:11ORM — она (он?) такая же реляционная как СУБД под ней.
реляционная в смысле орудует реляционной алгеброй (ну там картежи данных, предикаты) или в каком смысле вы употребляете это слово?
Должен ли это понимать джун? Я думаю да.
Понимают ли? думаю нет. Для подавляющего большинства джунов ORM это волшебная коробка которая просто работает. Более того — это довольно распространенное мнение. Вот выше тоже вещают про то что ORM это абстракция от базы. А если оно абстракция — значит про базу знать не обязательно.
alsii
14.11.2018 21:39реляционная в смысле орудует реляционной алгеброй (ну там картежи данных, предикаты)
В том смысле, что она орудует сущностями связанными отношениями. Если пожелаете, то можно и с предикатами. Есть например забавные штуки, которые позволяют строить запросы, которые отрабатываются по уже загруженным данным, вообще не обращаясь с СУБД, если все что нужно уже имееется. а если нет, то будет запрошено. Есть разумеется, некоторые ограничения, но иногда очень полезно.
Для подавляющего большинства джунов ORM это волшебная коробка которая просто работает.
Для подавляющего большинства джунов RDBMS — это волшебная коробка которая просто работает. Более того — это довольно распространенное мнение. "Оптимизация индексов? План исполнения? Нет, не слышали! Там есть какой-то оптимизатор внутре, вот он пусть и оптимизирует. А мы умеем в SELECT и UPDATE".
Fesor
14.11.2018 23:08которые отрабатываются по уже загруженным данным
и джойны там есть? Или чисто проверка условий? Ну мол реляционная алгебра это все ж чуть интереснее чем фильтрация коллекции.
Опять же — главное пожалуй отличие — отсутствие ссылок и возможности однонаправленные one-to-many связи делать (у вас на стороне many fk что делает его зависимым от one)
Ну и за счет всех этих нюансов и появляются кучи плюшек по оптимизации. А так можно просто key-value хранилище сделать и индексы строить, никто не мешает. Объектно-ориентированные базы были, сейчас вот есть документно ориентированные (или мой любимый объектно/реляционный постгресс)
alsii
15.11.2018 16:25и джойны там есть? Или чисто проверка условий? Ну мол реляционная алгебра это все ж чуть интереснее чем фильтрация коллекции.
Тут начинаются тонкости реализации.
Джойны есть в том смысле, что вы можете фильтровать по свойствам вложенных объектов. Ну и естественно получив объект(ы) вы получите доступ ко всему "дереву зависимостей". Но в общем да, это все же просто фильтрация. И если есть lazy loading, вы рискуете получить x*N+1, если cвязанные сущности не подгружены. Тут уж вам решать надо оно вам или нет. Ну и иногда (при больших объемах данных) быстрее будет выполнить запрос к СУБД, чем копаться в памяти.
у вас на стороне many fk что делает его зависимым от one
Нет, ну ORM — это все же не RDBMS, но связи между объектами и некоторые реляционно-ориентированные операции
поддерживаютсямогут поддерживаться.
transcengopher
15.11.2018 11:50забавные штуки, которые позволяют строить запросы, которые отрабатываются по уже загруженным данным
Расскажите подробнее, пожалуйста. Какие группы запросов поддерживаются — произвольные, или только фильтрация по PrimaryKey? Если произвольные запросы, то чем обеспечивается доказательство, что из базы уже всё прочитано в память, и в базу лезть не требуется?
Просто если здесь только фильтрация по PrimaryKey, то такие штуки по факту являются банальным кэшем, и ввиду этого абсолютно не забавны. А вот если там поддержка произвольных запросов (и не просто кэширование результатов) — то это да, интересно неимоверно.
alsii
15.11.2018 16:34Если произвольные запросы, то чем обеспечивается доказательство, что из базы уже всё прочитано в память, и в базу лезть не требуется?
Со стороны ORM ничем и никак. Любая коллекция итерируется так, как она есть. Рассматривайте это просто как кэш с некоторыми дополнительными фишками. Волшебного решения инвалидации кэша из коробки нет. Можно просто выкинуть все или часть загруженных сущностей. Тогда при следующем обращении они будут вытянуты. Плюс — lazy loading, который иногда удобен, но при неправильном использовании даст вам N+1.
Фильтрация в принципе произвольная, но с учетом оговорок выше.
VolCh
15.11.2018 16:51Может быть интересно: произвольные запросы разбиваются на две части: получение нужных идентификаторов и получение записей по идентификаторам, где для уже имеющихся запроса на получение не делается.
Virviil
13.11.2018 01:05+1Промышленная разработка софта отличается от идеальной разработки софта. Решения принимаются в различных условиях и всегда с неполными данными. Грамотная архитектура недостижима, когда приходишь в проект в любом случае видишь говно.
Пример с БД и бэком может быть обусловлен тысячей причин, начиная с "спроектировали БД, потом появились новые требования" заканчивая "для возможности будущей миграции с SQL на NoSQL (или наоборот) принято решение вынести логику на уровень Бэка".
То же самое с фронтом: ВК например отправляет через AJAX на фронт сразу куски готового HTML, в то время как стандарт — это JSON. Даже если условия изменились, и сейчас какое-то решение выглядит глупым, вполне возможно что оно принято в других условиях и сейчас это тупо ДОРОГО переделывать.
Глупость кода, таким образом, в 95% случаев не глупость, а стечение обстоятельств, недостаток рефакторинга и ошибки в архитектурных решениях, принятых в условиях дефицита информации, которых было невозможно избежать. А в оставшихся 5% случаев допускаются как "фулстеками" так и "частичниками".
И кстати, опять же с точки зрения архитектуры, "частичникам" гораздо проще сохранить консистентность слоев. Если ты знаешь свои границы — через них так просто не перейдешь.
А вот если ты пишешь сверху донизу, то вот тут как раз очень просто поместить логику "не туда", куда ты поместил аналогичную логику в прошлый раз. Да, может быть это дает какой-то эффект, но убивает архитектуру кода и ее консистентность.BigDflz
13.11.2018 07:02Я не говорю о проблемах возникших при сопровождении, я говорю о стадии разработки — это видно, когда возникла эта глупость…
Когда знаешь свои границы…, но чаще бывает важнее знать что и где выгоднее выполнить. Это важно ещё на стадии разработки.
Вот упоминание json… все считают стандарт… но это лишняя, как минимум двойная работа. Ajax — даже на новые разработки его втыкают, когда уже есть websocket.
Дорого переделывать — а кто оценивает? фуллстек? или «узкий специалист»?Virviil
13.11.2018 08:29+1Судя по вашему комментарию вы очень далеки от процессов разработки софта, я уж не знаю как:
В любом Agile окружение "разработка" и "поддержка" трудно отличимы после первого же цикла, а после MVP это вообще уже одно и то же.
Никогда не "выгоднее" выполнить что-то не там где надо, потому что с кодом работают люди, и им надо писать его так, чтобы можно было его поддерживать. Иначе бы все в мире писали на ассемблере, потому что это "очень выгодно".
json — лишняя, двойная работа? Вы о чем вообще??? Ajax заменяется веб-сокетом? Серьезно?? Наверное именно поэтому в GraphQL спецификации есть И Ajax И websocket? Я уже молчу о том, что по вебсокету обычно все передают json...
Дорого переделывать — обычно оценивает бизнес. Потому что он платит деньги. И это важно понимать любому разработчику… Если говорить про конкретных людей — CTO, Архитектор, ТехЛид, ТимЛид. Люди с кругозором на весь используемый стек.
BigDflz
13.11.2018 09:01Достаточно 3 пункта, чтоб понять, что дальнейший спор бесполезен.
json — лишняя, двойная работа
1 Преобразование данный в json
2 Пребразование json в html (рассматриваем веб проекты)
все это можно заменить на сервере простым «серверным рендерингом» преобразованием данных а hyml. на клиенте html строка вставляется в дом 1 строкой кода.
Ajax заменяется веб-сокетом? Серьезно??
элементарно на все 146%, без всяких проблем, что и делаю с момента появления websocket, без использования ajax.
Я уже молчу о том, что по вебсокету обычно все передают json...
Очень важное слово «обычно»,(раньше обычно ездили на телегах...) можно просто передать html, будет просто и наглядно и быстро. Я видел как запаковывают html в json вместе с другими с другими данными, но это отрыжка из прошлого, когда использование ajax требовало режима запрос-ответ, т.е. на один запрос только один ответ. Технология websocket позволяет отойти от этого. Чем я и пользуюсь.
Мало того, websocket позволяет снизить нагрузку на сервер. позволяет отображать данные в реальном масштабе времени. Есть проекты где по ws предаются данные с arduino, пишутся в базу и отображаются в виде бегущего графика у клиента, и все это в реальном времени с минимальной нагрузкой на сервер…VolCh
13.11.2018 10:472 Пребразование json в html (рассматриваем веб проекты)
В большинстве новых проектах на "хайповых" технологиях преобразования в html нет, преобразование идёт в DOM
BigDflz
13.11.2018 11:27есть, конечно варианты, но все равно это строка не json, в той или иной форме это строка из элементов html. Если мне надо вставить в див таблицу, я сформирую на сервере html строку таблицы. отправлю её клиенту и вставлю в дом простой командой .innerHTML='html_строка_таблицы'. есть вариации типа DocumentFragment., но это сути не меняет.
В большинстве новых проектах на «хайповых» технологиях преобразования в html нет, преобразование идёт в DOM
не будь голословным приведи варианты этих хайповых технологийfaiwer
13.11.2018 12:04+1не будь голословным приведи варианты этих хайповых технологий
React, Angular, Vue, KnockoutJS, Svelte, Ember… Честно говоря практически всё, что вы только сможете найти в области SPA. При этом oldschool подход формирования кусочков HTML на стороне backend продолжает использоваться в более простых задачах. Чем проще продукт, тем меньше ему нужно заморочек с frontend. Большая часть вебсайтов в сети будут себя прекрасно чувствовать вовсе без JS, используя только HTTP + HTML + CSS + JS.
.innerHTML='html_строка_таблицы'
Очень странно, что вы умудряетесь совмещать в своих проектах такие вещи как WebSocket (штука крутая, но нужна оооочень ограниченному числу проектов) и
.innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.BigDflz
13.11.2018 12:10-2React, Angular, Vue, KnockoutJS, Svelte, Ember
это всё фантики, я же просил код, пример.
штука крутая, но нужна оооочень ограниченному числу проектов
это просто потому что многие не умеют её готовить. проще по-старинке ajax…
.innerHTML=. Это примерно как летать на флайборде по торговому центру с каменным зубилом.
а что тут такого? на сервере готовлю html строку и на клиенте вставляю, просто, быстро, наглядно. Есть что-то более проще — воспользуюсь.faiwer
13.11.2018 12:19это всё фантики, я же просил код, пример.
Что именно вас интересует? Внутри этих библиотек используется DOMAPI (appendChild, createElement, setAttribute & etc...). Вам ссылку на MDN? Или ссылку на те места где эти методы используются в недрах этих библиотек? Или ссылку на те места где вы их руками в своём коде пишете? Если последнее, то в том то и суть, что руками вы это пишете только совсем уж в исключительных случаях. Библиотека\фреймворк делает это за вас в оставшихся 99%. Вы работаете над данными и взаимодействиями между ними.
это просто потому что многие не умеют её готовить. проще по-старинке ajax…
Нет. Полным полно людей умеющих готовить WS. Да и библиотек хватает (socket io, atmosphere, ...). Просто не нужно оно в 95+% случаев. Это один из множества инструментов, который вы приняли за серебряную пулю.
а что тут такого?
Ничего плохого в использовании каменного зубила нет. Просто непродуктивно это для больших и сложных frontend-проектов. Поэтому уже больше 5-и лет для сложных задач используют различные реактивные вещи. Правда более простыми я бы их не назвал, погружаться в эти технологии придётся долго и трудно. Это существенный пласт знаний, без которых сегодняшняя разработка серьёзных фронтенд приложений просто немыслима (ооочень дорого).
По сути это всё настолько объёмный пласт знаний, что по первой это может вызвать кровоизлияние в мозг. Шучу. Все эти webpack-и, babel-и, JSX-ы, React-ы, PostCSS-ы и тысячи других баззвордов — это реалия современного фронтенд рынка.
BigDflz
13.11.2018 12:28(appendChild, createElement, setAttribute & etc...)
это всё теже перепевы innerHTML, и конечно я их использую в тех местах где нужно, innerHTML я привел как самый элементарный, показательный вариант.
Нет. Полным полно людей умеющих готовить WS. Да и библиотек хватает (socket io, atmosphere, ...). Просто не нужно оно в 95+% случаев. Это один из множества инструментов, который вы приняли за серебряную пулю
.это хорошая новость., что есть люди, умеющие их готовить, но для меня это не серебрянная пуля, просто это универсальная технология позволяющая полностью заменить ajax, и отказаться от множества поддерживаемых технологий.
Для меня это элементарный механизм, как и хранимки, поэтому я считаю это одним из простейший кирпичиков для построения систем.faiwer
13.11.2018 12:32это всё теже перепевы innerHTML, и конечно я их использую в тех местах где нужно, innerHTML я привел как самый элементарный, показательный вариант.
Вы их используете. А мы нет. В этом суть. Мы не орудуем каменным зубилом. Им орудуют используемые нами инструменты. Это сложно объяснить в двух словах.
P.S. Ну и есть огромная разница между
innerHTML=и производительной работой с DOM.
VolCh
13.11.2018 17:02+2это всё теже перепевы innerHTML,
Это не перепевы, это прямой способ формировать DOM. А innerHTML — это способ запустить парсер, который распарсит строку и сделает из неё DOM. Концептуально ничем не отличается от json, разве что парсер куда-то проще.
eugene_bb
13.11.2018 19:09+2innerHTML это прямой путь чтобы получить XSS, не думаю что кто либо в библиотеках это использует
f0rk
14.11.2018 07:10+3> innerHTML это прямой путь чтобы получить XSS
Особенно учитывая то, что шаблонизаторы BigDflz тоже не использует и рендерит html конкатенацией :) Ну тут сильно запущенный случай, я не думаю что есть смысл что-то объяснять.BigDflz
14.11.2018 07:47-3не думаю что кто либо в библиотеках это использует
если не думаешь, не стоит об эом писать. 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(или ей подобные)faiwer
14.11.2018 08:35+3Ваши ангуляры и прочие фантики ничего другого не делают.
Вы несёте полнейшую чепуху, и похоже не имеете ни малейшего представления о том, как работают все эти "фантики". Ей богу, ну прекратите. Это ж даже не смешно. На дворе 2018г.
BigDflz
14.11.2018 08:42перечисли что может ангуляр, и не может js?
faiwer
14.11.2018 08:50-1перечисли что может ангуляр, и не может js?
Я с вами на "ты"? С каких пор?
Вопрос в высшей степени нелепый. Angular это JS фреймворк. Он на нём написан. Вопрос просто не имеет смысла.
Комментарий выше был про то, что все эти фантики работают на стороне клиента и никаких строчек в HTML не склеивают. На стороне JS нет необходимости формировать HTML из строк. Работа происходит на уровне объектов.
Серверный же рендеринг этих фантиков — явление достаточно редкое. Там тоже работа внутри "фантиков" происходит с объектами, а не строками. Строка собирается уже из объектов на самой самой финальной стадии. И это всё скрыто от разработчика в недрах библиотек.
faiwer
14.11.2018 08:45+3А так называемый рендеринг html (серверный рендеринг) ни что иное, как формирование html строки путем конкатенация строк, содержащих тэги html и пользовательских данных.
В конечном счёте, если речь идёт именно о серверном рендеринге (который зачастую отсутствует как класс), то да, сборка итогового HTML это сборка строки, которая отправляется клиенту назад по HTTP.
Однако, имеет существенное значение, как эта строка была сформирована. Если вы эти, пардон, руками формируете, склеивая строки в вашем коде явным образом… пример:
<div class="<?= htmlspecialchars($type.$some) ?>"><?= $title ?></div>
, то это привет каменный век. Мезозой. Если же у вас там какой-нибудь шаблонизатор, то вы ни строчки конкатенации сами не пишете. Вы используете дополнительный готовый уровень абстракции, который значительно упрощает работу, уменьшает количество багов, повышает уровень безопасности (большая часть XSS отпадает, как класс).
Шаблонизаторы внутри себя эти самые строчки и склеивают, да.
Правда я ещё раз сделаю акцент на том, что раз уж мы говорим про AJAX, WS и прочее, то у нас, как правило, почти всегда, нет никакого серверного рендеринга. Совсем. Вот прямо ни строки. Сервер передаёт нам только данные. А с
HTMLDOM работает уже клиент (JS). И клиент никаких строчек не склеивает, т.к. незачем. У нас ведь есть DOM и полноценное API к нему. И даже этими методами мы не пользуемся почти, т.к. это делает дополнительная прослойка — фреймворк.VolCh
14.11.2018 16:07Более того, может отсутствовать классический шаблонизатор типа PHP :), а на стороне сервера собираться поэлементно полноценный DOM (или virtual DOM), который рендерится в "outer/innerHtml"
faiwer
14.11.2018 16:26+2Оказалось, что наш друг вовсе не 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).
Nookie-Grey
15.11.2018 18:23BigDflz очень интересный уникум, он и в моей статье пытался доказать, что вся отрасль front-end глупцы, используют лишнюю абстракцию json и что нужно гонять html через ws
BigDflz
15.11.2018 18:43Да, получается что я уникум, да, я гоняю всё через ws. Это всё намного проще и производительнее, чем гонять через ajax. в начале появления ws, я наслышался такого про эту технологию… а теперь оказывается что все wf её используют. А насчет гоняния html через ws, могу сказать, что вы просто имеете поверхностные знания о работе ваши wf, которые по тихому вставляют собранную на сервере html строку в поле того же json. И называют это красиво — серверный рендеринг
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
VolCh
14.11.2018 16:02+2Чем для вас отличается конкатенация строк, их сложение и шаблонизация? простой сишный printf("Hello %s", name); для вас что?
cyberly
13.11.2018 13:31… позволяет снизить нагрузку на сервер ...
Как раз генерация HTML на клиенте очень-очень здорово позволяет ее снизить. Генерация HTML вообще может быть самой дорогой операцией в приложении. А если притянуть сюда, скажем, генерацию изображений, то еще и основным потребителем сети. Ну например, масштабирование/обрезка изображения перед загрузкой на сервер. Или построения графика по табличке с данными. Arduino застрелится такое сделать. И «нормальный» сервер застрелится при определенном (не очень большом) числе пользователей.
И вы почему-то смешали отчуждение уровня отрисовки (что делается, в том числе, c помощью AJAX/json) и решение проблемы большого числа запросов к серверу (websockets).
pawlo16
13.11.2018 13:33+1Ajax заменяется веб-сокетом? Серьезно??
элементарно на все 146%, без всяких проблем, что и делаю с момента появления websocket, без использования ajax.
Похоже на одурманенность хайпом, уж не знаю каким. Вебсокет или шмебсмокет, json или неджсон — какая половая разница, если это всего лишь транспортный протокол и текстовый формат? Когда инструмент становится фетишем — смешно же. в идеале ни фронт- ни бэк- программист вообще не должен думать о транспорте и сериализации, а должен думать о задачах бизнеса. Из ваши комментариев видно, что вы понятия не имеете об rpc фреймворках Thrift и grpc — а зря. В серьёзных проектах либо они, либо им подобные решения, которые выбирает тех.лид, затем вся команда использует явочным порядком. А вы тут втираете сказки про websocket vs ajax, тот ещё bubble effect.
Вебсокет между прочим в большинстве задач гораздо хуже ajax хотя бы уже тем, что он сложнее. А где именно и что рендерить — html на сервере или dom в браузере — это совсем уже зависит от задачи, и тут ещё более смешно кому то навязывать что-то в качестве универсального решения.
BigDflz
13.11.2018 09:11Наверное именно поэтому в GraphQL спецификации есть И Ajax И websocket?
Просто для любителей старины и для совместимости со старыми наработками.faiwer
13.11.2018 11:18+1У вас очень специфическое представление как о частностях (Ajax, WebSocket, data-flow), так и в целом об front- & backend разработке.
BigDflz
13.11.2018 11:41-1может просто это Ваше мнение? У меня большой опыт (с начала появления ) websocket, я наслышался о не нужности и пагубности ws, но время показывает, что все переходят на них. И нет ни одного аргумента, чтоб перейти на ajax и его производные велосипеды. Одно то, что это фулдуплекс, говорит о многом. Я могу из любого места серверного кода отправить данные нужному клиенту. это просто. Приведи пример что может ajax и неможет ws, обратного же куча.
И да использование ws меняет подход к веб проектам, тем кто привык к ajax это кажется не привычным, не правильным. Но это раскрывает огромные перспективы если понять и научиться работать с ws. У меня есть свои наработки, свои решения, которые позволяют использовать ws широко, просто, удобно.faiwer
13.11.2018 12:08Кажется у вас просто большой опыт с websocket, но очень специфический опыт с web в целом. Использовать webSocket вместо AJAX для большинства проектов, это как стрелять из пушки по воробьям. Воробья подстрелить можно, но зачем? Рекомендую вам ещё serviceWorkers тогда подключить, очень гармонично впишется ;) А ещё можно всё перевести на webAssembly. И не забыть сделать offlne-версию всех своих продуктов.
У меня тоже есть опыт с WS. Но мне бы и в голову не пришло тащить его в те проекты, где нет нужны в persistance connection.
BigDflz
13.11.2018 12:19Использовать webSocket вместо AJAX для большинства проектов, это как стрелять из пушки по воробьям
это заблуждение, на самом деле это намного проще чем ajax.
Рекомендую вам ещё serviceWorkers тогда подключить, очень гармонично впишется ;) А ещё можно всё перевести на webAssembly.
я к этому стремлюсь. Если есть опыт — прошу поделиться.
У меня тоже есть опыт с WS. Но мне бы и в голову не пришло тащить его в те проекты, где нет нужны в persistance connection.
могу согласиться, но у меня корпоративные порталы, где persistance connection как основа. С другой стороны если есть проверенные наработки с ws, почему не заменить ими ajax? и клиентская сторона и серверная получаются простыми, ни чуть не сложнее чем с ajax.faiwer
13.11.2018 12:23Я не буду вас переубеждать. Скажу проще вы очень сильно заблудились в своём познании web-а. Вероятно вы на 99%+ самоучка. Вам стоило бы рассмотреть возможность очной работы в крупной продуктовой компании, в команде более опытных коллег.
Whuthering
13.11.2018 13:01+1Скажу проще вы очень сильно заблудились в своём познании web-а. Вероятно вы на 99%+ самоучка.
Такое же впечатление, да. «Синдром самозванца» наоборот :)
indestructable
13.11.2018 15:45+4Хм, а вебсокеты умеют в request-response flow? Понятно, что эмулировать можно, но по дефолту?
А перестраивать всю архитектуру под двунаправленные серверные потоки данных — это намного сложнее, чем AJAX.
mayorovp
15.11.2018 12:22И главное — придется забыть про хранимки в СУБД, ибо они не умеют в нормальные двунаправленные потоки данных :-)
HerrDirektor
12.11.2018 18:19+5А мне нравится фуллстек. Да, я точно так же осознаю, что нельзя «объять необъятное», но меня это никак не смущает. Ровно как и «не помню про IDisposable без гугла» (кстати, не помню, ага). Я вообще много времени провожу в гугле при разработке чего-либо. Мне нравится учиться. Нравится смотреть, как программируют другие, нравится думать и сравнивать, почему вот этот подход лучше вот этого.
Никогда не считал зазорным спросить совета у более опытного разработчика в текущей технологии, не испытываю по этому поводу никаких комплексов.
Я тащусь от того, что в общем-то не ограничен языком или платформой. Ннннада .NET? Не вопрос (asp, xamarin, wpf). Запилить бэкенд на PHP? Легко. CSS к сайтику? И это тоже! Что здесь? Си и Linux? Давайте сюда, сделаем. Что это? Делфи? Воу, какой раритет! Ну ОК, давай в Делфи.
И так далее и тому подобное.
Да, я совершенно точно уступаю синьору в любой из этих платформ, в некоторых областях даже с натяжкой могу назвать себя «миддл» (а скорее «продвинутый джун»), но черт возьми… Это настолько удобно и комфортно, что даже не знаю с чем сравнить!
Можно в одиночку ненапряжно тащить некрупные проекты, не завися от других людей (и получать все деньги тоже в одного, что весьма приятно).
BigDflz
12.11.2018 18:49могу только отказаться от второго абзаца, просто не было необходимости, а остальное как с меня писано :)
akryukov
12.11.2018 21:16Ннннада .NET? Не вопрос (asp, xamarin, wpf). Запилить бэкенд на PHP? Легко. CSS к сайтику? И это тоже! Что здесь? Си и Linux? Давайте сюда, сделаем. Что это? Делфи? Воу, какой раритет! Ну ОК, давай в Делфи.
Что у вас за место работы, если приходится вот так вот скакать по технологиям? Или вы фрилансер?
HerrDirektor
13.11.2018 05:31Не совсем фрилансер. Просто за 20+ лет кодинга за деньги я наработал весьма солидную базу клиентов и (самое главное) — некий авторитет («широко известен в узких кругах»), благодаря которому не мне нужно искать клиентов на свои поделки, а наоборот, всегда стоит очередь на мои услуги. Уже закрытые и сданные как правило ничего не требуют, но есть десятка полтора, которые время от времени обновляются («на обслуживании»). За деньги конечно.
Кому-то нужен крайне специфический внутренний продукт (например, ПО для расчетов ТТХ изготавливаемой арматуры в мобильничек или «микро-CAD» для расчетов прочностных характеристик всяких специфичных железяк (на этом проекте я не осилил матан, поэтому понадобилась помощь зала, хех)). Здесь обычно рулит дотнет.
Кому-то нужен специфичный сайтик (не визитка, не интернет-магазин, и не шаблон WP/Drupal/итп, такое я не беру, неинтересно). Здесь как правило PHP/JS/CSS/HTML. Если нужен специфичный дизайн, то я привлекаю стороннего покемона (с художественным развитием у меня не очень).
Иногда приходится делать продукт для интранета (с подъемом серверов, блэкджеком и прочим).
И в чужих древних разработках (пресловутые Делфи/VB/CBuilder лохматых годов) приходится покопаться — ПО написано 20 лет назад, поддержки уже давно нет, а поменять что-то нужно (чаще прикрутить что-то к чужому коду быстрее и дешевле, чем переписать заново, проекты попадаются далеко не уровня «hello, world»).
Linux — это больше хобби, но случалось несколько раз писать за деньги и под него.
Почему я, а не «команда проф. разработчиков»? Потому что малый и средний бизнес как правило не понимает 90% того, что лидеры/«эффективные менеджеры» этих команд им говорят, и (главное) не тянут по финансам.
Скажем, переговоры по «микро-CADу» с разными командами заняли в итоге 4 месяца(!) и цены на готовый продукт начинались от 5 млн (в рублях разумеется), со временем разработки в 4-6 месяцев.
Я не особо напрягаясь сделал чуть больше, чем за квартал и за миллион. При этом вечерами ведя пару мелких проектов.
Не потому, что я круче упомянутых команд, а потому, что я мог по 2-3 дня подряд ничего не писать, а ходить хвостом за инженерами, для которых этот продукт делался.
Узнавать, что им нужно, помимо унылого ТЗ, как будет удобно, как вообще это работает с их точки зрения.
В результате, как минимум треть ТЗ ушла в помойку, а процесс разработки ускорился невероятно из-за того, что отпала необходимость реализовывать ненужные фичи, которые «вроде как нужны», но на самом деле никто их никогда бы и не использовал.
В общем, такой подход к разработке — это еще один очень важный скилл в жизни fullstack :)Quilin
13.11.2018 17:55+2Ну я бы сказал, что это уже не фуллстек-девелопер, а скорее фуллстек-вообще. Здорово, когда человек никому ничего не доказывает, а просто делает работу и понимает, для кого он ее делает. Респект вам.
В среднем по больнице, к сожалению, как и любые титулы, этот скорее связан с фаллометрией и используется далеко не во благо.
Nookie-Grey
15.11.2018 18:32Напишите публикацию, хочу поднять вам карму (а без публикаций +4 это максимум)
HerrDirektor
15.11.2018 19:34Публикацию «Почему быть фуллстеком клево»? :)
Если народу будет интересно, почему бы и нет? :)
boblenin
12.11.2018 23:44+1Вот такой подход — идеальный для найма.
Во-первых если сотрудника есть представление о разных технологиях, то по крайней мере есть возможность выбрать ту, что подходит лучше, а не лепить в очередной раз на том что умеет, но оно точно не работает. Если бизнесу нужен совет о технологии — то разработчик может его дать.
Во-вторых если может в одиночку тянуть некрупный проект — то значит не надо тратиться на лишних менеджеров, а значит на целую кучу организационных активностей (собрания о собраниях и о том как их правильно проводить). Кроме того если проект ведется одним разработчиком (лучше все-таки двумя для High Availability), то не требуется даже формальный SDLC, разве что некоторое количество инструментов.
В целом не знаю как там насчет синьора, но эти навыки по крайней мере по моей субъективной шкале стоят выше чем доскональное знание всех стандартных хранимых процедур того же Sql Server. Приоритет — это сделать софтину, а не родить инженерный шедевр.HanryCase
13.11.2018 13:53Согласен. Если ты занимаешься беком, то и в фронте должен хоть немного, но соображать и наоборот. Хороший инженер должен хоть немного но разбираться в смежных технологиях.
Я не встречал спецов которые знают только Java.Обычно спец идет под стек, кругозор и умение мыслить нужными категориями — определяют.
Страшно представить сферического Java кодера который 10 лет занимается только чистой Java и Spring_ом не зная ничего о фронте.boblenin
13.11.2018 17:27+2Увы, такое не редкость. Доводилось работать с людьми 15 лет занимающимися postgresql и ничем больше (не потрудившимися даже выяснить, что существуют системы контроля версий), с теми кто 10 лет пишет одно приложение на ASP.NET и не замчает то, что мир несколько изменился за это время. Недавно с проекта у нас ушел человек, толковый но вбивший себе в голову, что хочет работать только с CRM Dynamics, не хотел смотреть ни в сторону SalesForce ни в сторону разработки ни devops.
HerrDirektor
13.11.2018 19:26+3Приоритет — это сделать софтину, а не родить инженерный шедевр.
Именно так.
Кстати, когда я начинал свой путь (это когда за деньги), то разумеется смотрел, как это делают другие корифеи.
Поначалу меня всегда удивляло, что узкоспециализированное ПО (для одного человека или небольшой группы/команды) имеет «убогий дизайн».
Ну реально, вместо лаконичного и «уже вроде как привычного» от билгейца — какое-то малопонятное со стороны нагромождение UI-элементов, хоткеев и вообще, без бутылки не разберешься (под DOS вообще были шедевры почище vi).
Однако, после нескольких попыток нести в массы «правильный» интерфейс, начало приходить понимание, что это все явно неспроста, а заточено именно под упомянутого пользователя или группу.
Первым проектом после осознания факта, что узкоспециализированное ПО должно быть в первую очередь функциональным и удобным, а только потом «красивым», была система учета/управления библиотекой (заведение с бумажными книгами) под винду (год 98й однако был).
После изменения «красивенько» на «удобненько», приложение приобрело несколько страшноватый вид, но скорость работы трех девчонок повысилось где-то в 5 раз.
Т.е. UI было сделано так, как им было удобно. Хоткеи такие, какие им были удобны. Каждое движение, каждое нажатие было максимально функциональным — от автодобавления строк, до сортировок и сохранения.
Скажем, ну кто бы мог подумать, что девчонкам удобно нажать Ctrl+T n раз (режимы сортировок) и чтобы она (сортировка) не менялась в основном окне, а всплывало поверх формы, не загораживая основной список и висело там до тех пор, пока хоткей зажат?
Да в жизни бы до такого не догадался, а девкам, подсказавшим, как им было бы удобно ну очень нравилось — кинули взгляд, ага, здесь то, а здесь то; отпустили хоткей и дальше работать. На все про все уходило в пределах 1-2с, когда при «обычной» сортировке (когда все в одном списке) приходилось листать по 10 (а то и 30с), да еще запоминать большие объемы данных, т.к. перед глазами не было предыдущих данных.
И таких нюансов при плотном контакте с будущими пользователями — вагон и две тележки сверху.
ИМХО, только такой подход реализует тезис «вам шашечки или ехать» :)Estee
14.11.2018 17:53До такого действительно невозможно додуматься самостоятельно. А как сами девочки к такому решению пришли? Из какого-то старого ПО приползло?
HerrDirektor
14.11.2018 18:57Нет, это сугубо их идея. Простая как три рубля, внезапная, как понос :)
Что-то вроде того:
…
— Слух, а можно сразу две сортировки делать?
— Это как и зачем?
— Ну я вот тут смотрю, а когда переключаю, нифига не понимаю, что и откуда. Как-нить можно сразу и такую и такую?
— [сразу начинаешь думать, как перекроить UI, чтобы еще что-то влезало, на 14" с 1024х768 особо не разбежишься, а один из трех мониторов вообще в 800х600 только умеет] Ээээ… Нууу… А куда ее вставить-то тут, без того экран занят?!
— Да не надо вставлять, пусть тут [тык в экран пальцем] квадрат вылазит с ней, пока держу клавиши и все.
— Бинго!
…
Ровно как и перенести режимы сортировок на одну клавишу (слепым методом печати они не владели, т.е. куча хоткеев для одного и того же было для них не очень удобным решением).
А в таком виде (Ctrl+T) — клац = одна сортировка, клац-клац = другая, клац-клац-клац = третья…
А уж сколько денег было поднято на простецкой проге для сдачи данных/отчетов в налоговую до прихода в массы «1С Налогоплательщик» (да и после тоже, т.к. скорость внесения данных в мою поделку была без преувеличения на пару порядков выше)…
И все это благодаря тому, что кривенький и косонький UI был на самом деле выверен до последнего тыка в клавиатуру, все заточено под максимальную скорость ввода.
Закончилась лафа с этим ПО только после внедрения на предприятия и частникам всевозможных «Бухгалтерий», «Кадров», где эти отчеты формировались на автомате.
vsapronov
12.11.2018 18:26Все смешалось в доме Облонских: стеки, языки программирования, доменные области. Не понятно на счет чего именно из этого вы пишите.
Во взять, например, только языки.
Есть, условно говоря, три класса языков: нативные (c и c++) — очень близко к профессору, высокоуровневые ОО (java, c#, scala, kotlin), высокоуровневые функциональные (f#, haskel). Можно еще, скажем выделить высокоуровневые небезопасные (python, javascript).
Внутри класса языки очень легко менять. Основное время должно уходить не на чтение спеки, а на познавание тулов окружающих язык (они то точно сильно разные). Но это все при условии, что вы пробовали писать на этом языке уже когда-то. Переключение между языками из разных парадигм больно и дорого. Мозгу нужно выстроить синоптические дорожки...
Вообще работать одновременно на разных языках — это очень интересно. Это расширяет кругозор невероятно. Никогда не интересовались, как получилось, что Java стала таким говном? А мне это очевидно (как и то, что Java — говно, как язык) — программисты, создатели языка и пользователи, не смотрели по сторонам и не увидели что происходит в C#, когда они поняли что надо пилить фичи, то уже было слишком поздно — народ разошёлся по Scala'ам, Kotlin'ам и Clojure'ам.
И много такого. Обладая таким опытом можно предсказать куда идет развитие. Тот, что в Scala и C# появится enforced null safety, тем кто пробовал на F# было понятно очень давно. В C# уже объявили и в Scala тоже будет.springimport
12.11.2018 18:57А что вы думаете на счет php и php 7.2?
vsapronov
12.11.2018 20:05На сколько знаю он ОО, точно высокоуровневый — нет управления памятью. Как там с контролем типов во время компиляции? Раньше не было и это делало его небезопасным языком — без отрицательной коннотации, просто надо другие практики использовать — тотальное покрытие тестами… А как в современном PHP даже и не знаю.
VolCh
12.11.2018 22:28Контроля типов практически не было кроме ручного, сейчас есть времени исполнения на уровне сигнатур функций/методов, обещают завезти на уровне свойств.
vsapronov
13.11.2018 06:19Ну как бы тогда небезопасный. Нужно тотальное модульное тестирование. Это не хорошо и не плохо, но требует от мозга изменения подхода скорее всего на test first, потому как иначе не выжить. Поэтому переключения скажем C# <-> PHP не будут гладкими. В C# мы доверяемся компилятору и забиваем тестировать автоматизированными модульными тестами очень часто, зато больше тратим времени на проектирование системы типов в явном или неявном виде.
Druu
13.11.2018 10:39-1Ну как бы тогда небезопасный. Нужно тотальное модульное тестирование. Это не хорошо и не плохо, но требует от мозга изменения подхода скорее всего на test first, потому как иначе не выжить.
Замена типизации тестами — самое глупое решение, которое вообще можно себе представить. Лучше на динамике вообще не писать в таких случаях.
VolCh
13.11.2018 11:11+1Всё зависит от требований. Я предпочитаю тестировать логику, а не что будет, если в метод передадут целое вместо строки.
vsapronov
13.11.2018 17:25Да, в принципе, я тоже больше использую функциональные модульные тесты, чем просто формальные модульные.
Но тем не менее, без статической типизации надо покрывать тестами намного больше, чтобы код был поддерживаемым, иначе вносить изменения очень дорого.Fesor
13.11.2018 20:41+2функциональные модульные тесты, чем просто формальные модульные.
ммм… не поделитесь определением? Что есть что?
i0000
12.11.2018 19:23-3Все смешалось в доме Облонских: стеки, языки программирования, доменные области. Не понятно на счет чего именно из этого вы пишите.
Вот только одно не смешалось — неизменно неправильное написание программистами слова «пишИте».
maxzh83
12.11.2018 20:10народ разошёлся по Scala'ам, Kotlin'ам и Clojure'ам
Никто никуда не разошелся, основная масса как сидела на Java, так и сидит. Посмотрите на вакансии, все станет понятно. Из перечисленного только Котлин пока имеет перспективу и держится на хайпе. И тут тоже в основном из-за Андроида, где до недавнего времени была Java 6. Пик интереса к Scala уже прошел и по сути осталась только одна область (big data), где Scala — почти стандарт. Надеюсь, что с выходом версии 3, интерес к ней снова появится. Ну, а на clojure как сидели энтузиасты, которых немного, так и сидят.
К слову, пример со Scala очень показательный. Язык очень интересный сам по себе (в вашей терминологии «не говно»), но, в то же время, его очень сложно использовать в большом проекте. Во-первых, на нем одно и то же можно написать сильно по разному (в стиле Java+ и в стиле Haskel с линзами и монадами), во-вторых, создатели языка периодически кладут прибор на обратную совместимость и все ломают. Вот и получается, что когда в проекте более десятка разработчиков, то выбирают старую многословную и тупую Java.vsapronov
12.11.2018 20:34-6Посмотреть вакансии где?
Я смотрю на вакансии регулярно. Более того, ровно год назад я менял работу и получил 4 оффера в New York City. На Java пишут бэкенды только убогие дебильные подобные индо боди шопам банки. И даже из них далеко не все. Все нормальные конторы уже какое-то время назад ушли на Scala. А все нормальные девелоперы ушли в которые, где можно писать на нормальных языках. Ни один из известных мне хороших программистов не пишет на Java. А я поработал тут и в банках и не в банках.
Не поймите меня неправильно — я хорошо вижу косяки в Scala. И, честно говоря, думаю что они не будут пофикшены. Так что ждем нового языка. Ну или Kotlin прямо станет очень крут. Это только касаясь JVM. Не говоря о других.
mkshma
12.11.2018 21:25Зайдите на Glassdoor, вбейте Java в NYC. Увидите около 8800 вакансий. Вбейте Scala. Увидите примерно 1400, из которых в 2/3 случаев Scala упоминается в контексте «будет конкурентным преимуществом, но не более». У вас рассинхрон с реальностью.
vsapronov
12.11.2018 21:45+1У меня рассинхрон только с вашей метрикой: кол-во вакансий на Glassdoor. Не средняя з.п., не перспективность компании умноженная на кол-во предложенных стоков. Нет — это все фигня, нам нужно больше вакансий. На Glassdoor — не на LinkedIn — LinkedIn тоже фигня, тем более в России запрещен.
Рассинхрон с реальностью говорите, ну ну…mkshma
12.11.2018 22:26LinkedIn — онда большая спам-помойка. Не знаю кто там в здравом уме ищет работу.
vsapronov
12.11.2018 22:30+2У меня было 4 оффера в декабре 2017 по результатам примерно 20 начатых собеседован й. Все через LinkedIn. Могу показать список компаний. Единственное, что я платил за premium аккаунт, пока искал работу.
irsick
13.11.2018 03:19Вероятно, вы не с теми общались. Помимо хантеров часто пишут HR'ры самих компаний. Ну иногда даже получается обойти бюрократическое болото и связаться напрямую с тимлидами и CTO.
Milein
12.11.2018 22:14Если в вашем сообщении заменить «писать на Java» на «пользоваться Windows», то из первого обзаца получится классический вендекапец.
Не знаю откуда у вас такая ненависть к Java (под дулом пистолета писать на ней заставляли что ли?), но пророчить ей смерть пока преждевременно рано.
И да, на LinkedIn джавистов тоже ищут. А что-то там перемножать на стоки я не хочу, вам это нужно, вы и доказывайте что джава мертва.vsapronov
12.11.2018 22:27+1Я не доказываю, что она мертва. Где я такое говорил?
Я говорю язык Java — говно.
Существует много вещей которые говно, но они при этом живее всех живых. Чувствуете как вы манипулируете и подменяете понятия?
Даже если углубиться в разговор о том, что Джава жива, то первое что я слышу это не про хороший дизайн языка а вполне такой рыночный аргумент — вакансии. Даже этот аргумент не могут нормально приготовить:
— Вакансии! — Что вакансии? — 8800. — Что 8800? — Java жив, Java будет жить!
Дискуссия на уровне анекдота про Петьку. Если мы говорим про рынок, то приведем и другие метрики, более важные, чем кол-во требуемых визовых рабов в одном конкретном городе.
Опять же ^ это все оффтоп. Это никак не влияет на тот факт, что дизайн языка — серьезно устарел и в общем-то говно в 2018.Milein
12.11.2018 22:42+1Вы написали «посмотреть вакансии где» — вам написали конкретные цифры, где эти самые вакансии есть и их дофига и больше.
А вот вы ж тоже нифига не доказываете. «Все ушли на Scala».
Где цифры, где метрики о которых вы говорите? Где те самые оценки перспективности компаний и стоков? Шума много, фактов ноль, а цифры которые приводят оппоненты в споре это анекдот теперь.
Пока что анекдот это россказни о том что все с Java куда-то ушли.
vsapronov
12.11.2018 22:44Я не думаю, что вот прямо должен доказывать что-то.
Хорошо, не ушли — все прекрасно.
Еще раз, дизайн языка Java — говно.Milein
12.11.2018 23:03+1А я не зря сравнил с вендекапцом. Один и тот же детский сад.
-JavaВинда говно! Все с неё уходят! Только тупымбодишопамдомохозяйкам она нужна! Все нормальные люди уже ушли!
-Пруфы, Билли! Пруфы в студии!
-Да ничего я не буду показывать! НоJavaвинда всё равно говно!vsapronov
12.11.2018 23:51Еще раз, вы смешиваете понятия «смерти» и «говна». Я не говорю, что умерла, я говорю, что говно. То, что люди уходят на Scala и на Kotlin — это и ежу понятно, но если вдруг вы — не ёж, то компании Twitter, Amazon, Google (Android) отказываются (или уже отказались) от Java. Все эти программисты перешли с Java на другие jvm языки. Даже эти 3 компании — это очень много.
А вот то, что дизайн языка — говно не хотите обсудить? Будет много пруфоф, с фактами, метриками как Java добавляет фичи на 10 лет позднее, чем их просили и добавили в другие языки.anprs
13.11.2018 11:59Как человек только переходящий от нативного к высокоуровневым — реквестирую подробный ответ почему говно
pawlo16
13.11.2018 21:41Вот только Google и Amazon перешли не на «другие jvm языки», а на Go. Потому что, внезапно, сервисы, написанные на Go, обходятся в 10 раз дешевле аналогичных сервисов на Java-подобных языках
zagayevskiy
13.11.2018 14:20+2Вы пробовали на котлине писать? После него возвращаться на джаву очень больно, и то, что дизайн — говно становится чуть более очевидным.
maxzh83
12.11.2018 22:48+2Я не доказываю, что она мертва. Где я такое говорил?
Хм, смотрите
когда они поняли что надо пилить фичи, то уже было слишком поздно — народ разошёлся по Scala'ам, Kotlin'ам и Clojure'ам.
Делаем нехитрые умозаключения. Народ разошелся по котлинам, значит на Java никого не осталось.Если круглое и оранжевое, то апельсин.Если на Java никого не осталось, то язык — мертвый, не?vsapronov
12.11.2018 23:16-1Ну давайте чуть поясню, чтобы у вас не возникало умозаключений.
Народ — не в смысле вся нация или население все страны. Ведь вся нация не умеет программировать.
Народ — не в смысле все программисты вообще, ведь не все из них в принципе пишут для jvm.
Народ в смысле — программисты с которыми я знаком и поддерживаю отношения. И я наблюдаю, что ни один сеньерный из них не остался на Java. И я думаю, что серьезные контрибьюторы сбежали также как и мое окружение и дерьмовость языка+отсутствие развития — главная причина.
Вот даже такой пример могу привести — на чем пишет свои сервера Twitter? Они не только сами сервера пишут на Scala, но также сделали платформу для создания серверов для всеобщей пользы. Это значит, что Java сообщество потеряло не только всех программистов Twitter, но и серьезных контрибьюторов, которые могут сами запилить http framework. И таких примеров много: Android еще одна экосистема с целой армией сбежавших программистов среди которых безусловно есть крутаны, но увы — контрибьютить они будут не в Java.maxzh83
12.11.2018 23:33-1Народ в смысле — программисты с которыми я знаком и поддерживаю отношения.
Ясно, так себе статистика.
на чем пишет свои сервера Twitter?
Напишите название или ссылочку, интересно. Все из того, что видел, как правило, является оберткой поверх netty, который, о боже, написан на богомерзкой Java.vsapronov
12.11.2018 23:38Статистика лучше, чем 8800 на Glassdoor.
Первый и последний раз работаю для вас гуглом: github.com/twitter/finatramaxzh83
13.11.2018 00:00За ссылку спасибо, думал там что-то серьезное. На деле очередная поделка с хреновой документацией и без коммьюнити, которая интересна только твиттеру и то непонятно в каком объеме. Не законтрибьютил твиттер на Java, ну ничего-ничего.
vsapronov
13.11.2018 01:26Я читаю документацию. У вас все нормально с гуглом?
Я не работаю на Twitter. Finatra очень популярен вне Twitter'а.
Не до конца понимаю ваш посыл: все, кто работаю в Twitter'а — не программисты? Или очень плохие? Что ж вы тогда про Android разрабов думаете?maxzh83
13.11.2018 10:13Не до конца понимаю ваш посыл: все, кто работаю в Twitter'а — не программисты? Или очень плохие?
Вы его вообще не поняли. Посыл такой. В твиттере как и в других больших компаниях есть зоопарк технологий. Кроме этого, есть проекты, которые пилятся под свои нужды по разным причинам. Грубо говоря, нужна админка для чего-то, в которую будут ходить десяток человек в день. Людям дали свободу, люди запилили фреймворк на коленках и выложили в github. При этом тут же на этом фреймворке появляется штамп «ого, он используется в Твиттер», как именно обычно не уточняется. Дальше этот проект может быть и правда успешным и уйти в массы, а может так и остаться проектом под конкретные нужды. Посмотрите на Google, они открывают и хоронят проекты постоянно.
fcoder
13.11.2018 18:05+2Ну давай сравним твиттер с 3000 сотрудников и, например, дойче банк, со 100000. Не все они, конечно разработчики, но де-факто весь финансовый сектор использует джаву и усиленно в неё вкладывается. Три миллиарда устройств опять же, не могут ошибаться. Да и большая часть техноэнтерпрайзов вроде IBM со слоганом «ни один менеджер не был уволен за выбор Java» — тоже.
Поэтому, с точки зрения количественного сравнения — по вакансиям, по количеству денег в индустрии, скала-стартапы выглядят не просто маргинальными нищебродами по сравнению с джава-миром, а находятся где-то на границе погрешности измерений.
Теперь поговорим за качество. Ну и зачем мне технология, где минорный апдейт случается раз в три года и при этом ломает обратную совместимость? Тулов по сравнения с джавой… обнять и плакать. Зачем искать редких сложно-заменяемых специалистов с зарплатой на 30% выше рынка, если за эти же деньги можно нанять 3 легко заменяемых аутсорсера из индии/восточной европы, которые (под присмотром тимлида/архитектора) будут перформить как минимум не хуже? А код при этом будет написан со всем известными со школьной скамьи паттернами, в которых элементарно разобраться, вместо этой скала-зауми с ФП и с кастомными операторами «ЖОПА», для которых нужно phd, чтобы разобраться.
Таким образом, с точки зрения бизнеса, выражаясь вашими же словами, скала выходит очень дерьмовая технология и больше годна для почёсывания своего ЧСВ, нежели для достижения бизнес-целей.
JuniorIL
13.11.2018 11:21+1
Скала хороша только если жить где-то в Тель Авиве, Нидерландах или Берлине, где реально есть выбор работы на Скале. 3 года писал на Скале, захотел работать по удаленке и уехать из богатого на хайтек района — пришлось вернуться на Джаву. А теперь как ответственный за проект я тоже буду бояться выбрать Скалу; я то на ней быстро напишу, а вот людей в команду не найду.
tuxi
12.11.2018 20:30"Java сидит на берегу реки и с философским прищуром смотрит как мимо проплывают трупы всяких #"
vsapronov
12.11.2018 20:41+2Ну да, ну да. Главное никогда не признавать ошибок. Продолжаем упорно говорить, что "interface methods вот прямо ноу хау, вот прямо на острие дизайна яп, ни один язык такого не делал раньше".
Ждем null safety в течении следующих 40 лет.
Ну а всякие там records и pattern matching — это внукам, надо еще чтобы наука это придумала.tuxi
12.11.2018 21:21+1«Счет на табло» тем не менее. А хоронить java начали давно между прочим. А она сидит и смотрит как проплывают мимо… :) Потому что Java — это удачный баланс для энтерпрайза (да и не только для него) между строгостью и фривольностью.
vsapronov
12.11.2018 21:48+3Мой счет у меня в банке. Программирую на Scala, C# и F#. На Java не пишу более двух лет.
А вы про какое табло?maxzh83
12.11.2018 22:36Программирую на Scala, C# и F#. На Java не пишу более двух лет.
После этого люди в круге начали аплодировать. А если серьезно, то и что? Я не пишу на C# уже лет 7-8 и ни разу не пожалел, но это тоже ничего не доказывает.
когда они поняли что надо пилить фичи, то уже было слишком поздно.
MS с .net долгое время игнорировало Linux и нормальную кроссплаформенность, преследуя корпоративные интересы, пока носом не уперлась в тот факт, что большинство серверов, увы, не на винде. Сейчас делаются очень правильные шаги, но много времени упущено.
Главное никогда не признавать ошибок.
Язык это же не только синтаксис, а еще инфраструктура, коммьюнити, инструменты и т.д.vsapronov
12.11.2018 22:42Ни с чем не спорю из того, что вы сказали. Все правильно.
Я вообще ни разу не за МС. Они вообще знатные умельцы профукать все и еще и другим жизнь испортить.
Так вот я и говорю: хорошие программисты не хотят писать на Java — они увидели, что можно в Scala и в Kotlin и всё — они потеряны для Java. И все коммьюнити не может ничего без основных контрибьюторов.tuxi
12.11.2018 22:55Так вот я и говорю: хорошие программисты не хотят писать на Java — они увидели, что можно в Scala и в Kotlin и всё — они потеряны для Java. И все коммьюнити не может ничего без основных контрибьюторов.
это как то… как то уж очень категоричноvsapronov
12.11.2018 23:23Ну можно смягчить — суть не поменяется. Есть отток программистов. Среди них есть крутаны. И без того не развивающаяся платформа будет развиваться еще медленнее.
maxzh83
12.11.2018 22:56хорошие программисты не хотят писать на Java — они увидели, что можно в Scala и в Kotlin и всё — они потеряны для Java
Года 3-4 назад прошел два курса Одерского по Scala, написал на ней домашний проектик, который до сих пор работает, хотел было устроиться на Скалу по работе, но не получилось. Спустя несколько лет успокоился и теперь от предложений на Scala отказываюсь, пишу на Java. От Scala осталось одно разочарование, о котором писал выше. Котлин тоже немного попробовал. Да, неплохо, но и не настолько хорошо, чтобы ради синтаксических плюшек менять работу (тем более вакансий на котлине совсем мало пока). Может, правда, я не очень хороший программист, поэтому не потерян для Java.vsapronov
12.11.2018 23:27Какой город — страна? Этим многое определяется. До некоторых уголков планеты то, чт о пишут в интернатах доходит с задержкой. Вангую правильную потребность в Kotlin через год-два по всей России. Сейчас все конторы в NYC нанимают, чтобы совладать со своей Андроид кодовой базой. Но уже и звучит Kotlin for micro services, потому что корутины и потому что люди хотят писать на одном языке все (сомнительное желание). Так вот, этот тренд обязательно дойдёт до российских боди шопов и все…
Druu
13.11.2018 03:13Вангую правильную потребность в Kotlin через год-два по всей России.
Котлин — говно. Много косяков в дизайне. Не взлетит, даже не надейтесь. Ни в России, ни где-либо еще.
vsapronov
13.11.2018 03:15А какие? Я не говорю, что их нет — скорее интересно узнать.
Я слышал, что они там сознательно отказались от pattern matching. А где еще накосясили?
AnutaU
13.11.2018 10:17Много косяков в дизайне. Не взлетит, даже не надейтесь.
Простите, а какой язык из уже взлетевших может похвастаться идеальным дизайном без косяков?
Это я к тому, что качество дизайна может быть и влияет на успех языка, но точно не является определяющим фактором.Druu
13.11.2018 10:40Простите, а какой язык из уже взлетевших может похвастаться идеальным дизайном без косяков?
В том и смысл, что они уже взлетевшие. Так что новому языку надо конкурировать с существующими решениями, а не в вакууме. Например, те же плюсы в 2018 умерли бы не родившись.
AnutaU
13.11.2018 10:58Но дизайн — это же единственное, чем можно конкурировать.
И кстати, чем дизайн Котлина по вашему мнению хуже, чем у существующих решений? Какие там страшные косяки?
BingoBongo
13.11.2018 12:57Например, те же плюсы в 2018 умерли бы не родившись.
Не подскажите, кто бы занял их место?Whuthering
13.11.2018 13:05+1Rust?
BingoBongo
13.11.2018 13:30А как же ООП?
Fesor
13.11.2018 20:47Когда я придумал термин ООП я не имел ввиду C++ (с) Алан Кей.
Ну и если мы говорим про провославное ООП и Rust: https://github.com/actix/actix
BingoBongo
13.11.2018 21:45Наследование данных, виртуальные деструкторы?
Fesor
13.11.2018 23:44Наследование данных
composition over inheritance и все в таком духе.
Интересный момент — даже Страуступ признает что добавление
protectedв плюсы было ошибкой (очень легко неявное поведение организовать, всякие LSP нарушить, контракты сломать)
А без protected стэйта мы можем ограничиться наследованием об абстрактных классов без состояния (ибо если там приватный стэйт — скорее всего лучше вообще вынести это дело как зависимость, опять же композицией/агрегацией).
Опять же, идеям "ооп" в плюсах лет больше чем это самое ООП существует (Хоар классы описывал задолго до того как Алан Кей сказал кому то что он "ООП делает")
Lisp более ОО чем C++.
виртуальные деструкторы
Именно деструкторы? И именно виртуальные?
Зачем вам деструкторы, если за вас компилятор расставит где почистить ресурсы, высвободить память и т.д.
BingoBongo
14.11.2018 01:06composition over inheritance и все в таком духе.
Не знаю, я нашел обсуждение на хабре, из него вытекает, что в rust'е есть наследование поведения, но не данных: habr.com/post/309968/#comment_9805712
Зачем вам деструкторы, если за вас компилятор расставит где почистить ресурсы, высвободить память и т.д.
А как же неуправляемая память? Возьмите OpenGL: текстуры, буферы, шейдеры — все они создаются в видео-памяти — вряд ли rust будет ее разруливать сам. Ну и опять же, чтобы не вызывать всякие file.close(), socket.close() и т.д. Или как там дела с этим обстоят?Fesor
14.11.2018 13:21но не данных
поясните что вы имеете ввиду. Мне кажется что для вас "расширение данных" это просто расширение структуры. Что-то типа сишного варианта:
typedef struct foo { int a; } foo; typedef struct bar { struct foo; int b; } bar;
Нужно все же понимать о чем вы говорите, пока не понятно. Ибо "наследование данных" это какой-то процедурный концепт.
А как же неуправляемая память?
Она как раз неуправляемая, в том смысле что за всем следит компилятор. задайте явно вашим файлам и сокетам скоуп жизни и компилятор сможет определить когда вам больше не нужен ресурс и сам все закроет и сам все почистит.
Ну и да — деструкторы в rust все же есть
Nalivai
13.11.2018 17:17Мне кажется что вы не очень понимаете зачем нужны плюсы, почему они такие, и в чем их кайф.
pawlo16
13.11.2018 17:50-1Нужны — чтобы попить чайку во время получасовой компиляции. А особый кайф — в том, чтобы читать сообщения об ошибках на 100+ экранов текста. «Спасибо, уважаемый gcc, ударьте меня, пожалуйста, ещё разок, да по больнее»
tuxi
12.11.2018 22:59А вы про какое табло?
Я про табло реальных вакансий. Хайп хайпом, это нужно, это попытка совершить прогресс и все такое, но в сухом остатке, в суровой реальности, востребованным остаются в основном уже опробованные языки и технологии. И так будет очень долго, потому что конечный потребитель, заказчик прежде всего умеет считать деньги. А ЯП выжившие после конца хайпа, могут запросто занять одну, какую-нибудь узкую нишу. И вполне себе там жить.vsapronov
12.11.2018 23:30-2А я про реальные счета. Моя з.п. как Scala специалиста на 27% выше з.п. как Java-специалиста. И еще я могу приходить в офис с собакой (ее надо завести еще) и у меня неограниченное кол-во дней отпуска.
tuxi
12.11.2018 23:34На зарплаты Java разработчиков тратится прилично больше денег нежели чем на зарплаты Scala разработчиков. Поэтому это нифига не аргумент. Но если что, лично я рад за Вас :)
vsapronov
12.11.2018 23:41+1Ну что там где тратиться — я на своем счету не почувствовал. А почувствовал то, что сказал.
Опять же в моей системе ценностей вакансии, деньги никак не связаны с краткостью или говняностью языка. Все программисты не голодают, можно подумать и о более высоком.tuxi
13.11.2018 00:19Никогда не интересовались, как получилось, что Java стала таким говном? А мне это очевидно (как и то, что Java — говно, как язык)
«Начали за здравие, закончили за упокой».vsapronov
13.11.2018 01:37Не понял, вы к чему? Я думаю, я последовательно говорю, что Java как язык говно в 2018. Думаю, что тема: разработка на более чем одном языке играет существенную роль в приобретении этого понимания.
И еще есть уход программистов с Java на сколько он велик, можно судить по-разному, но то, что он есть — это ясно всем неидиотам.tuxi
13.11.2018 10:15Вы знаете, сколько я видел настоящих разработчиков на java, практически ни один из них не хэйтил другие языки. При этом любой из них по факту «фуллстек», так как «если припрет» он сможет на java сделать все. И фронт и бэк, и параллельные вычисления, и просто большие вычисления. И дескопную программу написать. Это самодостаточная система, понимаете?
Вот Вы обвиняете Java в том, что к ней не так быстро прикручивают новые идеи. Легко обвинять экосистему которая плодотворно развивается с конца 90-х годов, на которой написаны сотни тысяч _ПО НАСТОЯЩЕМУ_ больших бизнес приложений. Это уже часть мира, без которй не прожить. Большая «Экосистема» должна быть обратно совместимой как минимум. Новые ЯП с новой семантикой как раз и появляются по причине того, что ЯП ставшие стандартами отрасли не могут позволить себе менять кардинально свой стандарт на каждый новомодный чих и пых.
Я использую java с 2002...03 года. Я использовал реализацию comet уже тогда, когда слово «web-socket» еще не слышал практически ни один фронтендщик, да собсно говоря и node.js еще не было. Я уже делал реальные проекты и бэка и фронта только на java и они до сих пор работают. Представьте себе на сервере с 2гигами памяти, 1 ядром и db на нем же.
Поэтому, когда я писал про берег реки, поверьте, я писал о личном опыте. Много воды утекло с тех, а java есть и еще очень долго будет. Просто потому, что это реально удачный ЯП. Просто потому, что она заставляет соблюдать высокий стандарт разработки. Просто потому, что выстрелить себе в ногу на java достаточно проблематично. Даже если какому нибудь джуну очень захочется.
А новые языки всегда будут. И адепты нового языка будут говорить, что Scala это прошлый век, что она не реализует новые идеи.
Хайп всегда проходит, остается сухой остаток. Вопрос его количества. И у java он один из самых больших за последние 20..30 лет.
Stas911
13.11.2018 05:38Про неограниченное количество дней отпуска слышал, что такое декларируется некоторыми компаниями. Мне просто интересно — зачем вообще нужен бизнесу человек, без которого можно легко обойтись больше пары недель?
vsapronov
13.11.2018 06:12Ну вообще-то нормальный бизнесс не должен зависеть от конкретных сотрудников, и если по причине их отсутствия в течении N недель вот прямо все рушится, то значит что-то не так с бизнес процессами.
Кроме того, как вы себе представляете работу программиста? Собственными руками на продакшн серверах запускает только что написанный код ежеминутно? В нормальном процессе разработки отсутствие одного человека = отсутствие новых фич в какой-то области в течении этого времени, и то только в том случае если он обладает уникальными знаниями.
Многие бизнесы на западе уже поняли, что программист должен быть счастлив и доволен и именно тогда он будет наиболее продуктивен. Работа от «забора до обеда» не приносила ничего хорошего ни в одном интеллектуальном виде деятельности. Немного забавно, правда, что в основном компании которые это осознали в полной мере — это своего рода стартапы или успешные постстартапы этого десятилетия, и как раз в такого рода стартапах в основном новые нормальные яп, а не Java — ну вы поняли…Stas911
13.11.2018 06:27А разве такие условия только программистам полагаются? Кроме них еще полно всякого разного народу в компаниях.
А еще мне кажется, что если некто, скажем, будет сваливать по месяцу 4 раза в год, не показывая при этом экстраординарной производительности остальное время, его очень быстро попросят на выход.vsapronov
13.11.2018 06:54Ну нельзя же в компании 350 человек одной группе давать привилегированные условия! Хотя я не знаю, сколько там выходных дней у работников кухни, которые еду выкладывают.
По месяцу четыре раза в год (31% от full time) — может быть и уволят. Здесь employment at will. Но с другой стороны я стараюсь работать 4 дня (20% от full time) и никаких проблем с этим нет. Правда у меня рваный рабочий темп — не имею работать с одинаковой скоростью.
Whuthering
12.11.2018 18:39+4Когда я слышу старых мудрых засранцев с их мантрой «язык программирования не важен», сразу же вспоминаю не менее старую цитату:
«Человек, владеющий фортраном, может писать на любом языке, но делать это он будет как на фортране».
yokotoka
12.11.2018 19:00Я лично смотрел код GRPC клиента на пайтоне… настолько уродливо, неидиоматично и бездарно написанного кода я ещё не видел. Видимо его писал чувак, которому «все равно на чем», но он писал только на java или плюсах, что и отразилось на результате. С тех пор я не воспринимаю серьёзно гуггл как передовую технологическую компанию и их истории про «найм лучших» вижу скорее как фейк и самообман.
shiru8bit
12.11.2018 19:11Отразилось на результате — не работает как надо, или просто код выглядит непривычно?
yokotoka
12.11.2018 19:21Ну, написать на питоне write-only код и закатывать солнце вручную, не ознакомившись с базовыми возможностями стандартной библиотеки— это не просто «непривычно», это даже автоматический линтер не должен пропускать, не говоря что это идёт вразрез с дзеном питона. Скорее похоже что код сгенерели из плюсовых исходников автоматически и заинлайнили кучу всего. Но нет, вроде, реальные люди писали. К слову, работает он так же как и выглядит — через раз. Это 2 года назад было, может сейчас уже лучше.
zagayevskiy
13.11.2018 00:03Сталкивался с такой же херней, только вместо питона были джава и андроидовый фреймворк .
Stas911
13.11.2018 05:40Те же слова слышал от Скалистов, когда они видели код на Scala, написанный Java-программистами. Вот прямо слово в слово.
KYKYH
12.11.2018 18:55+1Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте» так не делают.
А зачем в тайпскрипте абстрактные классы если ими нельзя пользоваться? В чём сакральный смысл понятияПотому что в тайпскрипте» так не делают.
?
(Простите за профанство, сам не тайпскриптер)indestructable
12.11.2018 21:20Можно пользоваться, но пользуются редко (тк на джаваскрипте так тоже никто не делает).
Однако, называть это профанством я бы не стал. И прям выносить приговор квалификации разработчика — тоже не стал бы.
VolCh
12.11.2018 22:32Что значит «нельзя пользоваться»?
KYKYH
12.11.2018 22:57+1Ну по формальной логике, если
Однажды я зафигачил дизайн на абстрактных классах в typeScript ...
А существует парадигма
… в тайпскрипте» так не делают.
Соответственно нет условий, в которых данную фичу дозволяется использовать. Следует закономерный вопрос: зачем фича?Fesor
12.11.2018 23:35Не все проблемы в мире выгодно решать структурным тайпингом. Абстрактные классы бывают полезны (особенно если интерфейсы не могут содержать дефолтной реализации как в Java).
А в случае TS можно поразбираться в вопросах номинальный тайпинг vs структурный тайпинг, плюсы и минусы одного и второго.
Fesor
12.11.2018 23:32В TS в основном все юзают структурный тайпинг (опять же можно порассуждать на тему оверюза фич).
Вот есть у вас 2 модуля, A и B, один зависит от другого. Как сделать инверсию зависимостей в какой-нибудь Java? Добавим интерфейс в модуль A и B его будет имплементить, направление зависимостей уже меняется. Как это делать в TS? Примерно так же, только имплементить интерфейс не нужно. Типы либо сходятся либо нет.
И в целом как и в случае с Java необходимости в абстрактных классах практически нет (опять же после появления возможности объявлять дефолтное поведение в интерфейсах). И в целом в java как по мне абстрактные классы представляют ценность только для обратной совместимости.0xd34df00d
13.11.2018 00:44И это типа хорошо?
Раньше была явная точка, в которой выражались требования к типам: определение интерфейса. Код клиента тайпчекается против определения интерфейса, код реализующего интерфейс тайпчекается против того же определения. Стало как-то утино и хрупко: если я меняю код реализующего интерфейс, то надо пересобрать все клиенты, чтобы проверить, что типы сходятся. Не так ли?
Не, поймите, я сам иногда мечтаю об анонимных неявных тайпклассах в хаскеле. Но, скажем, пределы модуля оно покидать не должно, иначе это ад и погибель.Fesor
13.11.2018 01:08И это типа хорошо?
хорошо или плохо — не очень то инженерные понятия.
то надо пересобрать все клиенты, чтобы проверить, что типы сходятся. Не так ли?
все так, на уровне одного модуля все с типами хорошо, на уровне другого — не сходятся. Но на практике все не столь уж плохо что бы отказываться от преимуществ подобной "утиной типизации в компайл тайме".
Опять же, тут думаю стоит еще учитывать особенности системы модулей, которые сильно уменьшают риски от вот таких вот изменений (явно прослеживаются зависимости модулей, что позволяет отследить по иерархии зависимости все что надо на всякий случай протайпчекать)
0xd34df00d
13.11.2018 01:40+2хорошо или плохо — не очень то инженерные понятия.
Но на практике все не столь уж плохо
:]
Хз, как в этом тайпскрипте всё, но я утиной типизации уже по уши наелся в темплейтах C++ и не отказался бы от тайпчекинга до мономорфизации, а не после, например.
Хотя даже с исходным пропозалом концептов типы там описывались как удовлетворяющие концепту без всяких лишних телодвижений, утино. Фиг знает, в общем. Если ошибки вылавливаются на этапе компиляции, то, наверное, с этим можно жить.Druu
13.11.2018 03:19Хз, как в этом тайпскрипте всё, но я утиной типизации уже по уши наелся в темплейтах C++ и не отказался бы от тайпчекинга до мономорфизации, а не после, например.
В TS если делать полный тайпчек сразу, то не будут нормально работать mapped и conditional types, т.к. чтобы тип проверить, его надо сперва сконструировать, если конструкции выражать сразу в исходном типе то для простых вещей, котоыре сейчас делаются в две строки, придется писать тонны type-level кода. Так что в итоге там процесс мономорфизации с процессом чека сильно перемешаны, по сути это один процесс.
roman_kashitsyn
13.11.2018 01:12Не, поймите, я сам иногда мечтаю об анонимных неявных тайпклассах в хаскеле.
Наверное, вы хотите просто записи с Row Polymorphism.
0xd34df00d
13.11.2018 01:42Но его-то в хаскеле тоже нет, есть только какое-то нытьё про classy-линзы.
Druu
13.11.2018 03:15Стало как-то утино и хрупко: если я меняю код реализующего интерфейс, то надо пересобрать все клиенты, чтобы проверить, что типы сходятся.
А жалко что ли? Пусть пересобирается, я пека покупал не для того, чтобы он стоял.
В данном случае, класс с реализацией — и есть контракт.
Но и интерфейс отдельно выделить не мешает никто, если хочется.0xd34df00d
13.11.2018 03:31Ну, у меня есть некоторые возражения организационного толку (ответственность за изменения, владение кодом, объём зависимого кода) против такого подхода, но это уже частности и надо смотреть по ситуации.
mayorovp
13.11.2018 12:29Если вам важно заранее проверить что ваш класс удовлетворяет интерфейсу — то ключевое слово implements никто не отменял.
alatushkin
12.11.2018 18:57+6Предположу, что на самом деле причина всех этих проблем с самобичиванием и проим вот в этом:
«дайте немного времени на беглое чтение спеки, и я готов работать с этим говном
Я, конечно же, сделал вид, что просто мои коллеги — бездарные идиоты. Обычно это помогало, но в этот раз остался осадок.
Чем сильнее человек ведет себя как высокомерна задница по отношению к другим людям — тем тяжелее ему потом признавать свою не правоту.
Часто такое встречал у свежеиспеченных «молодых» CTO и архитекторов (знаете, такие типажи, которые во всех публичных местах добавляют себе подпись CTO?) )
Ну а дальше — в дополнение к комплексам и отсутствию воспитания, биология делает свое дело: когда уровень энергии падает — офисный мачизм превращается в бездну рефлексии.
Осознай и прими что ты «не самый умный» и как писали выше: это всё ерунда — «плюнуть и растереть».
amaksr
12.11.2018 19:00+1Однажды я зафигачил дизайн на абстрактных классах в typeScript, и меня высмеяли. Потому что в тайпскрипте» так не делают.
Можно подробнее? Что не так с абстрактными классами тайпскрипта?
Мой самоприсвоенный скилл «Я научился быстро учиться» оказался неправдой.
Не согласен. Многие сразу отказываются что-то там делать на основании, что они этого не знают. Я вот не отказываюсь, даже наоборот. Но сразу предупреждаю о том, сколько времени понадобится на изучение, и что именно я смогу после этого сделать.
Да и вообще, когда переходишь на новое место, с языком и технологией обычно разобраться проще всего. Сложнее — с фреймворками, если их не видел. А больше всего занимает понять то, что написано до тебя. Тут как раз сеньерность и помогает больше всего, т.к. если уж видел какой-нибудь хитрый паттерн, даже на другом языке, то сразу его узнаешь и время на дебаг и понимание сэкономишь.DarkGenius
12.11.2018 20:38При переходе на «новое место с новым языком» самое сложное, как мне кажется, перейти так, чтобы не сильно потерять в зп (а лучше не потерять вообще). Вряд ли senior .NET разработчика возьмут на аналогичную позицию по Java, если у него нет достаточного опыта в Java. Получается, что даже фуллстек ограничен рамками своего «фулл стека».
Hzpriezz
12.11.2018 19:03+1Актуально не только для кода. В принципе человек может учить все, главное правильно структурировать знания. Затем появляется вопрос о качестве этих знаний. Как только задаешься этим вопросом то понимаешь одно… ты ничего не понимаешь и знаний у тебя практически нет. Думаю именно с этой точки начинают развиваться хорошие квалифицированные специалисты.
И еще, очень важно уметь признавать свои ошибки, а не винить всех в «непонимании».
Автору спасибо, статья понравилась)
Dimash2
12.11.2018 19:17Узкий взгляд на жизнь и плохой совет. Люди разные и хотят разного. Если вы хотите всю жизнь работать на галере — учите одно и живите на галере.
Я 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 )
— Пора понять, что жизнь сложна и хватит высокомерно оценивать людей терминами и ярлыками. Вам нужна другая метрика, например деньги или репутация, значимость.Max2UP
12.11.2018 19:31«Front End так не может» — У меня так могут middel Front End. И я считаю это нормальным требование к современному Front End. И джунов обучаем в том же направлении. Похоже проблема в том, что вам похоже не встречались нормальные FrontEnd.
Alex_ME
12.11.2018 19:27+2Фулстек, говорили они. Сейчас я успокою всех переживающих фуллстеков и дам возможность почувствовать себя глубокими профессионалами. Я называю себя дилетантом широкого профиля. Чем мне приходилось заниматься и что я знаю, где-то больше, где-то меньше:
- C# (WinForms, MVC, немного WPF).
- Сюда же к вебу классическое: HTML, CSS, JS. На всякие реакты посмотрел одним глазом, но опыта практического нет
- C++ неплохо, но знаний и опыта в разной хардкорной и не очень темплейт-магии не достает
- Android (Java и один маааленький проект на Kotlin)
- Микроконтроллеры
ArduinoAVR ATmega и STM32 - Околоробототехническое: ROS, компьютерное зрение (посредственно) и что-то в этом духе.
snuk182
12.11.2018 19:28+2Актуальный вопрос в лоб: что выгоднее, быть вечным фулл-стек мидлом или гипер-сеньором в узкой отрасли, которая может сдохнуть в пределах пяти лет?
indestructable
12.11.2018 21:24+7Быть синьор фулл стеком и не считать мнение автора из интернета абсолютной истиной.
snuk182
13.11.2018 12:38Хорошо если так. Просто часто оказывается, что ашары ищут узкого специалиста по запасному выходу из левой ноздри (основной выход и правая ноздря не подходят), и ответы «хуле тут специализироваться, вы ж как байкеры, помрете через сезон, а я разберусь быстро» им чет не нравятся. Особенно весело, если это легаси, мелькнувшее на пару лет в восемьдесят мохнатом году, а чуваки хайпонули и прицепились к нему.
0xd34df00d
13.11.2018 00:47По каким критериям? По карьере, по деньгам или по удовлетворению от жизни?
Я стараюсь гипер-сеньорить в C++ и развиваться в этой всей хаскельной идрисне,второй дипломвторое синьорство там получать. Первое — потому что интересно и так получилось, второе — потому что интересно. Мне норм.
Ну и плюсы вряд ли сдохнут в обозримом будущем.
retran
12.11.2018 19:31+2Пока вы измеряете знания и скилл в языках и фреймворках — вы останетесь вечным миддлом. Независимо от того фуллстек вы, бэкендер, фронтендер или еще какой -ендер.
Учите фундаменталку, «нинужные» алгоритмы и вот это вот все — и будет вам счастье.
Samouvazhektra
12.11.2018 19:36+2По моему проблема просто в этом
и убедил себя, что теперь-то могу действительно всё. Я абстрагировался, мыслю в нескольких парадигмах программирования одновременно и обладаю практическими знаниями во всех аспектах профессиональной разработки ПО
вы просто застряли в развитии, а потом вынырнули и осознали жестокую реальность
terantul
12.11.2018 19:39Не скажу что я фуллстек, но не пхп единым…
В чём удобство знаний (и опыта) в нескольких направлениях — без работы никогда не останешся.
Бичевать себя что знаешь меньше чем коллега посвятивший технологии(языку) 10 лет? пффф. Не смешите.
Каждому своё (так было написано на одних воротах). Делайте то что Вам нравится и получайте от этого удовольствие. IT сфера хороша в том, что может быть хобби, за которое платят неплохие деньги. Ведь айтишниками не становятся, ими рождаются.
Nomad1
12.11.2018 20:01Люди, живущие в селе, обычно «фулл-стек» мидлы: они могут и трактор починить, и проводку сделать, и дом построить, и корову подоить. Правда, это не делает их специалистами в какой-то отрасли, но жить помогает. А уже узкая специализация у каждого своя: кто 40 лет на комбайне сениорит, кто самогон варит, а кто-то вообще сомилье на филансе — к полудню уже три сорта напитков опробует и философствует под забором.
И вы не страдайте напрасно, найдите для себя новое направления и изучите его, раз это приносит вам удовольствие и доход )
Arris
12.11.2018 20:04+1Язык программирования неважен, когда ты знаешь их 5 или 10 и кодишь на коленке в троллейбусе и проектируешь код во сне.
… если ты не знаешь ни одного — еще как важен. См. Синдром Утёнка.
Skykharkov
12.11.2018 20:05Мне кажется что тут налицо простая подмена понятий. Фуллстек — не объем знаний в разных (условно говоря) языках программирования. Фуллстек означает, что я знаю как оно все устроено внутри. Надо SQL базу — запросто, фронтэнд — не проблема, REST сервис — как два пальца. Desktop GUI — ой как хорошо, вообще запросто. Микросервисы на отдельных инстансах с отказоустойчивостью — легко. На асме вставочку — ну если десяток строк… С железякой какой-то нестандартной поговорить надо — запросто… Фуллстек это когда понимаешь как оно все работает отдельно и в связке. Фуллстек это знание всей внутренней кухни. А на чем все это делать (фреймвоки, языки и т.д.) — вопрос даже не второй. Если это работает быстро, стабильно и легко поддерживается. Да хоть на бейсике. Какая разница то?
SirEdvin
12.11.2018 20:08А давайте зададимся вопросом, а кто такие синьоры? В нормальном мире разницы между синьором и фуллстеком вполне может не быть, вы просто будете знать одну часть своего стека лучше, чем другие.
Синьоры, которые застревают в рамках одной технологии обычно еще хуже, чем фуллстек разработчики.
dempfi
12.11.2018 20:36+3Спасибо за статью. Я долгое время считал также как вы — старался развиваться вглубь в одной экосистеме. Потом углубился в фундаменталку и пришел к выводу что ориентация на специализации, экосистемы, языки и уж тем более фреймворки — это все от лукавого.
В программировании все суть одно и то же — одна и та же простая математика за всем. Это не какая-нибудь юриспруденция где абсолютно разный свод законов работает в разных случаях.
Наверное программирование можно сравнить с бухгалтерией, а языки/технологии с бухгалтерским софтом. Если компания нанимает бухгалтера для работы с определенным софтом, то она нанимает просто оператора этого конкретного бухгалтерского софта, а не бухгалтера. Точно также если компания нанимает фронтэнд разработчика. Только в отличии от бухгалтеров, программисты мало кому нужны — чаще нужны те самые операторы.
Я верю что название Fullstack разработчик появилось лишь как способ сказать что нужен просто разработчик ведь в IT так много названий.
Ну и напоследок, одно из отличительных качеств сеньор разработчика — это наставничество. И кажется мне специалисту узкого круга менторить за пределами его узкого кругозора будет крайне сложно, что ставит под сомнение вообще возможность существования сеньор разработчика с узким профилем.
tuxi
12.11.2018 20:41+1Наверное я мало видел проектов, но точно скажу, из тех проектов, что я видел, успешными стали только те, в которых разработчик(и) не пренебрегали предметной областью. Причем один такой неуспешный проект делался одновременно с другим. В итоге после полутора лет и трат выраженных 7ми значными числами в рублях, этот неуспешный проект был поглощен тем вторым, который делался, имея в своем базисе крепкое знание и понимание предметной области. При этом команда второго проекта постоянно проводила консультации для первой команды. И поглощение выглядело как "просто 301-й редирект" (это вебпроекты были). Взять и переюзать что-либо было просто нереально.
Разобраться грамотно в предметной области — это половина успеха и половина проекта. Даже для "кодера" джуна.
ZXZs
12.11.2018 20:51В моём понимании senior — это не тот программист, который до дыр обсосал выбранную им технологию. Senior — это такой дядька, который, вместо разведения холиваров на форумах по поводу и без, занимается внедрением в уже созданные проекты новых технологий, aka Deep Learning, машинное обучение, компьютерное зрение, ВебАссемблер в конце концов, и так далее.
Junior — исполняет идеи
Middle — делегирует джунам и участвует в исполнении идеи
Senior — генерирует идеи, делегирует мидлам и участвует в исполнении
Можно быть и сеньёром-фуллстеком, почему бы и нет?AEP
12.11.2018 21:22Что-то слишком положительное у вас получается. Должен быть еще кто-то, кто не дает ходу плохим идеям. И это должен быть не только директор, т.к. директор отвечает за соответствие направления развития проекта задачам бизнеса, а некоторые плохие идеи можно и нужно убивать по чисто техническим, не связанным с бизнесом, причинам.
Moxa
12.11.2018 20:52фулстек и мидл это разные понятия, никто не мешает копать в в одном направлении достаточно долго, чтобы стать сеньором. Жаве больше 20 лет, синтаксис за это время менялся не сильно, фреймворки тоже медленно эволюционируют. Любой жаваскриптовый фреймворк можно выучить полностью за пару месяцев, если не недель, было бы желание. Чтобы быть синьором, нужно постоянно развиваться, пробовать новое, а не сидеть на жопе и рисовать одни и теже формочки каждый день
imouseR
12.11.2018 20:54-1Спасибо автору, сам стою на распутье. И комментарии очень хороши, отчасти))) Все время лезу не в свой выбор (js/react) и потом понимаю, что только зря трачу бесценное время. Но каков же искусс! Например Ocaml/Reason — выглядит как пирожок, но заглотишь — проблем не оберёшься. Слава богу и таким авторам: постепенно приходит видение пути.
StroboNights
12.11.2018 20:56+1Когда я только начал учиться кодить, я поверил старым мудрым засранцам с их мантрой «язык программирования не важен».
Все правильно, так оно и есть: когда Вы только-только начинаете учиться программировать, сам по себе язык программирования, с которого начинаете, не так важен. Именно это Вам и сказали когда Вы начинали. Та же Arduino была создана как платформа для обучения с пониженным порогом вхождения для новичков. Способности у каждого человека очень разные, так уж природа распорядилась, поэтому, по аналогии, русский язык может освоить любой житель планеты, но вот Александр Сергеевич Пушкин, Достоевский, Толстой, Булгаков — единственные в своем роде.
AlexMal
12.11.2018 21:19+1Но в IT если ты не обновляешь свои знания о технологии в течение года, ты уже не актуален.
С C++ Это тоже работает?)0xd34df00d
13.11.2018 00:49Там нужно обновлять раз в три года, но зато каждое обновление как раз пару-тройку лет займёт.
Ъ плюсисты уже знают про модули, концепты и вот это вот всё, поигрались со свежими срезами clang и gcc прямиком из транка/мастера и представлят, как C++20 изменит написание кода.Gorthauer87
13.11.2018 12:59А потом оно еще кучу лет в дикую природу будет проникать, ведь не перепишут же сию минуту все на модули.
Whuthering
13.11.2018 12:40Там этот промежуток по времени растянут немного, но суть та же.
Код на C++98 ощутимо отличается от кода на C++11 (причем не только синтаксически, но и в плане подводных камней), далее пара минорных обновлений, но с C++20 снова довольно много чего может перевернуться.
Плюс еще где-то между всем этим появились Core Guidelines и GSL, тоже требующие изучения и «перестроения» себя, и во многих компаниях/проектах их вполне серьезно используют.
Другая проблема в том, что некоторые люди рассуждают так же, мол, «в плюсах все происходит медленно и резко ничего не меняется», из-за этого расслабляются, а потом при переходе в новое место, даже если пройдут собеседование, то очень больно и неприятно получают на первом же code-review :)
impwx
12.11.2018 21:23+1Настоящий фуллстэк — это не «с мира по нитке», а спец в одной-двух областях с общим знанием нескольких других. Фокусируясь на одной области, человек теряет способность критически оценивать свои подходы, да и руководить проектом не сможет.
Dywar
12.11.2018 21:26+1Каждому свое.
Есть успеные люди, которые каждые пару лет перепрыгивают на хайповые языки и снимают сливки.
Есть фуллстеки, которые просто не могут изучить все, но в 99% этого и не требуется.
Есть экперты по направлениям, но они тоже смотрят по сторонам. Доклады по продуктам MS читают эксперты, но при этом они тыкают соседние технологии.
Правильного пути нет, есть баланс между желанием, возможностью и потребностями.Dywar
13.11.2018 20:57В тему, поток мыслей (имхо), может кому интересно.
Схема:
Человеческий мозг ограничен в своих возможностях. Не слышал про людей которые в совершенстве владеют всеми языками существующими в мире, в уме умножают стозначные числа, и в деталях помнят кажду секунду своей жизни. (все это один человек)
Поэтому приходится делать выбор из множества варинатов. Емкость коробочки в которую все это складывается ограничена. Возможно у одного она 10 кубов, у другого 25. Одна коробка хранит все по полочкам, а другая в хаосе, и поиск в ней осуществляется с другой скоростью. И коробочка то не простая. Чем больше в ней лежит, тем проще туда добавлять. Похожие элементы занимают меньше места. Но все равно это очень сложно и долго.VolCh
13.11.2018 21:55+1Вот уровень познания и сложность решаемых задач не стоило объединять в одну ось точно. Самые сложные задачи, обычно, это задачи требующие взаимодействия разнородных систем и один фуллстэк здесь часто может «порвать» пару-тройку спецов.
Lexicon
12.11.2018 21:27+3Единственный контекст, в котором я бы согласился с заголовком — фуллстек — не источник денег.
Знание своих слабостей и сильных сторон — важнейшая черта для опытного специалиста, именно этот навык определяет, какую выгоду вы можете принести себе и проектам, с которыми вы работаете.
До тех пор, пока фуллстек(и любой другой специалист) отдает себе отчет в том, что он может сделать и в том, чего не может, это отличный путь, позволяющий сэкономить средства компании, проявить себя как основатель стартапа, архитектор или просто хороший разработчик.
Тренироваться на фуллстека — ребячество, никто не станет платить вам больше, никто не уверует в вашу универсальность, а если вы переживаете моральный кризис — "я так мало умею", его удастся исключительно усугубить.
Это навыки, которые возможно получить, работая в соответствующем окружении: пытаясь создать проект в условиях ограниченных ресурсов; руководя командой из разношерстных специалистов; увлекаясь по выходным моддингом майнкрафта и сражаясь с читерами, бесконечно читая книги и статьи от безопасности и до модных дизайнерских фич, будучи больше, чем специалистом на найм, идейным фанатом своего дела.
Фуллстек — элементарное стремление человека к созданию чего-то большого своими силами
amarao
12.11.2018 21:31+5Я могу рассказать про такого, но в контексте системного администрирования. Он получает много денег именно за «многомодальность». Потому что я, перед тем, как настроить IPSec, пойду и прочитаю. Если не всё, то хотя бы первые 5-7 тысяч страниц. А он идёт и настраивает IPSec между солярисом и циской через два ната за 4 часа.
Нужно сделать репликацию для оракла? Да. Поправить отчёт SAP'е? Да. Починить потерю пакетов в SDN с онлайн-интроспекцией? Да. Кривая метрика виртуалки в openstack'е? Да. Падают тесты в maven'е при сборке deb-пакета на jenkins'е? Да.
Но при этом он совершенно не разбирается в нюансах и деталях. Но на него есть спрос. Человек который может прийти и начать исправлять необъятное.
Dark_Scorpion
12.11.2018 22:00+1Несмотря на твои огромные усилия, каждый знаток конкретного языка будет с пеной у рта доказывать, что ты не достоин называться сеньором.
Может стоит меньше слушать «знатоков» языка и заниматься тем, что тебе нравится?
aol-nnov
12.11.2018 22:33BalinTomsk
12.11.2018 22:36— по пять лет опыта в каждой из фулстечных технологий.
Если между технологиями перерыв 5 лет — то забывается многое и остается пробел в знании когда выходит новая редакция языка.
Особенно если после С++ ныряешь в TSQL через несколько лет в памяти только общие детали.
sentyaev
12.11.2018 22:42Я изучил C# и .NET с разными областями применения (asp.net, wpf, xamarin), js/ts (react/redux, node) и убедил себя, что теперь-то могу действительно всё.
Тут все как всегда, хотите заниматься квадратно-гнездовым программированием и быть самым лучшим в этом деле, то да, нужно учить фреймворк, даже язык в этом случае будет вторичен.
Ну а если программированием, то фундаменталка, языки и фреймворки вторичны в этом случае, все равно принципы одинаковые.
Fedorkov
12.11.2018 22:46Cамые лучшие программисты — те, кто понимают, насколько ограничены их возможности. Они скромны. Худшие программисты отказываются признать, что их способности не соответствуют задаче. Характер не позволяет им стать отличными программистами. Чем усерднее вы работаете над компенсацией ограниченных возможностей своего разума, тем лучше будете программировать. Быстрота вашего развития напрямую зависит от вашей скромности.
— Св. Евангелие от Макконнелла
datacompboy
12.11.2018 22:50-1Фуллстек это не «учи всё». Фуллстек это инвестированные те самые 10к часов во множество технологий. Абстракция не сводит к нулю их, но снижает на порядки.
Абстрактные классы в JS? Глупость. Надо ли для этого знания тратить 10к часов на JS? Нет.
То есть в первую было вложено 10к. Во вторую — 8к. В третью 5к. В четвертую, пятую шестую — хватит 1-2к.
Я пишу на том, на чем придётся. Но я следую коду который уже есть вокруг. Да, мой результат может быть хуже, чем если я потрачу время и объясню каждому из 5 узких спецов, чей код я правил по дороге, и они потратят время на переписывание правильным образом.
Вместо этого я потрачу немного усилий, решу проблему перетреся 5 параллельных технологий и сервисов, после чего оно уже работает как надо, а узкие спецы когда-нибудь доберутся и причешут код за мной. Если понадобится. Обычно редко требуется.
Не «идиоматично»? Зато O(N) вместо O(N^2), потому что «я пол бака и ты пол бака, вместе оно полюбому бак будет, да?» (ц) день радио.
boblenin
12.11.2018 23:19Про фулстеков хорошо походит: «Every Marine a rifleman» ©. Каждый разработчик в комманде должен уметь разобраться в коде любого компонента, что-то дописать, что-то подправить (в противоположность тому, что если Вася-DBA находится в отпуске, то все задачи затрагивающие базу — стоят заблокированными). Но один будет гораздо сильнее в бэкэнде и сделает все эффективней, другой лучше выполнит UI, третий базу данных.
А насчет того, что нужно бизнесу. Бизнесу нужны разработчики, которые понимают бизнес. И способность осмыслить задачу, а не просто переложить ее на циклы и условные ветвления; задать корректные вопросы, уточнить моменты — которые могут быть либо пропущенными аналистом либо вообще некорректно проанализироваными — вот что надо бизнесу.
evil_random
13.11.2018 00:18Редко когда фулстек разбирается и в фронтенде и в бекенде одинаково. Где-то лучше, где-то хуже. Но это не повод гнушаться поправить пару строчек на Яваскрипте, Питоне или ПХП, если не нужно ничего глобально менять.
Обширные знания в смежных областях нужны и важны (если вы только не с ЕПАМа), хотя бы для того чтобы быстро переквалифицироваться если вдруг загнётся абстрактный Яваскрипт.
Меня всегда удивляли фронтенд-разработчики, которые не знают как работает чистый Яваскрипт, как написан тот же Реакт и что он из себя представляет внутри, что надо писать в консоль сервера на Дебиане, каким образом клиент с сервером обмениваются данными, как работают браузеры, ДНС и интернет в целом и т.д.onborodin
13.11.2018 12:57+1>Меня всегда удивляли фронтенд-разработчики
Вы еще не работали с 1С разработчиками.
Вас бы перестали удивляться вообще.
roman_kashitsyn
13.11.2018 01:02Программисты нужны не для того, чтобы хорошо знать «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), но если преимущества (простота в поддержке, эффективное использование ресурсов, лёгкость в отладке) «неидеоматичного» решения перевешивает недостатки, аргумент «так никто не делает» выглядит довольно нелепо.
0xd34df00d
13.11.2018 01:45-1Agda и Idris полезны ещё и потому, что после них куда лучше понимаешь все эти семейства типов, DataKinds, TypeInType и вот это вот всё, короче. И зачем оно нужно.
Так что исключительно практическая польза.
phoenixweiss
13.11.2018 01:26+2Давайте так — а везде ли нужны сеньоры? Какая разница кем работать — главное чтобы на жизнь хватало и работа была в радость, а если есть перспектива развития (не обязательно только карьерного роста), так вообще замечательно!
Тут все от человека зависит, кто-то упарывается в то чтобы быть лучшим специалистом по левой ноздре, но абсолютно не хочет лезть в правую, считая это не его компетенцией, а кого-то больше интересует как работает организм вцелом. Это из детства идет — одни выбирают кружок для досуга и спортивную секцию (или родители чаще всего выбирают) и ходят до победного, а другим интересно попробовать себя в разных сферах. Я вот с детства например занятий 20 точно сменил, и танцы, и автомодельный кружок, и плавание, и рисование, и литературный кружок, и много-много чего еще, а потом отучившись в одном институте понял что не мое, и совсем в другой сфере защитил кандидатскую, потратив дополнительно 7 лет. Мне интересно очень многое, и последнее что будет меня в жизни сдерживать — это какая-то классификация разработчиков. Если даже придется начинать с нуля, менять стек или даже профессию, ничего страшного нет в том чтобы не быть «сеньором» в чем-либо, главное чтобы было интересно (ну конечно если условия позволяют на эти деньги выживать). Очередной вон кризис грянет — и половина сеньоров под сокращения попадут или просто конторы обанкротятся. Меня 2 раза в жизни заставало такое дело, в 2008 (правда тогда не было никаких финансовых обязательств, и за душой тоже ничего, и терять особо нечего) и в 2014 (когда на пару лет пришлось вообще сменить профессию, чтобы тупо выжить и уже было что терять). В общем, каждый решает для себя сам чего ему нужно. Я с основной мыслью статьи не согласен совершенно категорически, однако это не означает что я ее не понимаю, просто не мое. Всестороннее развитие и возможность выбирать его вектор в каждый момент времени — это настоящая свобода для живого мыслящего человека.lxsmkv
13.11.2018 04:17+1С одной стороны есть програмисты на коболе, язык который сечас практически никому не нужен, но остались еще приложения которым несколько десятков лет и которые нужно поддерживать. Вот эти ребята берут трехзначную сумму долларов в час. И по праву.
Однако скольким из них посчастливилось попасть на такой проект и стать единственным незаменимым?
С бытовой точки зрения удобнее иметь широкие пусть и не глубокие познания. Чтобы можно было адаптироваться и переориентироваться в любой момент. Динамика спроса на рынке растет.
У нас сейчас даже так делают, берут одного сениора, пару мидлов и добирают джунами. Сениор и миддл приезжают на проект на пару месяцев, впитывают знания, а потом обучают команду у себя за границей — такой аутсорс и масштабирование. Т.е для рентабельности проекта нужно иметь набор низкооплачиваемых, не загруженных специфическими опытом и знаниями людей. В которых можно закачать что-то при необходимости.
sotnikdv
13.11.2018 02:27+4Продублирую.
— > посмешищем для сорокалетних сеньоров одной технологии
Мне почти сорок. Программить начал в 14. Профессионально — с 2000 года, т.е. 18 лет.
За это время я сменил около десятка языков, около десятка тайтлов и несколько направлений. Сейчас принципал архитектор и СТО в долине и мой бекграунд дает мне хорошее преимущество.
Те, кто прилипли к одной технологии — давно остались позади. Работают за копейки. Посмешише и мастодонты для нас.
Технология устаревает за 3 года, умирает за 5. Нет, зомби на ней копошатся еще лет 10, но суть ясна.
Да, фулл-стек — полон проблем, это ИМХО ложный путь.
Поэтому разделяй навыки на primary и secondary. Primary — то, в чем ты крут, на чем фокусируешься, от чего у тебя на коже проступает свитер, а на свитере ростет борода. Secondary — это навыки, которые ушли из фокуса (outdated) или которые еще не вошли в фокус (upcoming). Таким образом — ты всегда на острие, ты всегда эксперт, ты всегда учишь новое и у тебя всегда за плечами куча знаний.
lxsmkv
13.11.2018 03:10Причём ты всё ещё будешь недосягаемо хуже разраба, который каждый день пишет исключительно на тайпскрипте
Согласен, вот мой основной язык питон, я на нем пишу тестовые скрипты для сквозного тестирования. Я понимаю общую архитектуру нашего приложения, которое написано на яве. Я могу читать код приложения на яве, могу по стектрейсу определить где программа выкидывает ошибку, запустить дебаггер. И даже выяснить источник ошибки.
Но! Решить этот баг я просто не осмелюсь, потому что не знаком с устройством этого конкретного кода. Я не знаю какие побочные эффекты вызовет присвоение переменной в методе, я не знаю из каких разных мест этот метод вызывается и т.д. и т.п. Не имея полной картины устройства этого кода лезть в него глупо и даже, я бы сказал, безответственно.
Т.е. даже знания языка не сделают тебя автоматически разработчиком конкретного приложения. А ведь именно на это надеются кадровики? Что можно будет перекинуть человека с одного проекта на другой. Но сложность-то не во владении языком, а в продукте который разрабатывается. Конечно человек разберется со временем, но далеко не вдруг и не без посторонней помощи.
Но если мне вдруг скажут: «Алексей, сворачивай свой тестировочный лагерь — ты будешь помогать команде разработки писать приложение» — то я втянусь и наверное значительно быстрее чем человек со стороны, потому что есть общее понимание архитектуры. А с кодом можно познакомиться по ходу дела. При наличии боевых задач, обсуждать решения с более опытным разработчиком, делать код ревью, то-сё. И в конце концов точно стать не хуже среднего.
artiom_n
13.11.2018 08:57Как всегда: ещё один, считающий, что Web-разработкой и написанием "бизнес-логики интерфейса", разработка ограничивается.
Теперь, когда мне нужно поработать на каком-нибудь нелепом питоне
Что?
Причём, человек на полном серьёзе рассуждает о том, что "нужно бизнесу" и как подстроиться.
Зачем тогда идти в разработку? Ради бизнеса или "потому что IT — модно"? Так лучше идти в бизнес: солиднее и денег больше заработать возможно.
Berkof
13.11.2018 09:10Знавал я одного чувака, который в качестве решения этой проблемы сказал — «а я выкачу один ЯП, годный для всего»… ждём.
vladoos
13.11.2018 09:26Фулстеки это мидл программисты и одновременно джунер архитекторы. Карьерная лесница для Фулстека не так печальна, но она будет все больше абстрагироваться от кодинга. Если же нет сил или желания становиться манагером или архитектором, то на самом деле никогда не поздно закрыться в любимой технологии и набивать руку в течении двух трех лет и сознательно игнорируя все остально. Не смотря ни на какие ухищрения манагеров заставить вас делать, что-то из всего остального. Два года для мидла более чем достаточно чтобы стать синьером. Мы становимся лучше в том чем занимаемся каждый день. Или как говорил, кажется, Брюс Ли — я не боюсь человека, который знает тысячу приемов, я боюсь того кто тысячу раз учил один единственный прием.
DelphiCowboy
13.11.2018 12:09закрыться в любимой технологии и набивать руку в течении двух трех лет и сознательно игнорируя все остальное
Технологии за годы устаревают.
И потому, если не хотите потом заниматься легаси, имейте запасной вариант.
Для меня, когда Delphi сдох, запасным вариантом стал PL/SQL.
worldmind
А человек, который по-вашему, worldmind, видит и понимает всю картину совсем не нужен?
текущая трактовка термина фуллстэк противоречит всей логике развития цивилизации, которая всегда шла по пути спеуиализации, разделения труда и получала на это профит.
Причина необходимости фуллстэка в том, что типичный проджект-менеджер управляющий сложным проектом со множеством узких специалистов, может их просто не понимать.worldmind
13.11.2018 12:11Конечно нужен, только он совсем другой и нужен в других случаях, я вроде подробно описал.
ktulhu
14.11.2018 06:16когда Delphi сдох
Что вы имеете ввиду?Whuthering
14.11.2018 11:08+2Если вам самому лень, поискал по Hh.ru
Delphi — 143 вакансии
Результаты опросов пользователей StackOverflow, статистику Github и рейтинг TIOBE, думаю, сами нагуглить сможете.
Java — 2098 вакансий
Python — 2126 вакансий
Go — 472 вакансии
С учётом тенденции Делфи к падению спроса думаю вывод очевиден.
И да, давайте не будем устраивать здесь очередной делфисрач и скатываться в занудство, ну честно, надоело уже.pawlo16
14.11.2018 12:13-2рейтинг TIOBE, думаю, сами нагуглить сможете.
Вы бы сами сперва погуглили прежде чем вот так вот взять и сесть в лужу. В tiobe дельфя на 13 месте, обычно в первую десятку входит. и работы на ней более чем достаточно. Рейтинг hh отражает всего то навсего текучку кадров и количество стартапов, связанных с веб. Программисты для десктопа тоже — внезапно — нужны. А на десктопе к вашему сведению дельфя как присовывала всю жизнь java/C# по стоимости разработки и производительности (а с++-у по стоимости разработки), так и присовывает
давайте не будем устраивать здесь очередной делфисрач
Так не делайте необоснованных утверждений впредь, и признайте, что сказали про delphi не подумав.Whuthering
14.11.2018 16:29+2В tiobe дельфя на 13 месте,
Вы так говорите, как будто 13 место — это отличный результат, особенно для технологии, существующей уже пару десятков лет. И особенно учитывая, что...обычно в первую десятку входит.
Не «обычно входит», а «раньше входил» (вполне заслуженно в те года, надо отметить). Сейчас же тренд налицо.
Рейтинг hh отражает всего то навсего текучку кадров
Количество вакансий означает востребованность специалистов, владеющей этой технологией. И, соответственно, перспективы для этих самых специалистов при поиске работы. Одной «текучкой» это обосновать невозможно, поскольку во многих случаях происходит найм сотрудников не для замены ушедших, а для расширения команды или при старте новых проектов. И количество вакансий тут о многом говорит.
и количество стартапов, связанных с веб.
Что, кстати, тоже примечательно показывает спад спроса на десктопную разработку по сравнению с вебом. Вплоть до того, что очень многие современные информационные системы (банковское дело, медицина и т.д.) сейчас по умолчанию имеют веб-морду как интерфейс, а не десктопное GUI-приложение.
А на десктопе к вашему сведению дельфя как присовывала всю жизнь java/C# по стоимости разработки и производительности (а с++-у по стоимости разработки), так и присовывает
И этот человек мне говорит «не делайте необоснованных утверждений». Смешно.
присовывает
Термины уровня чотких дворовых пацанчиков на хабре. Внушает.
и признайте, что сказали про delphi не подумав
Изначально про «сдох» сказал не я, а хабраюзер DelphiCowboy, судя по нику, в прошлом сам заядлый дельфист (как и я, кстати говоря).
За сим откланиваюсь и перестаю отвечать в этой ветке. Не вижу смысла замусоривать Хабр холиварами. Я все-таки просил не разводить срач, а вы его упорно пытаетесь начать.pawlo16
14.11.2018 18:31-1Вы так говорите, как будто 13 место — это отличный результат
Это значит что утверждение «Delphi сдох» — брехня
Не «обычно входит», а «раньше входил» (вполне заслуженно в те года, надо отметить)
Год назад был на 9-м месте. Стало быть, за год всё круто изменилось. Когда рейтинг тиобе стал двузначным — делфи взял и сдох.
сейчас по умолчанию имеют веб-морду как интерфейс, а не десктопное GUI-приложение.
К чему здесь эти рассуждения и что именно вы сейчас доказывали?
И этот человек мне говорит «не делайте необоснованных утверждений». Смешно.
Истинность моего утверждения ни кто и не оспаривал чтобы мене его обосновывать
Термины уровня чотких дворовых пацанчиков на хабре. Внушает.
У дворовых поцанчиков меньше бреда и каши в головах, чем у некоторых хабровчан
Изначально про «сдох» сказал не я, а хабраюзер DelphiCowboy, судя по нику, в прошлом сам заядлый дельфист (как и я, кстати говоря).
То есть вы с ним не согласны? в таком случае не понятно к чему был ваш комментарий про Hh.ru и tiobe
Я все-таки просил не разводить срач, а вы его упорно пытаетесь начать.
Вы что, вахтёр, бегающий по веткам комментариев в поисках срача? В таком случае поясните, по каким признакам вы его обнаружили у меня. Я отнюдь не дельфист как могло бы показаться. Но с дельфями сталкивался, и бонусы, которые они дают, знаю. В частности, про вещи, типа «treeview с данными», которые в дельфи сделаны идеально, в гопнете как-то «так». Просто кое у кого вечная паника при слове Delphi/Pascal. Меня это слегка коробит, потому и тригернуло высказывание про дельфи сдох. А вы тут же — срач…
ktulhu
14.11.2018 20:04Если вам самому лень, поискал по Hh.ru
Вам другой юзернейм, в принципе, уже ответил.
От себя добавлю:
1. Измерять что-то количеством ваканский, конечно же, можно, только выводы оно в реальности даст не те, которые вы хотели бы видеть. Т.е. можно сказать, что «по Delphi количество вакансий в Х раз меньше, чем по Y». Да и это будет ерундой, потому что нужно учитывать время, сезонность (да-да! отчеты финансовые никто не отменял), срезы и т.п. И уж точно говорить, что Delphi умер — это, мягко говоря, малограмотно.
2. В Северной Америке дельфистов разбирают моментально. Не потому, что они супер и технология крутая, а потому что в нем можно делать отчеты быстро. Что не дот-комы очень любят. А когда они еще и видят, что тот же отчет можно выкатить в виде мобильного приложения без особых на то усилий, то владельцы бизнесов плевать хотели на какой именно модной технологии оно сделано и сколько вакансий опубликовано.
3. Исходя из п.2, в той же Северной Америке часто хотят секретарей и прочих непрямых ИТ-работников со знаниями Делфи от секретарш до сейлзов. Индустрии, где любят Делфи: retail, hospitality и пр., связанное с конечным потребителем.
Ну и confirmation bias никто не отменял.
не будем устраивать здесь очередной делфисрач
А что вы хотите, чтобы было если кто-то пишет космических масштабов глупость, опираясь на собственные ощущения и российский портал hh.ru? Или, что одна технология лучше другой, например, тот же Ruby хуже Delphi, потому что он на несколько позиций ниже в рейтинге популярности языков программирования.Whuthering
15.11.2018 11:19одна технология лучше другой
подождите, про «лучше» или «хуже» вообще ни слова сказано не было, вопрос был только в актуальности на конкретном рынке.
тот же Ruby хуже Delphi,
опять же, не «хуже», но популярность свою за последние годы тоже очень сильно подрастерял.
vladoos
14.11.2018 20:53Технологии за годы устаревают.
Смотря какие технологии. Специализация это конечно же риск, но не всегда. Например Java и С++ намного старее, но они до сих пор актуальнее всех прочих. И да, конечно, нынешняя Java и то что было 20 лет назад это совершено разные вещи. Но ведь никто не говорит, что нужно перестать изучать новое. Просто если ты развиваешься вместе с технологией, то ты всегда будешь оставаться актуальным, и при этом не выпадать статуса сеньера. Поэтому не все так печально. Не нужно делать вид, что технологии это битва на вылет, где одна технология убивает другую. Иногда такое происходит, но не потому, что кто-то кого-то убил, а потому, что технология не смогла эволюционировать достаточно быстро под новые условия, и умерла своей смертью. Пример с Delphi как раз самый яркий. Они застряли на вершине своего развития в своем славном прошлом где-то в середине нулевых, и до сих пор там топчутся. Но пока они полностью не умерли то никто не исключает вероятности их новой инкарнации. Но очевидно, что если это произойдет, то это будет совершенно новая Delphi в которой старый опыт будет уже не актуальным, и все придется начинать с начала.
Sad_Bro
13.11.2018 10:14Согласен с автором. Сейчас есть тенденция на человек оркестр, но какая будет эффективность такого разработчика не думают.
Автоматизатор, ок, будь добр настрой CI, подучи Ansible, и не важно что на реализацию этой задачи ты потратишь на пару недель больше чем нормальный девопс и скорее всего родишь не поддерживаемого уродца.
enjoykaz
13.11.2018 10:23Фулстечности программиста будет достаточно для менеджера? Ну что же, это будет неплохим стартом и можно даже получить титул Middl Project manager и уважение в лице разработчиков команды. Но дальше разобраться еще как минимум придется в маркетинге (PPC, SEO, SMM, копирайтинг), продажах, дизайне (UX/UI), аналитике (GA, Unit-экономика), HR и методологиях управления проектами. Разобраться естественно будет мало и нужно будет уметь ручками это делать самому и делать регулярно, как минимум для того чтобы дизайнеры, маркетологи, аналитики, продажники не закатывали глазки, когда получают свои задания от менеджера, а как максимум потому что людей с этими ролями в команде нет и делать нужно все самому. Еще скорее всего придется стать экспертом в предметной области, которой работает компания. Что еще? Еще зависит от компании. Возможно потребуется время пройти разные гавнообучения и сдать экзамен на PMbok или упаси Господи вступить в секту Agile и через 10 лет плясок тамадой стать Agile коучем.
Все ли менеджеры такие? Конечно нет, но я же не думаю, что автора устроит быть гавноменеджером с узкими и поверхностными знаниями и нормально разбираться только в разработке, при этом пойти сходу на понижение ЗП, а для всех других ролей в команде оставаться вечным неучем и безруким, который даже не может настроить рекламную кампанию за пару часов.
А, ну собственно к чему это я. Рассказываю, что менеджером быть сложнее, чем программистом? Нет, я не преследую цели сравнивать вообще. Это может делать человек, который и в той и в той области добился больших успехов. Я говорю о том, что фулстечность это бич не только разработчиков и убегая от нее в коде можно попасть в ловушку фулстечности в управлении
greabock
13.11.2018 10:34Мужик явно запутался.
Фуллстэк — это относительная характеристика, говорящая о том, что исполнитель обладает (ну или, как минимум, заявляет что обладает) всеми необходимыми компетенциями чтобы полностью разработать продукт определенного класса от начала и до конца.
- Фрилансер клепающий сайты "под ключ" — фуллстэк.
- Вебстудия делающая тоже самое — фуллстэк.
- Отделочник по найму, который делает полный ремонт квартиры — фуллстэк.
- Сторительная компания, которая делает тоже самое — фуллстэк.
А теперь внимание: Если отделочник по найму, умеет делать всё, кроме укладки керамической плиты на потолке по диагонали в шахматном порядке, то он вынужден будет нанять отдельного специалиста. Аутсорс, как сейчас модно говорить. И пока он не перекладывает заботы по поиску такого специалиста на заказчика — он всё еще фуллстэк.
Если единственное, чем вы занимаетесь, это ловите проекты на фрилансе, а потом разделяете их на задачи и делегируете эти задачи соответствующим специалистам, при этом сами вообще не программируете, то вы (внезапно) тоже фуллстэк.
А теперь что касается, Junior, Middle(?) Senior.
Понятия Junior, Middle, Senior отражают уровень компетенций (нет).
То есть: они отражают, но не совсем так как многим кажется.
Стоит ли удивляться, что джуны, которых набирают в какой ни будь гугл, хотя и не имеют практического опыта* (или имеют но мало) разработки, способны запросто заткнуть за пояс в вопросах computer scince** любого "синьора-помидора" работающего в мелкой конторе.
Это скорее ранг внутри команды, чем уровень "крутости" специалиста.
Что же касается самой статьи… Если называть вещи своими именами, то всю ее можно свести к вот такому выражению :
Стать профессионалом широкого профиля — легко, специалистом узкого профиля — сложнее, специалистом широкого профиля — почти невозможно.
* Или имеют но мало.
** Я не говорю "информатика", потому что это слово вывернула на изнанку российская система образования.
Ungla
13.11.2018 10:46А что пост заплюсованный такой? Человек изобразил своё виденье себя же самого. Обобщив всех под одну гребёнку.
dididididi
13.11.2018 10:53Люди, которые ковыряют самое дно ЯП, и люди, которые каждые полгода меняют технологию одинаково печальны.
Фуллстек — это человек который знает js+фреймворк(react, sencha ...)+css и какой-то из языков backend(java, python...)+ БД+общее знакомство c devops.
Естественно, у каждого уклон свой, у меня умный java-бэк, тупой фронт; другие поднимают graph ql+ круд-плагин для постгрес, а весь код пишут на js, потому что js им удобней, БДшники все на процедурах и триггерах напишут.
Без разницы, как именно ты напишешь приложение, лишь бы быстро и качественно. Нужно задействовать по максимуму свои сильные стороны для достижения результата.
И самым спорным решением конечно будет писать приложение на реакт+жава+монга, если ты знаешь ангуляр+пайтон+постгрес.Neikist
13.11.2018 10:54+1И вы туда-же… Кроме веба вообще то и другая разработка есть. И подразумевается что фуллстек может еще и мобилку написать нативную например, и десктоп приложение, и под мк что то набросать…
VolCh
13.11.2018 11:31Это, по-моему, уже не фуллстэк, а универсал. Фуллстэк предполагает полный стэк от клиента до СУБД, если брать трехзвенку. Он не предполагает, например, написание пяти различных видов клиентов, включая МК. Полный стэк не означе все стэки.
biilsun
13.11.2018 10:56Большинству не крупных компаний сеньоры не нужны тем более если их несколько штук необходимо по разным технологиям, им достаточно адекватный мидл full-stack который порешает конкретные задачи пускай даже не самым эффективным способом и без использования самых последних модных технологий.
worldmind
13.11.2018 10:59На самом деле, в стародавние времена, когда появился термин full-stack разработчик, под ним подразмевался не человек-оркестр, который фигарит на всём, что нужно в данную секунду, а человек, который понимает весь стек технологий начиная от своего языка программирования и далее вглубь до самого процессора.
Такое понимание нужно, чтобы решать нестандартные проблемы, которые возникают, когда абстракции начинают протекать.
А потом, всякие бестолковые конторки испортили термин.worldmind
13.11.2018 11:01И понятно, что текущая трактовка термина фуллстэк противоречит всей логике развития цивилизации, которая всегда шла по пути спеуиализации, разделения труда и получала на это профит.
ZAMnoTEX
13.11.2018 11:17Проблема в том, что бизнесу нужны фулстеки
— Это российскомумелко-среднемубизнесу нужны фуллстеки (почему зачеркнул? потому что в крупных не-IT компаниях так же). Попробуйте поработать в зарубежной IT-компании. Там четкое разделение ролей, нужны узкие специалисты с глубокими знаниями. Может быть, не везде. Но я ушел из такой компании в том числе и потому, что надоело заниматься одной очень узкой вещью.
Zoolander
13.11.2018 11:34Спасибо за статью, но теперь очень хочется увидеть статью про тот самый "дизайн на абстрактных классах в typeScript", чтобы понять, что произошло. В комментариях выше уже обсудили, но непонятно, что имеет в виду автор. Может быть, выложите хотя бы код на Гитхабе, чтобы можно было посмотреть? А лучше статью, чтобы можно было уютно посидеть в комментариях и ознакомиться со взглядами всех экспертов )
Mabusius
13.11.2018 11:43Все фуллстакеры, которых я встречал, были на самом деле фронтами, которые просто не ссали лезть в бекенд. По вакансиям, что я рассматривал, тоже самое — под «фуллстак» всегда подразумевался фронтенд, просто в компании как класса не было бекендеров и брать их они принципиально не хотели, используя на беке только типовые решения. ИМХО фулстакеры это миф. Уверен какойнибудь ушлый рекрутер и меня бы в фуллстакеры записал, ведь я тоже могу, в случае конца света, и фронт собрать из говна и палок.
aensidhe
13.11.2018 11:50Ты везде будешь свой, но везде среди чужих. Несмотря на твои огромные усилия, каждый знаток конкретного языка будет с пеной у рта доказывать, что ты не достоин называться сеньором. Ты станешь вечным мидлом.
Быть сеньором != знать спецификацию языка наизусть.
javamain
13.11.2018 12:10Ну мне кажется что это просто свинство не рости из джуниора в сеньора. С самого начала можно сказать что у сеньора всегда были корни джуниоров. Хотя не у всех, многие были сеньорами с самого начала.
ekubyshin
13.11.2018 12:14Мне кажется автор рассказывает о своем неудачном опыте быть крутым разработчиком. В моей жизни я видел несколько примеров успешных разработчиков, которые хорошо могли кодить на разных языках и при необходимости решать задачи на разных рубежах.
Как один из примеров — 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 лет у некоторых сениоров в голове возникает мысль, что он получил достаточно опыта и знаний в конкретной области и языке и появились новые знания и силы, чтобы попробовать себя в чем-то другом. Все это конечно при условии того, что разработчик постоянно развивается и познает новые вещи в мире программирования, а не просто пишет код на одном и том же и делает однотипные задачи на своей постоянной работе.
olegfil
13.11.2018 12:27Не отчаивайтесь — вы еще так попрыгаете по технологиям, потом поймете что у разработки ПО есть тоже свой уровень абстракции, слабо зависящий от технологий, заинтересуетесь им и станете архитектором :)
HellWalk
13.11.2018 12:36Работаю с сайтами с 2007 года, прошел путь от недоспециалиста на все руки под названием «веб-мастер» (который не только фулл стек, но еще и в дизайн, и в SEO, и в контент может), затем перешел в чистые программисты (фулл стек), затем, в чистый бек — каждый раз моя зарплата вырастала, а работа становилась комфортней.
Полностью согласен с автором — на рынке труда ценятся специалисты высшего уровня. А чтобы стать таким специалистом нужно долгие годы сидеть в одной узкой сферы. Хотя, какой узкой, даже бек часто совмещает в себе несколько специалистом — программист, спец по БД, админа по поддержке серверов.
Сколько бы я, бек, не читал книжек по Linux, я никогда не стану таким прошаренным в настройке и поддержке веб-серверов как профильный админ, который годами, целыми днями, только этим и занимается.
Mycolaos
13.11.2018 12:39Во-первых, было бы хорошо иметь более подробную информацию об опыте автора. Где и сколько учился, где и сколько работал, с какими технологиями и на какой позиции.
Во-вторых, со статьи кажется, что проблема в слишком большом разбросе используемых технологий – соответственно в поверхностном подходе. Все же «фуллстэк» тоже может быть специализирован.
prokubyshin
13.11.2018 12:55Мне кажется автор рассказывает о своем неудачном опыте быть крутым разработчиком. В моей жизни я видел несколько примеров успешных разработчиков, которые хорошо могли кодить на разных языках и при необходимости решать задачи на разных рубежах.
Как один из примеров — 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 лет у некоторых сениоров в голове возникает мысль, что он получил достаточно опыта и знаний в конкретной области и языке и появились новые знания и силы, чтобы попробовать себя в чем-то другом. Все это конечно при условии того, что разработчик постоянно развивается и познает новые вещи в мире программирования, а не просто пишет код на одном и том же и делает однотипные задачи на своей постоянной работе.
К сожалению, автор, видимо пошел по другому пути.
1Tiger1
13.11.2018 13:18+1Может я не верно понял статью но сложилось ощущение что автор все завязывает на «знания».
Простите, но знания не определяют уровень специалиста, практически в любой области.
Важет подход к решению задач, уровни абстракции, опыт и извлеченные из него практики. По сути уровень разработчика определяется тем как он мыслит.
Мы программисты решаем задачи с помощью кода. Сам код не особо важен, он инструмент. «Так не делают в… языке/фреймворке» — не аргумент. «Так мы не делаем, давайте придерживаться общих практик чтобы удобнее было писать код вместе» или «Так не стоит делать потому что с этим будут вот такие-то критичные проблемы» — это аргументы. Надеюсь разница понятна.
Синьор это не насколько детально знает человек язык, и не насколько много языков он знает, это насколько хорошо он применяет эти инструменты для решения нужных конкретных задач.
Ну это как готовясь к выступлению на конференции основное внимание уделять разминке дикции и повторять грамматику языка на котором говоришь, вместо того чтобы готовить материал.
«Я не знаю, что там за типы индексов в SQL.» — главное что вы знаете что они есть и разных типов и на что влияют индексы, а дальше просто ищем информацию и работаем. Если появится новый тип а вы об этом не узнаете вы что резко потеряете свою квалификацию?
«Бам! Забыл, когда вызывается статический конструктор в шарпах.» — о ужас, и что? провалите экзамен или собеседование где вас спросят «когда вызывается статический конструктор в шарпах»? Как это повлияет на реальную разработку на реальном проекте, одноминутной задержкой, одним запросом к гуглу или к мануалу?
«Упс! Я не могу правильно реализовать IDisposable без гугла» — та же ерунда, ну зачем без гугла, главное что вы знаете зачем это и что за собой потянет, а как реализовать можно и почитать.
«Пытаюсь мутировать стейт в реакт компоненте.» — вот это уже плохо. Хотя насколько плохо я не знаю, с реактом плохо, по нулям, но судя по контексту вы используете паттерн не по назначению и применяете его там где технологически не нужно или невозможно. Вот как раз знания чем что лучше делать и понимание как это лучше делать и определяют синьора. Архитектор поднимается на уровень абстракции выше и ему уже точно детали языка не нужны.
Простите за аналогию:
Джуниор умеет держать молоток и бить по гвоздю (иногда надсаженному).
Миддл умеет самостоятельно забивать гвозди куда скажут и часто уже понимает где они нужны, а так же и шурупы умеет вкручивать и клеем пользоваться. Может проконтролировать насколько хорошо джун забил гвозди, насадить, помочь если гвоздь согнулся.
Синьор знает куда нужно забивать гвозди и почему, а что лучше шурупами скрепить, а что склеить, а может тут стоит вспомнить старое и взяться за заклепки или наоборот попытаться использовать новейший суперклей. Понимает плюсы и минусы и области применения каждой из этих технологий скрепления материалов. Поможет мидлу указав что гвоздь вот сюда забить стоит, а вот этим 5 шурупам тут совсем не место, и джуну рассказав 5 способов зделать правильный замах молотком. Ну и главное он уже знает что результат важнее процесса, задача важнее кода, а все вокруг это не самые лучшие в мире и самые любимые молотки и лобзики а просто инструменты для создания продукта.
Архитектор знает что с чем скрепить и какой формы вырезать доски чтобы сделать этот сковречник, может это рассказать и даже нарисовать. Сам уже с трудом помнит как работать молотком или шуруповертом и чем винты отличаются от шурупов, про новейший суперклей слышал, но в его химический состав не вдавался, ограничился стоимостью, областями применения, скоростью засыхания и прочностью крепления, просто чтобы знать какие возможности он дает.
Тим лид задает настроение чтобы всем было комфортно делать этот скворечник, периодически извиняясь и обьясняя что требования к скворечнику поменялись и теперь вход нужен не круглый а прямоугольный и меньше чем был, и птичкам нужно остекление в пол. А так же ругаясь на запоротые доски и гвозди и потерянное время, и за то что крышу не успели доделать. Гвозди или шурупы не самая главная его задача но он все же был синьором и частично совмещает и сейчас, так что может то же что и синьор (но не факт что то же что и архитектор), хотя может про суперклей и не слышал, не хватило времени.
Ну продолжать можно долго. Главное что ни одному из них не нужно знать на зубок детальную информацию по гвоздям, их видам, размерам, составу, способу производства, как и не нужно знать как их красиво метать в дерево и что с помощью гвоздя и пластиковой бутылки можно сделать поливалку для мангала. Если надо все это можнно загуглить, почитать в справочнике или же это очень узкие области которые в создании скворечников не пригодяться а при создании табуретки можно и почитать опыт табуреточников, главное понимать что гвоздь острый, молоток тяжелый, скреплять материалы можно разными способами и разбираться в дереве и сопромате.
Еще раз извиняюсь за аналогию.hardmodebitch
13.11.2018 14:05Я согласен с вашей аналогией.
К несчастью, на собеседованиях чаще всего спрашивают именно про типы гвоздей и просят собрать табуретку у них на глазах, не пользуясь клеем и не заглядывая в справочники.1Tiger1
13.11.2018 15:51+2Ну и отлично. В таких случаях я понимаю что тот кто собеседует подходит к разработке по другому или просто не умеет собеседовать и ему не хватает опыта. Что им важен код а не результат. Обсудим, расскажу свою точку зрения. Не захотят слушать — значит нам не по пути. Плюс тут в том что прямо на собеседовании виден подход и не будет потерь времени и разочарований. Да таких большинство, чуть ли не тупо по списку идут. Если такие вопросы в духе «напишите код» или «что будет в результате выполнения этого кода» идут только по мелочи, или только для того чтобы развернуть беседу или как дополнительный фильтр — пожалуйста. Если они основные и главные — мне с такими не по пути, я не справочник чтобы все знать, и «справочники» в команде мне не нужны, у меня интернет для этого есть, важно уметь обрабатывать информацию а не помнить ее.
alsii
14.11.2018 17:10> К несчастью, на собеседованиях чаще всего спрашивают именно про типы гвоздей и просят собрать табуретку
Тем хуже для них. Они не пройдут собеседования.
hippoage
13.11.2018 13:21С одной стороны интересный терми «мультимидл», с другой стороны он не до конца верен. Все-таки такой человек лучше мидла и очень быстро приближается к сеньору по мере работы в одной технологии (скажем, где-то 6 мес, а после этого вполне тяжело отличить от сеньора). Время уходит на ментальную перестройку под платформу и обновление знаний. Плюс, кругозор позволяет время от времени гораздо эффективнее решать задачи, так что это вполне покрывает эффективность реального узкого сеньора (не просто по годам).
На каждой платформе (нечто более узкое, чем просто яп) нужно писать в соответствии с практиками платформы. Это да, важно осознавать. Так же важно понимать, что ментально работа на UI и бекенд разная: разные вещи важны. Нужно осознанно перестраиваться. Внутри одной недели делать разное с качеством сеньора не получится.
Мультимидлы хороши в аутсорсе и малых компаниях: там важно иметь реальную возможность перебросить человека с бека на фронт и наоборот. Оплачивается в таком случае не хуже сеньора, даже если вполне реальный мидл, а не мультисеньор.
Из мультимидлов получаются мультисеньоры, а потом архитекторы, т.к. им обязательно иметь кругозор.
Если человек средних способностей, то не нужно ему идти в мультимидлы, т.к. это гораздо сложнее с точки зрения «вычислительных» затрат человека, но легче с точки зрения мотивации.
Важно так же понимать, что 90% сеньоров в одной технологии особо много не знают, т.к. чем дальше учишься, тем прогресс слабее, а большинство вообще бросает это дело. Так что с точки зрения работодателя в среднем человек, который владеет несколькими технологиями гораздо лучше обучен (будет писать более поддерживаемый протестированный код с меньшим количеством багов, хотя и может что-то редко упустить в особенностях платформы), чем человек в одной технологии. Но ещё не все так считают: обычно отбрасывается «в среднем» и пытаются найти исключение.
gotz
13.11.2018 13:42+2Автор, вы упустили очень важный момент в своих выкладках. Все программные проекты, за которые платят деньги, можно (довольно условно) поделить на системные и прикладные.
Если вы пишете сложный системный проект вроде высокопроизводительного драйвера для СУБД — вы просто должны быть синьором в определенном языке, протоколе взаимодействия и прочих вещах. Погрузиться с головой в детали. Бывает, что на это требуются годы.
Когда вы работаете с проектом в прикладной области (екоммерс, веб, мобайл) — вы пользуетесь наработками системных кодеров и здесь скорее полезнее иметь общий кругозор и просто следовать лучшим практикам, которые принято использовать в рамках данного фреймворка, библиотеки, стека. Если кругозор уже есть, погрузиться в эти нюансы не так сложно, за пару месяцев вполне можно. На уровне миддла вы будете писать продукты примерно того же качества, что и синьор.
Выбирать можно любой путь, я бы не стал оценивать, кто круче или где интереснее работать. На этом шарике размер чека зависит не от визитки Senior / Full Stack, а скорее от сферы работы, компании и стека. На данный момент самыми дорогими техническими спецами в ИТ вообще являются девопсы.
norlin
13.11.2018 14:16Фуллстек – это про область применения, а «миддл/сеньёр» — это про уровень знаний. Намешали тёплое с мягким, приправили личным мнением… Не делайте так, пожалуйста.
Фуллстек может быть и джуном, и миддлом, и сеньёром. Очевидно, чтобы стать честным фуллстек-сеньёром, надо уметь каждую из входящих в «фуллстек» технологий на уровне сеньёра.VolCh
13.11.2018 18:15Тут, скорее, про то, что имея лычку "фуллстэк сеньора" по факту будешь соответствовать миддлу по каждой из технологий своего стэка.
norlin
13.11.2018 18:24+1Это уже вообще что-то крайне субъективное и личное.
Я вот считаю наоборот – «фуллстек» лычка не может превосходить минимальную «среднюю» лычку по технологиям. Но это всё сильно расплывчато, нет же никаких точных критериев оценки скиллов.Fesor
13.11.2018 20:54+1фулстэк подразумевает более широкий но менее глубокий скоуп знаний. Банально в силу того что за всем уследить вы не сможете. Да и "фулстэк фулстэку" рознь. Ну и даже если вы носите гордое звание фулстэка это не отменяет специализацию.
Например мне не составляет труда напилить какой-нибудь фронтэндик, поднять класстер серверов и т.д. но я прекрасно понимаю что моя специализация все же бэкэнд. И тот факт сколько времени я могу уделять развитию сильно сказывается на уровне "сопутствующих знаний".
Ну то есть я вижу проблему с тем что понятие "фулстэка" у всех разное. Знать все невозможно. Но оно и не нужно обычно. Достаточно знать много, а копать вглубь только при необходимости.
weiser
13.11.2018 15:52Работал я как-то с фулстеками.
Один (тимлид) не знал где находится в проекте папка node_modules.
Второй — задевелопил фичу, изменив исходный код пакета в локальном node_modules и закоммитил всё это (проапдейтив .gitignore конечно же).
Случаи смешные, а ситуация страшная.
kubk
13.11.2018 23:37+3Это не фуллстеки, а некомпетентные разработчики.
weiser
14.11.2018 08:46Одно другого не исключает. Но я бы сказал, что некомпетентных фуллстеков больше просто потому, что зона отвественности (читай компетентности) у них априори должна быть шире чем у узкого специалиста. Вот и доходит до вот таких вот «диких» случаев, которые я описал выше. Ведь сложно представить фронтендера (скажем шире — JS девелопера), который бы не знал, что такое node_modules и как с ней обращаться, верно?
VolCh
14.11.2018 16:14Легко.
weiser
14.11.2018 16:36По себе судите?
VolCh
14.11.2018 17:12+1Наоборот. Как бэкендер с концепцией пакетных менеджеров стал знаком задолго до появления ноды. И даже с самой нодой познакомился раньше, чем она начала просачиваться на фронтенд. Если фронтендер не работал с пакетными менеджерами вообще, и с npm в частности (а это вполне реально в нескольких сценариях), то я, как фуллстэк девелопер с уклоном в бэкенд, по вашим меркам, получается «сеньористей» фронтендера, который наизусть помнит все WebAPI's и, до кучи, почти не ошибается, когда говорит с какой версии IE тот или иной поддерживается и есть ли полифилл для более ранних. А это явно не так.
Fesor
14.11.2018 19:06сложно представить разработчика который с node работает (а на нем можно и бэк писать, и просто юзать тулы написанные и дистрибьютящиеся через npm) не знать что такое node_modules.
Ну а на тему изменения серд парти — это может намекать только на то что ваши разработчики никогда не работали с менеджерами пакетов. Что странно в наши дни.
Так что нет, это вопрос не в фулстэк/не фулстэк. Знания необходимые что бы не творить такой черни на 90% проэцируются из любых других языков.
math_coder
13.11.2018 18:03+1> Упс! Я не могу правильно реализовать IDisposable без гугла.
Реализовывать IDisposable без гугла — это уровень джуниора. Миддлу неплохо бы понимать, что IDisposable реализовывать вообще не надо.Ivanus_1
13.11.2018 23:37Что значит не надо, или я уже скатился до уровня джуниора. а если у меня в классе private переменная которая требует удаления сразу после использования?
math_coder
14.11.2018 09:12Что это антипаттерн, и что в современном 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>)
riky
13.11.2018 21:24+1зато будучи фуллстеком классно свои проекты поднимать (или с партнерами).
VolCh
13.11.2018 22:17Или обучать, хоть фуллстеку, хоть какой-то одной или нескольким технологиям из стэка. Грубо говоря, пока фронтендер будет учить своих учеников на статических сайтах, фуллстэк сервачок какой-то поднимет, чтоб динамика была.
toruk0109
14.11.2018 07:58Лично для меня fullstack разработчик — это такой человек, который знает такой набор технологий (и активно их использует), чтобы с помощью него было возможно одинаково продуктивно работать на стороне фронта и на стороне бэка. Описанное в данной статье больше походит на манию величия самого автора и погоню за детской мечтой «Знать все и обо всем», но отталкивается от какого-то своего понимания, что есть fullstack.
WeltRogg
14.11.2018 10:00full-stack это все еще ерунда по уровню нагрузки. Так как разработка сама по себе нуднятина (особенно если не для себя делать проекты), то я понял что меня тенет к творчеству, поэтому пришлось часть времени своей жизни отвести на рисование иллюстраций и работу с видео в affter effects, анимацию и написание музыки. Вот и получается что за весь день прерываюсь только на еду и поездку домой ну и хоть какой сон само собой.
Neikist
14.11.2018 10:26Так как разработка сама по себе нуднятина
рисование иллюстраций
когда нибудь тоже хочу заняться, когда программирование и математику подтяну, не зря в детстве почти год в художку ходил XD.
А пока хватает и программирования с двумя языками иностранными, даже математикой заняться не выходит)) Правда я сейчас в процессе спрыгивания на другую технологию, и это занимает от 2 до 6 часов свободного времени каждый день, когда по новой технологии на работу устроюсь может получше будет)Neikist
14.11.2018 14:04Кстати, обнаружил что не дописал
Так как разработка сама по себе нуднятина
— я так не считаю, но на мой взгляд свободное время хотя бы процентов на 50 не разработкой разбавлять все равно стоит.
SmilePic
14.11.2018 13:29Вы полагаете, среди специалистов в конкретной области это реже встречается? Интересно было бы собрать статистику. У меня в соседнем окне на это же ругается адовец со стажем…
Sergei_Erjemin
14.11.2018 12:00+1Все это хорошо, и возможно, правильно… Но только если вы планируете всю жизнь работать в найме!
А вот если фонтанируете бизнес-идеями, запускаете собственные проекты и т.п., то и фулстек-разраба маловато будет! Захочется изучать журналистику, дизайн, маркетинг, экономику и еще тонну всего. И вот представляете какая депрессияи аут, когда ваш проект «не полетел»??? Вы ж не то что там, мидл! Вы вообще ноль во всем!
Вроде и портал-ценовой-агрегатор-с-биллингом-и-блекджеком полностью закодить можете, и статью можете на уровне Эксперт/Коммерсантъ, и дизайн, и экономику проекта рассчитать со всеми сопутствующими исследованиями, кеш-флоу, дисконтированием, IRR, P/E и P/B на пятилетку… Да только PM, таких порталов штук пять одновременно волочёт… Кодер его запилит за месяц, а не за год… Штатный корреспондент из Ъ таких как ваша статья по две в неделю сдаёт, а ты одну со скрипом за полмесяц… Дизайнер по пять логотипов в день стругает и по пять вариантов каждого… Аналитик венчурного фонда по 20 проектов в неделю дьюти-дилинжит… А ты. по сравнению с ними, вообще детсадовец против Крепкого Орешка! Что ж теперь, такому широкопрофилю?.. Стреляться? Нет уж! Лучше ощущать себя д'Артаньяном… просто пока у вас всего 20 пистолей в кармане, странная лошадь из Мэнга над которой все ржут, и в добавок вообще не земляк де-Тревиля и про него даже и не слышали. :))
yakovenkoroman1993
14.11.2018 13:29-1«Я, конечно же, сделал вид, что просто мои коллеги — бездарные идиоты» — не много смущает такое отношение к команде, но дело Ваше. А что касается, фулл или не фулл, то для проекта лучше, если человек на старте знает какую-нибудь технологию, нежели только одну и глубоко. Компании будет проще зарядить такого фуллстэк разработчика на новую задачу, чем искать нового узкого специалиста для этой конкретной задачи. При том, что не факт, что такие задачи еще возникнут в ближайщем будущем. Касаемо, мутаций в реакте, то уверен, что разработчик даже поверхностно не смотрел документацию и рекомендации. Так даже и фуллстэк не делают.
k06a
14.11.2018 14:13+1Соболезную, что понял всё только потратив кучу собственных лет на это дело. Возможно твоя статья поможет многим заранее осознать на что они идут.
Я лично всегда кодил на том, на чем было вкайф, сначала 5 лет плюсы, потом несколько лет шарпы, потом на пяток лет двинул в iOS, сейчас второй год занимаюсь блокчейном, в каждую технологию погружась глубоко и получается в итоге довольно быстро переходить (буквально за пару месяцев). Ведь пока путешествуешь по этим областям все-равно копится огромный багаж фундаментальных знаний: структуры, алгоритмы, криптография и множество других.
bro-dev0
14.11.2018 21:01Знать несколько яп на высоком уровне это не быть фулстком, есть бизнес задачи которые требуют стек специалистов и если 1 чел способен решить их всё в 1 лицо он называется фулстеком.
Термин набрал популярность с развитием фриланса, когда 1 чел мог заменить студию и сам сделать бриф дизайн сверстать и интегрировать на кмс, и поддерживать дальше сайт, но в целом можно не только к ит применить, если челу заказывают шкаф, он сам приедет измерит спроектирует начертит выпилит и смонтирует то он тоже будет фулстек.
Ими выгодно быть, и бизнесу выгодно их нанимать когда задача условно занимает 1 человеко месяц, связано это с тем что человек в команде будет работать заведомо медление, так устроена жизнь, будут тратить время на коммуникации и максимум при гении менеджере-тимлиде можно достичь 0,9 эффективности от человека, а может быть и 0,5, то есть 2 будут работать как 1.
С другой стороны если задача будет на 10 человеко лет, то смысла заказывать её у 1 человека нет, тогда и нужны команды.VolCh
14.11.2018 22:59Команды тоже могут быть внутри фуллстэчные. И это выгодно бизнесу, если у него много задач на условный 1 человеко-месяц, слабо пересекающихся друг с другом и с непредсказуемым соотношением фронт-бэк
paratagas
14.11.2018 23:43Работодателю, особенно если это маленькая студия, очень выгодно держать фуллстэков. Он и бэкенд напишет и фронтенд. Часто еще и функции devops'а выполняет: сервак на облаке развернуть, настроить, БД, роли, все дела. Если разработчику это интересно, то все ОК. А если нет? Если ему нужно постоянно читать по выходным доки (ну что тебе стоит? пару вечеров же!). На бэкенде развиваются фрэймворки, по крайней мере, экосистема PHP и Python точно шустро идет вперед. На фронтенде их вообще зоопарк, и каждый день новый. Вчера новый VueJS, сегодня хуки и профайлеры в React, завтра новый Angular. А еще БД. Только SQL джойны и транзакции освоил, давай-ка NoSQL почитай. Вот тебе MongoDB, вот тебе Cassandra. А еще давай-ка репликации подучи, Linux, HTTP, естественно. Итого 5 языков (например, PHP, Javascript, SQL, HTML, CSS); 2 фрэймворка или библиотеки (например, Laravel и React). Немного Bash и HTTP. Немного дизайна и общения с заказчиком. Если нет UX- дизайнера (а в аутсорсе их почти нигде нет), то еще и это. Если нет тестировщика, то еще и потестить. А если на выходные упал сервак или база данных, то придется еще и отказаться от личных планов, чтобы восстановить работу приложения. В каждой из этих сфер каждый день создаётся что-то новое. Чтобы быть в теме, нужно задротствовать и не вылезать из мануалов. Но если такой путь утомил, можно ведь вполне за ту же ЗП только фронт или бэк готовить. Объем необходимых знаний, ответственности и головной боли в 2 раза меньше, и есть время хоть иногда просто поваляться вечером перед телеком и не пилить себе, что вышла очередная библиотека, а я тут лежу и не изучаю ее
kovalexius
15.11.2018 12:42-1Синьор — это специалист со знанием широкостекового мидла, который занимается неким режиссированием проекта — то есть продумывает архитектуру, концепцию, формализует и распараллеливает задачу от заказчика на несколько подзадач для разработчиков, ведет чейнджлог, просматривает merge request'ы, порой сам мёржит.
Frimko
15.11.2018 14:16бред собачий, это делает тимлид. работа сеньора, банально разбираться лучше в своей области чем остальные, не более.
з.ы. вы лучший среди своих коллег в вашей фирме? вы сеньор. Сильно размыты эти границы квалификаций.VolCh
15.11.2018 16:56Всё зависит от организации команды. Он может быть иерархическая: лид или ПМ ставит задачи паре сеньоров, те их декомпозируют и часть делегирует миддлам, те тоже декомпозируют и часть делегируют джунам.
Frimko
15.11.2018 17:37очень плохая иерархия. Так люди будут тасками швыряться, а не проект пилить. Думаю подобная иерархия в какой нить галере сойдет, где постоянная текучка, низкая безграмотность в профессии и зп такая-же. В любом другом случае… есть пул тасков, есть лид, ПМ и остальные, которые разгребают эти таски по принципу — «я хочу», остальные неурядицы устраняются средствами лида и ПМ. В подобных случаях, работа лида просто в кайф, когда народ в команде собирается нормальный.
serginho
Можно писать исключительно на typescript и быть fullstack
pawlo16
Это не правда. Во-1, Nodejs не всея руси, отнюдь не везде эта технология считается приемлемой. Во-2, сеньор бэкенд программист обязан знать как минимум sqlb ещё одну технологию, например, java или python.
serginho
pawlo16
1. Python, Go, раньше java была.
2. В статье же об этом речь. И, пожалуй, требование знать sql ко всем бэкендщикам относится.
serginho
Мой первый комментарий не ставит под вопрос другие технологии, но NodeJS + TypeScript (JavaScript) впервые дали возможность быть FullStack и писать только на одном ЯП. Тем самым упрощая процесс профессионального роста.
Simplevolk
C# -asp.core +Razor тоже даст вам такую возможность.
serginho
Поправьте меня если я неправ, но Razor — это по сути шаблонизатор. На нем клиентскую логику вы не напишете.
Fesor
Чего только в наше время не выдумают: Blazor — Full-stack web development with C# and WebAssembly
Flaksirus
Blazor — это конечно клево, но я бы лучше сразу писал на фронтовом языке вместо того чтобы постоянно огребать) Ну и blazor опять никак не решит проблему того, что сеньором во фронте не станешь, тонкости C# окажутся совсем не применимыми к фронту.
Fesor
А каким критериям должен удовлетворять уровень человека что бы можно было именовать его сеньором?
faiwer
Наверно, надо уметь писать асемблерные вставки :)
Flaksirus
Про это пишет автор статьи и я с ним в какой-то степени согласен.
mclander
Сеньор — это человек самостоятельно решающий проблемы и не создающий в этом процессе проблем коллегам, в том числе будущие проблемы.
Обычно сеньор отличается от мидла лучшей проработанностью решения (на тестировании всплывают только миноры) и понятностью мышления (поскольку человек знает предметную область он использует наиболее простые и логичные методы решения, следовательно код легко понять в целом, а часто и в нюансах).
Мидл же может наворотить пачку костылей. Просто потому, что хуже знает систему и предметку, плюс часто хочет показать что «я вот так умею».
Ну и сеньор менее заметен в офисе, но более заметен в баг-трекере)
MonoStas
Наверное наоборот:
«Ну и сеньор более заметен в офисе, но менее в баг-трекере»
mclander
Сеньоры разные бывают. Одни тащат задачи, другие любят потрындеть и покрасоваться. Я наверно 50 на 50. Хотя почти искренне верю, что первый тип)
mayorovp
Если вся клиентская часть — это набор формочек, то помогут библиотеки jquery-ajax-unobtrusive и jquery-validation-unobtrusive, они настраиваются исключительно атрибутами.
Хотя фулстеком того кто пользуется только ими назвать сложно.
alexr64
Если взять bridge.net — тогда да, фуллстек на одном языке.
Druu
Зачем сеньору-то знать другую технологию? Он же не джун.
kuber
Очень интересное утверждение. А можете привести пример триггера в какой-нибудь СУБД (SQL Server, MySQL, PosgreSQL, Oracle Database) на TypeScript?
serginho
Не все приложения требуют использования триггеров. Я и не писал, что typescript на все случаи жизни.
kuber
В таком случае нужно понимать что такое FullStack разработчик. В моем понимании это разработчик, который способен написать приложение от и до без посторонней помощи. А не так, что если нужны триггеры, то я уже не FullStack разработчик.
serginho
Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.
Так можно до бесконечности продолжать. Например у вас в проекте должен быть ИИ, а нейросеть вы строить не умеете. Вы уже не fullstack.
kuber
>> Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.
Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
VolCh
Что значит «грамотней»? По каким критериям?
kuber
Грамотней означает, что для каждой задачи нужно применять тот инструмент, который для нее наиболее подходит, а не пытаться писать свой велосипед для любой задачи.
VolCh
Подходит лучше технически или как?
kuber
Любите вы поспорить. :)
При решении любой задачи можно использовать различные подходы. Можно использовать решение проверенное временем от профессионалов (например, реализация триггеров Oracle Database), а можно взять и реализовать их самостоятельно. Можно и Web-серверы и СУБД реализовывать самостоятельно.
VolCh
Люблю, да. Особенно вижу категоричные суждения или оперирование общими оценочными категориями типа "грамотней" без указания критериев :)
noktigula
Скорее всего, самостоятельная реализация триггеров будет тормозить. Скорее всего, эти тормоза будут настолько не важными для проекта, особенно на ранней стадии, что ради них искать узкоспециализированного разработчика бд — пустая трата времени и денег.
Когда бизнес молодой и развивается, ему важно как можно быстрее и проще провалидировать жизнеспособность своей модели. В этих условиях, человек-оркестр, способный в одиночку запилить и бэк, и фронт, намного выгоднее двух крутых специализированных бэк/фронт разработчиков.
Другое дело — когда бизнес уже захватил основную часть аудитории, и начинается борьба за оптимизацию и увеличение конверсии. Тут нужен тюнинг перформанса и все остальное в таком духе, и нужны узкие спецы.
Проблема узких спецов на старте — часто они сходу начинают оптимизировать под будущий «хайлоад», когда вообще не факт что бизнес вообще взлетит.
mclander
Скорее не так. Использование триггеров, обеспечивает нам некоторую консистентность данных средствами DB (некоторую, потому что в триггере можно много чего сломать). И это круто — встроенное, надежное и известное решение.
Но всё решают зависимости. В триггере мы можем обработать данные из той же БД, довольно шустро и без особых рисков.
Но если, при изменении записи, нам надо взять данные не из DB, и как-то их по хитрому обработать… Тут возможно имеет смысл спроектировать слой над базой данных, а консистентность сохранить за счёт транзакционности и прямых рук. Это может оказаться, быстрее, надёжнее и даже проще реализовать.
Но, кмк, нам намекают, что то, что можно сделать в триггере, лучше сделать в триггере. Например записать лог изменения записи, или поддержать волшебным образом денормализацию «на лету». И плодить хитрое решение на технологии, которую лучше знаешь, а не на той, на которой от тебя ждут решение… По моему это подготовка будещего мазохизма, притом не своего, а того, кто будет поддерживать твою систему «если что».
VolCh
Если от тебя ждут решения на конкретной технологии, то надо его как-то делать или сообщать, что не можешь. Но часто такие нюансы как реализация логирования остаются в лучшем случае на усмотрение команды, а и одного разработчика.
Druu
Проблема же в цене поддержки. Если бизнес-логика размазана по триггерам и хранимкам дб — это очень печально. Просто sql очень плохой язык с точки зрения промышленного программирования, вот и все.
mclander
Ну тут есть вариант: бизнес логика собрана в триггерах и хранимках. И на это может быть много причин. До сих пор.
Кроме того, на триггер можно возлагать стандартные процедуры. Я уже упоминал логгирование, также принудительная генерация ключей в оракле, что бы исключить косоруков вручную ставящих id. Вообще да, триггер место для выстрелов в ногу, и много чего можно выносить на уровень приложения или хранимок.Но это не значит, что от триггеров надо отказываться принципиально.
И опять же начало спора было о том, что для разных случаев разные инструменты. И знание вариантов инструментов нелишне.
Druu
Об этом вроде никто и не говорил.
mclander
Ну значит мы друг-друга не поняли… в начале
mclander
PS. Sql в богатых расширениях(транзакт sql, pl/sql) это отличный язык для промышленного программирования. Просто нужно понимать какие, задачи решать на нём. Вы же не будете для построения статистики тащить 50 таблиц по миллиону записей на клиент) И пре и, пост обработку данных для некоторых операций проще делать хранимкой
roscomtheend
По критерию стабильности. Если есть два продукта (заливка в базу и редактирование с сайта) и недотриггер реализован програмно, то есть вероятность что только в одном месте (или неодинаково) и могут быть разные последствия. Просто один из вариантов.
Можно ведь и не в СУБД хранить, а в файлах и всю логику держать на клиенте (вообще всю базу сразу отправлять на клиента, включая данные всех пользователей, а уж клиент будет делать выборку). Вполне можно реализовать, но мало кто назовёт это правильным.
mayorovp
Для этих целей существуют подпрограммы :-)
roscomtheend
Для каких? Для замены триггеров? Не поможет при запросе в консоли или в программе, где этой подпрограммы нет (потому как не написали — сначала функция не планировалась, а потом реализовали).
Neikist
Ну не всегда это грамотнее, но вообще на мой взгляд как минимум иметь в виду такую возможность стоит.
kuber
Именно. Нужно понимать, что я не триггеры защищаю, а пытаюсь привести пример, который подтверждает содержимое статьи.
Neikist
Ну статья по моему немного не о том все же, тут наоборот автор в таком подходе разочаровался.
serginho
FullStack хорош для запуска первой версии продукта или для небольших фирм. Когда требуется не "грамотная реализация", а реализация в принципе. По мере роста проекта уже требуются более узкие специалисты.
А статья, если честно, ни о чем. Типа, если вы будете изучать технологии А, Б, В, то никогда не изучите технологию А также глубоко, как человек, который изучает только технологию А. Это очевидно.
kuber
>> Типа, если вы будете изучать технологии А, Б, В, то никогда не изучите технологию А также глубоко, как человек, который изучает только технологию А.
Вот с этим абсолютно согласен. Уверен, что множество разработчиков в принципе никогда не станут Senior разработчиками даже если будут изучать хоть всю жизнь одну технологию.
FieryCat
FullStack хорош не только для запуска, но и последующего контроля. Эволюция FullStack — это архитектор проекта.
VolCh
Что значит «нужны»? Вот в бизнес-задаче декларируется «нужны триггеры»?
f0rk
> А можете привести пример
pgxn.org/dist/plv8/doc/plv8.html
не совсем ts, но можно его при желании сбоку прикрутить :)
VolCh
deleted
Druu
Есть же достаточно распространенное мнение, что использование триггеров (и вообще дергание скл руками) — code smell. В такой парадигме неумение использовать тригеры — конкурентное преимущество.
kuber
Триггеры в данной ситуации лишь пример, а не предложение повсеместно их использовать т.е. вместо них можно придумать любой другой подходящий.
Druu
anprs
Уметь в SQL проще и продуктивнее чем уметь в ORM, разве нет?
Druu
Зависит от ситуации.
SQL, конечно, хорош в плане перформанса, но:
В общем, как и всегда — есть разные задачи, есть разные инструменты, а серебряной пули нет.
BigDflz
трудно не согласиться, но если есть возможность — надо ей пользоваться — к примеру поля даты можно уже в запросе привести у нужному виду, числа сформировать с нужными разделителями разрядов.
cyberly
Если она будет ровно одна, то, возможно, не стоит.
… однако, если у вас уже есть подсистема, которая форматирует данные, в том числе полученные не из БД, то этого делать не нужно. Особенно если там все по-взрослому, с подтягиванием настроек пользователя, определением региона, учетом смещений часовых поясов и всего такого.
ИМХО, спор про то, на чем правильно делать то или это в абстрактном проекте — беспредметный.
Quilin
А как например писать юнит-тесты на хранимки?
pawlo16
Трудно, но можно. В postgresql, mysql и оракле такая возможность есть. Суть такова:
Quilin
А есть ли возможность гонять эти тесты без непосредственно базы данных? Потому что для бэкенда как бы это практически всегда запросто. Более того, в моем родном дотнете скоро обещают возможность запуска owin-based-приложух прямо в памяти. Типа можно писать интеграционные тесты на ваш API вообще не запуская сервер.
Я сам вообще стараюсь хранимки использовать по минимуму. Понятное дело, что иногда они дают важный буст производительности, особенно учитывая, что ORM не серебрянная пуля и часто генерят диковатые запросы. Спросил не с целью «о, если мне еще юнит-тестов там подвезут, все буду на скулях писать», а с вопросом в духе «а чо, в мире есть проекты, где хорошо уживаются CI/CD, TDD и хранимки?» Потому что у меня на проекте они уживаются, но с очевидностью первое берет верх.
nsinreal
Я в эти сказки не верю после того, как столкнулся с развитием продукта построенного в основном на SQL. Боль заключается в том, что если на типичном бекендском языке можно разбить 2000 строк на 40 групп по 50 строк с дополнительным оверхедом в 200 строк, то на sql оверхед составляет ближе к 500-1000 строк. И это делает нецелесообразным попытки написать хороший код. Соблюдать DRY почти невозможно. Увы, SQL не имеет средств для нормального реюза кода. Т.е. развивать код на SQL можно только до определенных пределов.
В другой продукте использовались хранимки на SQL, но гораздо меньшие и более конкретные. И это было счастьем. За исключением того, что все хранимки стали выглядеть автоматизируемыми. Туда явно напрашивалась абстракция. Но существующие инструменты (ORM) слишком сильно были заточены под паттерн «хуяк-хуяк» и были малопроизводительными. Хранимки оказались наименьшим злом на тот момент.
mayorovp
Угу. Все запросы — в хранимках на сервере, а история и blame — в гите. Вот и выросла цена сопровождения кода на пустом месте.
VolCh
В целом зависит от задачи. И ОРМ придумали как раз для упрощения и увеличения продуктивности.
zmeykas
и еще видимо для абстрагирования от движка СУБД
VolCh
Не у всех ОРМ есть DBAL на самом деле.
nsinreal
Например, некоторые современные NoSQL-решения имеют возможность исполнять код на JS. Транспиляция TS->JS банальна.
Конкретно по триггерам: blog.kloud.com.au/2018/01/30/cosmos-db-server-side-programming-with-typescript-part-4-triggers
CheatEx
Node.JS научился в потоки?
serginho
Вы об этом?
CheatEx
Не совсем, но для некоторых целей уже пойдёт.