Я бы добавил сюда "Чистую архитектуру" Дядюшки Боба - книга легко читается и дает понимание того, откуда и зачем появились современные принципы.
На счет паттернов, я бы предпочел не общую книгу, а книгу, которая содержит примеры на языке, на котором я пишу. Читал паттерны ООП банды 4-х, которую никто не обновлял с 1993 или 1995 года, и читать примеры на c++ или smalltalk (если вы знаете вообще о таком) сущее наказание и вынос мозга.
"Кабанчик" вряд ли будет сильно нужен джуну, который пока не умеет программировать, как будто эта книга больше для уровня миддл и выше, когда начинается этап проектирования.
А что особенного дает Testplan если уже есть Playwright, Cypress? Их также можно натравить на storybook и получить скриншотные тесты вашего UI-кита. Также можно запустить тест условного веб-приложения (можно назвать UI-тесты), мокать данные и делать скриншоты в это время, тем самым получив динамику страниц и проверку на их целостность во время выполнения user story.
Согласен, что 20% может быть многовато для того, чтобы исправлять техдолг, но это были просто числа "например". Это не железное правило. Если команда может не создавать технический долг до тех пор, пока не потребуется обновить все библиотеки или что-то подобное, то можно хоть соотношение 99 к 1 делать с упором на бизнес.
Чтобы задачи не порождали техдолг, надо сперва определиться с тем, что входит в задачу. Например, во фронтенде тесты встречаются гораздо реже, и если захочется исправить ситуацию, то потребуется много времени и сил, чтобы начать их писать (научить команду писать тесты, найти нужную стратегию покрытия тестами кода и т.д.), пока идет подготовка к тестированию - команда уже напишет еще кучу непротестированого кода.
Согласен, что техдолг - это не только недоделки, но и тесты, документация, обновление библиотек, end of life сервисов, перенастройка CI и т.д. Просто "неноделки" можно решать через DoD-ы гораздо проще, чем обновление библиотек.
Полностью согласен, я бы даже добавил еще от себя на счет обучения технологиям. Не надо придумывать проект, который должен будет принести профит и деньги, надо просто взять и сделать учебный проект с синтетическими данными.
Для блогов есть уже много готовых ресурсов, особенно для начинающего блогера завести ТГ, ВК - вполне неплохой вариант, чем сделать сайт, на который нужно еще как-то нагнать трафик.
Для спама, мемесов, котиков (хотя котикам рады во всех чатах) можно завести отдельный чат, который можно поставить на mute, в него можно не вступать или игнорировать ещё как- нибудь. Можно завести правило на то, чтобы призывать в чате того, кто нужен для решения проблемы - если вас не позвали, можете игнорировать чат (тоже экономит время).
Почему лучше вести переписку даже между двумя членами команды в общем чате хорошая идея? Если ваш коллега вас заигнорил (отвлёкся и забыл, или нет времени, или токсик), то тогда уже можно привлечь ПМ-а, чтобы он фасилитировал процесс и увидел, что вы как взрослый человек приложили все усилия для решения проблемы. А также он сам увидит какая была проблема. А вот при общении в "личке" не понятно когда вы обратились и обращались ли за ответом к коллеге.
На счёт требования. Сперва вы собираете требования/решения в "хоть каком-то виде", потому что идёт процесс общения, а в конце вы или коллега можете сделать резюме, которое будет перенесено в задачу или куда надо. Это по сути тоже самое, что митинг ноут после каких-то встреч-созвонов. И вот тут можно позвать ПМа, чтобы он увидел ваше резюме, сказал ОК и не тратил свое время на чтение всего чата (у него тоже есть свои рабочие задачи).
Перекладывать все с сеньора (потому что ему надо работать и думать) на ПМ-а не всегда возможно. ПМ или лид могут не понимать ваш стек технологий, ПМ-у тем более не обязательно быть вообще программистом. Также, вы всегда можете обсудить с коллегой что-то совместно в чате - вы же взрослые люди, а вот если заиграет детство в одном месте или нужно вмешательство ПМа - тогда можно обратиться к нему. Иначе ваш ПМ будет отвечать на сообщения раз в несколько часов, потому что его будут дёргать по всякой фигне и вы и другие коллеги.
Вся связь через МП-а или лида - довольно удобная штука, ее можно решить через введение чата команды. Все вопросы можно задавать через него, тогда это решает сазу кучу проблем:
К сеньору не будет постоянно приходить какой-нибудь джун и теребить его, для этого есть чат и там может кто-то еще ответить.
В ходе беседы может выявиться какая-то серьезная проблема, которая может потребовать уточнений/пояснений от других специалистов, которые уже есть в чате и их надо просто туда позвать для уточнений.
Будет хоть в каком-то виде собрано решение какой-то проблемы, которое можно будет перенести пояснением в задачу.
Понятно, что есть личные конфликты, которые стоит решать через лида. А также есть личные вопросы, например пойдет ли твой коллега в бар, которые стоит спрашивать в личке)
Из своей жизни могу привести два варианта борьбы с техдолгом на уровне процессов:
Относительно распространенная практика - выделение квоты на техдолг. Например, вы работаете по спринтам и 20% спринта посвящаете техдолгу. Но тут надо уметь контролировать бизнес, ибо он будет напихивать в ваш спринт бизнесовых задач с горкой и приносить горящие задачи по среди спринта.
Второй вариант борьбы с техдолгом - это явно прописывать то, что должно входить в завершенную задачу (definition of done). Например, надо сделать сервис + тесты (юнит и/или интеграционные) + документация, и если чего-то из этого нет, то задача остается на этапе разработки. А задачу на тесты и документацию выносить в отдельный техдолг только тогда, когда есть угроза срывов дедлайнов или других серьезных проблем. Это не исключает техдолг, но позволяет заложить время на то, чтобы его создавать меньше. На практике несколько раз проходил такой момент, что тесты откладывали в задачу по техдолгу, а потом удаляли десятки задач на тесты, потому что делать их уже никто не планирует. Лучше сразу взять побольше срок на выполнение задачи (в рамках разумного), чем просить на это время.
В целом, это очень похоже на "метод 360 градусов", только очень упрощённый и обобщенный до 1-го вопроса. При желании, можно посмотреть аналогичные опросы. Но если у вас нет штата сотрудников отвечающих за процесс опросов и анализа результатов, то такой метод с одним вопросом кажется очень эффективным.
Написание статей - это скорее софт-скилл, который помогает собрать свои мысли в кучку, так же как и ведение какого-то дневника или канала. Заодно, умение доходчиво мыслить помогает в будущем при общении с коллегами и помогает в документировании своих решений.
По своему опыту, скажу, что это может даваться слишком тяжело (есть две статьи и свой мини-блог):
Нужна какая-то тема для статьи/поста, и ее поиск может занять долгое время (ни разу не находил тему, тема выбирала меня через обстоятельства). Мне как специалисту не хочется делать перепечатки/переводы чужих статей, как по мне это ближе к инфоцыганству. Мне хочется показать свой опыт, свои знания, которые могут помочь другим.
Написать хороший текст, тоже надо уметь. Несколько раз мои статьи читали и находили моменты, которые вызывали проблемы в понимании материала, приходилось переписывать. Формулировать мысли тяжело - если это не основной вид деятельности.
Кажется, что степень того, насколько это легко и круто, зависит от софт-скиллов человека. Но как раз таки пишу статьи и в блоге для того, чтобы развивать эти навыки, а заодно искать какие-то интересные мысли и знания.
Console не ограничивается лишь одним методом log. Их очень довольно много, и сразу оговорюсь, что для тестирования извне их или не применить, или очень сложно или нет смысла.
Но, например, для того, чтобы вывести таблицу есть отдельный метод .table(), который явно подойдет больше для отображения табличных данных.
Также, можно еще можно иногда пользоваться методами dir и dirxml.
Интересная статья, но есть один момент, который хочется узнать. Изменение этих настроек сказалось ли на других параметрах: потребление памяти, потребление GPU и т.д? Хочется понять реальную стоимость решения, а не только время потраченное разработчиками.
P.S. Разработчикам уважение, проделана классная и интересная работа
А при чем тут nodejs и nestjs? В тексте они упоминаются один раз. Как будто их можно заменить на любой сервис написанный на "язык + фреймворк выберите сами".
Также кажется указывать конкретные технологии при проектировании не очень хорошая идея. Ну или надо уточнять почему нам больше подходит MongoDb для поиска, потому что в зависимости от функционала, архитектурных решений можно вести эффективный поиск в реляционной базе или, вовсе, в графовой.
Если HTML5 может любой произвольный тег считать чем-то валидным, то Angular, например, будет пытается распарсить это тег как компонент, не сможет его найти и сломается на этапе билда.
Соглашусь, можно написать нативно. Тогда будет банд маленького размера, ну или как минимум меньше, чем нам достанется от Angular.
Но стоит смотреть на ситуацию под разными углами. Например, форма может уже существовать в рамках другого Angular-приложения. Тогда создать вторую форму на нативных технологиях будет "дороже", как по написанию, так и по поддержке, придётся повторять одну и ту же логику дважды на разных технологиях.
Имея под рукой UI-кит, инструменты для работы с формами и т.д., можно ускориться в процессе разработки, что тоже важно. А также готовые и проверенные инструменты уберегут нас от мелких проблем, таких как, например, баги кроссбраузерной верстки.
Также стоит смотреть в сторону дальнейшего развития функционала. Сегодня у нас два поля и кнопка, а завтра это может быть форма со степпером или другой логикой. Придётся создавать "конструктор форм", что уже будет на порядок сложнее.
Не часто выпадают такие задачи, поэтому, в целом, не было понимания на каком уровне находятся web components. Очень классный и мощный инструмент, но все же имеет свои плюсы и минусы. Так что все равно приходится подбирать инструмент под задачи. Тот же Youtube встраивает свои видео через iframe.
Чтобы использовать *ngIf нужно импортировать commonModule, или импортировать из него NgIf-директиву. Это не очень удобно, особенно в разрезе standalone-компонентов. А @if не требует импорта, это часть синтаксиса шаблона, что убирает ещё один импорт. Про то, что не нужен в некоторых кейсах ng-component, я уже написал.
Также, новый синтаксис для for обязывает имеет trackBy, но тут же упрощает его использование, достаточно при описании написать что-то типа `@for(item of items; track item.id)`, и получаем уменьшение перерисовок с привязкой к id-сущности.
С 17 версии Angular появился новый синтаксис в шаблонах@for , @if , @switch, которые позволяют избежать использования ng-container в описанных выше кейсах. Например, так:
@if(expression){
<div>first part content </div>
<div>second part content </div>
}
В кейсах с ngTemplateOutlet он вполне подходит, а вот вместе с новыми фичами шаблона - стал в большинстве случаев лишним.
Понятно, что там где нет code-review все будет очень плохо, сам работал без него однажды
Использовать дефолтные настройки не очень правильно, потому что у разработчиков могут быть разные IDE с разными дефолтными настройками. Разумно иметь единый источник правил, чтобы у всех разрабов был единый формат кода (был случай, когда поменял одну строку, но переформатировался весь файл).
"Спецификация дизайн", опечатался немного (спецификация или дизайн-ревью), но подразумевал спецификацию решения, или дизайн ревью решения. Какая-то активность, результатом которой будет описание технического решения, которое устроит остальных разработчиков, системных аналитиков или архитекторов (смотря какая команда)
Я бы добавил сюда "Чистую архитектуру" Дядюшки Боба - книга легко читается и дает понимание того, откуда и зачем появились современные принципы.
На счет паттернов, я бы предпочел не общую книгу, а книгу, которая содержит примеры на языке, на котором я пишу. Читал паттерны ООП банды 4-х, которую никто не обновлял с 1993 или 1995 года, и читать примеры на c++ или smalltalk (если вы знаете вообще о таком) сущее наказание и вынос мозга.
"Кабанчик" вряд ли будет сильно нужен джуну, который пока не умеет программировать, как будто эта книга больше для уровня миддл и выше, когда начинается этап проектирования.
А что особенного дает Testplan если уже есть Playwright, Cypress? Их также можно натравить на storybook и получить скриншотные тесты вашего UI-кита. Также можно запустить тест условного веб-приложения (можно назвать UI-тесты), мокать данные и делать скриншоты в это время, тем самым получив динамику страниц и проверку на их целостность во время выполнения user story.
Аналогично, для самых популярных команд завел алиасы, недавно описал ещё себе в github, чтобы переносить между рабочими и домашними машинами.
Вместо `git checkout master` ввожу `git cm`, вот и вся магия. Возможно, стоит заменить на switch, но и так работает.
Наверное стоит доработать до полного конфига, чтобы и другие настройки тоже переносить.
Согласен, что 20% может быть многовато для того, чтобы исправлять техдолг, но это были просто числа "например". Это не железное правило. Если команда может не создавать технический долг до тех пор, пока не потребуется обновить все библиотеки или что-то подобное, то можно хоть соотношение 99 к 1 делать с упором на бизнес.
Чтобы задачи не порождали техдолг, надо сперва определиться с тем, что входит в задачу. Например, во фронтенде тесты встречаются гораздо реже, и если захочется исправить ситуацию, то потребуется много времени и сил, чтобы начать их писать (научить команду писать тесты, найти нужную стратегию покрытия тестами кода и т.д.), пока идет подготовка к тестированию - команда уже напишет еще кучу непротестированого кода.
Согласен, что техдолг - это не только недоделки, но и тесты, документация, обновление библиотек, end of life сервисов, перенастройка CI и т.д. Просто "неноделки" можно решать через DoD-ы гораздо проще, чем обновление библиотек.
Полностью согласен, я бы даже добавил еще от себя на счет обучения технологиям. Не надо придумывать проект, который должен будет принести профит и деньги, надо просто взять и сделать учебный проект с синтетическими данными.
Для блогов есть уже много готовых ресурсов, особенно для начинающего блогера завести ТГ, ВК - вполне неплохой вариант, чем сделать сайт, на который нужно еще как-то нагнать трафик.
Для остального есть докер и гитхаб)
Для спама, мемесов, котиков (хотя котикам рады во всех чатах) можно завести отдельный чат, который можно поставить на mute, в него можно не вступать или игнорировать ещё как- нибудь. Можно завести правило на то, чтобы призывать в чате того, кто нужен для решения проблемы - если вас не позвали, можете игнорировать чат (тоже экономит время).
Почему лучше вести переписку даже между двумя членами команды в общем чате хорошая идея? Если ваш коллега вас заигнорил (отвлёкся и забыл, или нет времени, или токсик), то тогда уже можно привлечь ПМ-а, чтобы он фасилитировал процесс и увидел, что вы как взрослый человек приложили все усилия для решения проблемы. А также он сам увидит какая была проблема. А вот при общении в "личке" не понятно когда вы обратились и обращались ли за ответом к коллеге.
На счёт требования. Сперва вы собираете требования/решения в "хоть каком-то виде", потому что идёт процесс общения, а в конце вы или коллега можете сделать резюме, которое будет перенесено в задачу или куда надо. Это по сути тоже самое, что митинг ноут после каких-то встреч-созвонов. И вот тут можно позвать ПМа, чтобы он увидел ваше резюме, сказал ОК и не тратил свое время на чтение всего чата (у него тоже есть свои рабочие задачи).
Перекладывать все с сеньора (потому что ему надо работать и думать) на ПМ-а не всегда возможно. ПМ или лид могут не понимать ваш стек технологий, ПМ-у тем более не обязательно быть вообще программистом. Также, вы всегда можете обсудить с коллегой что-то совместно в чате - вы же взрослые люди, а вот если заиграет детство в одном месте или нужно вмешательство ПМа - тогда можно обратиться к нему. Иначе ваш ПМ будет отвечать на сообщения раз в несколько часов, потому что его будут дёргать по всякой фигне и вы и другие коллеги.
Вся связь через МП-а или лида - довольно удобная штука, ее можно решить через введение чата команды. Все вопросы можно задавать через него, тогда это решает сазу кучу проблем:
К сеньору не будет постоянно приходить какой-нибудь джун и теребить его, для этого есть чат и там может кто-то еще ответить.
В ходе беседы может выявиться какая-то серьезная проблема, которая может потребовать уточнений/пояснений от других специалистов, которые уже есть в чате и их надо просто туда позвать для уточнений.
Будет хоть в каком-то виде собрано решение какой-то проблемы, которое можно будет перенести пояснением в задачу.
Понятно, что есть личные конфликты, которые стоит решать через лида. А также есть личные вопросы, например пойдет ли твой коллега в бар, которые стоит спрашивать в личке)
Из своей жизни могу привести два варианта борьбы с техдолгом на уровне процессов:
Относительно распространенная практика - выделение квоты на техдолг. Например, вы работаете по спринтам и 20% спринта посвящаете техдолгу. Но тут надо уметь контролировать бизнес, ибо он будет напихивать в ваш спринт бизнесовых задач с горкой и приносить горящие задачи по среди спринта.
Второй вариант борьбы с техдолгом - это явно прописывать то, что должно входить в завершенную задачу (definition of done). Например, надо сделать сервис + тесты (юнит и/или интеграционные) + документация, и если чего-то из этого нет, то задача остается на этапе разработки. А задачу на тесты и документацию выносить в отдельный техдолг только тогда, когда есть угроза срывов дедлайнов или других серьезных проблем. Это не исключает техдолг, но позволяет заложить время на то, чтобы его создавать меньше. На практике несколько раз проходил такой момент, что тесты откладывали в задачу по техдолгу, а потом удаляли десятки задач на тесты, потому что делать их уже никто не планирует. Лучше сразу взять побольше срок на выполнение задачи (в рамках разумного), чем просить на это время.
В целом, это очень похоже на "метод 360 градусов", только очень упрощённый и обобщенный до 1-го вопроса. При желании, можно посмотреть аналогичные опросы. Но если у вас нет штата сотрудников отвечающих за процесс опросов и анализа результатов, то такой метод с одним вопросом кажется очень эффективным.
Написание статей - это скорее софт-скилл, который помогает собрать свои мысли в кучку, так же как и ведение какого-то дневника или канала. Заодно, умение доходчиво мыслить помогает в будущем при общении с коллегами и помогает в документировании своих решений.
По своему опыту, скажу, что это может даваться слишком тяжело (есть две статьи и свой мини-блог):
Нужна какая-то тема для статьи/поста, и ее поиск может занять долгое время (ни разу не находил тему, тема выбирала меня через обстоятельства). Мне как специалисту не хочется делать перепечатки/переводы чужих статей, как по мне это ближе к инфоцыганству. Мне хочется показать свой опыт, свои знания, которые могут помочь другим.
Написать хороший текст, тоже надо уметь. Несколько раз мои статьи читали и находили моменты, которые вызывали проблемы в понимании материала, приходилось переписывать. Формулировать мысли тяжело - если это не основной вид деятельности.
Кажется, что степень того, насколько это легко и круто, зависит от софт-скиллов человека. Но как раз таки пишу статьи и в блоге для того, чтобы развивать эти навыки, а заодно искать какие-то интересные мысли и знания.
Console не ограничивается лишь одним методом log. Их очень довольно много, и сразу оговорюсь, что для тестирования извне их или не применить, или очень сложно или нет смысла.
Но, например, для того, чтобы вывести таблицу есть отдельный метод .table(), который явно подойдет больше для отображения табличных данных.
Также, можно еще можно иногда пользоваться методами dir и dirxml.
Интересная статья, но есть один момент, который хочется узнать. Изменение этих настроек сказалось ли на других параметрах: потребление памяти, потребление GPU и т.д? Хочется понять реальную стоимость решения, а не только время потраченное разработчиками.
P.S. Разработчикам уважение, проделана классная и интересная работа
А при чем тут nodejs и nestjs? В тексте они упоминаются один раз. Как будто их можно заменить на любой сервис написанный на "язык + фреймворк выберите сами".
Также кажется указывать конкретные технологии при проектировании не очень хорошая идея. Ну или надо уточнять почему нам больше подходит MongoDb для поиска, потому что в зависимости от функционала, архитектурных решений можно вести эффективный поиск в реляционной базе или, вовсе, в графовой.
Каюсь, упустил этот вариант. Спасибо, что натолкнул на этот вариант. Потребовалось некоторое время, чтобы изучить этот вопрос.
Если приложение-компонент одно, не имеет необходимости в общении с внешним сайтом, то очень даже подходит. Я бы сказал, что практически web-component.
Из плюсов
Доступ к window и другим данным родительской страницы как в web component и так же работают css-переменные, можно добиться конфигурирования.
Встраивание аналогично Web-components
Практически закрывает все возможности, что было у web omponents.
Из минусов
Не получилось встроить второе приложение параллельно, Angular не рассчитан на 2 и более инстансов на одной странице.
Также не работает Router
Нельзя динамически создать несколько компонентов (1п)
Нет общения посредством Input-Output, если это необходимо, то придется повозиться.
В остальном, если этот вариант удобен, то почему бы и нет. Можно выбирать вариант под свои потребности любой рабочий вариант.
Сильно подробно не исследовал, скорее всего, что-нибудь еще упустил.
Если HTML5 может любой произвольный тег считать чем-то валидным, то Angular, например, будет пытается распарсить это тег как компонент, не сможет его найти и сломается на этапе билда.
Соглашусь, можно написать нативно. Тогда будет банд маленького размера, ну или как минимум меньше, чем нам достанется от Angular.
Но стоит смотреть на ситуацию под разными углами. Например, форма может уже существовать в рамках другого Angular-приложения. Тогда создать вторую форму на нативных технологиях будет "дороже", как по написанию, так и по поддержке, придётся повторять одну и ту же логику дважды на разных технологиях.
Имея под рукой UI-кит, инструменты для работы с формами и т.д., можно ускориться в процессе разработки, что тоже важно. А также готовые и проверенные инструменты уберегут нас от мелких проблем, таких как, например, баги кроссбраузерной верстки.
Также стоит смотреть в сторону дальнейшего развития функционала. Сегодня у нас два поля и кнопка, а завтра это может быть форма со степпером или другой логикой. Придётся создавать "конструктор форм", что уже будет на порядок сложнее.
Рад, что статья пришлась по душе.
Не часто выпадают такие задачи, поэтому, в целом, не было понимания на каком уровне находятся web components. Очень классный и мощный инструмент, но все же имеет свои плюсы и минусы. Так что все равно приходится подбирать инструмент под задачи. Тот же Youtube встраивает свои видео через iframe.
Вместе с 17 версией документация перешла на новый домен и новый сайт. https://angular.dev
Выше уже указали ссылку на новый синтаксис, но тоже продублирую тут: https://angular.dev/guide/templates/control-flow
Сам синтаксис обсуждали в RFC ещё год назад https://github.com/angular/angular/discussions/50719
Чтобы использовать *ngIf нужно импортировать commonModule, или импортировать из него NgIf-директиву. Это не очень удобно, особенно в разрезе standalone-компонентов. А
@ifне требует импорта, это часть синтаксиса шаблона, что убирает ещё один импорт. Про то, что не нужен в некоторых кейсах ng-component, я уже написал.Также, новый синтаксис для for обязывает имеет trackBy, но тут же упрощает его использование, достаточно при описании написать что-то типа `@for(item of items; track item.id)`, и получаем уменьшение перерисовок с привязкой к id-сущности.
С 17 версии Angular появился новый синтаксис в шаблонах
@for,@if,@switch, которые позволяют избежать использования ng-container в описанных выше кейсах. Например, так:В кейсах с ngTemplateOutlet он вполне подходит, а вот вместе с новыми фичами шаблона - стал в большинстве случаев лишним.
Ответ был не Вам, а общим комментарием к статье)
Понятно, что там где нет code-review все будет очень плохо, сам работал без него однажды
Использовать дефолтные настройки не очень правильно, потому что у разработчиков могут быть разные IDE с разными дефолтными настройками. Разумно иметь единый источник правил, чтобы у всех разрабов был единый формат кода (был случай, когда поменял одну строку, но переформатировался весь файл).
"Спецификация дизайн", опечатался немного (спецификация или дизайн-ревью), но подразумевал спецификацию решения, или дизайн ревью решения. Какая-то активность, результатом которой будет описание технического решения, которое устроит остальных разработчиков, системных аналитиков или архитекторов (смотря какая команда)