Из этого следует, то что простые разработчики общаются только между собой и тимлидом. Простые разработчики не хотят на созвоны с ПМами и прочими паразитами. Это тимлид должен создавать задачи по написанию кода и думать о том как выполнять их параллельно.
А ПМ должен вести переговоры с бизнесом (выступать в роли БА) или самому генерировать требования.
Здесь ПМ - это ПРОДУКТ менеджер, который отвечает за коммерческий успех продукта.
Сюда может добавиться бизнес аналитик, который будет заниматься документированием требований. И вот когда его нет, обязанности аналитика делятся между ПМ и Тимлидом.
Все недопонимание происходить из-за того, что некий глава этого продукта не хочет или не может полностью за него отвечать, а вместо того, что бы нанять ПМ/БА скидывает это все на ТимЛида
Либо другой вариант, ПМу нечем заняться и от интересуется что там с задачами создает и двигает карточки, созывает бесполезные созвоны.
Мне кажется более важным навык технического писателя. Когда разработчик может четко описать идею, концепцию или архитектуру. Ещё важно писать код красиво, что бы комментарии не требовались или были минимальны.
Я по себе знаю, что такое преподавать материал из головы, и что такое если тебе дали уже готовый текст. По готовому тексту никакой навык не нужен. Просто читай с бумажки и отвечай на вопросы аудитории. Поэтому более важно уметь готовит материал, а само выступление менее важно.
PNPM работает в несколько раз быстрее, чем NPM и YARN, потребляет меньше интернет-трафика. Также он более надежен, так как проверяет валидность пакетов через хэши.
Это делает и npm, и yarn. У них тоже есть хэши в лок файлах.
Так же не описаны правильные команды для восстановления пакетов по лок-файлам.
npm ci // вместо npm i как видно на скриншоте с логами тестов
Ну так и реальзуйте идеи на js, никто не мешает. А когда все будет готово, добавьте аннотации, что бы другие люди смогли быстрее прочитать, понять и модификацировать ваш код, если ставите такую цель.
Вы удивитесь, но есть много людей, которым проще писать код добавляя "ненужные" аннотации, потому что им проще мыслить абстракциями.
Сборщики работали бы быстрее, если бы они работали с уже собранными пакетами. Если в пакету будет index.js и index.d.ts то сборка будет идти гораздо быстрее. Но во много пакетах, помимо кучи транзитивных зависимостей или и бардак с самим кодом. Там зачастую, просто хранят исходники, а бывает и юнит тесты. Про esbuild все и так знают. Но что насчёт пакетов? Почему никто не бьёт в колокол по этому поводу?
По работе, нескольким людям надо добавлять записи в гугл таблицу. Мне будет по кайфу, взять этого бота, докинуть базовую валидацию и пусть через него таблицу и заполняют. Потому что редактировать таблицы с телефона это ужас, а там как раз люди с телефона и заполняют, находясь на улице.
Убейтесь об стену со своим export default, автоимпорты будут работать нигде.
get = async (resource, params) => this.instance.get(resource, { params });
Тут async по приколу написан?
5. Валидировать пропсы, использовать типы
Ну хорошо хоть где-то типы есть, еще бы export default выпилить
Есть множество методологий написания CSS, например БЭМ, OOCSS, SMACSS, Atomic CSS и т. п.
Я вот вообще не понимаю, как БЭМ созданных для того что бы стили не ломались при копи-пасте разметки и отсутствию тулзов, применим к Vue и Angular где есть изоляция стилей и директивы. Опишите, что именно считается блоком, а что элементом? И как сюда присунуть модификаторы и эффективно управлять ими из кода?
Так вьюшки или страницы? Или это два разных типа компонент? Как это вы называете? Давайте придем к единому стандарту.
API/services
Аналогичный вопрос.
Interfaces, enums
Вы действительно считаете, что так удобно? Быть может стоит хранить интерфейсы енумы по месту первичного использования? Например если это используется в пропсах блока, то лучше к блоку. Если возвращается api, то рядом с api.
export function getProduct (id) {
return axios.get(`${API_URL}/products/${id}`)
}
export function postProduct (data) {
return axios.post(`${API_URL}/products`, data)
}
export function patchProduct (data) {
return axios.patch(`${API_URL}/products`, data)
}
Почему это три функции, а не класс с двумя методами (я видел, что именно так в Angularделают)? А почему нет ts-типов?
Это может быть удобным решением для хранения данных, так как чаще всего в больших приложениях есть данные, которые используют на нескольких страницах или в нескольких частях приложения. К таким относятся данные учетной записи пользователя или конфигурация приложения.
Зачем здесь стор? Почему мы не можем сделать глобальный объект-экземпляр класса, который хранит эти данные? Зачем писать куча каши со стором? Мне кажется что использовать сервисы как в Angular и получать их через inject, было бы удобнее (Там правда ручками надо поколдовать с созданием зависимостей), но у меня нет опыта реализации этого на множестве промышленных проектах.
Вообще весь 3-й совет, я так и не понял. Если данные могут использоваться на нескольких страницах то кажется должен подходить provide/inject. В класс-обертка для api-сервиса, может помочь реализовать кэширование? В Angular не используют глобальный стор (ну кроме пары извращенцев) и как-то живут. Почему этот подход нельзя использовать во Vue?
САМОЕ ГЛАВНОЕ!!! Вы забыли совет номер 0: используйте Typescript. Настройте линтер на strict mode, запрет any, а так же js-файлов.
Ну такое себе под постом про vue спрашивать об этом. Но мое мнение, что Angular или Vue. При этом Vue кажется более перспективным.
В Angular уже есть дефолтаная архитектура, которая уменьшает боль при разработке.
Во Vue дефолтаная архитектура менее жёсткая, собственно за хорошей архитектурой я и пришел а эту статью, но её так и не нашёл здесь. Во Vue 3 уже исправлено множество детских болезней Angular(а здесь они закостылены), плюс гораздо реже сталкиваешься с ограничениями фреймворка.
В React разброд и шатание, это же просто библиотека. Я так и ни разу не увидел хорошей архитектуры на реакте. Киллер-фича реакта это jsx/tsx, так как можно гибко переиспользовать UI компоненты. Хуки, это красивый костыль, но все равно костыль. Composition Api во Vue получше будут. Да и jsx во Vue можно прикрутить.
Vue сейчас очень развит, но нужно придумать хорошую архитектуру к нему. React я врагу не пожелаю, это черная дыра пожирающая бюджет любого проекта, много боли и костылей.
Конфигурация должна быть кодом на Typescript, который json. И все становится хорошо. Вместо ts, можно использовать любой другой статически типизируемый язык. Ныть про то, что нужно таскать с собой node-runtime не нужно, пару сотен мегабайт, это не много. Зато написание конфигурации превращается в кайф.
Радует глаз 1% фронта на c#, что больше чем у Dart. Ждём развитие Blazor и дальше.
Из этого следует, то что простые разработчики общаются только между собой и тимлидом. Простые разработчики не хотят на созвоны с ПМами и прочими паразитами. Это тимлид должен создавать задачи по написанию кода и думать о том как выполнять их параллельно.
А ПМ должен вести переговоры с бизнесом (выступать в роли БА) или самому генерировать требования.
Здесь ПМ - это ПРОДУКТ менеджер, который отвечает за коммерческий успех продукта.
Сюда может добавиться бизнес аналитик, который будет заниматься документированием требований. И вот когда его нет, обязанности аналитика делятся между ПМ и Тимлидом.
Все недопонимание происходить из-за того, что некий глава этого продукта не хочет или не может полностью за него отвечать, а вместо того, что бы нанять ПМ/БА скидывает это все на ТимЛида
Либо другой вариант, ПМу нечем заняться и от интересуется что там с задачами создает и двигает карточки, созывает бесполезные созвоны.
Хабр тоже хочет кушать.
Специально зарегался на Хабре, что бы оставить Вам это.
Язык C#
Командная строка компиляции
"{home}\dotnet.exe" "{home}\sdk\3.1.100\Roslyn\bincore\csc.dll" -reference:"{home}\packs\NETStandard.Library.Ref\2.1.0\ref\netstandard2.1\netstandard.dll" -langversion:8.0 -out:Solution.dll -define:ONLINE_JUDGE -debug- -optimize+ -nologo -warn:3 "{srcFile}"
Командная строка запуска
"{home}\dotnet.exe" exec --runtimeconfig "{home}\sdk\3.1.100\dotnet.runtimeconfig.json" "{location}\Solution.dll"
Мне кажется более важным навык технического писателя. Когда разработчик может четко описать идею, концепцию или архитектуру. Ещё важно писать код красиво, что бы комментарии не требовались или были минимальны.
Я по себе знаю, что такое преподавать материал из головы, и что такое если тебе дали уже готовый текст. По готовому тексту никакой навык не нужен. Просто читай с бумажки и отвечай на вопросы аудитории. Поэтому более важно уметь готовит материал, а само выступление менее важно.
Они зарабатывают бабки закрывая на это глаза. Грустно только то, что нормальных статей становится все меньше и меньше.
type Position = typeof Positions[keyof typeof Positions];
Сделать обёртку над двойным typeof оставляю в качестве домашнего задания.
В РБ pnpm.io тоже не доступен.
В статье очень много неточностей, например:
PNPM работает в несколько раз быстрее, чем NPM и YARN, потребляет меньше интернет-трафика. Также он более надежен, так как проверяет валидность пакетов через хэши.Это делает и npm, и yarn. У них тоже есть хэши в лок файлах.
Так же не описаны правильные команды для восстановления пакетов по лок-файлам.
npm ci // вместо npm i как видно на скриншоте с логами тестовyarn install --frozen-lockfilepnpm i --frozen-lockfileНу так и реальзуйте идеи на js, никто не мешает. А когда все будет готово, добавьте аннотации, что бы другие люди смогли быстрее прочитать, понять и модификацировать ваш код, если ставите такую цель.
Вы удивитесь, но есть много людей, которым проще писать код добавляя "ненужные" аннотации, потому что им проще мыслить абстракциями.
Сборщики работали бы быстрее, если бы они работали с уже собранными пакетами. Если в пакету будет index.js и index.d.ts то сборка будет идти гораздо быстрее. Но во много пакетах, помимо кучи транзитивных зависимостей или и бардак с самим кодом. Там зачастую, просто хранят исходники, а бывает и юнит тесты. Про esbuild все и так знают. Но что насчёт пакетов? Почему никто не бьёт в колокол по этому поводу?
А про что статья?
По работе, нескольким людям надо добавлять записи в гугл таблицу. Мне будет по кайфу, взять этого бота, докинуть базовую валидацию и пусть через него таблицу и заполняют. Потому что редактировать таблицы с телефона это ужас, а там как раз люди с телефона и заполняют, находясь на улице.
Убейтесь об стену со своим export default, автоимпорты будут работать нигде.
Тут async по приколу написан?
Ну хорошо хоть где-то типы есть, еще бы export default выпилить
Я вот вообще не понимаю, как БЭМ созданных для того что бы стили не ломались при копи-пасте разметки и отсутствию тулзов, применим к Vue и Angular где есть изоляция стилей и директивы. Опишите, что именно считается блоком, а что элементом? И как сюда присунуть модификаторы и эффективно управлять ими из кода?
@nkalacheva
P.S. Скудное количество материала, еще хуже чем предыдущая часть. Не пишите такой мусор.
А можно код рабочего приложения? Можно без вашей бизнес логики.
Читал, что там есть некое подобие di, но так и не понял как это заставить работать. Может быть у вас есть пример кода/проект где настроем di?
Так вьюшки или страницы? Или это два разных типа компонент? Как это вы называете? Давайте придем к единому стандарту.
Аналогичный вопрос.
Вы действительно считаете, что так удобно? Быть может стоит хранить интерфейсы енумы по месту первичного использования? Например если это используется в пропсах блока, то лучше к блоку. Если возвращается api, то рядом с api.
Почему это три функции, а не класс с двумя методами (я видел, что именно так в Angularделают)? А почему нет ts-типов?
А почему типы здесь появились?
Зачем здесь стор? Почему мы не можем сделать глобальный объект-экземпляр класса, который хранит эти данные? Зачем писать куча каши со стором? Мне кажется что использовать сервисы как в Angular и получать их через inject, было бы удобнее (Там правда ручками надо поколдовать с созданием зависимостей), но у меня нет опыта реализации этого на множестве промышленных проектах.
Вообще весь 3-й совет, я так и не понял. Если данные могут использоваться на нескольких страницах то кажется должен подходить provide/inject. В класс-обертка для api-сервиса, может помочь реализовать кэширование? В Angular не используют глобальный стор (ну кроме пары извращенцев) и как-то живут. Почему этот подход нельзя использовать во Vue?
САМОЕ ГЛАВНОЕ!!! Вы забыли совет номер 0: используйте Typescript. Настройте линтер на strict mode, запрет any, а так же js-файлов.
@nkalacheva
Ну такое себе под постом про vue спрашивать об этом. Но мое мнение, что Angular или Vue. При этом Vue кажется более перспективным.
В Angular уже есть дефолтаная архитектура, которая уменьшает боль при разработке.
Во Vue дефолтаная архитектура менее жёсткая, собственно за хорошей архитектурой я и пришел а эту статью, но её так и не нашёл здесь. Во Vue 3 уже исправлено множество детских болезней Angular(а здесь они закостылены), плюс гораздо реже сталкиваешься с ограничениями фреймворка.
В React разброд и шатание, это же просто библиотека. Я так и ни разу не увидел хорошей архитектуры на реакте. Киллер-фича реакта это jsx/tsx, так как можно гибко переиспользовать UI компоненты. Хуки, это красивый костыль, но все равно костыль. Composition Api во Vue получше будут. Да и jsx во Vue можно прикрутить.
Vue сейчас очень развит, но нужно придумать хорошую архитектуру к нему. React я врагу не пожелаю, это черная дыра пожирающая бюджет любого проекта, много боли и костылей.
Конфигурация должна быть кодом на Typescript, который json. И все становится хорошо. Вместо ts, можно использовать любой другой статически типизируемый язык. Ныть про то, что нужно таскать с собой node-runtime не нужно, пару сотен мегабайт, это не много. Зато написание конфигурации превращается в кайф.