По словам Адама Шапли, full-stack разработчики востребованы как никогда, т.к. в компаниях требуют от IT сотрудников целый ряд навыков. Мы в свою очередь тоже замечаем, что все чаще получаем от наших клиентов запросы на поиск full-stack разработчиков.
Если вы разработчик, вы можете быть либо front-end, либо back-end специалистом. На первый взгляд, сосредоточиться на определенных навыках имеет смысл, т.к вы можете представить себя на рынке как эксперт в одной области. Однако полная разработка быстро набирает темпы, и full-stack разработчики становятся очень популярны в некоторых компаниях. Исследование Stack Overflow 2017 показало, что данный тип разработчиков не только самый востребованный, но и самый популярный.
Разработчики широкого профиля работают во всех слоях программного обеспечения. Они понимают принципы и могут работать по обе стороны, хотя и не всегда овладевают всеми тонкостями как их узкоспециализированные коллеги.
Безусловно, есть плюсы и минусы такой работы. Некоторые утверждают, что разработка становится с каждым годом сложнее. Именно поэтому необходимо иметь узко сегментированных разработчиков.
Недостатком этого аргумента является то, что full-stack разработчик не одинокий волк, а часть команды и ему придется положиться на опыт своих коллег. При этом в команде необходимо иметь хотя бы одного специалиста, готового погрузиться в тонкости, чтобы получить качественный продукт.
Востребованность full-stack разработчиков связана с тем, что наличие одного человека с несколькими навыками, а не нескольких людей с определенными навыками, представляет реальную ценность для многих организаций. Кроме того, существует большая экономия времени, если вы используете разработчика, который может переключаться между уровнями и понимать весь процесс.
Это, в свою очередь, означает, что full-stack разработчики лучше работают в команде, поскольку они знают и понимают инструменты, которыми пользуются другие члены команды, и это делает команду гибче. Таким образом, многие компании привлекают таких разработчиков для аджайл разработки, чтобы в конечном итоге остальная команда также расширяла свою экспертизу.
Какими навыками должен обладать full-stack разработчик?
Такие разработчики должны понимать целый ряд инструментов, языков и систем:
Очень важно понимать HTML / CSS и JavaScript, и, как только вы освоите эти языки, вам понадобится освоить языки для back-end для управления базами данных, аутентификации пользователя и т.д.
SQL и Java пользуются спросом в данный момент — или вы можете изучить Node.js. Затем вам нужно будет понять основы баз данных и веб-хранилищ. Итак, выберите систему баз данных (например, MySQL) и один веб-сервер (например, Apache), а также протокол HTTP и как включить REST в ваши HTTP-вызовы.
Чтобы полностью понять «общую картину» работы по разработке, вам также нужно будет получить навыки в архитектуре веб-приложений.
Как разработчикам получить опыт в full-stack разработке?
Существует множество онлайн-сообществ и курсов, которые помогут вам ускорить работу со всеми упомянутыми технологиями. Например, GitHub — отличный ресурс.
Конечно, только практика сможет вас вывести на новый уровень. Создайте что-нибудь самостоятельно или узнайте у своих коллег, можете ли Вы помочь с небольшими работами, которые находятся за пределами вашей обычной зоны ответственности.
Full-stack разработчик — это не просто востребованная роль во многих организациях, но и хорошо оплачиваемый вариант. Понимание большего количества технологий, безусловно, является преимуществом для Вашей карьеры.
Как бывает на практике…
Мы работаем с рядом крупных и средних по размеру компаний, и не всегда количество лет опыта в full-stack разработке является критерием выбора кандидата. Так, например, у нас был поиск сильного full-stack разработчика на синиорскую позицию для одной известной компании, хотели человека с большим послужным списком и багажом знаний и опыта. Поиск шел долго, клиент хотел «увидеть рынок» максимально широко прежде, чем принимать решение. Через несколько недель поиска нам удалось по рекомендации одного из кандидатов выйти на юного (с точки зрения опыта) специалиста, который в лучшем случае мог бы претендовать на роль джуна в команде. Тем не менее молодой человек оказался очень хорошо подкован с точки зрения знаний технологий, с легкостью прошел техническое интервью с руководителем, а также продемонстрировал высокий уровень мотивации на работу в этой компании, благодаря чему его таки взяли в команду, хоть и не на грейд старшего специалиста. Так что не только опыт в крутых компаниях, но и знания теории в сочетании с прозрачной мотивацией могут привести к успешному трудоустройству.
В рамках этой статьи мы в общих чертах обрисовали путь к full-stack разработчику, при этом остается вопрос актуальности этого направления. Мы со своей стороны ощущаем потребность в таких специалистах, при этом от кандидатов слышим разные точки зрения: одни считают, что лучше быть экспертом в определённой области (front/back), другие же уверены, что за full-stack разработкой будущее.
Комментарии (125)
artemt
22.09.2017 17:52+4Следует упомянуть один распространённый путь в fool-stack разработчики. Компания периодически сокращает штат, перераспределяя обязанности внутри команды, пока не останется он, fool-stack developer.
Free_ze
22.09.2017 18:18Итак, HR-специалисты в двух предложениях рассказывают нам о том, как стать full-stack разработчиком (без каких-либо ссылок на исследования, графиков, обзоров и сравнений, о чем вы вообще?). Потрясающе познавательная статья, спасибо HaysRussia!
pm_wanderer
22.09.2017 18:45+6… А еще он должен уметь летать.
PS
Измученные лица на картинке с тремя программистами, безмолвно кричат: «Бегите, глупцы»)
viru0
22.09.2017 18:47+1Тут от нагрузки зависит. Full stack он обычно может быстро на коленке и все, но не глубоко.
Это значит что если у вас проект огромный и ошибка на 0.5% производительности или не сделать нормальную верстку для экзотического браузера — убытки больше ЗП, то вам нужна специализация. Если у вас начальная стадия проекта, трафик около ноля, то тут скорость разработки выходят на первый план. И тут full stack очень хорошо вписывается.
В итоге все просто, в большом матером enterprise попытка нанимать full stack — это просто тренд. В небольших компаниях и стартапах — потребность рынка.DrPass
23.09.2017 01:17Тут от нагрузки зависит. Full stack он обычно может быстро на коленке и все, но не глубоко.
Я, пожалуй, возражу. Если не брать в расчет специализацию по какому-то одному продукту (а-ля «разработчик MongoDB с опытом разработки самой MongoDB, или хотя бы контрибьютор проекта Mongoose»), то, ИМХО, нет никаких сложностей освоить оба направления на глубоком профессиональном уровне. Успешный программист ведь обычно всю свою карьеру только и занимается тем, что изучает новые направления и инструменты.
AsianCat
22.09.2017 19:23+5Это от жмотства такие тенденции. У нас есть еще одна тенденция — попытка набирать разрабов и инженеров инфраструктуры в одном флаконе. Чистый идиотизм на марше.
onegreyonewhite
23.09.2017 03:56+1Хуже всего то, что они их называют (почему-то) devops-инженерами, даже не понимая что это значит. Раньше их называли админами локахоста и избегали, а теперь ищут…
AsianCat
23.09.2017 23:31+2Я честно говоря сам не понимаю, откуда такое название. Были всегда инженеры инфраструктуры. Разработчику банально нет времени заниматься инфраструктурой, собирать код в докеры и т.п. Это уже задача инженеров — выкладывать в продакшн, мониторить, смотреть что там с масштабируемостью и т.п.
ohotNik_alex
26.09.2017 10:33это отдельная профессия, вообще-то. попробуйте на конференции поездить — там разъяснят.
если вкратце, то это мутант, получившийся от скрещивания админа и разработчика. причем может вырасти как из одной профессии, так и из другой.
относительно «нет времени» точка зрения крайне субъективная. как по мне — плох тот разработчик, который не понимает как его код запускается. это как писать приложения без знаний что такое JMM. да и курить бамбук со словами «я жду пока мне настроят» как минимум стыдно.
кроме того решается еще одна задача — некоторым разработчикам банально страшно давать доступ к критическим ресурсам, а доступ может быть необходим. выполнят по ошибке форматирование диска. имея навыки админа этот человек врятли совершит подобную ошибку.
можете подробнее поискать лекцию Димы Чирухина с JPoint2017. Может быть уже открыли всем.
hVostt
23.09.2017 23:24При чём тут жмотство? Фуллстек программист за единицу времени не делает аналогичную работу фроненд и бекенд программистов за ту же единицу времени. Я не первый раз слышу подобную чушь и ересь, и искренне не понимаю, у вас ребята с логикой всё в порядке?
Знать и уметь больше это сегодня не круто и не модно?AsianCat
23.09.2017 23:28+2Знать и уметь больше это круто и модно. Вопрос в другом — такого знающего припашут работать ровно за ту же зарплату в двойном обьеме или как минимум захотят и будут требовать. Не сталкивались? Вы счастливый человек.
hVostt
23.09.2017 23:31-1Я не зря спросил про логику. Какой ещё двойной объём? Давайте так, допустим вас нанимают на работу программистом и уборщиком, вы всерьёз полагаете, что вам надо будет одновременно заниматься и уборкой и программированием? Если это действительно так, то это маразм. Если вы думаете, что это так, то это тоже маразм. Фуллстек, это значит, грубо говоря, пол дня вы будете делать одно, пол дня другое. А в случае с двумя программистами фронт и бек, пол дня оба будут делать свою работу, и пол дня дружить свои решения друг с другом, именно про это работодатель думает с точки зрения оптимизации, и жлобство тут не при чём ни разу.
AsianCat
23.09.2017 23:35Я говорю же — вам повезло с работодателем.
hVostt
23.09.2017 23:38-1У нас весь коллектив смеялся, когда на собеседовании один кандидат спросил: «а за фуллстек будут платить в двойном объёме?». Учитывая, что в фуллстек коллеги перешли из узкой специализации по собственной инициативе, а начинали некоторые кто с бек, кто с фронт. Просто это банально неудобно, когда ты видишь решение лишь одним глазом. Также разработчиков принято посвящать в детали предметной области и раскрывать им полную картину того, над чем они работают, кому это нужно, как это будут использовать и так далее. Воспринимать разработчика как инструмент с одной резьбой — вот это издевательство.
DrPass
24.09.2017 00:20+1Вопрос в другом — такого знающего припашут работать ровно за ту же зарплату в двойном обьеме или как минимум захотят и будут требовать.
А почему «в двойном объеме»? В обычном рабочем дне 8 часов. От фуллстеков кто-то где-то требует работать по 16 часов, что ли?M_AJ
24.09.2017 10:52+1В хороших компаниях может и 8, а в обычных через неделю все должно быть готово, и крутись как хочешь.
DrPass
24.09.2017 14:41Я все же думаю, что никакой корреляции между отношением к разработчикам в компании и требованиям к фуллстекам нет. Если в компании задачи в принципе оцениваются по срокам неадекватно, то ваша специализация роли уж точно не играет.
M_AJ
24.09.2017 15:19Такой вариант конечно есть, но мне кажется тут всего пара кейсов: вялотекущее сопровождение, когда на двоих узких специалистов работы не хватит, или бодишоп, который не знает, что ему закажут завтра, и ему нужны максимально универсальные работники. В остальных случаях, мне слабо понятно, зачем делать проект 4 месяца силами одного фулстэка, когда можно сделать за 2 силами двух узких специалистов.
DrPass
24.09.2017 19:21Мне кажется, наиболее эффективный вариант — это делать проект полтора месяца силами двух фуллстеков :)
ohotNik_alex
26.09.2017 10:51но не самый дешевый. это потом все поддерживать, а оклад фулстека все же выше — вы ведь требуете оклад за имеющиеся навыки / сертификаты. что там требуется заказчику — проблема исключительно его.
а то получится возможным диалог:
— мне нужен фулстек.
— ок. 200 тысяч.
— но мне только пару кнопок на сайте подправить — половина ваших знаний мне не нужна!
— аааа… ну тогда я буду работать за 30 тысяч.artemt
26.09.2017 11:11оклад фулстека все же выше
То, что full-stack разработчики много получают — миф. Знать все области на уровне сеньора крайне сложно, это штучные специалисты. Большинство full-stack разработчиков — это широкие мидл. Вот они и получают где-то между мидл и сеньором, ближе к сеньору всё-таки. Данная прибавка лишь отчасти за навыки. В основном, это страховка компании для понижения рисков потерять специалиста, на котором многое завязано. ИМХО.
sentyaev
26.09.2017 01:47можно сделать за 2 силами двух узких специалистов
Я допускаю, что 2 специалиста могут сделать проект быстрее на 20-30%, но что в 2 раза быстрее… к сожалению не встречал такого.ohotNik_alex
26.09.2017 10:46ну что вы… это ведь столь же очевидно, как способность 9 женщин родить ребенка за месяц =)
Desprit
22.09.2017 20:59+1А еще очень много совсем мелких стартапов, которым попросту не нужно в штат несколько специалистов по простой причине — не смогут загрузить работой одновременно всех. Тяжелых задач порою у них совсем немного, зато поверхностное знание ML'а, фронтенда и бэкенда в одном лице — именно то, что им нужно для прототипирования.
AsianCat
23.09.2017 23:43В стартапах лучше вообще не работать, если ты не совладелец. Ни денег ни перспектив ни гарантий что он не лопнет через месяц.
sentyaev
24.09.2017 05:38Я более 10 лет работаю исключительно в стартапах, поработал уже в пяти, сейчас иду в шестой. Из этих пяти, один уже не существует (его поглотила другая компания после покупке), у второго закончились денги и он закрылся, третий доживает последние дни. Остальные два отлично себя чувствуют. Везде работал от одного до трех лет.
1. Про деньги
Мне всего один раз платили на 10% ниже рынка (я сам согласился на это, т.к. проект казался очень интересным). И тут я с вами согласен, если предлагают деньги ниже рынка, и ничего не предлагают взамен, то лучше отказаться (но это всего лишь мой личный опыт). Все остальные стартапы платили либо верхнюю планку по рынку, либо выше.
2. Про перспективы
Во всех этих компаниях (кроме той которая платила ниже рынка) я работал с очень крутыми специалистами, всегда была плоская система управления, минимум бюрократии.
А также возможность решать действительно интересные и сложные задачи, возможность влиять на бизнес, на принятие решений. Т.е. я действительно мог участвовать в жизни этих компаний. Другими словами можно получить гораздо больше ответственности.
Ну и главное, за год можно очень сильно прокачаться как специалисту, т.к. приходится работать в условиях ограниченных ресурсов, а в таких условиях люди придумывают оригинальные решения. Плюс стартапы чаще используют новые технологии, больше рискуют, гораздо выше шансы поучаствовать в новых проектах, понять как проектировать архитектуру, инфраструктуру и т.д.
3. Про гарантии
Этот момент мне правда не ясен. Если посмотреть на большие компании, то там тоже нет никаких гарантий. Вот недавно Oracle, например, уволил всех кто занимался Solaris, причем просто в один день. Или как Microsoft увольнял тысячами.
С другой стороны поиск работы для хорошего специалиста — неделя, а учитывая что скорее всего после стартапов у людей больше опыта, то и берут на работу их охотнее.
Это конечно же мой личный опыт.
ZyXI
23.09.2017 01:00+2Frontend+backend — это ни о чём вообще. Настоящие разработчики должны уметь
- Писать frontend (HTML+CSS+JavaScript, labview).
- Писать backend (Python+circuits).
- Настраивать Web?сервер (nginx) и вообще ОС (Raspbian).
- Разводить печатные платы (Altium).
- Припаивать на них элементы.
- Писать программы для фрезерного станка, вместе с инструкцией для оператора. Потом служить этим самым оператором.
- Уметь скрутить/спаять всё это вместе.
- Писать программы на для микроконтроллеров (C, компилятор «как повезёт»).
- Писать программы для FPGA (labview/VHDL).
С 1989 так существуем и ничего.
gricom
24.09.2017 02:12ничего себе, а кто же тогда допиливает 1с и настраивает комп директору? не набираете же для этого отдельных людей?
ZyXI
24.09.2017 11:27Для администрирования компьютеров и локальной сети в целом есть отдельные «программисты». Правда, они не только наши компьютеры администрируют, но, вроде бы, всех в здании. К ним же идут за лицензиями.
noodles
23.09.2017 11:09Ещё можно предложить вариант — фулл стек на фронте. Т.е. выяснение требований -> прототип -> дизайн -> вёрстка -> клиентская логика. Имхо, тоже достаточно востребованный универсал получится, который разом убирает кривотолки, недопонимания и войны между заказчиком-дизайнерами-верстаками-разрабами. Также такой спец сразу сможет внятно рассказать главному архитектору про будущие модели и потоки данных. И также такой спец сможет реализовать крутые спецэффекты, основанные на канвасе или свг, т.к. понимает что и как конкретно нужно отрисовать и как потом с этим работать в коде.
Но такой вариант получается в основном, только когда технический специалист (фронтендщик) решил более глубоко изучить дизайн. А не наоборот из дизайнера во фронтендеры. Много есть мнений, основанных на положительных историях, что хороший дизайнер тот кто обладает техническим образованием, а не художественным.
lair
23.09.2017 12:29… то есть давайте объединим разработчика с аналитиком? Требования на бэкенд тоже он писать будет?
nekt
24.09.2017 18:07всего пару раз видел, как на стороне бэкенда не приходилось заниматься аналитикой и архитектурой.
lair
24.09.2017 20:43Ну то есть "фулл стек на фронте" из исходного комментария выяснит требования и напишет архитектуру, и на стороне бэкенда все то же самое. С клиентом поговорили два раза, получили две архитектуры. Как стыковать будем?
noodles
24.09.2017 23:05Имел ввиду, что «фулл-стек на фронте» более адекватно сможет выпонить подготовительную работу дизайнера (проектировщика инерфейса если угодно), а именно выяснит на на начальных этапах что вообще хочет заказчик, консолидирует и аккамулирует требования, накидает прототип. После чего он же сможет более адекватно, чем аналитики/менеджеры/продукт-оунеры рассказать команде (архитекторам, бекенду) что вообще это будет, после чего уже все вместе составят вменяемое тз.
lair
24.09.2017 23:07Имел ввиду, что «фулл-стек на фронте» более адекватно сможет выпонить подготовительную работу дизайнера (проектировщика инерфейса если угодно)
Более адекватно, чем кто?
а именно выяснит на на начальных этапах что вообще хочет заказчик, консолидирует и аккамулирует требования,
Это работа аналитика, а не разработчика.
После чего он же сможет более адекватно, чем аналитики/менеджеры/продукт-оунеры
Почему вы думаете, что разработчик может более адекватно, чем аналитик, выполнить работу аналитика?
noodles
24.09.2017 23:18… Чем дизайнер.
Согласен про аналитиков, просто не видел их вживую) мой первый пост — это было лишь предположение наделить фронтендера навыками не в сторону бек-а, а в сторону дизайна.lair
24.09.2017 23:22… Чем дизайнер.
То есть вы думаете, что разработчик может делать работу дизайнера лучше, чем дизайнер. Серьезно?
мой первый пост — это было лишь предположение наделить фронтендера навыками не в сторону бек-а, а в сторону дизайна.
Во-первых, это отдельная специализация, непростая. Во-вторых, тогда откуда берется сбор требований?
DrPass
24.09.2017 23:37То есть вы думаете, что разработчик может делать работу дизайнера лучше, чем дизайнер. Серьезно?
«Работа дизайнера» — это понятие весьма многогранное. Вы какую работу дизайнера имеете в виду?lair
24.09.2017 23:40Это вопрос не ко мне, а к человеку, который написал "Имел ввиду, что «фулл-стек на фронте» более адекватно [чем дизайнер] сможет выпонить подготовительную работу дизайнера"
DrPass
25.09.2017 00:03А, ну это риторическое утверждение. В каких-то случаях дизайнер, естественно, сделает работу лучше программиста. В каких-то случаях он наоборот, лишнее звено, которое лишь добавит ненужную прослойку в коммуникациях между пользователем и разработчиком. Так что без привязки к конкретной ситуации здесь спорить не о чем.
lair
25.09.2017 00:07А что у вас дизайнер делает между разработчиком и пользователем? Ему там не место.
DrPass
25.09.2017 00:24А что у вас дизайнер делает между разработчиком и пользователем? Ему там не место.
А где ему место? Дизайнер, как и все остальные проектировщики, всегда работает между разработчиками и пользователями. Я имею в виду не написание стилей CSS и тому подобные вещи, которые являются частью процесса разработки, и могут делаться параллельно с написанием кода. Я под работой дизайнера подразумеваю проектирование интерфейса и аналогичные штуки, которые делаются до разработки, а не во время. Он может не коммуницировать непосредственно с пользователем. А может и коммуницировать в каких-то случаях. Но так и или иначе, дизайнер в этом процессе все равно лежит на пути проекта от пользователя к разрабам.lair
25.09.2017 00:33А где ему место?
Рядом с разработчиком, конечно.
Дизайнер, как и все остальные проектировщики, всегда работает между разработчиками и пользователями.
… а проектировщики — они тоже не работают между разработчиками и пользователями. "Между" могут быть аналитики, продакты и QA. А весь дев-тим — он на одной линейке.
Я под работой дизайнера подразумеваю проектирование интерфейса и аналогичные штуки, которые делаются до разработки, а не во время.
Эм, итеративная разработка и прочий аджайл, не?
DrPass
25.09.2017 01:02… а проектировщики — они тоже не работают между разработчиками и пользователями. «Между» могут быть аналитики, продакты и QA. А весь дев-тим — он на одной линейке.
Разработчик работает с проектом после того, как над ним поработали архитекторы, UX-дизайнеры и т.д. Значит, они все находятся перед разработчиком в той цепочке, которая ведет от хотелок заказчика к получению готового продукта.
Эм, итеративная разработка и прочий аджайл, не?
Баловство всё это. Если в команде есть чувак, в задачах которого стоит рисовать диаграмки/макеты, по которым другой чувак будет что-то писать, то либо в каждом забеге первый будет работать перед вторым, либо первый не нужен.lair
25.09.2017 11:13Смотрите, как здорово получается. С одной стороны, вы настаиваете на водопадной модели. А с другой стороны, вы считаете, что какие-то ее участки — только, заметим, ей и навязанные — избыточны. Может просто надо модель сменить?
DrPass
25.09.2017 11:46Смотрите, как здорово получается.
У меня так здорово не получается. У вас какие-то слишком далеко идущие и неочевидные выводы получились. В какой модели вообще допускается, что проектировщик может работать параллельно с разработчиком? Я имею в виду, естественно, работать параллельно над одной и той же фичей проекта, а не над разными.lair
25.09.2017 11:53В какой модели вообще допускается, что проектировщик может работать параллельно с разработчиком?
В той, где emergent design.
Архитектуру же не в замках из слоновой кости придумывают. Оценили требования, прикинули варианты, написали прототипы, сравнили, что получилось, выбрали, начали реализовывать, поняли, что что-то не так, поправили архитектуру, снова реализовали, и так по кругу.
Я уж молчу про такую святую обязанность "проектировщиков" как публичный API.
DrPass
25.09.2017 12:09начали реализовывать, поняли, что что-то не так, поправили архитектуру,
Если это происходит систематически, а не редкими эпизодами, даже в эджайле, то что-то не так в самой команде. Архитектор — он для того и существует, чтобы проектировать архитектуру эффективно, с минимумом переделок в будущем. Кое-как, с «гибкими» изменениями в процессе реализации её в общем случае и разработчик самостоятельно набросает.
В той, где emergent design.
На самом деле суть всего этого — дробление длительного «водопадного» цикла разработки на мелкие короткие ручейки. Вместо годичной последовательности «собрали требования» — «написали талмуд спецификаций» — «разработали» — «мучаемся с подгонкой под реальную жизнь» получается много, допустим, двухнедельных забегов «описали фичу» — «написали спек на фичу» — «реализовали» — «посмотрели, и оставили или переделали как надо в следующем забеге». Сама по себе последовательность работы «проектировщик — разработчик» при этом никуда не делась, и никаких изменений не претерпела. Просто они чаще стали коммуницировать.lair
25.09.2017 12:13Если это происходит систематически, а не редкими эпизодами, даже в аджайле, то что-то не так в самой команде. Архитектор — он для того и существует, чтобы проектировать архитектуру эффективно, с минимумом переделок в будущем.
К сожалению, данная нам (мне) в ощущениях реальность такова, что эффективно можно спроектировать архитектуру недели на две. Потом половина требований поменяется и вперед перепроектировать.
Так что вопрос из "как бы спроектировать с минимум переделок" давно перешел (для меня, опять же) в "как бы спроектировать, чтобы переделывать было дешево".
Сама по себе последовательность работы «проектировщик — разработчик» при этом никуда не делась, и никаких изменений не претерпела. Просто они чаще стали коммуницировать.
Как ни странно, вот это вот "чаще комуницировать" (и вообще разворот потока, с возможностью движения изменений в обе стороны) как раз и играет ключевую роль (и, в том числе, убирает "лишние звенья между").
noodles
25.09.2017 00:16Имел ввиду проектирование интерфейса. А уж после запуска продукта, если уж действительно нужен секси-ui, то можно разово привлечь специалиста с художественным образованием и тонкой душой, который отполирует и наведёт лоск.
noodles
25.09.2017 00:14Да, сможет. Только если не замещать его — дизайнера, а действительно обучиться новой специализации. Повторюсь, что есть мнения, что якобы технарь переквалифировавшийся в дизайнеры — лучше, чем наоборот. И я поддерживаю.
Об этом собственно моя идея, что расширяться не в сторону очередного яп или фреймворка, а в сторону дизайна, таким образом убрав все тёрки между указанными специализациями и воспроизвести всю цепочку самостоятельно. И ещё раз скажу — такому человеку будет проще реализовать крутые интерактивные спецэффекты (от задумки до реализации) основанные на современных возможностях браузеров (свг, канвас, шейдеры, использовать веб-жл и т.д.).lair
25.09.2017 00:32Да, сможет. Только если не замещать его — дизайнера, а действительно обучиться новой специализации.
То есть стать дизайнером самому. Эм. Две специализации в одной голове, хотя каждая из них требует целой головы… не, бывают такие таланты, конечно.
Повторюсь, что есть мнения, что якобы технарь переквалифировавшийся в дизайнеры — лучше, чем наоборот. И я поддерживаю.
И на чем оно основано-то?
И ещё раз скажу — такому человеку будет проще реализовать крутые интерактивные спецэффекты
Мда. Дизайн — он не про это немножко.
michael_vostrikov
25.09.2017 05:09То есть вы думаете
Речь же про full-stack. Это примерно то же самое, что сказать "То есть вы думаете, что фронтенд-разработчик может делать работу бэкенд-разработчика лучше, чем бэкенд-разработчик". В целом может и нет, только разработчики на оба края никуда не денутся.
lair
25.09.2017 11:16Неее.
Есть же чувствительная разница между "делать лучше" и "делать не хуже". Фул-стек — это надежда на то, что один фул-стек разработчик сможет сделать работу фронта и бэка не хуже, чем раздельные фронт и бэк (а выигрыш мы ожидаем из-за того, что нам не надо кормить двух человек, не надо думать, как распределить нагрузку, и не надо тратиться на коммуникации). Мне казалось, ни один разумный человек не ожидает, что фул-стек будет выполнять каждый сегмент работы лучше, чем соответствующий специалист (и с чего бы?).
mrguardian
23.09.2017 19:43Ниразу не fullstack разработчик. Поясните пожалуйста, а зарплату вы таким как за двоих платите?
kloppspb
23.09.2017 20:26Тоже этого никогда не понимал. За двоих — это только при очень грубом делении на back и front :) У нас, например, только backend может делиться на 3-4 области, каждая со своей спецификой, и требующих отдельных специалистов…
hVostt
23.09.2017 23:12-4Один программист хорошо знает циклы, но не знает условия, другой хорошо знает условия, но не знает циклы. Собеседуете человека на вакансию программиста и желаете, чтобы он умел работать и с циклами и условиями, и попробуйте не рассмеяться ему в лицо на «а зарплату вы таким как за двоих платите?». В общем, детский сад какой-то.
ohotNik_alex
26.09.2017 11:03ну как двоим это перебор, но почему их оклад должен быть как у обычного спеца?
если человек знает 2 области (реально знает, а не так поверху шуршит) — он более ценный специалист, позволяющий как минимум балансировать нагрузку команды и в совсем идеальном мире знать весь продукт на уровне взаимодействия между компонентами).
уж молчу о том, что освоение навыков это время и силы. желающие сэкономить работодатели могут брать студента и прививать ему навыки до нужного уровня несколько лет.
в моей практике бывало, что надо очень активно влезать в чужую область чтобы найти источник проблемы. навыки фронта в этом случае сильно выручали, хотя никогда не позиционировался как фуллстэк. а вот без этих навыков сидел бы и ждал пока придет фронт, сядет рядом и расскажет что же он там такого наворотил. поле для маневра у фуллстэка шире.
hVostt
23.09.2017 23:21+2Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, побросать навоз, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать.
Специализация — удел насекомых.
Роберт Хайнлайн, Достаточно времени для любви, 1973
:)AsianCat
23.09.2017 23:40Ага, конечно. Врачи, например. Нахрен им специализация, тело одно и все должны делать.
hVostt
23.09.2017 23:45Уметь не значит постоянно заниматься этим и разбираться в предмете глубоко. Фуллстек программист не обязан иметь глубокие познания во всех сферах разработки абсолютно.
Самая большая проблема в узкоспециализированных (фронт/бек) программистах, что они полностью открещиваются от чужой специализации, что создаёт проблемы и сегрегацию в коллективе.kloppspb
23.09.2017 23:59+1Самая большая проблема в узкоспециализированных (фронт/бек) программистах, что они полностью открещиваются от чужой специализации, что создаёт проблемы и сегрегацию в коллективе.
Это уже какая-то маргинальная ситуация.
Для меня очевидно, что, например, программист, знакомый только с одним языком программирования, с одной ОС, с одной БД — это всего лишь заготовка.
У меня, например, в активе 5 языков, и ещё столько же в пассиве (то есть если припрёт, смогу что-то написать).
Но это не значит, что я должен одинаково хорошо разбираться во всех тонкостях JQuery и PL/SQL одновременно. Иметь крепкое представление о том, что происходит вокруг — да, но это другое.
При этом — да, несмотря на довольно узкую нишу в бэкенде, приходится иногда и JS поправить, и XSLT ковырнуть. Но назвать себя full-stack, тем более выполнять одинаково хорошо всё на всех уровнях — да в пень.hVostt
24.09.2017 00:09Не совсем понимаю тогда в чём вы видите проблему. Возможно вам довелось столкнуться с ситуацией, когда вас за одно и тоже время попросили сделать и фронт и бек, что являются лишь дуростью руководства.
Как вы правильно сказали, фуллстек — это по большей части заготовка. Т.е. человек в состоянии перейти из разработки фронт в бек и обратно. Он понимает как работает, как устроены и как запрограммировать решение для обоих случаев. Самое главное, что он может все ньюансы по взаимодействию учитывать сразу, а не в течении многочасовых ежесуточных переговоров команд. В его активе также может быть лишь по одной технологии для фронт и бек.
Узкая специализация означает, что человек ни морально, ни принципиально не готов покинуть свою вотчину, а в тяжёлых случаях он даже не понимает как оно там на другом берегу вообще работает.kloppspb
24.09.2017 00:21Узкая специализация означает, что человек ни морально, ни принципиально не готов покинуть свою вотчину, а в тяжёлых случаях он даже не понимает как оно там на другом берегу вообще работает.
Можно ещё вспомнить о Козьме Пруткове и флюсе :)
Проблему я вижу в том, что некоторые вещи почему-то доводятся до абсурда ещё на стадии определения. Ну вот кто вам надиктовал именно такое понятие об «узком специалисте»? По мне так это человек, который много чего знает, но сознательно выбрал свою нишу, исходя из совокупности знаний, умений, личных пристрастий, etc.
А что подразумевается под full-stack с точки зрения и HR, и работодателей, я плохо представляю. Во всяком случае сейчас. На рубеже веков — да, это было необходимостью :)hVostt
24.09.2017 00:32Тяжело рассуждать в отрыве от контекста конечно. Но скажите, вы считаете абсурдными утверждения об «двойном объёме работы» для фуллстек программиста или нет? Почему-то именно такой позиции придерживаются «узкие специалисты». Я не понимаю почему. Про пристрастия понятно, это верно даже в отношении стиля кода, библиотек, и т.д.
kloppspb
24.09.2017 00:53вы считаете абсурдными утверждения об «двойном объёме работы» для фуллстек программиста или нет
Нет, не считаю абсурдным.
Потому что именно такие картинки в голове и рисуются: сегодня ты отфотошопь картинку, завтра положи асфальт, а послезавтра вырежи аппендикс.
Почему-то именно такой позиции придерживаются «узкие специалисты»
Вы не путаете действительно специалистов со студентами-недоучками?hVostt
24.09.2017 00:59Забавно, что вы видите проблему в том, что некоторые вещи доводятся до абсурда, и сами же это делаете.
Даже если опустить абсурдность ваших примеров, ок. Сегодня отфотошопь картинку, завтра положи асфальт. Интересно, а где здесь «двойной объём работы»?kloppspb
24.09.2017 01:09а где здесь «двойной объём работы»?
У, как всё запущено…
Вот вы, лично, знаете как правильно класть асфальт?
Какой шовный материал для кого и в каких случаях подходит? Чем кохер отличается от москита?
Каждый из этих случаев отличается нехилым накоплением опыта, и… Стоп. Кажется, я понял: говорю с ребёнком :) Или с троллем.hVostt
24.09.2017 01:15Простите, но я не увидел где здесь двойной объём работы. Или здесь у вас тоже проблемы с определением?
Давайте представим, что укладка асфальта это метафора. Нет я не знаю, как класть асфальт. Это знание наверное передаётся по наследству? Мне его никак и ни в какие сроки не получить?
А программисты, верно, по вашему убеждению, либо знают всё, все библиотеки, все инструменты, все технологии, и никогда не пользуются ни гуглом, ни SO, не обращаются к документации, не задают вопросы на форумах, не обсуждают проблемы в сообществах, либо путь к решению для программиста закрыт.
hVostt
24.09.2017 01:04Вы не путаете действительно специалистов со студентами-недоучками?
Нет. Почему я должен их путать?
DrPass
24.09.2017 02:40Потому что именно такие картинки в голове и рисуются: сегодня ты отфотошопь картинку, завтра положи асфальт, а послезавтра вырежи аппендикс.
Есть некая разница между «сегодня ты отфотошопь картинку, завтра положи асфальт, а послезавтра вырежи аппендикс.» и «сегодня ты сделай REST-сервис, а завтра напиши к нему же форму для просмотра и редактирования». Причем разница принципиальная.
michael_vostrikov
24.09.2017 12:13Допустим, проект требует M единиц работы на фронтентде, N на бэкенде, и C на интеграцию. Два специалиста выполнят работу M+C и N+C, один M+N и возможно сэкономит на C. То есть на одного приходится больше работы. В результате один или будет делать в два раза дольше или сэкономит дополнительно на M и N.
DrPass
24.09.2017 14:47Два специалиста выполнят работу M+C и N+C, один M+N и возможно сэкономит на C. То есть на одного приходится больше работы
Да, но ведь один потратит, допустим, две недели своего времени на N+M, а те два специалиста потратят на это пусть неделю, но потом их все равно нагрузят какой-то другой работой. Никто же не говорит о том, что бэкэндщикам и фронтэндщикам выделяют больше свободных часов на безделье в оплаченное работодателем время.michael_vostrikov
24.09.2017 15:34Как бы да, но одному тоже другую работу дадут. То есть у них одинаковые условия за исключением того, что один имеет больше знаний и делает всё, а другие только часть. И как-то редко бывает, чтобы сроки увеличивали в 2 раза из-за того что full-stack.
Разве что всегда есть разделение — один занимается фронтендом, другой бэкендом, а на другом проекте возможно наоборот. Тогда норм.
nekt
24.09.2017 18:24В итоге мы рискуем получить ситуацию, когда работа, которая должна быть проведена в этапе С — документация контрактов, описание API остается только в голове у разработчика. С тем же успехом можно требовать от программиста навыков тестировщика — сам написал, сам протестировал. Экономия же!
michael_vostrikov
24.09.2017 20:20Документация это вопрос квалификации программиста и организации разработки. Ручное тестирование часто так и делается, до определенного размера проекта. А всякие юнит и функциональные тесты почти всегда пишут сами программисты.
nzeemin
24.09.2017 22:26+1Статья ни о чём. На вопрос в заголовке не отвечает. На очевидные соседние вопросы — например, почему именно сейчас? — не отвечает тоже.
vyatsek
25.09.2017 10:01-1Считаю, что спрос на full-stack спрос будет только увеличиваться. С увеличением уровня доступности информации, на первый план выходят способности к обучению, кто быстрее учится и познает, тот и будет на шаг впереди.
Вообще не понимаю деление на front-end, back-end, люди которые умеют писать код и делать продукт, сделают одинаково хорошо и там и там.
На личном опыте и не в одной команде видел как люди легко изучали технологии: базовым был C++, потом C#, потом HTML+CSS+javascript.
В современном мире нет вопроса знаешь технологию или нет, есть вопрос, за сколько сможешь изучить.lair
25.09.2017 11:17В современном мире нет вопроса знаешь технологию или нет, есть вопрос, за сколько сможешь изучить.
Если продукт надо писать сейчас, то очевидно, выгоднее те, кто технологию знают, а не будут изучать. Разве нет?
vyatsek
25.09.2017 14:17Как правило слаженную профессиональную и продуктивную команду собрать намного сложнее, чем выучить технологию. Более того хороший разработчик так или иначе знает еще какие-то технологии помимо основных.
А если случится так, что 1-2 человека неплохо знают нужные технологии, «расшарить» знания проблемы не составит.
Поиск технологического знатока целесообразен для написания фреймворков, если говорить про продуктовые команды, то там нужны программисты думающие, а не знающие.lair
25.09.2017 14:21Как правило слаженную профессиональную команду собрать намного сложнее, чем выучить технологию.
Ну да, несколько месяцев (или лет) постоянной работы с технологией, какие мелочи, право слово.
А если команде случится так, что 1,2 человек неплохо знают нужные технологии, «расшарить» знания проблемы не составит.
Ага, давайте потратим несколько месяцев (всей команды) на шаринг знаний.
vyatsek
26.09.2017 02:50-1>Ну да, несколько месяцев (или лет) постоянной работы с технологией, какие мелочи, право слово.
Возможно вы просто «тормоз» и для вас обучение — тяжело, по этому вы придаете такую важность знанию технологий, либо у вас просто мало опыта.
>Ага, давайте потратим несколько месяцев (всей команды) на шаринг знаний.
На самом деле не так много для инвестиций в знания профессионалов.
А за какой срок вы создадите сплоченную команду в которой у каждого члена присутствуют нужные навыки?
Вы либо никогда не нанимали, либо никогда не работали с профессионалами.ohotNik_alex
26.09.2017 11:13+1ммм… эти профессионалы научили вас хамить незнакомым людям?
полностью согласен с товарищем выше.
то что человек у себя в резюме написал «знаю джаву» не тождественно «могу обучить». если бы все было так просто — дефицита на рынке не было бы. я вот джаву выучил за 2 недели) а последующие 7 лет просто ее доучиваю и оттачиваю. из десятков книг я видел только в одной описание бага банального синглтона на десереализации и путей его обхода. что, студент прочтет их все за неделю и будет знать такие мелочи? поработайте «в поле». а то веет диванным специалистом, чес слово.
кроме того вы же сами написали — на собственном опыте ВИДЕЛИ как учат. попробовать не судьба самому? а то как заяц в мультике «вы не правильно топитесь».
lair
26.09.2017 11:30Возможно вы просто «тормоз» и для вас обучение — тяжело, по этому вы придаете такую важность знанию технологий, либо у вас просто мало опыта.
Да, конечно, я тормоз, и мне тяжело учиться. И, конечно, у меня мало опыта. Что еще?
На самом деле не так много для инвестиций в знания профессионалов.
Для проекта с планируемой продолжительностью в три месяца?
Вы либо никогда не нанимали, либо никогда не работали с профессионалами.
Конечно-конечно. Я, правда, создал с нуля отдел разработки в одной неизвестной компании, но, конечно, никогда не нанимал и не работал с профессионалами. И вообще сварщик ненастоящий, маску на свалке нашел.
sentyaev
26.09.2017 02:12Если продукт надо писать сейчас, то очевидно, выгоднее те, кто технологию знают, а не будут изучать. Разве нет?
Странно то, что тут проблема не в изучении. Языки/технологии стали скорее религией для большей части разработчиков. Попросить .net разработчика запилить nodejs приложение… да на тебя как на неверного посмотрят.
Я вот в веб разработке параллельно веду два проекта на .net и nodejs, плюс есть pet project на python, так я особой разници между технологиями не вижу. Библиотеки/фреймворки очень похожи, в языках тоже разница минимальна.vyatsek
26.09.2017 02:42Адептов религии сразу ф топку ) Есть разные инструменты надо уметь объективно оценивать плюсы/минусы и область применения.
lair
26.09.2017 11:28Языки/технологии стали скорее религией для большей части разработчиков. Попросить .net разработчика запилить nodejs приложение… да на тебя как на неверного посмотрят.
А при чем тут религия? Вот приходите вы к .net-разработчику в компании, занимающейся .net-разработкой, с предложением "запилить node.js", а он просто оценивает, сколько тулинга придется поменять/добавить, и задает разумный вопрос: а зачем?
Я вот в веб разработке параллельно веду два проекта на .net и nodejs, плюс есть pet project на python, так я особой разници между технологиями не вижу. Библиотеки/фреймворки очень похожи, в языках тоже разница минимальна.
… а если не видите, то зачем использовать больше одного?
artemt
25.09.2017 11:34Вопрос ведь не в том, чтобы изучить, а в поддержке знаний на актуальном уровне. И чем шире область твоих знаний, тем больше с этим проблем. Изучить новое не задача, проблема в том, кто будет поддерживать твоё изученное старое. И вот здесь крупным компаниям и нужен fool-stack для того, чтобы легаси код продолжал скрипеть с минимальными затратами. В моём случае это T-SQL, C#, VBScript, JScript, JavaScript, XSLT, CSS и небольшой палеозоопарк фреймворков и библиотек.
Есть другой full-stack, который на фрилансе клепает типовые сайты магазинов, например. Как правило, это PHP + WordPress + CSS + JQuery или что-то вроде того. Вполне достойная работа.
Более половины проголосовавшим следует крепко подумать, стоит ли развиваться в этих двух направлениях.
zodchiy
25.09.2017 15:37В защиту фулстеков.
Фулстэк в основном, по моему опыту, это не про стартапы и продукты, а про корпоративщину.
Причем профиль компаний мало связанный с IT.
Почему? Краеугольный камень — время.
Зачастую, компания для своих внутренних нужд необходимы люди, для которых не надо ТЗ, максимум обсуждение на митинге.
Никаких ПМ-ов, лидов и архитекторов, вообще. Между тобой и заказчиком только кружка кофе.
У меня 80% задач ставятся даже не письменно, а устно, например:
— Помнишь проект ХХХ? Вот надо сделать также, только в другую сторону от контрагентов, ок? В пятницу тестируем. — или
— Видел ХХХ, ты глянь в исходниках как написали YYY, нам нужно вырезать его в виде нового проекта под другие нужды.
Короче, делаем новый UI, переносим данные на новую структуру, делаем синхронизацию в обе стороны, 4 дня хватит? — Вот и все ТЗ (последнее тз этого утра). Ты сам в голове видишь и UI, и данные, и бэкэнд.
Сам выбираешь технологии. Бизнесу наплевать, что ты там используешь, Angular + NodeJS или React + C#, хоть JQuery + PHP. Ему важен результат, сейчас.
Хуяк-хуяк и в продакшн, но с максимальной, личной отвественностью. За ошибки бьют очень и очень больно.
Слово рефакторинг под запретом, совсем, ну дома если хочешь посиди, поковыряй.
На такие позиции берут именно таких людей, которым не надо ТЗ, не надо описывать как оно должно выглядеть, как должно функционировать, и он должен делать это быстро и качественно.
Все остальное — красиво, много, долго, внешний и очень важный продукт, это отдается на аутсорс.
Если проект по плану меньше полугода, то отдается внутренним фулстекам.
В нашей компании в данный момент 4 фулстек разработчика и ни одного фронтэндщика, хотя мы честно пытались нанять уже два года как и не смогли.
Все уходили, им не понятно как так можно работать.artemt
25.09.2017 16:04+1В чём выгода такого full-stack для бизнеса в лице менеджеров понятно. Но раз уж это слово в защиту. Зачем начинающим программистам стремиться к такому "счастью"?
zodchiy
25.09.2017 16:11Ну, есть разные программисты. И для них всех разная мотивация.
Если разработка как способ решения задачи, это то, к чему лежит душа, то выбор в пользу фулстека очевиден. Ты решил задачу, сам, полностью. Придумал, спроектировал, реализовал, протестировал, релиз, поддержка.
Ну и плюс выбор технологий за тобой, зачастую.artemt
25.09.2017 17:00Программисты любят решать задачи, это так. Отсюда совсем не следует предпочтение full-stack. Большие задачи проще решать группой.
Выбор технологий самим разработчиком — во многом миф. Потому что "краеугольный камень — время", "хуяк-хуяк и в продакшн", "глянь в исходниках", "результат сейчас", "рефакторинг под запретом" и т.п… Но иногда случается. Тогда к нашему зверинцу добавляется новый зверёк :)
zodchiy
25.09.2017 18:32-1Большие задачи проще решать группой.
Я так и написал.
Все остальное — красиво, много, долго, внешний и очень важный продукт, это отдается на аутсорc
michael_vostrikov
25.09.2017 18:17+1Потом разработчику однажды это выходит боком (я тебе не так сказал, ты просто не так понял), надоедает разбираться после работы в чужом коде (потому что надо завтра, а за день не успел, он же нерефакторенный), править постоянные баги и отвечать за чужие ошибки (кто-то поменял функцию, а сломалось у тебя), наступает выгорание и пофигизм к работе. А понятие фуллстек тут ни при чем.
zodchiy
25.09.2017 18:29-1Потом разработчику однажды это выходит боком (я тебе не так сказал, ты просто не так понял
Значит что-то сам не спросил, или не понял. Дело в разработчике.
надоедает разбираться после работы в чужом коде
???? Ты сам разработчик своего проекта, откуда там чужой код? Очень редко приходится чужой код не только менять, но и даже читать.
править постоянные баги
Ну смотря как напишешь.
отвечать за чужие ошибки (кто-то поменял функцию, а сломалось у тебя)
Опять же, проект твой и только твой.
А понятие фуллстек тут ни при чем.
Вы похоже не читали, что я написал. Совсем.lair
25.09.2017 18:51Значит что-то сам не спросил, или не понял. Дело в разработчике.
Да-да-да, всегда виноват исполнитель.
Проблема в том, что телепатию завезли не всем, а работа аналитиком — она, того, сложная.
zodchiy
25.09.2017 19:32Тут есть тонкость. Именно этого качества и ждут таких разработчиков.
Которым, или такого ТЗ достаточно для работы над проектом, или они задолбают вопросами заказчика до полного понимания проекта.
Я сам когда опять вернулся на фулстек, с проектов где есть фронт/бэк, аналитики, пм-ы, архитекторы и преферанс с тестировщиками, очень по этому поводу переживал. Но это как ездить на велосипеде, быстро вспоминаешь как это.
Даже было такое — заказчик нанял аналитиков (ввел в штат), чтобы описали ТЗ, пока они писали, требования менялись и менялись, аналитики писали и писали. И пока они писали ТЗ, конкурент, который начал разработку после нас (наш топ на конференции похвастался проектом), выпустил свой сервис, а мы нет.lair
25.09.2017 22:34+1Тут есть тонкость. Именно этого качества и ждут таких разработчиков.
"Этого качества" — это телепатии? Ну давайте я вам расскажу, как это бывает:
Которым [...] такого ТЗ достаточно для работы над проектом
"Конечно, такого ТЗ достаточно для работы над проектом," — думает наш программист, и идет делать "как в проекте XXX, но для проекта YYY с мелкими правками по месту". Все начинается с того, что проект XXX делал гениальный разработчик, уволившийся два года назад и уехавший в Австралию. И, поскольку он гениальный, он делал его на собственном диалекте лиспа (он все на нем делал, потому что ему так было удобно). Никаких требований на XXX нет, никаких тестов тоже нет, есть только исходники на этом прекрасном языке. Потом внезапно выясняется, что между XXX и YYY общего только автокомплит в формочке ввода адреса, который и имели в виду под "сделай как", но совершенно забыли сказать, что раньше адреса были по КЛАДРу, а теперь по ФИАС, и системы автозагрузки ФИАС, конечно, нет (и она входит в доработку). А, да, и еще забыли сказать, что все это делается только в защищенной системе обмена секретными данными, доступ к тестовой среде которой оформляется за два месяца.
Преодолев все это, наш талантливый программист слышит две вещи. Во-первых, "что так долго? надо было три месяца назад, мы думали, ты все за день сделаешь, там работы-то...", и, во-вторых, "эммм, но это вообще не то, что нам надо. Нам надо было точку на карте кликнуть и реверс-геокодирование, а у тебя зачем-то текстовая форма ввода. Так сложно было догадаться, не?"
На третий (второй, если умный, и сразу после первого, если шибко сильно умный) раз наш программист понимает, что телепат из него не вышел, и переходит ко второму варианту:
они задолбают вопросами заказчика до полного понимания проекта.
… ключевое слово в котором "задолбают". Заказчик не любит быть задолбан. У него есть бизнес, который его задалбывает, ему не хочется, чтобы его еще и задалбывали программисты, которые денег не приносят, а только жрут. И тем более он не любит, когда эти программисты сомневаются в каждом его слове, переспрашивают по четыре раза, а потом говорят, что это предложение противоречит сказанному пять минут назад. Оно не противоречит, оно дополняет. Просто посмотрите на проблему с другой стороны. И еще прочитайте ФЗ-18, ФЗ-46 и ФЗ-282 (только обязательно свежую редакцию). И вот эти методические рекомендации, в них все написано. Они, правда, через месяц сменятся на новые, но вы же успеете закончить раньше, правда?
[...]
Вы знаете, я люблю разрабатывать системы. Уточнять неясные требования, придумывать дизайн, выбирать технологии. Писать разработческие тесты. Прикручивать систему развертывания. Но я терпеть не могу все то, что описано выше (и это мы еще не дошли до тестирования). Так что я предпочту забыть это, и никогда больше не вспоминать.
michael_vostrikov
26.09.2017 05:26+1требования менялись и менялись… конкурент, который начал разработку после нас, выпустил свой сервис, а мы нет.
Может у него требования не менялись?)
artemt
25.09.2017 19:42+1Ты сам разработчик своего проекта, откуда там чужой код?
А вдруг ты уволишься? Что делать компании? Она пойдёт к условной "Hays Russia" и попросит найти им full-stack разработчика. Зачем компании это понятно. Зачем молодому программисту в это вляпываться?
Имхо, почему сейчас растёт спрос на full-stack в корпоративном секторе. Из-за кризисных времён компании заморозили многие проекты и сократили штат команд. В сокращённых командах как крысиные волки выросли full-stack поддерживальщики корпоративных штанов. Но они мигрируют, места освобождаются а штаны нужно поддерживать. Менеджер не может сказать высшему руководству, что вместо Васи, который со всем худо бедно справлялся, надо целую команду нанимать. Поэтому ищут fool-stack. А молодёжи дуют в уши как это круто и как их будут ценить.
michael_vostrikov
25.09.2017 20:01+2Значит что-то сам не спросил, или не понял. Дело в разработчике.
"Я же спрашивал у вас про то-то и то-то, вы сказали не надо — Не помню ничего такого, я тебе наверно про другое говорил". Что именно еще должен был спросить разработчик, если уже получил ответ, что не надо?
???? Ты сам разработчик своего проекта, откуда там чужой код?
Например отсюда: "ты глянь в исходниках как написали YYY, нам нужно вырезать его в виде нового проекта".
Или "вот тебе проект, его писал человек, который уволился полгода назад, надо добавить кое-что". Возможно кто-то из ваших коллег.
Или вы сами уволитесь, и кому-то придется поддерживать ваш код.
Ну смотря как напишешь.
Ну как, без ТЗ и рефакторинг под запретом. А на тесты времени нет.
Опять же, проект твой и только твой.
Опять же, это может поменяться.
Но да, если проекты настолько маленькие, то можно и так работать, если нравится. Только это не пример для подражания.
Вы похоже не читали, что я написал. Совсем.
Прочитал и не согласен с вашим определением full-stack програмиста. Full-stack != бардак.
lasalas
26.09.2017 11:55…
Какой ему срок и подробный паек,
конечно, особый вопрос,
Но скверно, что он ни пехота, ни флот,
ни к этим, ни к тем не прирос,
Болтается, будто он дуромфродит,
диковинный солдоматрос.
…
(Р. Киплинг)
lair
Серьезно?
DrPass
Я туда заходил, нормальный такой сайт. Исходники разного софта есть, некоторые даже с комментариями. В общем, рекомендую.
tangro
Надо будет посмотреть как-то…
KinsleR
Уже хорошо что кадровики про такое слышали :)
lair
Почему?
KinsleR
Потому что наши думали что JS и JavaScript разные вещи :(
manefesto
Некоторые наоборот, думают что Java и java Script это одно и тоже
lair
И что, знание о наличии GitHub как-то помогает в этом вопросе?
sidny_vicious
Мне один раз кадровик доказывал, что JavaScript — это Java для работы на клиенте, которая даёт пользователю возможность работать с базой данных напрямую, без использования сервера и поэтому ни Java, ни сервера вообще не нужны. Нужен только клиент. После этого я решил не идти на работу в эту компанию.