Чтобы развивать свои компетенции не только вглубь, но и вширь. После того как изнутри понимаешь, как используется результат твоего труда, это очень увеличивает качество твоего результата.
Задачи разработки пользовательского интерфейса и бэкенда
Как ни странно, большая часть задач на фронте и на бэкенде абсолютно одинаковые.
Мы берем данные (из СУБД или кэша в случае с бэком и из бэкенда или хранилища состояния (redux/mobx/rxJs) в случае с фронтом), выполняем некоторые преобразования и отдаем их потребителю (фронту в случае с бэком или компоненте визуализации в случае с фронтом). Специфичные регулярно возникающие задачи — это проектирование СУБД и интерфейсов — для бэка и верстка — для фронта.
Как сделать, чтобы крутой бэкендер не залип на несколько дней с верстальной задачей?
достаточно хорошо декомпозировать задачу (чтобы занимала не больше дня) и прийти на помощь разработчику, если в ожидаемый срок результата нет
у кого лучше получается, тот и берет как бороться со специализацией?
постепенно. Сначала давать небольшой объем несвойственных задач, потом контролировать результат и удовлетворенность разработчика от того, что он делает. Если совсем не его, то не давать такой тип задач. Но у нас разве что верстку не все любят, а с остальным таких проблем я не замечаю
Все это в купе с переходом от типизации C# должно сказаться на процессах обеспечивающих качество
от типизации C# мы перешли к типизации typescript
Измеряли ли вы (а потом сравнивали) показатели качества?
Для нас показатели качества всегда были в приоритете. К нам возвращаются наши Клиенты за разработками нового ПО, для меня это самый главный показатель. Говорят, что им очень нравится наша скорость работы и недельные спринты с понятным результатом
у вас все разработчики фулл-стеки, а значит дороже
Фулстеки бывают разные. Джуны, мидлы, сеньоры. З/п зависит от общего уровня
Кто-то может выполнять задачу, в которой не является специалистом (например, мобильная разработка), а значит будет делать дольше, а значит дороже
Это так, но мы идем на эти потери (надо сказать, очень небольшие) сознательно. У нас соотношение серверной/WEB/мобильной разработки часто меняется. Поэтому нужны надежные резервы во всех направлениях.
Код-ревью подразумевает, что все будут либо распыляться на три платформы (фронт, бэк, мобилки)
Я предпочитаю формулировку «набираться опыта в трех платформах»
сделали как сделали, а потом тянем деньги на суппорт
Нет, у нас не такая бизнес модель. У нас есть бесплатная тех-поддержка для наших решений (от полу года до года в зависимости от проекта). Поэтому для нас траты на тех. поддержку — это минус и мы стремимся делать так, чтобы Клиенты возвращались с запросами на новые фичи или системы, а не за исправлением багов.
так исторически сложилось)
заголовок взят из предыдущей статьи.
про кросс платформенность, да в .Net Core с этим ok
но основной смысл перехода на node.js был именно в унификации стека, а не кросплатформенности, поэтому как не называй статью, смысл не поменяется)
Большое спасибо всем, кто не прошел мимо и оставил комментарии!
Я понял, что тема перехода с .Net на node.js оказалась не раскрыта и поэтому написал продолжение на основании личного опыта
Максим, спасибо за статью. Пара вопросов:
Есть ли у вас метрики, показывающие то, насколько жизнеспособен девелоперцентричный подход к обработке уязвимостей?
Можете ли раскрыть, какой ASOC используете?
Он ещё слишком молодой. И как выше справедливо заметили, его перспективы на сегодня слишком туманны
Чтобы развивать свои компетенции не только вглубь, но и вширь. После того как изнутри понимаешь, как используется результат твоего труда, это очень увеличивает качество твоего результата.
В чем именно заблуждение? .Net Core так же как и обычный .Net не даёт писать фронт на c#
Как ни странно, большая часть задач на фронте и на бэкенде абсолютно одинаковые.
Мы берем данные (из СУБД или кэша в случае с бэком и из бэкенда или хранилища состояния (redux/mobx/rxJs) в случае с фронтом), выполняем некоторые преобразования и отдаем их потребителю (фронту в случае с бэком или компоненте визуализации в случае с фронтом). Специфичные регулярно возникающие задачи — это проектирование СУБД и интерфейсов — для бэка и верстка — для фронта.
достаточно хорошо декомпозировать задачу (чтобы занимала не больше дня) и прийти на помощь разработчику, если в ожидаемый срок результата нет
постепенно. Сначала давать небольшой объем несвойственных задач, потом контролировать результат и удовлетворенность разработчика от того, что он делает. Если совсем не его, то не давать такой тип задач. Но у нас разве что верстку не все любят, а с остальным таких проблем я не замечаю
от типизации C# мы перешли к типизации typescript
Для нас показатели качества всегда были в приоритете. К нам возвращаются наши Клиенты за разработками нового ПО, для меня это самый главный показатель. Говорят, что им очень нравится наша скорость работы и недельные спринты с понятным результатом
Фулстеки бывают разные. Джуны, мидлы, сеньоры. З/п зависит от общего уровня
Это так, но мы идем на эти потери (надо сказать, очень небольшие) сознательно. У нас соотношение серверной/WEB/мобильной разработки часто меняется. Поэтому нужны надежные резервы во всех направлениях.
Я предпочитаю формулировку «набираться опыта в трех платформах»
Нет, у нас не такая бизнес модель. У нас есть бесплатная тех-поддержка для наших решений (от полу года до года в зависимости от проекта). Поэтому для нас траты на тех. поддержку — это минус и мы стремимся делать так, чтобы Клиенты возвращались с запросами на новые фичи или системы, а не за исправлением багов.
заголовок взят из предыдущей статьи.
про кросс платформенность, да в .Net Core с этим ok
но основной смысл перехода на node.js был именно в унификации стека, а не кросплатформенности, поэтому как не называй статью, смысл не поменяется)
Чистые бэкендеры на C# втягивались в ноду около 2-х месяцев. Но зато сразу после этого могли решать задачи, не связанные с версткой, на фронте.
Я понял, что тема перехода с .Net на node.js оказалась не раскрыта и поэтому написал продолжение на основании личного опыта