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

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

  <channel>
    <title><![CDATA[Комментарии / Профиль devbitrix]]></title>
    <link>https://habr.com/ru/users/devbitrix/comments/</link>
    <description><![CDATA[Хабр: комментарии пользователя devbitrix]]></description>
    <language>ru</language>
    <managingEditor>editor@habr.com</managingEditor>
    <generator>habr.com</generator>
    <pubDate>Fri, 24 Apr 2026 01:50:34 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>07.02.2025 13:21:55 </title>
      <guid isPermaLink="true">https://habr.com/ru/companies/kislorod/articles/879992/#comment_27892448</guid>
      <link>https://habr.com/ru/companies/kislorod/articles/879992/#comment_27892448</link>
      <description><![CDATA[<p>Спасибо за оценку.</p><p>По поводу стандартизации процесса разработки — тут важно определить, что подразумевается под «стандартизацией». Является ли стандартизацией процесса разработки принятый в компании Code style? Кажется, что да, но бывает, что не все разработчики соблюдают Code style, и иногда это может считаться вполне оправданным (например, при внесении изменений в legacy проект, где весь код написан по другим стандартам).</p><p>В нашей компании использование «базового модуля» не является стандартом. К каждому проекту мы подходим индивидуально. Многое зависит от типа проекта и от опыта команды разработки, которая будет его делать. Использовать или нет базовый модуль, команда принимает самостоятельно. Но если «базовый модуль» используется на проекте, то «стандартизация» проявляется в том, что появляется некая «структура» (рамки) и правила, которые нужно учитывать при написании нового кода.</p><p>По поводу сокращения времени на запуск новых проектов — это сложно оценить, если не собирать метрики. По нашему опыту: для нескольких проектов, где мы с заказчиками изначально согласовали существенно меньший бюджет проекта на основании того, что при реализации этого проекта будут использоваться наши «внутренние модули», мы в итоге в эти «сокращенные» бюджеты уложились. В целом: «стандартизировать» лучше то, что уже проверено и улучшено посредством нескольких итераций. Чтобы понять, «ускорилось» что-то или нет, нужно отслеживать «как у нас сейчас» и «как стало после применения».</p>]]></description>
      <pubDate>Fri, 07 Feb 2025 13:21:55 GMT</pubDate>
      <dc:creator><![CDATA[]]></dc:creator>
    </item>
  

  
    <item>
      <title>07.02.2025 13:18:38 </title>
      <guid isPermaLink="true">https://habr.com/ru/companies/kislorod/articles/879992/#comment_27892442</guid>
      <link>https://habr.com/ru/companies/kislorod/articles/879992/#comment_27892442</link>
      <description><![CDATA[<p>Вопрос о том, что выгоднее, стоит рассмотреть с двух точек зрения: кому это выгоднее?</p><p>Для заказчика, который хочет создать интернет-магазин по типовому шаблону в сжатые сроки и с ограниченным бюджетом, выбор «готового решения» (например, от «Аспро») может стать хорошей альтернативой разработке с нуля. Выгодно ли это таким заказчикам? Вероятно, да.</p><p>Мы проанализировали запросы наших клиентов и пришли к выводу, что процент таких запросов остается стабильным, если не увеличивается. Учитывая, что некоторые заказчики обращаются к нам за технической поддержкой проектов, созданных на основе «готовых решений», мы были вынуждены повысить квалификацию своих разработчиков в работе с этими решениями. Теперь у нас есть специалисты по «Аспро» и другим популярным готовым платформам.</p><p>Если говорить про нас как компанию, то нам, конечно, выгоднее продавать собственные решения вместо использования сторонних. Это выгодно и нашим заказчикам, если мы осуществляем дальнейшее сопровождение проекта. Если эта функция будет передана другим подрядчикам или выполняться силами заказчика, выгода может быть не столь очевидной. Мы прилагаем все усилия, чтобы сделать процесс максимально простым и удобным: предоставляем документацию, консультируем и поддерживаем.</p>]]></description>
      <pubDate>Fri, 07 Feb 2025 13:18:38 GMT</pubDate>
      <dc:creator><![CDATA[]]></dc:creator>
    </item>
  

  
    <item>
      <title>07.02.2025 13:13:07 </title>
      <guid isPermaLink="true">https://habr.com/ru/companies/kislorod/articles/879992/#comment_27892418</guid>
      <link>https://habr.com/ru/companies/kislorod/articles/879992/#comment_27892418</link>
      <description><![CDATA[<p>Спасибо за комментарий. Рад, что информация оказалась полезной для вас.</p><ol><li><p><strong>Процесс адаптации новых разработчиков к проекту является крайне важным аспектом.</strong> Ведь использование внутренних модулей требует от новичков дополнительных усилий для изучения их работы и навыков применения. И тем самым повышает «порог входа» при онбординге нового разработчика на такой проект.&nbsp;</p><p></p><p>Поэтому необходимо заранее продумать меры, которые могли бы облегчить адаптацию. Например, можно организовать внутреннюю презентацию для разработчиков, которая будет доступна в записи. Также важно предоставить открытую и исчерпывающую документацию, а также обеспечить наличие внутренних экспертов в команде, которые смогут помочь с любыми вопросами, связанными с реализацией.</p></li><li><p><strong>По поводу вовлечения разработчиков</strong> — это не менее важный аспект, поскольку часто можно столкнуться с их сопротивлением, когда новые инициативы пытаются навязать сверху.</p><p></p><p>Чтобы избежать подобных трудностей, необходимо обсудить новый подход к разработке внутри команд. Все участники должны понимать, какую пользу он может принести и какие проблемы способен решить. Важно, чтобы нашлись лидеры, готовые продвигать этот подход, а также возможность отказаться от него, если он не оправдает ожиданий.</p><p></p><p>Можно подойти к изменениям постепенно: реализовать один-два «пилотных» проекта, собрать обратную связь от разработчиков и заказчиков, а затем принять решение — отказаться от этого подхода или улучшить его и использовать в дальнейшем.</p></li></ol>]]></description>
      <pubDate>Fri, 07 Feb 2025 13:13:07 GMT</pubDate>
      <dc:creator><![CDATA[]]></dc:creator>
    </item>
  

  
    <item>
      <title>27.09.2024 14:58:19 </title>
      <guid isPermaLink="true">https://habr.com/ru/companies/kislorod/articles/846576/#comment_27349240</guid>
      <link>https://habr.com/ru/companies/kislorod/articles/846576/#comment_27349240</link>
      <description><![CDATA[<p>Да, страницы создаются на php. Но в Битриксе есть возможность добавлять разные шаблонизаторы. Но для того, чтобы их добавить, нужно еще потрудиться и покодить. Ну по сути для Битрикса это не сильно актуально.</p><p>Тут еще можно почитать:&nbsp;<a href="https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&amp;LESSON_ID=3235&amp;ysclid=m1ktie6elk969199473" rel="noopener noreferrer nofollow">https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&amp;LESSON_ID=3235&amp;ysclid=m1ktie6elk969199473</a></p>]]></description>
      <pubDate>Fri, 27 Sep 2024 14:58:19 GMT</pubDate>
      <dc:creator><![CDATA[]]></dc:creator>
    </item>
  

  
    <item>
      <title>20.09.2024 09:23:45 </title>
      <guid isPermaLink="true">https://habr.com/ru/companies/kislorod/articles/844724/#comment_27319450</guid>
      <link>https://habr.com/ru/companies/kislorod/articles/844724/#comment_27319450</link>
      <description><![CDATA[<p>спасибо) рад, что понравилось. опыта накопилось достаточно, пора делиться</p>]]></description>
      <pubDate>Fri, 20 Sep 2024 09:23:45 GMT</pubDate>
      <dc:creator><![CDATA[]]></dc:creator>
    </item>
  

      

      

    
  </channel>
</rss>
