Как поставить задачу программисту 1с
Одна из основных проблем в ИТ проектах — взаимопонимание двух миров: бизнеса и разработки. Одни хотят быстро и красиво, другие хотят получить исчерпывающее описание хотелки. Переговоры занимают много времени, но еще больше — исправление ошибок. Как эффективно выстроить процесс, рассказывает зам технического директора музыкального сервиса «Звук» Кирилл Ларин.
Так как разработка (+тестирование) — самое дорогое звено в создании ИТ-решения, то необходимо экономить время разработчика любым способом.
Если задача поступает в разработку с неполным описанием, то есть в ней нет всех Use cases и Corner cases, то разработчик тратит массу времени на выяснение нюансов. Или не хочет вступать в полемику и делает все, опираясь на свою картину мира, по принципу “художник так видит”.
Если в компании ограничены ресурсы, нет системного аналитика, либо он не покрывает весь бэклог, то необходимо найти другой выход, который позволит эффективно решить проблему.
Одно из решений — выработка стандарта описания задач. Лучше больше продумывать их до реализации, чем додумывать в процессе исполнения. Здесь необходимо найти баланс между заказчиком и разработкой.
Основа баланса — смещение большей части работы на постановщика/представителя бизнеса. Чем лучше он проработает фичу, тем вернее будет результат на выходе.
Однако часто бизнес не знает, что требуется разработчику, чтобы сделать задачу верно и в срок. Как найти общий язык?
Сквозь слёзы и пот мы в Звуке сформировали стандарт, который позволяет получить 90% информации, необходимой для решения любой it-задачи.
Главная цель — реализовать именно то, что хотел заказчик. Так как любую информацию можно трактовать по-разному, то следует использовать утвержденный формат постановки задачи. Такой формат, который уменьшит вероятность разночтений.
Для этого заказчику необходимо описать следующие аспекты задачи:
- Требование
- Проблема, которую надо решить
- Продуктовые требования
- Технологические требования
- User stories
- Use cases
- Corner cases
Рассмотрим подробно каждый аспект.
Для точного определения, что требуется сделать в постановке задачи используется принцип SMART:
- Specifiс. Задача должна быть конкретной. Куда мы пойдем, чего мы хотим достичь?
- Measurable. В чем должен измеряться результат и какой результат будет для нас хорошим
- Attainable. Достижимые цели. Здесь мы проверяем, находятся ли наши цели в реальных пределах
- Relevant. Все задачи должны относиться к бизнесу и должны вести к цели проекта
- Time-bound. Обязательное ограничение во времени. Большие задачи надо стараться разбить на более мелкие
Какую проблему заказчик пытается решить?
Какие метрики будут оцениваться, какие показатели будут достигнуты в ходе решения задачи?
Какие технологические требования и ограничения предъявляет заказчик к функционалу?
Какая функциональность ожидается?
Несмотря на то, что US в огромной степени играют роль, ранее принадлежавшую спецификациям требований, сценариям использования и т.п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
- Они не являются детальным описанием требований (то-есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого).
- Они являются короткими и легко читаемыми, понятными разработчикам, заказчикам и пользователям.
- Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель.
- Они относительно легко поддаются оценке, таким образом, усилия, необходимые для реализации, могут быть быстро определены.
- Они не занимают огромных, громоздких документов, а организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации.
- Они не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок», избегая таким образом слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения.
- Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации.
Текст самой US должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которые пользователь получит после того как история случится.
- Есть одна Роль
- Есть одно действие
- Есть одна ценность/влияние
US можно оценить по критериям INVEST:
- Independent. Меньше зависимостей — легче планировать
- Negotiable. Детали появляются в ходе обсуждений команды разработки и заказчика
- Valuable. Измеримая история — какие метрики изменились
- Estimable. Большая или расплывчатая история — невозможно точно оценить трудозатраты
- Small. Небольшая история разрабатывается в рамках недели
- Testable. Простой критерий готовности
Важно помнить, что:
- Лучше написать много историй поменьше, чем несколько громоздких.
- Каждая история в идеале должна быть написана избегая технического жаргона — чтобы суть была понятна и бизнесу и разработке.
- Истории должны быть написаны таким образом, чтобы их можно было протестировать.
- Тест-план должен быть написан до кода.
- Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
- Каждая история должна содержать оценку.
- История должна иметь концовку — т.е. приводить к конкретному результату.
- История должна помещаться в итерацию.
Какой сценарий необходимо пройти, чтобы достичь цель?
Что UC включают в себя:
- Кто пользуется системой
- Что пользователь хочет сделать
- Какая у пользователя цель
- Шаги к достижению цели
- Как система реагирует на действия пользователя
Что UC не включают в себя:
- Реализацию на специфическом языке (терминология и т.п.)
- Информацию про интерфейсы
В зависимости от глубины и сложности того, что вы хотите или должны достичь, UC описывают комбинацию следующих элементов:
- Актер — кто или что выполняет действие.
- Предварительные условия — что должно быть/случиться до и после прохождения UC.
- Триггер — какое-то событие, которое стало причиной запуска UC.
- Главный успешный сценарий — прохождение UC по ожидаемому сценарию.
- Альтернативный сценарий — вариации главного успешного сценария. Происходит, когда что-то пошло не так на системном уровне.
Для написания UC используются следующие шаги:
- Определить кто будет пользоваться системой.
- Выбрать одного пользователя.
- Определить, что этот пользователь будет делать с системой. Каждое действие станет UC.
- Для каждого UC определить курс событий, когда этот пользователь использует систему.
- Опишите основной курс в описании для UC. Опишите его с точки зрения того, что делает пользователь и что система делает в ответ, о чем пользователь должен знать.
- Когда базовый курс описан, рассмотрите альтернативные курсы и добавьте их, чтобы «расширить» UC.
- Ищите общие черты среди UC. Объедините их как UC одного курса.
- Повторить шаги с 2 по 7 для всех пользователей.
Для того чтобы избежать непредвиденных сценариев в работе фичи, необходимо описать все возможные CC. По сути, CC отвечает на вопрос А что будет, если . СС должны покрывать большинство вариантов и указывать на причины возникновения вариантов.
Чтобы описать CC нужно определить, какие факторы влияют на фичу и описать результат/сценарий при всевозможных комбинациях этих факторов.
Для этого целесообразно использовать таблицу, в которой на пересечении факторов будет описан результат/сценарий.
С теорией всё понятно, но как дело обстоит на практике? Разберем упрощенное описание задачи на примере сохранения настроек приложения.
Сохранять настройки приложения
В ходе опроса было выявлено, что пользователь ожидает, что приложение запоминает его последнее состояние (настройки). По аналогии с другими сервисами.
Продуктовые требования
Использовать распространенный UX для реализации решения
Технологические требования
Сохранять настройки приложения на серверной стороне в связке с данными пользователя
Как пользователь, я хочу, чтобы приложение запоминало мои настройки, чтобы мне не приходилось указывать их каждый раз при авторизации
— Пользователь открывает приложение.
— Пользователь входит в учетную запись в приложении.
— Пользователь устанавливает настройки приложения.
— Система сохраняет настройки.
— Пользователь выходит из учетной записи в приложении.
— Пользователь входит в учетную запись в приложении (+ на другом устройстве).
— Система передает сохраненные настройки в приложение.
— Приложение отображает сохраненные настройки пользователя.
Corner case
Обеспечить обратную совместимость со старыми клиентами.
Первое. Объяснить команде боль. Как известно, если вы указываете причину внедрения, конверсия увеличивается.
Второе. Показать пример, поставить некоторое количество задач для начала по стандарту, показать заказчикам, как это надо делать, как оно работает.
Третье. При внедрении обязательно собрать обратную связь по стандарту. Ответить на все вопросы, внести корректировки. Тогда будет коллективный труд, порог вхождения ниже.
Четвертое. Воспринимать все нововведения, как эксперимент. Если он удался (были достигнуты цели), он приживется сам собой, так как мотивация у людей будет осознанной. Если не удался, можно вернуться к прежнему состоянию.
Пятое. Закрепить нововведения фактами в виде цифр — сравните с периодом до внедрения. Производительность увеличилась на столько-то, количество ошибок упало на столько-то.
Каждая система, находящаяся в покое, противиться изменению. При внедрении подобных стандартов/изменении процессов вы столкнетесь с сопротивлением. Но игра стоит свеч. Лучший аргумент — это метрики. Если они пошли вверх, значит, вы на верном пути.
В «Звуке» после внедрения стандарта скорость и качество работы увеличилось в 2 раза. Мы получили положительные отзывы от всех участников команды и решили основную проблему.
Скажите, вы когда-нибудь слышали фразу: «Дайте нам ТЗ» от ваших 1С-разработчиков?
А теперь скажите, насколько сильно она вас раздражала? Готовы ли вы были к тому, чтобы выделить личное время на изучение незнакомой вам среды, будь то 1С или что-то другое? Желаете ли вы добровольно описать функциональные, нефункциональные, системные и прочие требования, а также атрибуты качества и другие рабочие параметры, чтобы преподнести желаемый вами результат «на блюдечке» вашему подрядчику?
И это вместо того, чтобы заплатить деньги профессионалам за их работу и получить предложения от них.
Не было ли у вас желания послать такого подрядчика к чертям?
Не опускались ли у вас руки от безысходности ситуации – ведь, чтобы сделать ТЗ нужно владеть терминологией разрабатываемой системы и, как минимум, представлять себе возможности, которые предлагает эта система при масштабировании? Располагаете ли вы такой информацией?
Как человек, посвятивший более 12 лет своей жизни автоматизации процессов, уверен, что такая ситуация, как минимум, несправедлива по отношению к клиентам.
Вроде бы как ты хочешь заплатить деньги за решение своей проблемы, и логично было бы получить варианты ее решения от подрядчика, но тебя вынуждают делать непрофильную работу самому, да еще и думать за тех, кто мог бы (и должен) озаботиться этим по роду своей деятельности!
Конечно, я надеюсь, что такие подрядчики скоро вымрут как класс, ведь после них клиенты теряют вообще какую-либо мотивацию что-то менять в своих учетных системах.
Сегодня же я хочу дать совет. Особенно он будет актуален малому бизнесу, у которого нет времени разбираться во множестве технической информации вокруг ИТ-систем, в том числе 1С.
И вот мой совет:
Гоните в шею тех подрядчиков, кто просит у вас ТЗ. Если у вас оно есть – хорошо, но вы вовсе не обязаны заниматься работой технических специалистов.
Время ТЗ истекло. Совсем.
В современных динамично-меняющихся условиях бизнеса пока вы (или кто-то за вас) будет писать ТЗ, желаемая вами идея уже потеряет актуальность, а команда ваших единомышленников – мотивацию к ее реализации.
Именно поэтому я подготовил для вас чек-лист о том, как работать с подрядчиками максимально эффективно:
- Позвоните подрядчику и обратите внимание на то, как быстро на том конце снимают трубку. Если ее не снимают – исключите такого подрядчика из вашей жизни – он будет также работать.
- Попросите специалиста проконсультировать вас по вашей проблеме. Расскажите ему о ситуациях, которые вызывают неудобства при управлении бизнес-процессами, опишите, при каких обстоятельствах возникают проблемы. Послушайте ответ.
- Обратите внимание на то, сколько времени готов уделить вам специалист по телефону. Если вам ответил продажник – попросите к телефону именно специалиста по 1С. Если он просит ТЗ – вы знаете, что делать
- Задает ли вам специалист вопросы по существу или пытается всеми силами узнать ваш е-мэйл и распрощаться?
- Спросите, решали ли в компании такую же или похожую задачу. Если решали, то есть ли рекомендации.
- Договоритесь о времени, в течение которого вам будет сделано коммерческое предложение. Обратите внимание будет ли оно готово вовремя или нет.
Теперь давайте поговорим о том, как наиболее эффективно вести диалог с подрядчиком, который претендует на решение вашей задачи при отсутствии ТЗ. Как поставить ему задачу так, чтобы она была понятна?
Ну, во-первых, надо признаться, что вы можете не представлять себе в полной мере, что вы хотите. И это нормально, особенно, если ваш опыт автоматизации пока невелик. Если ваш подрядчик тоже это понимает, то он обязательно подскажет вам возможные пути автоматизации по вашему описанию проблемы, а не будет требовать от вас ТЗ.
Чаще всего путей решения будет несколько. Задумайтесь, если получите только один.
Чтобы ваше общение было более эффективным подготовьте ответы на наиболее часто встречаемые вопросы:
Какая у вас платформа? Платформа – это то, на чем будет строиться ваша учетная система. Набор механизмов для решения прикладных задач бизнеса. Чаще всего ответом на этот вопрос будет «8.2» или «8.3», если речь идет об 1С. Если вы не знаете, какая у вас платформа или какую платформу следует приобрести – пусть вам расскажет об этом сам подрядчик – не стесняйтесь просить его об этом.
Какая у вас конфигурация? Конфигурация представляет собой среду, в которой вы ведете или собираетесь вести учет своей деятельности. Конфигураций великое множество: если вы знаете, как называется именно ваша – сообщите об этом подрядчику, не знаете – спрашивайте, пусть показывает или рекомендует к покупке и объясняет почему именно эту конфигурацию следует использовать в вашем случае, а не другую.
Сколько пользователей будет работать в вашей системе? Хороший вопрос, который обязательно должен задать грамотный специалист. Ответ на него поможет подрядчику подобрать оптимальную инфраструктуру для вашего проекта. При ответе на этот вопрос следует закладывать в число пользователей не только текущих, но и тех, кто будет подключен к системе в течение года. Так вы сможете сэкономить на приобретаемых лицензиях.
Кто будет пользоваться системой? Так разработчик хочет выяснить роли, на которые ему будет необходимо ориентировать учетную среду. Такими ролями может быть «Менеджер», «Бухгалтер», «Директор», «Кадровик» и другие лица. Обычно за ролью кроется определенный функционал, который будет доступен или недоступен в зависимости от своего назначения. Подумайте и озвучьте подрядчику все роли, которые будут фигурировать в системе. Это не сложно, т.к. обычно состав ролей совпадает с функциональными обязанностями персонала в организации.
Зачем это нужно? Профессионал всегда спросит «зачем» даже, если вам кажется, что ответ на этот вопрос очевиден. Не удивляйтесь этому. Просто проясните ваши цели. Лучше, если этот вопрос будет задан, а ответ на него будет определен, чем выяснить в конце проекта, что полученный результат не совпадает с ожидаемым из-за разных ценностных фильтров участников проекта.
Какие проблемы испытывает ваш бизнес? Этот вопрос может задаваться в разных вариациях. Возможно, вам будут заданы какие-то более специфичные уточняющие вопросы, но в любом случае будьте готовы поделиться вашей болью с подрядчиком. Расскажите ему, что тормозит ваш бизнес в развитии, какие процессы учета отнимают наибольшее количество времени, какие несвойственные для себя операции вынуждены делать ваши сотрудники или вы сами.
И помните, чем больше подрядчик интересуется вашим бизнесом, тем точнее будут выполнены ваши пожелания.
Много вопросов – это хорошо. А вот их отсутствие должно вас насторожить!
Эффективную систему учета на предположениях не построить. Любые гипотезы должны быть проверены.
В жизни очень часто бывает так, что человек не может объяснить, что хочет, даже в бытовых вещах. Когда дело доходит до объяснения программисту своих «хотелок», человек просто впадает в ступор.
Кто должен писать ТЗ?
В идеале ТЗ должен составлять заказчик — только он знает, что ему нужно. Но на практике из-за низкой компетенции заказчика в сфере 1С часто это приходится делать исполнителю. Заказчик устно озвучивает свои потребности, а программист(консультант) оформляет это в письменной форме.
Зачем нужно техническое задание?
Любые доработки в системе 1С, в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.
Что должно содержать в себе техническое задание?
Тех. задание обязательно должно содержать в себе:
- цель — задача, которую мы решим, реализуя данное ТЗ;
- описание — краткое изложение предстоящих доработок;
- способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие регистры, справочники создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
- оценка работы — очень важный пункт, описание трудозатрат.
Также существуют государственные стандарты к написанию ТЗ — ГОСТы. На практике мало где применяются, но бывает, заказчик настаивает на этом.
По опыту, при сдаче работ очень часто возникают ситуации вроде «а мы Вам тогда-то говорили же…», что не очень приятно, и зачастую приходится переделывать работу целиком. Поэтому хорошо написанное ТЗ сильно облегчает жизнь обеих сторон.
Примеры и образцы ТЗ для 1С
Небольшая подборка, которую я нашел в свободном доступе в сети. Начиная от самых простых и доступных, заканчивая достаточно сложными документами:
Привет, Хабр!
В этой статье мы расскажем, как построен процесс разработки платформы «1С:Предприятие», как мы работаем над обеспечением качества, и поделимся уроками, которые получили, создавая один из самых больших российских программных комплексов.
Люди и процессы
- Средства разработки (Конфигуратор)
- Веб-клиент
- Серверная инфраструктура и отказоустойчивый кластер
- и т.д.
С другой стороны, в практиках, которые направлены «вовнутрь», команды достаточно автономны. Например, инспекции кода сейчас применяются во всех командах (и существуют общие правила, определяющие обязательность прохождения ревью), но были внедрены в разное время и процесс построен по разным правилам.
То же самое касается организации процесса — кто-то практикует варианты Agile, кто-то использует другие стили ведения проекта. Канонического SCRUM, кажется, нет нигде — специфика коробочного продукта накладывает свои ограничения. Например, замечательная практика демонстрации оказывается неприменимой в неизменном виде. Другие практики, например, роль Product Owner, имеют у нас свои аналоги. В качестве Product Owner по своему направлению обычно выступает руководитель группы. Помимо технического лидерства в команде, одной из самых главных его задач является определение дальнейших направлений развития. Процессы выработки стратегии и тактики развития платформы – это сложная и интересная тема, которой мы посвятим отдельную статью.
Работа над задачами
Когда принято решение о реализации того или иного функционала, его облик определяется в серии обсуждений, в которых участвуют, как минимум, разработчик, ответственный за задачу и руководитель группы. Часто привлекаются другие члены команды или сотрудники из других групп, обладающие нужной экспертизой. Окончательный вариант утверждается руководством разработки платформы 1С: Предприятия.
- что входит, а что не входит в scope задачи
- какие мы представляем себе сценарии использования. Еще важнее понять, какие возможные сценарии мы не будем поддерживать
- как будут выглядеть пользовательские интерфейсы
- как будут выглядеть API для прикладного разработчика
- как новый механизм будет сочетаться с уже существующими
- что будет с безопасностью
- и т.д.
- Анализ проблемы и вариантов решения
- Описание выбранного решения
- Описания технических деталей реализации
- Единство используемых терминов. Если в одном месте Платформы в похожей ситуации был использован термин «записать», то использование «сохранить» должно быть очень серьёзно оправданным
- Единство подходов. Иногда ради упрощения изучения и единого опыта использования приходится повторять в новых задачах старые подходы, даже если очевидны их минусы
- Совместимость. В тех случаях, когда старое поведение сохранять нельзя, нужно все равно подумать о совместимости. Часто бывает, что прикладные решения могут быть завязаны на ошибку и резкое изменение повлечёт неработоспособность на стороне конечных пользователей. Поэтому, мы часто оставляем старое поведение «в режиме совместимости». Существующие конфигурации, запущенные на новом релизе платформы будут использовать «режим совместимости» до тех пор, пока их разработчиком не будет принято сознательное решение о его отключении.
Уроки и рецепты
- Ценность проектного документа, как любой документации, не всегда бывает очевидна. Для нас она в следующем:
- Во время проектирования помогает всем участникам быстро восстановить контекст обсуждения и быть уверенными, что принятые решения не будут забыты или искажены
- Позже, в сомнительных ситуациях, когда мы не уверены в правильности поведения, проектный документ помогает вспомнить само решение и мотивацию, которая стояла за его принятием.
- Проектный документ служит отправной точкой для пользовательской документации. Разработчику не нужно что-то писать с нуля или устно объяснять техническим писателям — уже есть готовая основа.
Обеспечение качества
Вообще, «качество» и «обеспечение качества» — очень широкие термины. Как минимум, можно выделить два процесса — верификацию и валидацию. Под верификацией обычно понимают соответствие поведения ПО спецификации и отсутствие других явных ошибок, а под валидацией — проверку на соответствие потребностям пользователя. В этом разделе речь пойдёт об обеспечении качества в смысле верификации.
Тестировщики получают доступ к задаче уже после ее вливания, но процесс обеспечения качества начинается намного раньше. В последнее время нам пришлось приложить значительные усилия по его совершенствованию, т.к. стало очевидно, что существовавшие механизмы стали недостаточно адекватны увеличившемуся объёму функционала и заметно возросшей сложности. Эти усилия, по отзывам партнёров о новой версии 8.3.6, как нам кажется, уже дали эффект, но много работы, конечно, ещё впереди.
Существующие механизмы обеспечения качества можно условно разделить на организационные и технологические. Начнём с последних.Тесты
Когда речь заходит о механизмах обеспечения качества, сразу на ум приходят тесты. Мы, конечно, их тоже используем, причём в нескольких вариантах:
Unit-тесты
На C++ мы пишем unit-тесты. Как уже упоминалось в предыдущей статье, мы используем модифицированные варианты Google Test и Google Mock. Например, типичный тест, проверяющий экранирование символа амперсанда ("&") при записи JSON, может выглядеть так:
Интеграционные тесты
Следующий уровень тестирования — интеграционные тесты, написанные на языке «1С:Предприятие». Именно они образуют основную часть наших тестов. Типичный набор тестов представляет собой отдельную информационную базу, хранящуюся в *.dt файле. Инфраструктура тестов загружает эту базу и вызывает в ней заранее известный метод, который вызывает уже отдельные тесты, написанные разработчиками, и форматирует их результаты так, чтобы их могла интерпретировать инфраструктура CI (Continuous Integration).
В данном случае, если результат записи разойдётся с эталоном, вылетит исключение, которое инфраструктура перехватит и интерпретирует как провал теста.
Наша система CI сама выполняет эти тесты под различные версии ОС и СУБД, включая 32- и 64-разрядные Windows и Linux, а из СУБД — MS SQL Server, Oracle, PostgreSQL, IBM DB2, а также нашу собственную файловую базу.
Пользовательские тестовые системы
Третий и самый громоздкий вид тестов — это т.н. «Пользовательские тестовые системы». Они применяются тогда, когда проверяемый сценарий выходит за пределы одной базы на 1С, например, при тестировании взаимодействия с внешними системами через веб-сервисы. Для каждой группы тестов выделяется одна или несколько виртуальных машин, на каждую из которых устанавливается специальная программа-агент. В остальном разработчик теста имеет полную свободу, ограниченную только требованием выдавать результат в виде файла в формате Google Test, который может быть прочитан CI.
Упомянутые выше тесты пишут сами разработчики платформы, на С++ или создавая небольшие конфигурации (прикладные решения), заточенные под тестирование конкретного функционала. Это является необходимым условием отсутствия ошибок, но не достаточным, особенно в такой системе как платформа 1С: Предприятие, где большая часть возможностей не являются прикладными (используемыми пользователем напрямую), а служат основой для построения прикладных программ. Поэтому существует ещё один эшелон тестирования: автоматизированные и ручные сценарные тесты на реальных прикладных решениях. К этой же группе можно отнести и нагрузочные тесты. Это интересная и большая тема, про которую мы планируем отдельную статью.
При этом все виды тестов выполняются на CI. В качестве сервера непрерывной интеграции используется Jenkins. Вот как он выглядит на момент написания статьи:
Для каждой конфигурации сборки(Windows x86 и x64, Linux x86 и x64) заведены свои задачи по сборке, которые запускаются параллельно на разных машинах. Сборка одной конфигурации занимает длительное время — даже на мощном оборудовании компиляция и линковка больших объёмов C++ представляет непростую задачу. Кроме того, создание пакетов под Linux (deb и rpm), как оказалось, занимает сопоставимое с компиляцией время.
Поэтому в течение дня работает «укороченная сборка», которая проверяет компилируемость под Windows x86 и Linux x64 и выполняет минимальный набор тестов, а каждую ночь работает регулярная сборка, собирающая все конфигурации и прогоняющая все тесты. Каждая собранная и проверенная ночная сборка помечается тэгом — так, чтобы разработчик, создавая ветку для задачи или вливая изменения из основной ветки, был уверен, что работает с компилирующейся и работоспособной копией. Сейчас мы работаем над тем, чтобы регулярная сборка запускалась чаще и включала больше тестов. Конечная цель этой работы — обнаружение ошибки тестами (если её можно обнаружить тестами) в течение не более двух часов после коммита, чтобы найденная ошибка была исправлена до конца рабочего дня. Такое время реакции резко повышает эффективность: во-первых, самому разработчику не нужно восстанавливать контекст, с которым он работал во время привнесения ошибки, во-вторых, меньше вероятность, что ошибка заблокирует чью-нибудь ещё работу.Статический и динамический анализ
- CppCheck
- PVS-Studio
- Встроенный в Microsoft Visual Studio
- обращений к неинициализированной памяти
- обращений к освобождённой памяти
- выходов за границы массива и т.д.
Организационные меры обеспечения качества
Помимо автоматических проверок, выполняемых машинами, мы стараемся встраивать обеспечение качества в ежедневный процесс разработки.
Наиболее широко применяемая практика для этого — peer code review. Как показывает наш опыт, постоянные инспекции кода не столько отлавливают конкретные ошибки (хотя и это периодически происходит), сколько предотвращают их появление за счёт обеспечения более читаемого и хорошо организованного кода, т.е. обеспечивают качество «в долгую».
Другие цели преследует ручная проверка работы друг друга программистами внутри группы — оказывается, даже поверхностное тестирование не погруженным в задачу человеком помогает выявить ошибки на раннем этапе, ещё до того, как задача влита в ствол.Eat your own dogfood
Но самым эффективным из всех организационных мер оказывается подход, который в Microsoft называется «eat your own dogfood», при котором разработчики продукта оказываются первыми его пользователями. В нашем случае «продуктом» оказывается наш таск-трекер (упомянутая выше «База задач»), с которой разработчик работает в течение дня. Каждый день эта конфигурация переводится на последнюю собранную на CI версию платформы, и все недочеты и недостатки сразу сказываются на их авторах.
Хочется подчеркнуть, что «База задач» — серьёзная информационная система, хранящая информацию о десятках тысяч задач и ошибок, а число пользователей превышает сотню. Это не сравнимо с самыми крупными внедрениями 1С: Предприятия, но вполне сопоставимо с фирмой среднего размера. Конечно, не все механизмы можно проверить таким способом (например, никак не задействована бухгалтерская подсистема), но для того, чтобы увеличить покрытие проверяемого функционала, есть договоренность, что разные группы разработчиков используют разные способы подключения, например, кто-то использует Web-клиент, кто-то тонкий клиент на Windows, а кто-то на Linux. Кроме того, используется несколько экземпляров сервера базы задач, работающие в разных конфигурациях (разные версии, разные ОС и т.д.), которые синхронизируются между собой, используя входящие в платформу механизмы.
Помимо Базы задач есть и другие «подопытные» базы, но менее функциональные и менее нагруженные.Выученные уроки
- В таком большом и массово используемом продукте дешевле написать тест, чем не написать. Если в функциональности есть ошибка и она будет пропущена — затраты конечных пользователей, партнеров, службы поддержки и даже одного отдела разработки, связанные с воспроизведением, исправлением и последующей проверкой ошибки будут куда больше.
- Даже если написание автоматических тестов затруднительно, можно попросить разработчика подготовить формализованное описание ручных тестов. Прочитав его, можно будет найти лакуны в том, как разработчик проверял своё детище, а значит, и потенциальные ошибки.
- Создание инфраструктуры для CI и тестов — дело затратное и по финансам, и по времени. Особенно, если приходится это делать для уже зрелого проекта. Поэтому начинайте как можно раньше!
И ещё один вывод, который не следует прямо из статей, но послужит анонсом следующих: самое лучшее тестирование фреймворка — это тестирование построенных на нем прикладных приложений. Но о том, как мы тестируем Платформу с применением прикладных решений, таких как «1С:Бухгалтерия», мы расскажем в одной из следующих статей.
Какие ассоциации вызывает у Вас слово программирование 1С? Для нас это творчество, интерес, самореализация, ощущение востребованности на рынке и многое-многое другое. Программирование 1С — наше хобби и работа одновременно. На нашем ресурсе мы делимся знаниями и информацией по своему любимому делу.
Если Вас интересует какие-либо вопросы по программированию 1С 8.3, задайте их программисту 1С на нашем форуме, мы обязательно ответим!
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
Материалы по программированию
-
– достаточно неплохой сборник бесплатных и платных курсов, где можно найти подходящий вариант. Как по основам 1С программирования, так и по самым популярным программам 1С (Бухгалтерия, ЗУП, Управление торговлей и т.д.). — подборка материалов для самостоятельного изучения 1С программирования 8. — сборник книг, полезных программисту 1С. — основы программирования 1С. — сборка полезных материалов программисту.
Заметки программистов 1С
Самые обычные вопросы, которые возникают в повседневной работе программиста.
-
— полная инструкция по работе с запросами 1С. — описания встроенного языка программирования 1С. — описание встроенного языка. — мануал по включению данного внешнего вида. — инструкция по типовому обновлению. — инструкция по внедрению подсистемы. — тривиальная задача для новичков. — методика разработки внешних отчетов и обработок в БСП 2.0. — самоучитель от специалиста по самому простому способу обновления не типовой конфигурации. — совет, как отладить права. — легкий способ быстро перейти на новую программу. — нюансы от практика. — описания среды разработки 1С 8.2. — краткое описание методов авторизации. — стандарты конфигурирования 1С и не только. — методы отладки программного кода. — описание очень полезных и интересных функций. — описание включения в реестре сервера. — способ запуска формирование отчета фоновым заданием. — запуск и пошаговая работа с механизмом. — методика интегрального вычисления производительности. — руководство, как без программирования создать печатную форму. — особенности настройки аппаратных ключей в 1С 8.3. — описание и универсальная обработка-шаблон. — пример обработки для подключение к браузеру. — инструкция и универсальная обработка-шаблон. — установка бесплатной СУБД в ОС Windows. — чтение и запись в файл DBF. — описание и настройка ограничения прав на уровне записей. — способ обмена информации 1С с ФТП. — объект системы, который позволяет автоматизировать процесс анализирования информации. — простая инструкция по программированию отчета. — пример кода для прямого подключения. — получения электронной почты из профиля. — описание встроенного механизма. — описание обменов в 1С. — как в 1С получить остаток от деления. — описание конфигурации, подборка учебников для изучения. — способ отладки обработчиков в 1С КД. — контроль записи. — для файловой и клиент-серверной базы. — метод через веб-сервис. — более простой вариант рассылки, через метод GET. — мануал по переходу. — короткая, но эффективная инструкция. — с помощью внешней dll. — запуск 1С с различными параметрами. — облегчающие жизнь программиста 1С функции. — пример нестандартной настройки торгового оборудования.
- Библиотека стандартных подсистем часть 1, часть 2 — использование программы Effect saver. — функции для изменения формата. — способ поиска в строковой переменной. — это просто. — универсальный способ. — несложная функция. — если у вас стоит задача штрихкодировать документы. — пример поиска в системе документа по штрих-коду. — краткое описание механизма. — описание и инструкция по работе. — хитрость. — как получить время с точностью до миллисекунды в 1С 8.3. — аналог goto в 1С программировании. — непростая ситуация.
Тонкости управляемого приложения
Режим «управляемое приложение» — уже достаточно устоявшийся функционал. Однако даже опытные специалисты не всегда знают всех тонкостей программирование в 1С.
-
— на клиенте, на сервере: чем отличаются? — хитрость с использованием объекта. — как узнать новый объект или запись или нет. — непростая задача. — способы настройки.
Язык запросов 1С
Язык запросов — основа основ 1С программирования. Цель его — получение информации. С помощью синтаксиса запросов Вы можете получить нужные данные максимально удобно и оптимально с точки зрения производительности.
-
— описание встроенного языка. — скачать для управляемой формы и обычной в одной обработке. — отличный инструмент 1С без аналогов. — особенности конструкции. — блокировка при чтении. — зачем нужно и особенности использования. — небольшая заметка о том, как использовать функцию для расчета разности между датами. — методика оптимизация, одобренная фирмой 1С. — правильное использование методов. — хитрый способ быстро найти такие ссылки. — небольшой трюк.
Статьи о программистах
Программисты — очень интересная профессия. Каждый день на работе можно узнать что-то новое, интересное. Ниже представлены статьи, в которых автор размышляет о данной специальности — программирование 1С 8.2.
-
— как начать в 1C? — очень популярная тематика. — какие материалы использовать, как планировать обучение. — с чего начинать путь программиста «с нуля» до опытного специалиста. — как найти работу 1С стажером. — методика сертификации программных продуктов 1С. — фриланс: вторая работа или свой 1С-бизнес?
Исправление ошибок в 1С 8.3
«У ёжика есть иголки, а в программе есть ошибки» — гласит смешная поговорка. Однако тут речь идет не об ошибке в 1С, а проблемах использования программы пользователями. Не все ошибки прозрачны и понятны всем, специально для этого описаны следующие статьи:
-
— проблема с полями неограниченной длины. — действие блокировок. — исправление проблемы БД. — обычная ситуация. — если система ругается при запуске — характерна для начинающих программистов — где скачать компоненту. — способ устранение проблемы. — как избежать данной проблемы и инструкция по конструкции ВЫРАЗИТЬ. — часто возникает при переходе на новую платформу. — причины и решение. — что делать? — проблема в разборе XML файлов. — конфигурация БД не обновлена. — системная неполадка с dll. — выбор схемы сопоставления в MS SQL. — ошибка таблицы значения. — нюанс в динамическом списке. — распространенная проблема прав. — 1С 7.7. — утечка памяти. — отсутствие rphost.exe. — способ конвертации обработки. -исправление и причины проблемы.
Справочник по программированию 1C
Метаданные — это предопределенные объекты и классы, встроенные в 1С предприятие. Каждый из них решает свою специфическую задачу по конфигурированию. Чтобы не запутаться в большом количестве таких метаданных, ниже описаны каждые из них. Картинки кликабельны.
Видеокурсы по 1 С программированию:
Читайте также: