А кто-нибудь использовал крупные готовые архитектурные фреймворки типа DevExpress XAF?

теперь уже ты пропустил основной поинт про оценку рисков и принятие тех.долга.

а как это связано с цитируемым комментом ?

В разных проектах всё по разному, не нужно всё обобщать

По идее готовая архитектура приложения с готовой реализацией, пригодной для быстрого наследования вероятно снижает техдолг, нет?

я же правильно тебя понял, что ты пропагандируешь идею - доку не читай, внедряй - в стартапах так и делают ?

Недопонимание на недопонимании или намеренно? Уже же попрощались?

вы

:)

ты просто в очередной раз в чате пишешь откровенно вредные советы.
зачем ?
хочешь рассказать, что кто-то делает говно ?
да, есть такие люди.
ты хочешь это выставить, как пример для подражания ?
в чем цель твоего коммента-то ?

архитектура - другая история.
вот допустим тебе нужно новое приложение - ты подумал - вот примерно такие компоненты будут, такой фреймворк.
нафигачил прототип
может быть несколько прототипов на разных фреймворках с целью выбора.
Но в конце концов что-то ты выбрал.
По сути мы еще даже не начали писать приложуху - просто потестировали - на чём удобно писать.
Вот, архитектуру сформировали.


Тех.долг это другая история - у тебя есть задача - сделать штуку.
Можно её сделать на кубере - но компетенций в команде нет - значит на изучение потребуется условный человеко-месяц.
но есть компетенции по swarm, хоть он и deprecated. Это займёт человеко-неделю.

Ты оценил то, что выкатка приложения на 3 недели раньше для тебя сильно выгоднее. Потом, когда-нибудь, может быть вы переделаете это на кубер (и потеряете человеко-неделю).

Вот это тех.долг - мы выбрали простое решение, вместо "правильного".

Пример на самом деле очень не корректный. Но в рамках текущего разговора - показательный.

Цель оправдывает средства. Не стоит ждать идеального изучения документации и несколько месяцев готовиться, чтобы попробовать новую для себя платформу и попробовать запустить на ней приложение, тем более, что какой-то опыт уже имеется. Некоторые вещи лучше делать пока есть желание их делать. Запустить приложение в кубере и поразбираться с этим несколько выходных подряд и параллельно почитать доки, посмотреть видео и т.д. это норм. А можно и dev окружение попробовать там развернуть, насесть на это командой и набивая шишки тащить это дальше в staging и prod. Инфраструктура это тоже приложение и проходить даолжно те же стадии и сначала это POC где можнт использоваться любой удобный быстрый подход.

хорошо вам там в стартапах
мы тут шишечки месяцок набьём, но ничего страшного - у нас и так доступность шесть девяток - 69,99999

И параллельно анализируются риски, человекочасы и всё это применяется и либо двигается дальше либо нет.

Про dev и этапы хотя бы опять не прочли. Ой.

Так ведь и в случае с готовой наследуемой архитектурой приложения таже история. Можно побыстрому набросать в простеньких фреймворках, а можно за несколько недель изучить сложную готовую систему для быстрой разработки, в которой масса проблем уже решена, но которую нужно долго изучать. Нормальная современная практика - это когда, чукча читатель - чукча не писатель, - а когда наоборот, то получается тех. долг - нет?

ну конечно, пусть команда месяц набьёт шишек.
для команды из 5 человек - это всего 5 человеко-месяцев.
ерунда, ей богу.

Пусть сначала 1 человек их набьёт, ему и poc делать

а потом через полгода в проде внезапно отвалится kube-api из-за неучтённого протухания сертификата...

> Цель оправдывает средства.
ахха.
только чуть последовательнее надо быть.
Спасибо и еще раз приятного вечера.