Здравствуйте, John1979, Вы писали:

mgu>>Как раз "ниндзей" очень не хватает многим проектам: узкие специалисты прекрасно справятся со своими частями, а всё вместе не работает.
J>Это значит, что не хватает архитектора.

А кстати, откуда берутся архитекторы? Ведь не учат же на них в институтах. Стало быть, если архитектор вырастает из узкого специалиста, то проект будет хромать на все слои, в которых данный специалист не разбирается.

Здравствуйте, mgu, Вы писали:

J>>Это значит, что не хватает архитектора.
mgu>А кстати, откуда берутся архитекторы? Ведь не учат же на них в институтах. Стало быть, если архитектор вырастает из узкого специалиста, то проект будет хромать на все слои, в которых данный специалист не разбирается.

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

Здравствуйте, mgu, Вы писали:
mgu>А кстати, откуда берутся архитекторы? Ведь не учат же на них в институтах.
архитекторы они разные бывают
есть те, которые просто ходят по митингам. таким архитектором кто угодно быть может
есть те, которые реально что-то делают — обычно появляются из тех, кто делал собственные проекты с нуля, руководил своим собвенным небольшим стартапом, уже наполучал шишек вагон и совершенно спокойно может взяться за проект в аналогичной области

Здравствуйте, Lazy Bear, Вы писали:

mgu>>А кстати, откуда берутся архитекторы? Ведь не учат же на них в институтах. Стало быть, если архитектор вырастает из узкого специалиста, то проект будет хромать на все слои, в которых данный специалист не разбирается.

LB>Архитектору нужно получить информацию от узких специалистов по слоям и принять решение, основываясь на этой информации.

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

S>Прошла ли уже мода на Full Stack Developer?

Не прошла и не пройдёт. В проектах всё зависит от сложности разных слоёв системы. Если в БД порядка 30 таблиц с максимальным числом записей порядка миллиона, несложная интеграция данных, то выделять специализированного человека, который занимается только данными, бессмысленная трата ресурсов. То же самое и с UI. Но в проекте или в компании должны быть люди, которые обладают высокой компетенцией для каждого уровня. Меня, например, тошнит от всего мира web frontend, но разрабатывать "по аналогии" я могу и на этом уровне.

Здравствуйте, D. Petrov, Вы писали:

DP>Всяких специализированных поисковиков пилятся сотни прямо сейчас.
Кем пилятся? Какой в этом смысл, если уже есть несколько годных опен-сорс решений? Публичные поисковики для веба — 10 штук в мире.


DP>Но и без них есть много областей более близких к поисковикам чем к сайтам.
DP>Возми успешные российские страртапы — Призма и СтатсБот. Они конечно же не поисковики, но фронт-энд там наверняка не является основной частью.
Ох не стоило тебе это писать.
Во-первых призма написана одним человеком (fullstack, ага). Насколько я понимаю там клиент на iOS и Android сложнее, чем нейронная сеть на сервере. То есть если ты одинаково хорошо знаешь как делать UI для iOS и Android и как делать НС, то UI надо будет программировать больше.
Во-вторых алгоритм призмы, насколько я понимаю, не оригинальная разработка. См https://arxiv.org/abs/1508.06576 и https://github.com/jcjohnson/neural-style — появилось на год раньше приложения.
В-третьих где сейчас эта призма? Там же где и год назад? В чем успех?
В-четвертых СтатсБот — примитивнейшая хрень, пишется в одно лицо за один вечер. Не утрирую.
В-пятых СтатсБот реально был написан 1-2 человеками, и что-то мне кажется что они не делились на front-end и backend.
В-шестых Оценивать успешность технологий и подходов на основании привлеченных инвестиций — крайне глупо. Чтобы привлечь инвестиции надо попасть в одну или несколько горячих тем. Slack + боты + аналитика — три горячие темы, Фото на мобилке + НС — две горячие темы.


G>>Я бы сказал, что ты вряд ли найдешь работу, где навыки создания UI не будут востребованы.
DP>Хе, хе... За 12 лет мне не приходилось заниматься UI. За парой исключений которыми можно принебреч.
Ты этим гордишься?

G>>Поэтому в большинстве случаев один "fullstack" программист будет предпочтительнее двух специализированных при прочих равных.
DP>В проекте на 2-5 человек — да. На 10 человек — может. На 50+ человек — точно нет, за редким исключением (при прочих равных).
Ты в качестве примеров привел проекты в 1-2 человека

В крупных проектах очень редко команда делится "горизонтально" на FE и BE. Чаще встречается вертикальное деление — одна подкоманда пилит одну фичу\модуль. Пилит сверху до низу. И в каждой такой подкоманде есть как минимум один человек, который владеет всем стеком технологий, обычно он главный в команде.

Здравствуйте, mgu, Вы писали:

mgu>Здравствуйте, wamaco, Вы писали:

W>>Не верю я в универсальных спецов! Нет таких. Вершки знать — не значит быть профи.

mgu>Ну, я такой. И что? Разница между языками только в синтаксисе, а это от силы процентов 20 знаний в программировании -- задокументированных и застековерфлоуенных.

Частенько за синтаксисом скрывается разная семантика, что ведёт к трудноуловимым ошибкам. Потом дебажить бывает оооооооооочень долго, особенно когда код написан как-то так:
var a = b( c(d()), e(), f())? g():h(). Ну да ладно, вопрос не про общее качество кода всё-таки...

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

Только не дай бог тебе код при этом писать — сиди рисуй свои обобщённые схемки, выступай на митингах, консультируй саппорт, рассказывай девелоперам что надо сделать. Только код не пиши — всем же лучше будет.

Здравствуйте, gandjustas, Вы писали:

G>Кем пилятся? Какой в этом смысл, если уже есть несколько годных опен-сорс решений? Публичные поисковики для веба — 10 штук в мире.

Внутри всяких Amazon, Yelp, AirBnB тоже есть как бы специализированные поисковые или рекомендательные движки.

DP>>Возми успешные российские страртапы — Призма и СтатсБот. Они конечно же не поисковики, но фронт-энд там наверняка не является основной частью.
G>Ох не стоило тебе это писать.
G>Во-первых призма написана одним человеком (fullstack, ага). Насколько я понимаю там клиент на iOS и Android сложнее, чем нейронная сеть на сервере. То есть если ты одинаково хорошо знаешь как делать UI для iOS и Android и как делать НС, то UI надо будет программировать больше.

Да, пожалуй не самые удачные примеры... В целом, любой стартап начальной стадии это обычное веб приложение, за очень редким исключением.

G>>>Я бы сказал, что ты вряд ли найдешь работу, где навыки создания UI не будут востребованы.
DP>>Хе, хе... За 12 лет мне не приходилось заниматься UI. За парой исключений которыми можно принебреч.
G>Ты этим гордишься?

Не, я лишь говорю что тебе не стоило это писать в столь категоричной форме

G>>>Поэтому в большинстве случаев один "fullstack" программист будет предпочтительнее двух специализированных при прочих равных.
DP>>В проекте на 2-5 человек — да. На 10 человек — может. На 50+ человек — точно нет, за редким исключением (при прочих равных).
G>Ты в качестве примеров привел проекты в 1-2 человека

Ну да, примеры были не удачные.

G>В крупных проектах очень редко команда делится "горизонтально" на FE и BE. Чаще встречается вертикальное деление — одна подкоманда пилит одну фичу\модуль. Пилит сверху до низу. И в каждой такой подкоманде есть как минимум один человек, который владеет всем стеком технологий, обычно он главный в команде.

Такое я видел в конторах среднего масштаба. Для одной и той же платформы пилят фичи две команды по 5-7 человек каждая. Все таки в группе 50+ человек такого уже не получится — они на "толкотню" будут тратить больше времени чем на развитие.

Здравствуйте, D. Petrov, Вы писали:

DP>Здравствуйте, gandjustas, Вы писали:

G>>Кем пилятся? Какой в этом смысл, если уже есть несколько годных опен-сорс решений? Публичные поисковики для веба — 10 штук в мире.

DP>Внутри всяких Amazon, Yelp, AirBnB тоже есть как бы специализированные поисковые или рекомендательные движки.

Не знаю что там у амазона, но готов биться об заклад, что airbnb использует что-то готовое, а не свою разработку.

Вообще говоря написать поисковый движок, который вычисляет релевантность на основе tf/idf, не сильно сложно. И по большому счету не нужно, есть lucene.
Сложно делать ранжирование на основании ссылок, а оно как раз не нужно ни Amazon, ни Yelp, ни Airbnb.

Рекомендательные системы это вообще халява. Там по сути одна формула на 20 строк, а остальное — внезапно UI.


G>>>>Я бы сказал, что ты вряд ли найдешь работу, где навыки создания UI не будут востребованы.
DP>>>Хе, хе... За 12 лет мне не приходилось заниматься UI. За парой исключений которыми можно принебреч.
G>>Ты этим гордишься?
DP>Не, я лишь говорю что тебе не стоило это писать в столь категоричной форме
Я сказал, гораздо проще найти работу, где навык создания UI пригодится, чем работу где ты будешь только сервер-сайдом заниматься. Ты пытаешься это опровергнуть тем, что у тебя было два (или сколько там) места работы, где ты занимался только сервер-сайдом. Хотя ты сам, возможно, вне сможешь сделать UI даже уровня prisma.


G>>>>Поэтому в большинстве случаев один "fullstack" программист будет предпочтительнее двух специализированных при прочих равных.
DP>>>В проекте на 2-5 человек — да. На 10 человек — может. На 50+ человек — точно нет, за редким исключением (при прочих равных).
G>>Ты в качестве примеров привел проекты в 1-2 человека

DP>Ну да, примеры были не удачные.

DP>Такое я видел в конторах среднего масштаба. Для одной и той же платформы пилят фичи две команды по 5-7 человек каждая.

Все таки в группе 50+ человек такого уже не получится — они на "толкотню" будут тратить больше времени чем на развитие.
Как раз в крупных конторах только так и можно поделить. Насколько я знаю в MS примерно так и устроено. В яндексе тоже очень похоже.
Это не значит что внутри одной команды не будет отдельных frontend и backend разработчиков. Но как минимум один человек, владеющий всем стеком, будет.

Ф>Частенько за синтаксисом скрывается разная семантика, что ведёт к трудноуловимым ошибкам. Потом дебажить бывает оооооооооочень долго, особенно когда код написан как-то так:
Ф>var a = b( c(d()), e(), f())? g():h(). Ну да ладно, вопрос не про общее качество кода всё-таки...

По-моему, ternary оператор работает одинаков во всех языках программирования, в которых он реализован. Просто более короткая версия конструкций с if. Не совсем понятно, что этот пример должен доказывать.

Здравствуйте, gandjustas, Вы писали:

G>Я сказал, гораздо проще найти работу, где навык создания UI пригодится, чем работу где ты будешь только сервер-сайдом заниматься. Ты пытаешься это опровергнуть тем, что у тебя было два (или сколько там) места работы, где ты занимался только сервер-сайдом. Хотя ты сам, возможно, вне сможешь сделать UI даже уровня prisma.

Похоже, что твое мнение основанно на твоей собственной предвзятости (bias). Вот например, у меня нет опыта в UI и меня еще никто не звал на работу с ним хотя предложений хватает. Таким образом, я могу сделать вывод, что программисты с навыками UI вообще не нужны. Хотя я то по косвенным наблюдениям знаю, что это не так. А вот тебе как то не получается уйти от своей предвзятости.

G>Все таки в группе 50+ человек такого уже не получится — они на "толкотню" будут тратить больше времени чем на развитие.
G>Как раз в крупных конторах только так и можно поделить. Насколько я знаю в MS примерно так и устроено. В яндексе тоже очень похоже.
G>Это не значит что внутри одной команды не будет отдельных frontend и backend разработчиков. Но как минимум один человек, владеющий всем стеком, будет.

Не, не так там устроенно. Обычный программист в большой интернет-компании работает на бэк-енде потому, что там работы значительно больше: инфраструктура, серверная логика, БД всякие, релевантность, дата-сайнс.

А в мелких проектах на 2-10 человек все это можно делать одновременно. Вот там фул-стек и нужен. И то что он релевантность посчитает по tf-idf ему простят

Здравствуйте, namespace, Вы писали:

N> подобрал бы русский аналог этих слов. А может быть, в процессе даже и понял, что это абсолютно ничего незначащие слова.

'рокет саенс'

так?

Здравствуйте, mgu, Вы писали:

mgu>>>А кстати, откуда берутся архитекторы? Ведь не учат же на них в институтах. Стало быть, если архитектор вырастает из узкого специалиста, то проект будет хромать на все слои, в которых данный специалист не разбирается.

LB>>Архитектору нужно получить информацию от узких специалистов по слоям и принять решение, основываясь на этой информации.

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

Информация ходит обоих направлениях, постепенно обрастая необходимыми деталями. Конечно, архитектор решает, какие специалисты ему нужны. Он принимает решение, основываясь на своем опыте и мнении/опыте других специалистов.

Здравствуйте, De-Bill, Вы писали:

Ф>>Частенько за синтаксисом скрывается разная семантика, что ведёт к трудноуловимым ошибкам. Потом дебажить бывает оооооооооочень долго, особенно когда код написан как-то так:
Ф>>var a = b( c(d()), e(), f())? g():h(). Ну да ладно, вопрос не про общее качество кода всё-таки...

DB>По-моему, ternary оператор работает одинаков во всех языках программирования, в которых он реализован. Просто более короткая версия конструкций с if. Не совсем понятно, что этот пример должен доказывать.

Этот короткий пример про 7 вызовов функций и 1 тернарный оператор в одной строке. Как именно в этом случае работает тернарный оператор в каждом конкретном языке не важно.

Здравствуйте, D. Petrov, Вы писали:

DP>С ростом проекта неизбежна специализация.
DP>Можно дробить до достаточно сильно если процесс поставлен и команда достаточно большая.

Это всё в рамках конкретного проекта.
А специализация в целом это, как правило, frontend/backend vs fullstack. Специалистов по одному узкоспециализированному инструменту отдельно взятого бэкэнда или фронтенда не очень любят.

Здравствуйте, D. Petrov, Вы писали:

G>>Насколько я знаю в MS примерно так и устроено. В яндексе тоже очень похоже.
DP>Не, не так там устроенно. Обычный программист в большой интернет-компании работает на бэк-енде потому, что там работы значительно больше: инфраструктура, серверная логика, БД всякие, релевантность, дата-сайнс.

То, что я видел внутри MS, было устроено с большим перекосом в сторону full-stack разработки.
Я работал в Bing. Бинг это большой проект и внутри его условно можно поделить на десяток крупных блоков, взаимодействующих между собой. Общей "шиной" для этих блоков является так называемый "global data pipeline", куда сливаются уже все данные, на основе которых строится индекс.
Так вот внутри этих крупных блоков люди пишут фичу от начала и до конца. Большинство из этих компонентов имеют и базу данных в том или ином виде и UI. И работают надо всем этим одни и те же люди.
При этом, на самом верхнем уровне узкая специализация таки тоже присутствует — UI пишется отдельной командой, где работают UI-профессионалы, а над object store работают те, кто хорошо разбирается в хранении индексированных данных. В object store есть свой внутренний UI, который пилят те же разработчики, которые пилят и сервис. Но требований к этому UI, конечно, куда меньше, чем к тому, что видят конечные пользователи.

Отбрыкаться от UI-работы и сказать что не хотите заниматься ничем кроме бэкенда там, в общем-то, тоже можно, но смотреть будут косо.

Здравствуйте, Artem Korneev, Вы писали:

AK>То, что я видел внутри MS, было устроено с большим перекосом в сторону full-stack разработки.
AK>Я работал в Bing. Бинг это большой проект и внутри его условно можно поделить на десяток крупных блоков, взаимодействующих между собой. Общей "шиной" для этих блоков является так называемый "global data pipeline", куда сливаются уже все данные, на основе которых строится индекс.

Плавали, знаем... Как мне кажется это не совсем то, то называют UI. Многие из этих "UI" построенны на готовых фреймворках куда просто надо данные в верном формате заливать время от времени, они графики построят, а ты кликнешь куда график приткнуть — вот и весь UI. По моему опыту — работа Бинге очень далека от UI. Я сначала строил индекс в платформе, а позже дата-сайнс в БингАдс Релеванси.

Здравствуйте, Философ, Вы писали:

Ф>Частенько за синтаксисом скрывается разная семантика, что ведёт к трудноуловимым ошибкам. Потом дебажить бывает оооооооооочень долго, особенно когда код написан как-то так:
Ф>var a = b( c(d()), e(), f())? g():h(). Ну да ладно, вопрос не про общее качество кода всё-таки...

За такой вот код — надо молотком по рукам бить...
Даже автор, через максимум месяц, будет блеять что-то про семь функций (с топроными именами) и один тернарный оператор, при этом НЕ имея понятия — зачем всё это...

Здравствуйте, D. Petrov, Вы писали:

DP>В проекте на 2-5 человек — да. На 10 человек — может. На 50+ человек — точно нет, за редким исключением (при прочих равных).

Широкая специализация позволяет выполнять вертикальную декомпозицию, что на больших и маленьких проектах дает много преимуществ. Кроме того, на больших проектах, если команда состоит из узкоспециализированных людей, то все время кто-то из них будет являться узким звеном, а кто-то плевать в потолок. В результате, проект делается медленно, денег на зарплаты при этом тратиться немерено. Закономерный финал — фейл проекта.

Здравствуйте, Shmj, Вы писали:

S>Прошла ли уже мода на Full Stack Developer? Это типа такой ниндзя, который в совершенстве владеет всеми технологиями начиная от SQL и Java, заканчивая JS и HTML-версткой, может делать любую часть проекта или даже проект целиком.

1. Это не мода. Человек, который не в зуб ногой в фронтэнде или в бэкенде подобен одноногому бегуну — все время будет спотыкаться и хромать.
2. Но это не означает, что человек не должен специализироваться на определенных задачах. Быть суперспецом везде — обычно не нужно.

S>И второй вопрос. На сколько мелко нужно дробить стеки так сказать технологий? Вот если чел. занимается только работой с базами данных, оптимизацией запросов и пр. Больше ничего не знает. Или же чел. занимается исключительно написанием/поддержкой API, больше ничего на знает, зато об API знает все.

Чем больше разработчиков знает конкретный участок кода, тем лучше. Дальше выводы делай сам.