<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Комментарии: Если вам нужен архитектор, то у меня для вас плохие новости	</title>
	<atom:link href="https://koniglabs.ru/nuzhen-arhitektor/feed/" rel="self" type="application/rss+xml" />
	<link>https://koniglabs.ru/nuzhen-arhitektor/</link>
	<description></description>
	<lastBuildDate>Wed, 21 May 2025 12:54:06 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		Автор: Николай		</title>
		<link>https://koniglabs.ru/nuzhen-arhitektor/#comment-5230</link>

		<dc:creator><![CDATA[Николай]]></dc:creator>
		<pubDate>Fri, 11 Jun 2021 05:37:02 +0000</pubDate>
		<guid isPermaLink="false">https://koniglabs.com/?p=5925#comment-5230</guid>

					<description><![CDATA[@Алексей
Согласен. Воспитание и рост разработчиков нужны не всегда. С точки зрения бизнеса, как бы ужасно это ни звучало, - разработчик есть полезный ресурс с определёнными свойствами. Например, с умением писать код. И ещё думать.. но это уже не всегда обязательно. ;)
Вполне можно создать годную, хорошо идущую по волнам галеру, на принципе множества Звёзд. Чем больше Звёзд будет введено в эксплуатацию, тем меньше будет Bus Factor. В пределе мы получим вполне надёжную и устойчивую в долгой перспективе систему. Работать в ней захочет далеко не каждый - но ведь, положа руку на сердце, не каждый кодер хочет быть разработчиком. Так что своя целевая аудитория у такого HR брэнда всегда найдётся.

Ну, и не надо забывать также, что есть системы на уровне государства и крупного бизнеса, где основные проблемы - вовсе не в написании кода или выстраивании архитектуры отдельного монолита или набора микросервисов. Где главный challenge - в понятной, хорошо работающей интеграции. Которая оказывается понятной не только лишь всегда - мало когда она таковой является. Вот тут появляется ещё один вид Архитектора - Сантехник. Который договаривается с Сантехниками из других систем, как проложить трубы от одного здания к другому, где пройтись герметиком, а где просто накрутить изоленты. Где протечка будет критически опасной, а где &quot;и так сойдёт&quot;. Это - очень важная роль, для исполнения которой надо знать и архитектуру систем, и психологию, и характер бюрократических отношений, и конкретные сложности - бюрократические и технические - в интегрируемых системах. Причём понятно, что это - костыль, но это чень важный костыль, без которого кривоногие интеграции никак не смогут ходить.]]></description>
			<content:encoded><![CDATA[<p>@Алексей<br />
Согласен. Воспитание и рост разработчиков нужны не всегда. С точки зрения бизнеса, как бы ужасно это ни звучало, &#8211; разработчик есть полезный ресурс с определёнными свойствами. Например, с умением писать код. И ещё думать.. но это уже не всегда обязательно. 😉<br />
Вполне можно создать годную, хорошо идущую по волнам галеру, на принципе множества Звёзд. Чем больше Звёзд будет введено в эксплуатацию, тем меньше будет Bus Factor. В пределе мы получим вполне надёжную и устойчивую в долгой перспективе систему. Работать в ней захочет далеко не каждый &#8211; но ведь, положа руку на сердце, не каждый кодер хочет быть разработчиком. Так что своя целевая аудитория у такого HR брэнда всегда найдётся.</p>
<p>Ну, и не надо забывать также, что есть системы на уровне государства и крупного бизнеса, где основные проблемы &#8211; вовсе не в написании кода или выстраивании архитектуры отдельного монолита или набора микросервисов. Где главный challenge &#8211; в понятной, хорошо работающей интеграции. Которая оказывается понятной не только лишь всегда &#8211; мало когда она таковой является. Вот тут появляется ещё один вид Архитектора &#8211; Сантехник. Который договаривается с Сантехниками из других систем, как проложить трубы от одного здания к другому, где пройтись герметиком, а где просто накрутить изоленты. Где протечка будет критически опасной, а где &#8220;и так сойдёт&#8221;. Это &#8211; очень важная роль, для исполнения которой надо знать и архитектуру систем, и психологию, и характер бюрократических отношений, и конкретные сложности &#8211; бюрократические и технические &#8211; в интегрируемых системах. Причём понятно, что это &#8211; костыль, но это чень важный костыль, без которого кривоногие интеграции никак не смогут ходить.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Алексей		</title>
		<link>https://koniglabs.ru/nuzhen-arhitektor/#comment-5229</link>

		<dc:creator><![CDATA[Алексей]]></dc:creator>
		<pubDate>Thu, 10 Jun 2021 07:54:17 +0000</pubDate>
		<guid isPermaLink="false">https://koniglabs.com/?p=5925#comment-5229</guid>

					<description><![CDATA[Коля, спасибо за статью. Мне кажется что очень классно изложил свои мысли. Действительно, решать две ситуации в реальном мире тяжело и там куча подводных камней. Но, если хотя бы примерно знаешь что тебя ожидает дальше, то тебе проще &quot;инструменты&quot; для работы подбирать. 
Я бы добавил что при реализации того или другого решения важно понимать ситуацию. Мы можем реализовать спокойно подход &quot;звезды&quot;, если срок жизни проекта не большой или затраты на то что у нас разработчики не будут мини архитекторами то же не большие будут в данном проекте. Другими словами, мы понимаем что у нас цели кроткосрочные, Жизненный Цикл не большой и высокая ротация сотрудников для нас норма. При этом если мы делаем продукт и цели хотя бы среднесрочные и одним из важных показателей, который влияет на основные метрики (предположим это качество, деньги и т.д.) является стабилизация состава всей команды, то скорее всего надо инвестировать во второе решение. 
А возможно есть ещё какие-нибудь решений?)))]]></description>
			<content:encoded><![CDATA[<p>Коля, спасибо за статью. Мне кажется что очень классно изложил свои мысли. Действительно, решать две ситуации в реальном мире тяжело и там куча подводных камней. Но, если хотя бы примерно знаешь что тебя ожидает дальше, то тебе проще &#8220;инструменты&#8221; для работы подбирать.<br />
Я бы добавил что при реализации того или другого решения важно понимать ситуацию. Мы можем реализовать спокойно подход &#8220;звезды&#8221;, если срок жизни проекта не большой или затраты на то что у нас разработчики не будут мини архитекторами то же не большие будут в данном проекте. Другими словами, мы понимаем что у нас цели кроткосрочные, Жизненный Цикл не большой и высокая ротация сотрудников для нас норма. При этом если мы делаем продукт и цели хотя бы среднесрочные и одним из важных показателей, который влияет на основные метрики (предположим это качество, деньги и т.д.) является стабилизация состава всей команды, то скорее всего надо инвестировать во второе решение.<br />
А возможно есть ещё какие-нибудь решений?)))</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>