скорее да, сложно точно ограничить зону работы. Во многом зависит от возможностей компаний, разумности руководства. Да и в целом нигде нет талмута, который как 2+2 обозначил рабочие обязанности. Даже нет четких ограничений между senior и middle или middle и junior. Есть только размытые трактовки.
Тимлид разработчиков — мост между миром менеджеров и разработчиков. Его цель доносить мысль управленцев, заказчиков до команды в том виде, как они лучше понимают. Мышление у всех разное ). А также наоборот, объяснять заказчикам технические нюансы его требований на понятном ему языке.
Если стоит задача клепать единообразное(клиентов все устраивает), то спору нет. Это больше тема для outsourcing, которые хотят сильно экономить на программистах. Подобные библиотеки имеют низкий порог вхождения. За пару дней можешь заклепать приличное приложение и сдать проект. Для вас как стажера — это минус. Слабо развивается абстракционное мышление, мышление как строить архитектуру приложения.
Понятие симпатичный дизайн относительно. Из опыта. Дизайн приложения ~material. Но клиента не устраивало, говорил что это не дизайн, ему не нравится. Долго не понимали в чем причина. Оказалось, что для него таблицы в стиле 90ых — это настоящий стиль ).
Async/await удобна там, где много взаимного вызова асинхронного кода. При этом проверки на ошибку производится а самом верхнем уровне. В клиентских приложениях скорее редкость. При написании веб служб встречается чаще
Декларативный методология ограничивает разработчика в рамки, которые заложены в библиотеку. Создается вау эффект, что-то слегка написал и вот крутой результат. Для реальных проектов, с реальными заказчиками это не живой вариант. Часто требуют чего-то специфического)
Скажите — это футболистам, хоккеистам, моделям, артистам ). Они ничего не производят, кроме настроения. Ваша статья из категории обиженных на жизнь мужиков )(не в обиду). Рынок сам диктует сколько воздать каждой профессии. Среди программистов не мало и тех, кто получает заметно ниже рынка. Насчет доходов беспокоиться не стоит, как только произойдет рывок компьютерного железа, зп у программистов поубавиться )
Из личного опыта и наблюдений за другими: обычно необходимость в монорепозитории появляется из-за нехватки рабочих рук, трудно скакать по репозиториям. Если хватает, то каждый отвечает за свою. Периодически собирая готовую сборку и выкладывая в пакетный менеджер. По хорошему монолит должен собираться как единое целое, значит при таких размерах будет долго, сложно отслеживать какие ее части, с какого момента стали источником багов. Если не так, то попровьте плиз.
Для простых решений это норм. Node.js позволяет автоматизировать многие процессы(сборку в общий бандл, минификацию, typescript, less, тесты и прочее). Рекомендую изучить, у Vue если не ошибаюсь, есть cli, который упрощает процесс использования node.js
Что вас больше всего цепляет в использовании vue? Для себя пока не могу увидеть явных преимуществ. Тесты на производительность ± похожи на конкурентов.
В малых и средних самостоятельных проектах полностью верно. Когда речь идет о больших проектах, модульная независимость важнее максимального быстрого получения результата. Разбиение проекта сразу на множество репозиторий не эффективно. Но можно разбить на модули по проектам. Т.е. система контроля кода общая, но разработчики работают в отдельных проектах, что соответсвует отдельным package.json. Возможно автору стоило рассмотреть вариант использования одного package.json, но настроив ts разные области видимости. Можно много дискутировать, все зависит от размера как проекта, так и комманды )
Если разрабатывает один человек да, все верно. Если участвует больше то болен оправдано. Особенно если предпалагается расширение команды и возможный распил репы на множество реп. Меньше переделывать придется
У сайтов много ограничений доступа к устройству. Диктуется безопасностью. Без большего доступа сложно говорить о полноценных приложениях. Не стоит забывать об ограниченных ресурсах(батарея, процессор, память), веб пока требует много. Если предвидеться скачок железа, то сообщество продвинет на базе веба универсальный механизм. Если также будет как сейчас, то и веб может ждать серьезные изменения(webassembly начало)
Понятие симпатичный дизайн относительно. Из опыта. Дизайн приложения ~material. Но клиента не устраивало, говорил что это не дизайн, ему не нравится. Долго не понимали в чем причина. Оказалось, что для него таблицы в стиле 90ых — это настоящий стиль ).
Async/await удобна там, где много взаимного вызова асинхронного кода. При этом проверки на ошибку производится а самом верхнем уровне. В клиентских приложениях скорее редкость. При написании веб служб встречается чаще
Все фичи перечисленные в статье хорошие, вот только не все браузеры поддерживают. Сам предпочитаю typescript. Он позволяет обезопасить совместимость
Вместо VS code предпочитаю продукции jetbrains, в частностм webstorm)
Декларативный методология ограничивает разработчика в рамки, которые заложены в библиотеку. Создается вау эффект, что-то слегка написал и вот крутой результат. Для реальных проектов, с реальными заказчиками это не живой вариант. Часто требуют чего-то специфического)
Не думали, что придется делать для третьих лиц апишки)
Из личного опыта и наблюдений за другими: обычно необходимость в монорепозитории появляется из-за нехватки рабочих рук, трудно скакать по репозиториям. Если хватает, то каждый отвечает за свою. Периодически собирая готовую сборку и выкладывая в пакетный менеджер. По хорошему монолит должен собираться как единое целое, значит при таких размерах будет долго, сложно отслеживать какие ее части, с какого момента стали источником багов. Если не так, то попровьте плиз.
Что вас больше всего цепляет в использовании vue? Для себя пока не могу увидеть явных преимуществ. Тесты на производительность ± похожи на конкурентов.
У сайтов много ограничений доступа к устройству. Диктуется безопасностью. Без большего доступа сложно говорить о полноценных приложениях. Не стоит забывать об ограниченных ресурсах(батарея, процессор, память), веб пока требует много. Если предвидеться скачок железа, то сообщество продвинет на базе веба универсальный механизм. Если также будет как сейчас, то и веб может ждать серьезные изменения(webassembly начало)
В ts еще много чего интересного:). Лично долго ждал оператора .? Пример выше это декораторы — позволяют многое. Напоминает атрибуты в c#.