100% remote - Full stack - Web.API 2, C#, SQL, EF, Angular - есть 5 вакансий

[stenking]

Фул стак не работает. Точнее конечно любой бакенд чувак должен уметь HTML написать что бы дату показать но потом туда обязательно должен залесть фронтенд чувак и этот HTML зачистить и стили написать. И конечно фронтенд чувак не должен разбиратся в логике но вполне себе может какое-то поле в API добавить.

Т.е. любая задача должна проходить хотя бы минимальный цикл: хотелка => обсуждение => оценка => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => продакшин.

А дальше усложнение может быть до бесконечности. например:

хотелка => обсуждение => оценка => ахкитектор=> дизайин => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => А/Б => userbase subset => KPI => production

T.e. в цепочке должно участвовать больше чем 1 человек как не крути а 3 или 10 уже большой разницы нет. Поэтому сократить одно звено и заменить бакенд => фронтенд на фулстак реально ничего не упрощает а вот качество кода и скорость разработки понижает значительно.

Совет автору: поработать над процессом

[Andrey Strelnikov]

Раз ждут, значит команда не сбалансирована. Вы серьезно полагаете, что есть люди, которые однаково хорошо и базы дизайнят, и квери с сервисами пишут, и UI ваяют так, что глазу приятно? В вашей конкретной ситуации мне представляется, что ни model, ни даже квери (а значит и сервис) вашим full-stack писать врядли придется. Максимум багу найти в чем-то готовом. Скорее уклон в UI, т.е. view и controller. Я не прав?

-- и UI ваяют так, что глазу приятно--
Ну html им уже нарезали.
А
--model, ни даже квери--
T-SQL у шарписта от зубов должен отлетать. Не джавист чай с ораклом. Просто MS инструментарий и документация не отнимают столько сил и времени.

[Oleg-NY]

Фул стак не работает. Точнее конечно любой бакенд чувак должен уметь HTML написать что бы дату показать но потом туда обязательно должен залесть фронтенд чувак и этот HTML зачистить и стили написать. И конечно фронтенд чувак не должен разбиратся в логике но вполне себе может какое-то поле в API добавить.

Т.е. любая задача должна проходить хотя бы минимальный цикл: хотелка => обсуждение => оценка => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => продакшин.

А дальше усложнение может быть до бесконечности. например:

хотелка => обсуждение => оценка => ахкитектор=> дизайин => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => А/Б => userbase subset => KPI => production

T.e. в цепочке должно участвовать больше чем 1 человек как не крути а 3 или 10 уже большой разницы нет. Поэтому сократить одно звено и заменить бакенд => фронтенд на фулстак реально ничего не упрощает а вот качество кода и скорость разработки понижает значительно.

Совет автору: поработать над процессом

Там, имхо, синдром маленькой компании. Качественный и количественный порог еще не пройден.

[stenking]

Там, имхо, синдром маленькой компании. Качественный и количественный порог еще не пройден.

У меня тоже маленькая компания но без цепочки ж**а и бардак. Особенно при удалённой команде.

[FreemanUSA]

у меня все рисуется нормально (xром и фф)
а как Вы добились чтоб растягивало?

Safari

Не чего сложного, они допустили небольшую ошибку в CSS не дописав пару деректив. Из -за этого дебагю всегда юзер итерфэйс в Safari & Explorer самые корявые браузеры.

[Slava V]

Фул стак не работает.

у нас работает, что мы делаем не так?

любая задача должна проходить хотя бы минимальный цикл: хотелка => обсуждение => оценка => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => продакшин.

чаще это выглядит так:

хотелка => обсуждение => оценка => бекедн => фронтенд => бекедн => фронтенд => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => продакшин.

(в процессе реализации вылезают новые подробности, меняются контракты методов, нужны измененния в UI/API)

[Oleg-NY]

Раз ждут, значит команда не сбалансирована. Вы серьезно полагаете, что есть люди, которые однаково хорошо и базы дизайнят, и квери с сервисами пишут, и UI ваяют так, что глазу приятно? В вашей конкретной ситуации мне представляется, что ни model, ни даже квери (а значит и сервис) вашим full-stack писать врядли придется. Максимум багу найти в чем-то готовом. Скорее уклон в UI, т.е. view и controller. Я не прав?

-- и UI ваяют так, что глазу приятно--
Ну html им уже нарезали.
А
--model, ни даже квери--
T-SQL у шарписта от зубов должен отлетать. Не джавист чай с ораклом. Просто MS инструментарий и документация не отнимают столько сил и времени.

Это с какого перепуга именно T-SQL и именно у шарписта-то? Я бы еще согласился с просто SQL. Уж не намекаете ли вы, что всю бизнес-логику надо непременно в stored procedure хранить, а сервис это так, чисто данные туда-сюда? У ТС, кстати, явно EF указан. Видимо неспроста! ))

[Slava V]

Это с какого перепуга именно T-SQL и именно у шарписта-то? Я бы еще согласился с просто SQL. Уж не намекаете ли вы, что всю бизнес-логику надо непременно в stored procedure хранить, а сервис это так, чисто данные туда-сюда? У ТС, кстати, явно EF указан. Видимо неспроста! ))

у нас SQL server, stored procedures тоже xватает

[Oleg-NY]

Это с какого перепуга именно T-SQL и именно у шарписта-то? Я бы еще согласился с просто SQL. Уж не намекаете ли вы, что всю бизнес-логику надо непременно в stored procedure хранить, а сервис это так, чисто данные туда-сюда? У ТС, кстати, явно EF указан. Видимо неспроста! ))

у нас SQL server, stored procedures тоже xватает

Я догадывался, что не Oracle или MySql. )) Некоторые вещи реально эфективнее делать в процедурах, но не факт, что это правильный подход в принципе. Лишняя зависимость от Мелкософта.

[stenking]

у нас работает, что мы делаем не так?

чаще это выглядит так:

хотелка => обсуждение => оценка => бекедн => фронтенд => бекедн => фронтенд => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => продакшин.

(в процессе реализации вылезают новые подробности, меняются контракты методов, нужны измененния в UI/API)

например можно улучшить стадию планирования. Во вторых отделять фукционал от презентации /лейблов. Т.е. бэкенд дожен не разбиратся почему тут лоадер сьехал и не пытатся сделать красивый еффект при нажатии и тексты вылизывать но вполне себе должен отлично знать клиента что бы уметь сложную логику закодировать. Бекенд должен изменить API и сделать работающую штуку которая страшно выглядет. А фронтэнд должен с неё сделать конфекту. Иногда даже нужно 3 человека тута: бекенд ( базы и API ) + фронтенд ( ангулар/реакт ) + красавчик ( стили, HTML, effects, браузеры )

Т.е. 2 мин, 3 желательно. А вы это ходите одним человеком заменить а так не бывает.

[Slava V]

у нас работает, что мы делаем не так?

чаще это выглядит так:

хотелка => обсуждение => оценка => бекедн => фронтенд => бекедн => фронтенд => бекедн => фронтенд => код ревью => общее ревью => QA => тестировка => продакшин.

(в процессе реализации вылезают новые подробности, меняются контракты методов, нужны измененния в UI/API)

например можно улучшить стадию планирования.

говорю же, "в процессе реализации"

я видел эти монстроидные сессии по планированию (попытка из каждой истории сделать mini-waterfall) - занимают туеву xучу времени а толку чуть

Во вторых отделять фукционал от презентации /лейблов.

удивительно, кто бы догадался?

Т.е. 2 мин, 3 желательно. А вы это ходите одним человеком заменить а так не бывает.

бывает, см. выше
но не везде, тут я согласен
если человеку удобнее забиться в свою норку и не пробовать что-то другое (xотя ему помогут, научат, если надо то дадут время пройти пару курсов на pluralsight) - из такиx действительно не выйдет full-stack

[Slava V]

Некоторые вещи реально эфективнее делать в процедурах, но не факт, что это правильный подход в принципе. Лишняя зависимость от Мелкософта.

не вижу проблемы.
когда-то возможность поменять базу преподносилось как крутая фича, но за 25+ лет я ни разу не видел чтоб это реально делали в мало-мальски большиx проектаx - без сноса всего остального
замену sql на nosql видел, а вот замену sql server на oracle - нет.

[Oleg-NY]

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

Причем тут удобство? Это вопрос эффективности и качества, а значит производительности труда. Пробовать можно что угодно для расширения кругозора, но набивать руку скорее всего будете чем-то одним. Нет, ну бывают наверное монстры, которым все равно, типа "куем все!". Однако в реальности комнаду приходится набирать из простых людей...

[stenking]

бывает, см. выше
но не везде, тут я согласен
если человеку удобнее забиться в свою норку и не пробовать что-то другое (xотя ему помогут, научат, если надо то дадут время пройти пару курсов на pluralsight) - из такиx действительно не выйдет full-stack

Нет, не бывает никогда. Нет программистов которые одинаково хорошо знаю сложный бекенд, сложный фротн-енд и сложную презентацию. Всегда есть уклон в что-то одно. И дело не в курсе а в том что одно всегда заберёт от друго-го. Если у вас есть 10000 часов которые вы потратите на фронтенд то вы будете мастером в ангулярах/реактах/реакт натив и прочих сложных фронт-ендах. Если вы вестральщик то будете писать краисивейший HTML -со всякими сложными еффектами, спрайтами, продвинутой оптимизацией, всякими красивостями и подсказами. Если нужно настроить CI/doker всякие бекеапы, деплоументы, репликации мониторинги то нужно там потратить несколько лет что бы стать профессионалом. А за эти несколько лет сильно шагнёт впрерёд всё остальное.

Поэтому ваши фул стаки вполе себе возможно до сих пор используют всякие штучки которые уже давно устарели ( например CSS пишут а не SASS/LESS )

[Slava V]

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

Причем тут удобство? Это вопрос эффективности и качества, а значит производительности труда. Пробовать можно что угодно для расширения кругозора, но набивать руку скорее всего будете чем-то одним. Нет, ну бывают наверное монстры, которым все равно, типа "куем все!". Однако в реальности комнаду приходится набирать из простых людей...

все так
но и суперкрутые задачи встречаются нечасто (и достатются при этом "спецам")
а обычное, ежедневное - вполне по силе всем - было бы желание

[Oleg-NY]

Некоторые вещи реально эфективнее делать в процедурах, но не факт, что это правильный подход в принципе. Лишняя зависимость от Мелкософта.

не вижу проблемы.
когда-то возможность поменять базу преподносилось как крутая фича, но за 25+ лет я ни разу не видел чтоб это реально делали в мало-мальски большиx проектаx - без сноса всего остального
замену sql на nosql видел, а вот замену sql server на oracle - нет.

Я не знаю вашего продукта и бизнес модели, но если продукт продается с опциями хочешь платить за MSSQL или Oracle, не вопрос, а не хочешь, то вот тебе то же самое с MySql, это дает определенное преимущество на рынке.

[Slava V]

Нет, не бывает никогда. Нет программистов которые одинаково хорошо знаю сложный бекенд, сложный фротн-енд и сложную презентацию. Всегда есть уклон в что-то одно. И дело не в курсе а в том что одно всегда заберёт от друго-го. Если у вас есть 10000 часов которые вы потратите на фронтенд то вы будете мастером в ангулярах/реактах/реакт натив и прочих сложных фронт-ендах. Если вы вестральщик то будете писать краисивейший HTML -со всякими сложными еффектами, спрайтами, продвинутой оптимизацией, всякими красивостями и подсказами. Если нужно настроить CI/doker всякие бекеапы, деплоументы, репликации мониторинги то нужно там потратить несколько лет что бы стать профессионалом. А за эти несколько лет сильно шагнёт впрерёд всё остальное.

Поэтому ваши фул стаки вполе себе возможно до сих пор используют всякие штучки которые уже давно устарели ( например CSS пишут а не SASS/LESS )

у нас фулл стаки как раз перенимают новые феньки друг у друга - он и не узнает про SASS/LESS пока на него не наткнется в нашем проекте - попросит объяснить как оно работает и станет пользоваться

не бином Ньютона.

[Slava V]

Некоторые вещи реально эфективнее делать в процедурах, но не факт, что это правильный подход в принципе. Лишняя зависимость от Мелкософта.

не вижу проблемы.
когда-то возможность поменять базу преподносилось как крутая фича, но за 25+ лет я ни разу не видел чтоб это реально делали в мало-мальски большиx проектаx - без сноса всего остального
замену sql на nosql видел, а вот замену sql server на oracle - нет.

Я не знаю вашего продукта и бизнес модели, но если продукт продается с опциями хочешь платить за MSSQL или Oracle, не вопрос, а не хочешь, то вот тебе то же самое с MySql, это дает определенное преимущество на рынке.

ну, это вообще отдельный разговор, тогда да, надо писать чтоб работало на всем (полагаю, в итоге получится франкенштейн)

[stenking]

у нас фулл стаки как раз перенимают новые феньки друг у друга - он и не узнает про SASS/LESS пока на него не наткнется в нашем проекте - попросит объяснить как оно работает и станет пользоваться

не бином Ньютона.

Вы не слышите что я говорю. У вас есть Х часов. Мы можете потратить их на 3 разных предмета или совершенствовать 1. 3 узких специалиста ( хирург, анастезиолог и медсестра) при хорошо выстроенном процессе эффективнее 3-х специалистов широкого профиля ( 3 семейных доктора )

[Oleg-NY]

ну, это вообще отдельный разговор, тогда да, надо писать чтоб работало на всем (полагаю, в итоге получится франкенштейн)

Ну точно не франкенштейн. Оного нам здесь уже показывали... )) Все может быть весьма красиво, но может не так быстро. На одном сервере... однако если спроектировано изначально правильно, то масштабирование не проблема.

[Slava V]

у нас фулл стаки как раз перенимают новые феньки друг у друга - он и не узнает про SASS/LESS пока на него не наткнется в нашем проекте - попросит объяснить как оно работает и станет пользоваться
не бином Ньютона.

Вы не слышите что я говорю. У вас есть Х часов. Мы можете потратить их на 3 разных предмета или совершенствовать 1. 3 узких специалиста ( хирург, анастезиолог и медсестра) при хорошо выстроенном процессе эффективнее 3-х специалистов широкого профиля ( 3 семейных доктора )

имxо, это передергивание

выучиться на xирурга занимает несколько больше времени, чем научиться пользоваться SASS/LESS

У вас есть Х часов. Мы можете потратить их на 3 разных предмета

опыт показывает, что обычно эти X часов тратятся на всякую фигню - типа срача на привете по поводу того, можно ли фулл стаку на приемлемом уровне научиться писать HTML

[Slava V]

ну, это вообще отдельный разговор, тогда да, надо писать чтоб работало на всем (полагаю, в итоге получится франкенштейн)

Ну точно не франкенштейн. Оного нам здесь уже показывали... )) Все может быть весьма красиво, но может не так быстро. На одном сервере... однако если спроектировано изначально правильно, то масштабирование не проблема.

в смысле - если я должен поддерживать 3 разные базы, то под интерфейс с Business Layer мне надо написать 3 data layers - каждый со своим кодом (включая api и sprocs)
я что-то упустил?

[stenking]

выучиться на xирурга занимает несколько больше времени, чем научиться пользоваться SASS/LESS

Когда вы поработаете с теми кто только пишет HTML/SASS 10 лет то тогда вы и почувствуете разницу

А так на приемлемом уровне и я смогу Только мне это займёт в 10 раз дольше, будет х 2 раза больше кода и будет глючить для половины пользователей.

П.С. А вообще, один ремонт дома своими силами сразу мозги про фул стаков на место ставит

[Slava V]

выучиться на xирурга занимает несколько больше времени, чем научиться пользоваться SASS/LESS

Когда когда вы поработаете с теми кто только пишет HTML/SASS 10 лет то тогда вы и почувствуете разницу

уже
разницу увидел только одну - они не желают заниматься ничем другим - в итоге все получается медленнее (см выше)

но я не сомневаюсь, что где-нибудь в суперкрутыx компанияx (где делают, напирмер, игры) такие спецы пришлись бы очень кстати.

А вообще, один ремонт дома своими силами сразу мозги про фул стаков на место ставит

да-да, так и представляю как специалист по использованию дрели и специалист по использованию пилы несколько часов планируют свои действия, а потом постоянно ждут друг друга

[stenking]

разницу увидел только одну - они не желают заниматься ничем другим - в итоге все получается медленнее (см выше)

Поломанный процесс. Нет запланированных задач задолго вперёд, еффективной системы тикетов и т.д.

Т.е. хирург ждёт пока медсестра давление поменяет а анастезиолог забыл что утром пациент.