Це перший збір, при чому настільки неоднозначний що викликає більше питань чим відповідей. Мені як людині, яка хоч трішки знайома з кібербезпокою, незрозумілий момент з обвалення комунікацій ворога на ідентифікація ворожих цілей та їх локацій. Про який саме кібернаступ йде мова? Що вкладають у це поняття? Як би це прикро не звучало, але це повна ахінея в описі. Можливо спеціалісти з кібербезпеки доповнять, тому що реально незрозуміло що тут і до чого.

+

+

А можете навести приклад альтернативи щоб передавати дані між компонентами? Просто те що ви описали, це дефакто стандарт коли потрібно розділяти архітектуру на smart\presentational components blog.angular-university.io/...​when-to-use-each-and-why Мені здається,що ви просто не до кінця розумієте, навіщо це використовується на проекті, але це ніяк не робить підхід неправильним.

Хотів би звернути увагу на те, що у вас у статті зроблено декілька неправильних висновків.
1) Логіка, що дублюється. Посил в цілому правильний, але логіку можна виносити не тільки в сервіси, але й створювати шарені компоненти і наслідуватись від них
2) Відписуватися від Observables. В 99% відсотків випадків, новачки використовують observable для роботи з http викликами (HttpClient), так ось, будь-який викликами
get\post\put\delete і т.д. після виконання викличе відразу complete, і потік закриється сам. Єдиний варіант коли потрібно відписуватись від таких колів, це коли у вас
довгі запити на сервер і ви хочете їх закенселити, в такому випадку unsubscribe автоматично відмінить ваш запит.
3) +
4) +
5) +

Я б додав наступні пункти.
1) Поставте і налаштуйте prettier + linter щоб весь код був одного стилю і з мінімум помилок
2) Мінімізуйте перебивання стилів через !important
3) Мінімізуйте використання функцій в темплейтах. Приклад:
{{ getSubtitle() }}
Просто поставте виклик console.log і подивіться скільки раз у вас викликається така функція
4) Використовуйте по максимуму changeDetection: ChangeDetectionStrategy.OnPush для всіх presentation components
5) Не робіть обробку для кожного елемента списку, особливо якщо він великий. Робіть один обробник на парент.

+ Третій заход. Надіюсь ми все таки зможемо добити цей збір до кінця.

+ По другому колу

+

"

«Плани», «бюджети». Все це бла-бла. Особливо про плани — це що несподіванка, що наприкінці серпня День Незалежності і очевидно що буде збір?

" Я б не назвав це несподіванкою. Просто з початку повномаштабної війни у багатьох змінилось планування. Наприклад, першим чином після отримання ЗП, починаю переводити у фонди у які це потрібно саме зараз, не чекаючи День Незалежності. Багато знайомих\друзів програмістів роблять те ж саме. Тому все таки надіюсь що просто вибраний невдалий час збору і на початку місяця все пішло б набагато швидше. Хотілось би у це вірити принаймі.

Просто гляньте ту же саму кількість переглядів перед тим як порівнювати. На DOU на даний момент 94332. Врахувати той факт що багато вносять по другому колу, або просто заходять переглянути скільки назбиралось. Якщо взяти хоча б що 80% з тих що заходять закинули хоча б по 150$, сума вийже 14 млн, а треба 31. Плюс у Лечена кількість користувачів більша в десятки раз чим зайшло на DOU подивитись по збору. Я думаю що навіть у тих айтівців, донати просіли дуже сильно.

+ Погнали по другому колу. З Днем Незалежності, Україно!

+

Я думаю просто что те ПМ/Лиды с которыми я работал просто, умели сразу нормально оценить сложность проекта и сколько на него будет потрачено человеко часов. Не вижу смысла что-то пробовать донести до человека который считает программирование и разработку через ad-hoc решения нормальной практикой. Меня больше удивляет как ваш ПМ/Лид умудряется продавать постоянно «костыльные» решения и с вами до сих пор кто-то сотрудничает.

Значит вам реально очень везет что на рефакторинг выделяют время. Обычно все бывает в точности наоборот. Заказчик не хочет зачастую платить деньги за рефакторинг, а объяснить почему например предыдущие N-задач подобного плана решались например за 2 часа, а следующая задача такого же плана займет 20 часов. То у заказчика возникнет резонный вопрос: «Почему 20 часов, если на предыдущие задачи были по 2 часа.» И приходится тратить время чтобы объяснить, что эти 20 часов необходимость для проекта, потому что старое ad-hoc решение не работает уже.

Если проект простой, то ваш подход возможно имеет смысл для существования. Но в крупных проектах ваш подход не будет работать. Я к сожалению работал в таких проектах в которых использовался ваш подход. Как только доходит дело до расширения проекта, заказчик начинает хотеть чуть больше, ты понимаешь что ту эрунду которую написала вся команда до этого можно просто выбросить. И обычно в таких случаях время на рефакторинг не выделяется. Бывают даже случаи когда проще переписать проект заново чем пытаться сопровождать монстра который состоит из сплошных «костылей» и «велосипедов».

Владислав Бовсуновский Вы пишете какую то белиберду. Такое ощущение что вы только что проснулись. С каких это пор государство вдруг стало направо и налево раздавать деньги со своей казны. Вы хоть вдумайтесь в то что вы пишете.

Вы наверное в стоимости программного обеспечения совсем ничего не понимаете и как оно рассчитывается. Как вы вообще можете говорить о суммах в 5млн. гривен в год. Посчитайте: 13 гос. реестров 5000000 / 12 месяцев = ~416666, теперь эту суму мы разделим на количество гос. реестров 416666 / 13 = 32051 гривен на один гос. реестр в месяц. Это же какого уровня должны быть разработчики чтобы писать реестры за 2 тис. гривен в месяц? Так вы считаете?