<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" >

  <channel>
    <title><![CDATA[Статьи]]></title>
    <link>https://habr.com/ru/users/ar2code/publications/articles/</link>
    <description><![CDATA[Хабр: статьи пользователя ar2code]]></description>
    <language>ru</language>
    <managingEditor>editor@habr.com</managingEditor>
    <generator>habr.com</generator>
    <pubDate>Thu, 23 Apr 2026 22:19:17 GMT</pubDate>
    
    
      <image>
        <link>https://habr.com/ru/</link>
        <url>https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png</url>
        <title>Хабр</title>
      </image>
    

    
      
        
    
    <item>
      <title><![CDATA[Чем заняться тимлиду, если не кодить? Рассказываю о своих задачах]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/738036/</guid>
      <link>https://habr.com/ru/articles/738036/?utm_campaign=738036&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<p>Моя предыдущая <a href="https://habr.com/ru/articles/730584/" rel="noopener noreferrer nofollow"><u>статья</u></a> вызвала довольно бурное обсуждение на тему, кто такой тимлид и чем он занимается, поэтому в этой статье я хотел рассказать о том, чем занимаюсь я.</p><p>Вообще задачи тимлида могут сильно отличаться в разных компаниях. В моем опыте обычно было так: чем меньше в команде представлено ролей, тем больше задач будет у тимлида. Я как-то работал с тимлидом, которому приходилось даже тестировать, потому что в команде не было тестировщика.</p><p>Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.</p> <a href="https://habr.com/ru/articles/738036/?utm_campaign=738036&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать далее</a>]]></description>
      
      <pubDate>Sat, 27 May 2023 19:49:57 GMT</pubDate>
      <dc:creator><![CDATA[ar2code]]></dc:creator>
      <category><![CDATA[Управление разработкой]]></category><category><![CDATA[Карьера в IT-индустрии]]></category>
      <category><![CDATA[тимлидство]]></category><category><![CDATA[управление командой]]></category><category><![CDATA[управление разработкой]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Почему я чуть не запорол свою карьеру тимлида. 4 совета начинающим]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/730584/</guid>
      <link>https://habr.com/ru/articles/730584/?utm_campaign=730584&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<p>Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромном воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.</p><p>Итак, четыре проблемы начинающего тимлида.</p><p></p> <a href="https://habr.com/ru/articles/730584/?utm_campaign=730584&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать далее</a>]]></description>
      
      <pubDate>Thu, 20 Apr 2023 19:16:16 GMT</pubDate>
      <dc:creator><![CDATA[ar2code]]></dc:creator>
      <category><![CDATA[Управление разработкой]]></category><category><![CDATA[Карьера в IT-индустрии]]></category>
      <category><![CDATA[тимлид]]></category><category><![CDATA[начинающий руководитель]]></category><category><![CDATA[управление командой]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Как рассчитать скорость работы команды и не завалить дату релиза? Спринтовая модель глазами тимлида]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/724620/</guid>
      <link>https://habr.com/ru/articles/724620/?utm_campaign=724620&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<img src="https://habrastorage.org/getpro/habr/upload_files/36b/e9d/15f/36be9d15ff425ec783800e77a1680a2d.jpeg" /><p>Всем привет! Я достаточно давно в разработке и мне приходилось видеть разные вариации гибких методологий управления проектами. Чаще всего я встречал такую картину: вроде есть спринты, дейли, иногда даже демо, отчеты, но все равно, получив набор фичей от бизнеса, команда не могла сказать достаточно быстро (где-то в течение недели), сколько времени ей потребуется на реализацию. Со временем я пришел к своей спринтовой модели, которая позволяет моей команде довольно точно и быстро давать оценку трудозатрат, что в итоге приводит к успешному попаданию в дату релиза.</p><p></p> <a href="https://habr.com/ru/articles/724620/?utm_campaign=724620&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать далее</a>]]></description>
      
      <pubDate>Fri, 24 Mar 2023 19:53:29 GMT</pubDate>
      <dc:creator><![CDATA[ar2code]]></dc:creator>
      <category><![CDATA[Управление разработкой]]></category><category><![CDATA[Управление проектами]]></category><category><![CDATA[Управление продуктом]]></category>
      <category><![CDATA[управление разработкой]]></category><category><![CDATA[спринты]]></category><category><![CDATA[управление проектами и командой]]></category><category><![CDATA[гибкая методология разработки]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Пример модульного андроид приложения с помощью Navigation component и Koin (DI)]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/558494/</guid>
      <link>https://habr.com/ru/articles/558494/?utm_campaign=558494&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<p>Разработчик, привет!</p><p>В этом статье я хочу поделиться примером модульного андроид приложения с помощью NavComponent (JetPack) и Koin (DI).</p><p>У нас в компании есть много разных андроид проектов, которые должны использовать фичи (Feature) друг друга - это некая экосистема. Чтобы этого добиться нам необходимо разрабатывать эти фичи максимально независимыми и гибкими.</p> <a href="https://habr.com/ru/articles/558494/?utm_campaign=558494&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать далее</a>]]></description>
      
      <pubDate>Thu, 20 May 2021 14:24:43 GMT</pubDate>
      <dc:creator><![CDATA[ar2code]]></dc:creator>
      <category><![CDATA[Android]]></category>
      <category><![CDATA[modularization]]></category><category><![CDATA[navigation]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Почему я не использую SharedViewModel для фрагментов?]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/504712/</guid>
      <link>https://habr.com/ru/articles/504712/?utm_campaign=504712&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[Хабр, привет!<br>
<br>
Задача организации взаимодействия между фрагментами встречается очень часто. На первый взгляд, ShareViewModel отлично подходит для этого. Мы создаем ViewModel с owner = наша activity, в которой отображаются наши фрагменты, и получаем эту ViewModel внутри каждого фрагмента. Т.к. владелец ViewModel — активити, то фрагменты получают один и тот же экземпляр ViewModel, что и позволяет им обмениваться данными, вызывать методы и т.д. Вот ссылка из <a href="https://developer.android.com/topic/libraries/architecture/viewmodel#sharing" rel="nofollow">документации</a>. <br>
<br>
На рисунке ниже представлена схема взаимодействия 3-х фрагментов.<br>
<br>
<img src="https://habrastorage.org/getpro/habr/post_images/367/ad4/04f/367ad404f3bf81ec55692ad5c7fc7ac7.jpg" alt="image"><br>
<br>
Т.е. что мы делаем: в каждом фрагменте мы достаем SharedViewModel тех фрагментов, с которыми нам нужно взаимодействовать…<br>
<br>
И это не самое лучшее решение, на мой взгляд. Потому что:<br> <a href="https://habr.com/ru/articles/504712/?utm_campaign=504712&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать дальше &rarr;</a>]]></description>
      
      <pubDate>Sun, 31 May 2020 18:39:45 GMT</pubDate>
      <dc:creator><![CDATA[ar2code]]></dc:creator>
      <category><![CDATA[Android]]></category>
      <category><![CDATA[android development]]></category><category><![CDATA[android architecture components]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Архитектура и дизайн Android приложения (мой опыт)]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/500128/</guid>
      <link>https://habr.com/ru/articles/500128/?utm_campaign=500128&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[Хабр, привет!<br>
<br>
Сегодня я хочу рассказать об архитектуре, которой я следую в своих Android приложениях. За основу я беру Clean Architecture, а в качестве инструментов использую Android Architecture Components (ViewModel, LiveData, LiveEvent) + Kotlin Coroutines. К статье прилагается код вымышленного примера, который доступен на <a href="https://github.com/ar2code/AndroidArchitectureSample" rel="nofollow">GitHub</a>.<br>
<br>
<h4>Disclaimer</h4><br>
Я хочу поделиться своим опытом разработки, я ни в коем случае не претендую на то, что мое решение является единственно верным и лишенным недостатков. Архитектура приложения – это своего рода модель, которую мы выбираем для решения той или иной задачи, и для выбранной модели важна её адекватность применения к конкретной задаче. <br> <a href="https://habr.com/ru/articles/500128/?utm_campaign=500128&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать дальше &rarr;</a>]]></description>
      
      <pubDate>Sat, 02 May 2020 15:18:37 GMT</pubDate>
      <dc:creator><![CDATA[ar2code]]></dc:creator>
      <category><![CDATA[Android]]></category>
      <category><![CDATA[android development]]></category><category><![CDATA[clean architecture]]></category><category><![CDATA[android architecture components]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[События на базе LiveData Android]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/468749/</guid>
      <link>https://habr.com/ru/articles/468749/?utm_campaign=468749&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[LiveData – это отличный инструмент для связывания состояния ваших данных и объектов с жизненным циклом (LifecycleOwner, обычно это Fragment или Activity).<br/>
<br/>
Обычно LiveData помещаются во ViewModel и используются для обновления состояния вашего UI. Часто ViewModel может пережить LifecycleOwner и сохранить состояние LiveData. Такой механизм подходит, когда вам нужно сохранить данные и восстановить их через некоторое время, например, после смены конфигурации.<br/>
<br/>
Но что, если мы хотим использовать механизм событий, а не состояний? Причем обязательно в контексте жизненного цикла обозревателя (LifecycleOwner). Например, нам нужно вывести сообщение после асинхронной операции при условии, что LifecycleOwner еще жив, имеет активных обозревателей и готов обновить свой UI. Если мы будем использовать LiveData, то мы будем получать одно и то же сообщение после каждой смены конфигурации, или при каждом новом подписчике. Одно из решений, которое напрашивается, это после обработки данных в некотором обозревателе обнулить эти данные в LiveData.<br/>
<br/>
Например, такой код:<br/>
<br/>
<pre><code class="kotlin">Observer {
	handle(it)
	yourViewModel.liveData.value = null
}
</code></pre><br/>
Но такой подход имеет ряд недостатков и не отвечает всем необходимым требованиям. <br/>
 <a href="https://habr.com/ru/articles/468749/?utm_campaign=468749&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать дальше &rarr;</a>]]></description>
      
      <pubDate>Tue, 24 Sep 2019 16:49:39 GMT</pubDate>
      <dc:creator><![CDATA[ar2code]]></dc:creator>
      <category><![CDATA[Android]]></category>
      <category><![CDATA[android]]></category><category><![CDATA[livedata]]></category><category><![CDATA[jetpack]]></category>
    </item>
  

  

  

	
  

  

  

      

      

      

    
  </channel>
</rss>
