Управление техническим долгом - Концепция Continuous Inspection

Публикация № 622617

Разработка - Инструментарий разработчика

Сегодня я вам хочу рассказать про тему «Управление техническим долгом» – что это такое, как с этим бороться и почему с этим надо бороться.

Для кого эта статья?

В первую очередь я хочу обозначить людей, которым может быть полезна эта статья.

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

Что такое Технический долг?

Есть такое каноническое определение, что технический долг – это работа, оставленная «на потом».

  • Это может быть какая-нибудь плохо спроектированная архитектура, слабоструктурированный или слишком запутанный код. На момент, когда мы его написали, мы понимаем, что это такое, но остается ощущение, что что-то здесь не так и что-то надо исправить.
  • Условно, с точки зрения разработчика, количество технического долга при просмотре некачественного кода можно охарактеризовать, как количество воскликов «Что же здесь происходит?» в час.
  • Очень часто, когда разработчики разбираются в сложном и запутанном коде, они долго не могут понять, что делает этот код, и тратят свое время на повторное укладывание в голове происходящего. Тем самым, тратят свои (и заказчика) деньги. Примерно посчитав, сколько времени тратит разработчик на каждый такой случай, мы можем определить общий объем технического долга в часах и перевести его в деньги, например, умножив на часовую ставку программиста.

Зачем управлять техническим долгом?

  • Поскольку при увеличении технического долга время на разработку новой функциональности увеличивается, то и стоимость поддержки при развитии системы с течением времени тоже будет увеличиваться. И чем больше у вас будет этого технического долга, тем сложнее и дороже вам будет разрабатывать новую функциональность и исправлять ошибки в текущей.
  • Так как разработчики – люди не идеальные, и бизнес требует, чтобы изменения происходили быстро и стремительно, то долг постоянно растет. Очень редко во время обычного цикла разработки можно заметить тренды снижения технического долга – в абсолютном большинстве случаев идет постоянное увеличение.
  • Если не следить за архитектурой, структурой и кодом приложения, то, в конце концов, это приведет к тому, что его будет невозможно улучшать дальше. Разработчики будут заняты только исправлением очередных найденных ошибок, и, пробираясь сквозь плохой код, будут тратить много времени на понимание, что же здесь происходит.

Игра «в долгую»

 

 

Управление техническим долгом – это так называемая игра «в долгую». На этом слайде вы можете видеть два «джедайских меча» – оранжевый и синий. Они олицетворяют два подхода к разработке:

  • Синяя команда (с синим графиком) не следит за своим техническим долгом, не считает его, и в короткой перспективе может быстро реализовывать новую функциональность и быстрее приносить пользу бизнесу (так называемый Time to Market).
  • А оранжевая команда с самого начала своей работы пытается следить за тем, насколько качественно она разрабатывает, устраняя утечки своего технического долга параллельно с выпуском новой функциональности.

В долгосрочной перспективе наступает такой момент, когда:

  • Команда, которая не следила за качеством, попадает в ситуацию снижения производительности из-за накопившихся в процессе разработки ошибок – время у нас идет, а количество новой, полезной функциональности не увеличивается.
  • Оранжевая же команда, изначально следившая за своим качеством разработки, планомерно, в том же самом темпе, в котором и начинала, продолжает наращивать функциональность.

Семь смертных грехов разработчика

Есть такая концепция «семи смертных грехов разработчика». Это некие плохие процессы, которые в итоге приводят к появлению технического долга и удорожанию системы. За этими смертными грехами можно следить и пытаться как-то нивелировать их влияние или вообще стараться этого не допускать.

Первый смертный грех, который могут допускать разработчики, это – ошибки и потенциальные ошибки.

  • Например, это могут быть ошибки проектирования, заключающиеся к неправильной реализации той функциональности, которую от нас хочет бизнес.
  • Либо это могут быть какие-то ошибки в коде, которые приводят к «страшным красным надписям» при работе заказчика.
  • Либо в коде могут оставаться какие-то потенциальные ошибки – непротестированные участки, которые на данный момент времени из-за текущих настроек системы не вызываются, но в будущем, при изменении бизнес-процессов этот код начнет выполняться, и пользователи уже потом будут получать эти «красные надписи».

Для отслеживания таких ошибок служит два показателя – надежность и безопасность. Это количественные показатели того, сколько алгоритмических ошибок и уязвимостей есть сейчас в нашей системе.

Самый распространенный вариант уязвимости в коде 1С – это выполнение строки кода, заданной в качестве параметра экспортной процедуры, которую можно вызвать из любого места системы (чаще всего даже подключившись через COM). Например:

Процедура ВыполнитьКод(ПроизвольнаяСтрока) Экспорт
    Выполнить(ПроизвольнаяСтрока);
КонецПроцедуры

Наличие такой уязвимости в худшем случае может привести к очистке всех данных и полному разрушению базы – это очень плачевно скажется на бизнесе.

Второй смертный грех – это нарушение стандартов разработки.

  • К сожалению, мало кто из разработчиков знает, а еще меньше применяет стандарты разработки, рекомендованные компанией 1С. Они опубликованы на ИТС – там довольно большой раздел, в котором описано, как правильно писать код, причем не только с эстетической точки зрения, но и для того, чтобы его потом было проще поддерживать и дорабатывать.
  • Помимо общепринятых стандартов, поставляемых вендором, у команды разработки могут быть свои внутренние стандарты кодирования. Если они у вас есть, то им тоже нужно следовать. Иначе, когда ваши партнеры по команде будут разбирать ваш код, им будет менее комфортно с ним работать, и они опять-таки, будут тратить на это больше времени.

Для контроля над этим смертным грехом используется показатель сопровождаемости. Так как требования к качеству написания кода более-менее стандартизированы, мы можем посчитать все случаи отклонения от идеального поведения и сформировать некий показатель сопровождаемости. В него входит, например, такая метрика, как отношение количество строк плохого кода к общему количеству строк кода. Это очень важная метрика, потому что на ее на основании мы можем рассчитать, насколько больше нам нужно заложить времени на разработку какой-то новой функциональности или изменения старой.

Третий смертный грех – это дублирование кода.

  • Я думаю, многие из вас при разборе какого-то алгоритма встречали в одном и том же модуле целиком скопированные участки кода, которые просто просятся, чтобы их вынесли в отдельную процедуру для повторного использования. Тем самым, можно сократить количество кода, а также увеличить сопровождаемость в случае обнаружения какой-либо ошибки.
  • Хуже того, иногда разработчики копируют код в два места, а при обнаружении в них ошибок исправления вносят неодинаково – в одном месте исправляют одни ошибки, в другом – другие, хотя это один и тот же код, но в разных местах.
  • Либо бездумно копируют кусок кода, чтобы модифицировать его под какие-то новые требования. Правильнее было бы попытаться реализовать некий универсальный алгоритм, учитывающий различные варианты применения и повторно его использовать - тогда последующим разработчикам было бы уже проще.

За это отвечает показатель дублирования. Чтобы его вычислить, мы можем посчитать количество таких дублирующихся участков и строк в них по отношению к общему количеству кода. Это позволит узнать, насколько наша конфигурация состоит из так называемого «копипаста» и сколько у нас уникального кода в конфигурации.

Четвертый грех – это недостаток тестирования.

  • Если вы не пишете автоматические тесты или не прогоняете ручные по какому-то заранее сформированному комплекту проверок, это приводит к тому, что вы не понимаете, насколько ваша система надежна и насколько безопасно вы можете изменять те или иные участки кода. Потому что опять-таки, программисты – люди не идеальные и при доработке функциональности они могут внести новые ошибки, сломав, таким образом, что-то, что работало раньше. Это приведет к регрессии системы.

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

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

  • При большой цикломатический сложности в лучшем случае мы можем наблюдать в коде какие-то огромные процедуры, которые сложно читать, сложно понимать – приходится тратить время.
  • В худшем случае это приводит к так называемому «спагетти-коду», когда программист открывает какую-то одну огромную процедуру, которая делает 50 процентов логики всей системы, долго-долго листает ее в конфигураторе, ему постоянно приходится перемещать редактор кода слева направо, потому что он выглядит как спагетти, который разместили на столе. Опять-таки, затрудняется понимание при дальнейшей разработке и поддержке.

Показатель здесь – это сложность системы. Его тоже можно посчитать.

Помимо сложности кода у нас еще есть сложность самой архитектуры.

Если вы используете какое-то многомодульное приложение (а 1С – это, условно говоря, трехкомпонентная система, состоящая из: визуальной части; серверной части, за которую отвечает сервер приложения; и непосредственно СУБД), и у вас в коде смешана работа с разными компонентами, то модифицировать все это потом будет опять-таки сложнее.

Показатель здесь тот же самый, это – сложность.

И седьмой смертный грех – это недостаток или излишнее количество комментариев.

  • Некоторые сложные алгоритмы (даже если они структурированы, разбиты на какие-то маленькие функции) приходится комментировать просто в силу их сложности и непонятности неподготовленному человеку. Особенно это касается программного интерфейса для экспортных процедур и функций. Например, когда я, как разработчик, хочу использовать библиотеку подключаемого оборудования, я не хочу разбираться в том, как она работает на аппаратном уровне с конкретными сканерами штрихкодов или печатью этикеток. Я хочу просто получить список доступных процедур и функций, описание того, что они делают, и, в идеале, пример их использования. Но чтобы я смог это понять, эти процедуры и функции должны быть определенным образом закомментированы.
  • Второй недостаток – это излишнее комментирование. Есть каноничный пример, когда в коде объявляется переменная и в комментарии пишется, что «я объявил переменную и присвоил ей такое-то значение». Я думаю, что все понимают, что это делать не надо, однако, к сожалению, так периодически делают.

Показатель, который нам здесь поможет – это документирование. Мы можем посчитать процентное соотношение количества строк комментариев к общему количеству кода и тоже этим управлять.

Зачем нужны показатели качества кода?

 

 

Если мы посмотрим на показатели качества, характеризующие нашу систему в целом, и добавим сюда показатели размера (будем знать, сколько у нас всего модулей, процедур и функций, строк кода в них), то мы сможем понимать, куда нужно бросить усилия для того, чтобы исправить ту или иную ситуацию:

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

Какие есть подходы к управлению техническим долгом?

Я назову четыре. Я думаю, с первыми тремя из них вы более-менее знакомы.

  • Первый подход – это контроль качества внешними аудиторами. Вы можете разрабатывать конфигурацию, потом собрать этот cf-ник, отдать его в какую-то внешнюю компанию с громким названием (обычно, с фамилиями) – они будут долго и упорно смотреть на ваш код, а потом сформируют вам огромный отчет по поводу недостатков вашей конфигурации. Этот подход имеет право на жизнь, но он имеет минусы, о которых я расскажу чуть позже.
  • Второй подход – это визуальная проверка кода разработчиками (или code-review). Обычно у нас есть некий абстрактный стажер, и наставник, который дает этому стажеру задачу. Стажер задачу решает, приносит код своему наставнику, тот смотрит на этот код и дает своему стажеру некую обратную связь. Если вы пользуетесь какими-то более сложными, чем хранилище, серверами по контролю версий (например, Github, Gogs или Gitlab), то у вас есть возможность точечного просмотра измений каждого помещения (коммита) или формировать запросы на слияние кодовой базы, где разработчики могут более подробно и более детально изучать, какие же были изменения в вашем коде.
  • Третий подход – это разовые автоматизированные отчеты о качестве кода. Например, у вас есть некая система, в которую вы загружаете весь свой код, она вам долго-долго его анализирует, а потом опять-таки выдает огромный отчет. Вы смотрите на этот отчет, но так как у вас перед этой системой нет никаких обязательств, и вы ее запустили именно разово, для того, чтобы увидеть, насколько у вас все плохо, то чаще всего, вы откладываете этот отчет в дальний ящик стола и продолжаете кодировать дальше.
  • А четвертый подход – это непрерывная инспекция. Именно о ней я и собираюсь рассказать чуть подробнее.

Continuous Inspection – ключевые принципы

Что же вообще такое Continuous Inspection (непрерывная инспекция кода), какие у нее ключевые принципы и из чего она состоит?

  • Основной ее постулат заключается в том, что качество – это общая задача всей команды разработки и результат выполнения этой задачи зависит непосредственно от самих разработчиков, потому что они производят код, за который несут ответственность.
  • Второй ключевой принцип – это актуальность информации. Если мы проверяем нашу систему и получаем о ней какие-то качественные показатели, мы должны их получать регулярно, чтобы у нас под рукой всегда была актуальная информация о текущем состоянии нашей кодовой базы.
  • Данные о качестве (как показатели, так и какие-то списки замечаний), мы должны получать не только в абсолютных значениях, но и в разностных. Мы должны понимать, а что же у нас изменилось за неделю с выхода прошлой версии, за день и т.д.
  • Проверка качества должна быть автоматизированной, и мы в идеале должны исключить каких-то конечных людей (внешних аудиторов либо самих разработчиков в плане ручного code-review), чтобы проводить эти проверки автоматически.
  • И еще один ключевой принцип – стандарты качества должны быть едиными для всех проектов. Часто бывает ситуация, когда какая-то команда уже 8 лет внедряет УПП, а теперь начала внедрять УТ 11 на управляемых формах. И в головах возникает такое отношение – проекту по УПП уже 8 лет, 1С этот продукт уже давным-давно не поддерживает, там уже в принципе все плохо и за его качеством можно не следить. А вот для УТ 11 в плане контроля качества еще можно что-то сделать, поэтому следить будем только за ним. Это – неправильно. Не смотря на то, что УПП – это система, которая разрабатывается давным-давно, стандарты качества к ней точно такие же. Просто здесь на первый план выходят не абсолютные показатели (когда мы знаем, что за 8 лет разработки у нас накопилось 10 лет технического долга), а именно относительные – когда мы разрабатываем новую версию функциональности, мы должны быть уверенными в том, что мы ее сделали качественно.
  • Последний ключевой принцип – это то, что все новые замечания, особенно критические, должны иметь ответственного. И если у нас несколько человек в команде, то каждое выявленное замечание по качеству должно относиться на конкретного разработчика. Может быть, он уже уволился – это неважно, но в принципе, мы должны понимать, кто привел к конкретной проблеме.

Сравнение подходов.

 

 

Аудит, если он проводится вручную, и код-ревью имеют под собой некий человеческий фактор.

  • Люди чаще всего имеют склонность пропускать какие-то замечания, у них может «замылиться» глаз. Аудиторы на этой ниве работают уже много лет, они какие-то моменты могут случайно упустить, и в результате мы, выполняя задачу контроля качества, можем не получить полную картину того, что у нас происходит.
  • А в случае применения неких автоматизированных систем (либо разово, либо в непрерывном варианте), влияние человеческого фактора уходит, потому что все эти проверки проводятся автоматически, и код у нас анализируется на основании каких-то алгоритмов.

 

 

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

  • Чаще всего аудит выполняется долго, и пока отчет не готов, мы продолжаем разрабатывать. Когда мы этот отчет получаем, у нас уже и код поменялся, и состав модулей другой. Получается, что та конфигурация, которую изучал аудитор, и то, что у нас в кодовой базе сейчас – это в принципе, два разных программных продукта.
  • С код-ревью получше, он производится либо в момент сдачи функциональности, либо в момент влития изменений в основную ветку, поэтому там с актуальностью все более-менее хорошо.
  • И разовые проверки (в случае, если вы сразу исправляете свой код) также могут быть полезны. А если вы откладываете их исправление «в долгий ящик» – пользы не будет.
  • Continuous Inspection предполагает частую автоматическую проверку вашего кода. Причем, когда я говорю «частую», это не значит, что раз в неделю или раз в месяц. Проверяется каждое ваше изменение при помещении в хранилище, либо коммит в Git (если вы пользуетесь системой контроля версий). И на каждое изменение вы получаете отчет о качестве.

 

 

Следующая проблема заключается в том, что аудит имеет свойство некоего психологического давления на команду разработки.

  • Приходят какие-то «левые дядьки» из фамильной компании, приносят нам стопку «косяков» в нашей системе (это я как разработчик сейчас говорю), говорят, что мы не правы! Первая реакция у разработчиков – сами вы нехорошие люди, ничего мы с вашим отчетом делать не будем.
  • Если же качество проверяется где-то внутри вашей компании, то ситуация становится получше.

 

 

То же самое касается распределения ответственности.

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

 

 

А если у вас используется код-ревью, и ваш код проверяет какой-то более опытный коллега (или наставник), то это предполагает, что вы тратите время более опытного, более дорогого разработчика на то, чтобы проверить свой не очень опытный код. Чаще всего для вас это оправдано и приносит пользу, но на этом можно сэкономить.

 

 

Также для всех перечисленных разовых подходов характерно отсутствие динамики.

Когда вы периодически, но нерегулярно проверяете код, вы не понимаете, как ваша система менялась с течением времени на коротком промежутке (в идеале, при помещении в хранилище одного изменения).

Что такое Continuous Inspection с точки зрения разработки?

Каждый день каждое изменение в хранилище должно сопровождаться результатами контроля качества.

 

 

Вы должны каким-то образом получать отчет о проверке. Например, это может быть письмо на почту о том, что вы написали код и своим небольшим изменением добавили 2 с половиной часа технического долга. Это реальный отчет, который мне пришел на одном из проектов.

 

 

Второй вариант – если вы используете Git-flow и Pull-request (программисты знают, что это такое), то можно оценивать и сами изменения кода – только то, что поменялось в конкретном предложении на влитие в основную ветку. И тоже получать об этом отчет.

 

 

Результаты анализа должны быть инкрементальны не только относительно вашего текущего изменения, но и от последнего релиза вашего продукта. На данном слайде вы видите в левой части количество зафиксированных ошибок, а посередине (где написано «Новые ошибки», «Новый некачественный код») – именно то, что у нас изменилось с прошлой версии. Это – уже инструмент для релиз-менеджера, чтобы он мог видеть, что же у нас происходит с кодовой базой и насколько наш релиз готов к выпуску. В данном случае, вы видите рейтинг надежности E (наихудший). Это потому, что одна из этих 18-ти новых ошибок – блокирующая, и ее нужно срочно исправить.

Каждое замечание должно иметь ответственного.

 

 

Мы должны иметь возможность посмотреть общий список зафиксированных ошибок, чтобы понять, что у нас происходит в системе. Заметьте, здесь каждая ошибка назначена на конкретного человека: что-то на меня, что-то на уважаемого Алексея Лустина и т.д.

 

 

Помимо этого, ошибки должны быть доступны для просмотра сразу из кода, чтобы разработчики не «рвали контекст».

 

 

Так как проверки кода у нас автоматизированы, мы можем сразу накапливать некую информацию не только о том, что у нас плохо, но и почему это плохо, предоставляя методические материалы о том, как это нужно исправить, со ссылкой на те же самые стандарты ИТС. Здесь в нижней части скриншота как раз и представлен текст с ИТС об этой конкретной ошибке.

 

 

Мы можем видеть, насколько у нас все плохо не только в конкретном проекте, но и во всех наших проектах. Для собственного перфекционизма и желания все делать хорошо это тоже может быть полезный показатель.

 

 

Скриншот с техническим долгом проекта я вам уже показывал, а это – его расширенная версия. Здесь на средней полоске как раз виден график тренда увеличения или уменьшения нашего технического долга.

Важной концепцией для релиз-менеджера является порог качества. В качестве него мы можем настроить некоторые очень объективные показатели.

 

 

Например, в качестве порога качества мы можем принять, что у нас не должно быть новых зарегистрированных ошибок кодирования, а отношение плохого кода к хорошему не должно быть более 5 %. На основании этого мы можем принимать решение – выпускать новый релиз или не выпускать.

И последнее, что я хочу сказать – это то, что список наших ошибок в идеале мы должны получать еще на этапе кодирования, до того, как мы поместили наши изменения в хранилище. В других языках такие вещи уже давно поддерживаются на уровне редакторов кода, а для 1С такие инструменты только начинают появляться. Например, это есть в Eclipse, на базе которого построен EDT, а теперь такие инструменты появились и для VSCode.

 

 

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

***************

Данная статья написана на основе доклада, представленного автором на конференции Infostart в 2016 году. Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

 

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. vano-ekt 841 30.06.17 09:05 Сейчас в теме
Что такое Технический долг?

как изящно слово "**внокод" завуалировали :-D
kolya_tlt; wowik; Vladimir Litvinenko; Berckk; Brawler; sorb; корум; Lem0n; artbear; Bazil; +10 Ответить
2. Артано 674 30.06.17 09:55 Сейчас в теме
(1) Речь не только о говнокоде, а в принципе о копро-методах в разработке. В известном мультике это обозначали фразой "и так сойдёт"
wowik; Vladimir Litvinenko; Brawler; корум; nixel; +5 Ответить
3. nixel 922 30.06.17 09:55 Сейчас в теме
(1) для *овнокода есть изящный "code smells" :)
Когда мы делали плагин локализации SonarQube, очень долго думали, как же его перевести эээ... по-корректнее :) и чтобы в интерфейсе легло
4. Stepa86 1383 30.06.17 10:15 Сейчас в теме
Все таки истина посередине. Действовать нужно согласно ситуации и выгодам. Для написания одноразовой обработки нет смысла задумываться над качеством, а при старте огромного проекта не очень хорошо сразу кидаться херачить код. И в больших проектах есть одноразовые вещи, в которых есть смысл повышать качество только если они перестают быть одноразовыми.

Ну и график сравнения команд не очень верный. У синей команды должен быть более быстрый старт, но в концовке линия может даже пойти вниз и закончиться регрессионной спиралью смерти, а у оранжевой наоборот более долгий старт, но потом производительность растет лучше, чем линейно, скорее квадратично
Артано; sulfur17; +2 Ответить
5. v3rter 30.06.17 10:54 Сейчас в теме
Законы ненадежности Джилба.

1. Компьютеры ненадежны, но люди еще ненадежнее.
2. Любая система, зависящая от человеческой надежности, ненадежна.
3. Число ошибок, которые нельзя обнаружить, бесконечно, в противовес числу ошибок, которые можно обнаружить,- оно конечно по определению.
4. В [исправление *%вн0к0да] поиски повышения надежности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.

Законы Мерфи. Законы машинного программирования

1. Внутри каждой большой программы есть маленькая, которая там совсем не нужна.
2. Все ошибки, описанные как особенности [фичи], в момент сдачи программы не сработают или будут вести себя, как ошибки.
3. Все программы содержат ошибки, просто о некоторых мы не догадываемся.
4. Если Вы заводите в компьютер ерунду, то ничего кроме ерунды оттуда не выходит, только прошедшая через обработку такой умной машиной ерунда становится ценной и значимой.
6. Если Вы точно не знаете, что ваша программа должна делать, надо ли ее начинать?
7. Если программа бесполезна, она будет документирована. Если программа полезна, ее изменят.
8. Если программа полностью отлажена, ее нужно будет скорректировать.
10. Компьютерам свойственно ошибаться, но людям свойственно делать это намного чаще
11. Любая, даже самая гениальная программа никогда не работает в момент сдачи ее заказчику.
12. Любая действующая программа устарела.
13. Любая программа обходится дороже и требует больших затрат времени, чем предполагалось.
14. Любая программа стремится занять всю доступную память.
15. Мощность компьютера увеличивается как квадрат цены. Таким образом, если Вы хотите сделать ваш компьютер в два раза дешевле, Вам нужно сделать его вчетверо быстрее.
16. Неопределимые ошибки бесконечны, а определимые ограничены способностями компилятора.
19. Работа с автоматическим исправителем ошибок приведет к обнаружению его узких способностей и широких недостатков.
22. Сложность программы растет до тех пор, пока не превысит способности программиста.
23. Программы тестирования обязательно находят ошибку там, где их нет. Если ошибка все-таки есть то она в другом месте (например, на 5-10 символов выше, за границей экрана).
24. То, что некоторые пользователи зовут в программе, пользуясь ей, ошибкой, на самом деле является особенностью [фичей].
25. Усилия, прилагаемые для исправления ошибки, увеличивают ее в геометрической прогрессии по отношению к затраченному времени.
26. Ценность программы прямо пропорциональна весу ее "выдачи".
27. Чем более сложна и совершенна программа, тем более неточные результаты она выдает.

Первая компьютерная аксиома Лео Бейзера.
Закладывая что-то в ЭВМ, помните, куда Вы это положили.

Руководство по системному программированию Штейнбаха.
Никогда не выявляйте в программе ошибки, если не знаете, что с ними дальше делать.

Первая аксиома компьютеров.
Чтобы ошибиться, достаточно компьютера, но чтобы действительно испортить все, нужен все-таки еще и человек.

Второй закон Вейнберга.
Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию.
Показать
Nerich; rusmil; weissfeuer; +3 Ответить
6. starik-2005 2212 30.06.17 13:15 Сейчас в теме
+ чисто за воспоминание о теме. Не читал, но... )))
7. nixel 922 30.06.17 13:37 Сейчас в теме
8. brr 179 30.06.17 15:26 Сейчас в теме
Условно, с точки зрения разработчика, количество технического долга при просмотре некачественного кода можно охарактеризовать, как количество воскликов «Что же здесь происходит?» в час.


Другие восклики раздаются
9. nixel 922 30.06.17 15:54 Сейчас в теме
(8) во время доклада на слайде в этот момент отображалась строчка "WTF?/hour" :)
10. CSiER 29 01.07.17 05:09 Сейчас в теме
Хорошая статья. Просьба добавить ссылки на инструментарий и мануалы по настройке всего этого в контексте 1С.
wowik; sulfur17; +2 Ответить
11. Makushimo 157 03.07.17 06:00 Сейчас в теме
читаю статью и не дает покоя мысль "где-то в параллельной вселенной: в 1С управляют техническим долгом... автоматический контроль качества кода..."

жаль, что я не в вашей команде...
sulfur17; artbear; +2 Ответить
12. &rew 24 03.07.17 06:12 Сейчас в теме
Статья интересная, и поэтому вызывает вопросы:
1. "Самый распространенный вариант уязвимости в коде 1С ... Например:
Процедура ВыполнитьКод(ПроизвольнаяСтрока) Экспорт Выполнить(ПроизвольнаяСтрока); КонецПроцедуры
Наличие такой уязвимости в худшем случае может привести к очистке всех данных и полному разрушению базы – это очень плачевно скажется на бизнесе. "

Так обычно клиентов пугают, которые договор на обслуживание подписывать не хотят. А вообще перед внесением изменений + ежедневно хотя бы раз в день бэкапы уберегут бизнес от простаивания. Это аксиома, которой не следуют только маргиналы.

2. "К сожалению, мало кто из разработчиков знает, а еще меньше применяет стандарты разработки, рекомендованные компанией 1С. Они опубликованы на ИТС – там довольно большой раздел, в котором описано, как правильно писать код, причем не только с эстетической точки зрения, но и для того, чтобы его потом было проще поддерживать и дорабатывать."

Включая саму фирму 1С. Глядя в типовые конфигурации сейчас очень легко запутаться, какие данные откуда берутся (например при работе с Хранилищем). Переменные очень часто не информативны. Избыточные "перескоки" между процедурами, функциями и фоновыми заданиямиФоновые задания тогда тоже можно отнести к "самым распространенным уязвимостям". Дублирование кода тоже имеется. И всё это в типовых! конфигурациях.
.......
sulfur17; Makushimo; +2 1 Ответить
13. ifilll 03.07.17 14:19 Сейчас в теме
(12) Андрей +

Правда "перескок" чаще объясним особенностями реализации БСП или отклонения от него в конкретном случае.
Модули продуктов разрабатываются разными командами программистов, где могут преследоваться локальные условности, либо недоговоренности с другими командами.

Но в целом вы правы, ИМХО конечно.
14. chng 07.07.17 11:48 Сейчас в теме
(12)
А вообще перед внесением изменений + ежедневно хотя бы раз в день бэкапы уберегут бизнес от простаивания

Эта фраза верна только до определенного размера бизнеса...
15. &rew 24 10.07.17 08:05 Сейчас в теме
(14)Вы знаете, любое утверждение верно только до конкретных значений элементов объектной природы. Мне кажется, что вы в курсе как именно уберечь обслуживаемый Вами бизнес.
Кстати, как там аукцион по 1С по присоединению вновь обретенных мощностей? Выполнили? (простите за моветон)
16. sulfur17 36 17.07.17 10:14 Сейчас в теме
Восхитительно! Добавил в избранное и очень надеюсь на развитие этой темы (ссылки на скачивание, мануалы). Один проект уже пришлось бросить из за чрезмерного тех.долга, хотелось бы научиться с этим бороться.
Оставьте свое сообщение

См. также

Легкий способ обновления измененной конфигурации Промо

Инструментарий разработчика v8 Бесплатно (free)

Легкий способ обновления измененной конфигурации. Сервис подготовки расширения конфигурации

25.10.2017    23585    avk72    63    

Как сделать плагин для 1С:EDT для начинающего Java+1C разработчика. Часть 1

EDT Бесплатно (free)

Введение в разработку плагинов для 1С:EDT. Цель: показать, что плагины для 1С:EDT можно делать быстро и легко.

17.10.2020    1484    marmyshev    24    

Улучшенный конструктор запроса тонкого клиента (УИР)

Инструментарий разработчика Консоль запросов v8 1cv8.cf Бесплатно (free)

Конструктор запросов тонкого клиента появился в платформе с 8.3.5 обладает рядом недостатков, которые возможно исправить. Передача входных таблиц, исправление связей и другое

07.09.2020    2780    Evg-Lylyk    13    

Пробуем Снегопат (устанавливаем и настраиваем полнофункциональную триальную версию)

Снегопат, openconf v8 Бесплатно (free)

Снегопат — это инструмент, который расширяет штатные функции конфигуратора 1C и превращает его в современную IDE. В данной статье я подробно расскажу, как установить триал-версию Снегопата и сразу начать использовать его наиболее полезные функции. Статья рассчитана прежде всего на тех, кто со Снегопатом сталкивается впервые и хочет разобраться в его возможностях.

31.08.2020    8736    kuntashov    63    

Универсальная функция для программного выполнения СКД Промо

Инструментарий разработчика Универсальные функции v8::СКД 1cv8.cf Бесплатно (free)

Часто встречаются вопросы на форумах о программном формировании СКД. Вроде и информации много по этому поводу, но... Все как всегда :) Собственно, в описании без лишних слов выложен текст общей функции, в которую, для выполнения отчета, нужно передать (минимум 2 параметра): СКД и ТабличныйДокумент.

20.05.2015    30627    dj_serega    18    

paste1c.ru - сервис для обмена кодом для 1С:Предприятия

Прочие инструменты разработчика v8 Бесплатно (free)

Paste1C.ru - сервис для обмена кодом для 1С:Предприятия c подсветкой синтаксиса и подсказками.

21.08.2020    5721    salexdv    48    

1С:EDT. Куда пинать, чтобы полетело?

EDT v8 УНФ Россия Бесплатно (free)

Работал в 1С Конфигуратор и решил перейти на 1С EDT. Не получилось сразу. Потребовалась модификация компьютера.

19.08.2020    4534    pa240775    33    

Снегопат – Dev или Ops?

Снегопат, openconf v8 Бесплатно (free)

Снегопат – программный комплекс, повышающий эффективность работы в конфигураторе 1С. О новом эволюционном этапе проекта, его возможностях и планах развития на митапе «DevOps в 1С» рассказал разработчик Снегопата, системный программист компании Инфостарт Александр Орефков.

17.08.2020    4714    orefkov    44    

Перевод интерфейса конфигурации с использованием программы 1С:Переводчик Промо

Инструментарий разработчика v8 Бесплатно (free)

Перевод текстов интерфейсов конфигураций без использования технологии памяти переводов приводит к рассогласованности терминологии, когда один и тот же объект в конфигурации в разных меню может называться по-разному. Решить эту проблему можно используя программу 1С:Переводчик.

09.02.2015    33187    boogie    21    

Динамический список, ключи записей. Нюансы

Инструментарий разработчика Практика программирования Конфигурирование 1С v8 Бесплатно (free)

Заметки об особенностях динамических списков с произвольным запросом и видом ключа, отличным от "Авто"

07.08.2020    1677    Yashazz    4    

Редактор HTML

Инструментарий разработчика Прочие инструменты разработчика v8 1cv8.cf Россия Бесплатно (free)

Инструмент из состава набора "Универсальные инструменты 1С" для быстрой адаптации html страниц для корректного отображения в Поле HTML документа

03.08.2020    1258    cprit    3    

Глобальное меню разработчика для управляемых форм

Инструментарий разработчика v8 v8::УФ 1cv8.cf Бесплатно (free)

Подсистема "Инструменты разработчика". Глобальное контекстное меню разработчика для управляемых форм в толстом клиенте.

03.08.2020    3375    tormozit    14    

Сервис обмена кодом Промо

Инструментарий разработчика v8 1cv8.cf Бесплатно (free)

Бывало так, что вам нужно быстро показать кому-то свой код, но опубликовать его негде, так как популярные сервисы просто не поддерживают раскраску кода 1С? Теперь решение есть!

26.06.2015    20493    Infactum    23    

Консоль кода и зачем она нужна

Прочие инструменты разработчика v8 Бесплатно (free)

Когда использовать, обзор консолей кода: плюсы - минусы.

27.07.2020    4462    Evg-Lylyk    47    

Unit-тесты с помощью 1C:Enterprise Development Tools

EDT v8 Бесплатно (free)

Концепция TDD требует перестроения подходов к разработке и наличия инструментов для запуска Unit-тестов. Про написание плагина для EDT, который содержит в себе инструменты написания, анализа результатов и запуска Unit-тестов для конфигураций 1С на конференции Infostart Event 2019 Inception рассказал ведущий специалист по внедрению компании 1С-Рарус Александр Капралов.

11.06.2020    3960    doublesun    7    

Обработка кодом результата запроса в Консоли запросов 9000

Консоль запросов v8::Запросы Бесплатно (free)

Пять вариантов обработки кодом в консоли запросов 9000: простое выполнение, построчно без индикации, построчно с индикацией, простое в фоне, построчно в фоне с индикацией.

01.06.2020    1515    kuza2000    7    

1C:Enterprise Development tools (EDT) или кодим в Eclipse Промо

EDT v8 Бесплатно (free)

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

11.04.2015    77240    DitriX    297    

Шпаргалка. Автоматическое тестирование внешних отчетов и обработок в нескольких информационных базах

Прочие инструменты разработчика v8 Бесплатно (free)

Используем Автоматизированное тестирование на практике. Простой код для обновления и запуска внешних отчетов и обработок в нескольких ИБ. Создаем рабочее решение с нуля.

02.05.2020    4418    pparshin    21    

Установка EDT 2020.2 на Ubuntu 18.04

EDT Россия Бесплатно (free)

Установка EDT 2020.2 на Ubuntu 18.04 Заметки на будущее.

12.04.2020    2651    awk    14    

Enterprise Development Tools, версия 2020.2 для мобильной разработки. Бег по граблям (серия публикаций от чайника для чайников)

EDT v8::Mobile 1cv8.cf Бесплатно (free)

Небольшие советы, которые сберегут время при работе с Enterprise Development Tools, версия 2020.2.

10.04.2020    4350    capitan    8    

Проставление большого количества галочек в активном окне винды Промо

Практика программирования Сервисные утилиты Инструментарий разработчика Россия Бесплатно (free)

Как проставить большое количество галочек подряд в любом окне винды

07.11.2010    30750    Boris-Leleko    9    

Управляемая консоль отчетов – новый функциональный инструмент для работы с запросами и СКД в управляемых формах

Прочие инструменты разработчика Консоль запросов v8::УФ v8::Запросы v8::СКД Бесплатно (free)

Консоль запросов и СКД – один из наиболее часто используемых программистом инструментов. Как с его помощью можно упростить разработку, в своем докладе на конференции Infostart Event 2019 Inception рассказал Евгений Люлюк, ведущий программист компании GLT.

06.04.2020    7319    Evg-Lylyk    0    

Технология разветвлённой разработки, использующая git, ci/cd

CI/CD Git (GitHub, GitLab, BitBucket) Методология управления разработкой EDT 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Адаптация и расширение требований к разветвлённой разработке с использованием git и ci/cd, основанное на стандартах 1С

24.02.2020    5936    check2    10    

CI/CD для 1С проектов, унифицировано, с кастомизацией

CI/CD Инструментарий разработчика Бесплатно (free)

Тема CI/CD в связке с 1С не нова, но многих пугает сложность использования и поддержки, необходимость обучения команды. Про то, как унифицировать и упростить поддержку сборочных конвейеров для большого количества решений, в своем докладе на конференции Infostart Event 2019 Inception рассказал начальник отдела компании BIA-Technologies Валерий Максимов.

20.02.2020    6294    theshadowco    11    

TurboConf:Шаблоны - сервис для поиска и хранения фрагментов кода Промо

Инструментарий разработчика v8 1cv8.cf Бесплатно (free)

Сервис добавляет в Конфигуратор возможность поиска и хранения фрагментов кода. Делитесь своими шаблонами с другими разработчиками или используйте уже готовые!

13.08.2014    22522    m.bolsun    68    

О синхронизации ИБ с проектом в EDT

EDT Бесплатно (free)

Немного о работе механизма синхронизации информационной базы с проектом EDT и как эти знания можно использовать для экономии времени. Или как объяснить, что проект в рабочей области эквивалентен конфигурации информационной базы, связанной с ним.

19.02.2020    3725    check2    2    

EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 03

EDT v8 Бесплатно (free)

Групповая разработка в EDT.

21.01.2020    4380    YuriYuriev    3    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    5992    nixel    22    

Подсистема "COMExchange": консоль запросов в режиме «Консоль кода». Промо

Консоль запросов v8 1cv8.cf Россия Бесплатно (free)

Описана возможность использования обработки «Консоль запросов 1С+ADO» в качестве «консоли кода». При этом имеется возможность помещения результатов вычислений в «табло формул». Кроме результатов вычислений в это «табло» можно также вывести время выполнения и описание обработанных ошибок времени исполнения.

03.04.2014    26063    yuraos    2    

Часовой на страже логов

Практика программирования Инструментарий разработчика Бесплатно (free)

При поддержке решений, которые установлены у большого количества пользователей на различных системах, очень важно вовремя получать подробную информацию о возникших проблемах. О том, как собирать логи и анализировать полученные данные в трекере ошибок Sentry на конференции Infostart Event 2019 Inception рассказал Андрей Крапивин.

13.01.2020    6847    Scorpion4eg    8    

EDT + УТ 11.4 + БП 3.0 + Расширения. Часть 02

EDT v8 Бесплатно (free)

Продолжение "путевых заметок" про EDT...

09.01.2020    6260    YuriYuriev    31    

Как управлять качеством кода 1С, используя платформу SonarQube

Рефакторинг и качество кода Инструментарий разработчика Бесплатно (free)

При быстром росте функциональности проводить визуальный Code-Review для обнаружения некачественного кода проблематично. О том, как автоматизировать проверку качества кода 1С с помощью платформы SonarQube на конференции Infostart Event 2019 Inception рассказал ведущий разработчик компании «Командор» Олег Тымко.

30.12.2019    8642    olegtymko    9    

Ускорение реструктуризации таблиц Промо

Инструментарий разработчика Администрирование данных 1С Тестирование и исправление Бесплатно (free)

Иногда, может сложиться так, что на уже долгое время работающей базе нужно изменить типа реквизита, или добавить индексируемые поля, или просто добавить реквизит. Так вот после этого, нас ожидает долгий процесс (если база больших размеров)реструктуризации таблицы. В этой статье я рассмотрю алгоритм значительного сокращения времени реструктуризации.

12.09.2013    51878    OLEG4120    32    

EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 01

EDT v8 Бесплатно (free)

...продолжаем мучить(ся с) EDT

28.12.2019    6610    YuriYuriev    8    

EDT 1.16. Первые 20 часов работы

EDT v8 Россия Бесплатно (free)

Первое знакомство с 1C:Enterprise Development Tools, версия 1.16.0.363.

25.12.2019    10802    YuriYuriev    13    

Как работают управляемые формы и тонкий клиент 1С – взгляд "из-под капота"

Практика программирования Инструментарий разработчика v8::УФ Бесплатно (free)

Переход на управляемые формы перевернул процесс разработки на 1С, заставив программистов менять привычные подходы к описанию логики работы интерфейса. Руководитель компании «Цифровой Кот» Юрий Лазаренко в своем докладе на конференции Infostart Event 2019 Inception рассказал о том, как устроены управляемые формы и как правильно работать с тонким клиентом платформы 1С:Предприятие.

23.12.2019    12810    TitanLuchs    23    

VM1C - виртуальная машина для 1С Промо

Инструментарий разработчика v8 1cv8.cf Россия Бесплатно (free)

Демонстрация возможностей виртуальной машины для 1С. Создаем и выполняем код модулей в режиме Предприятия в реальном времени.

07.06.2013    24061    m.bolsun    46    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    11592    ivanov660    16    

Разбор любого JSON-объекта в соответствующую структуру

Инструментарий разработчика WEB v8 1cv8.cf Бесплатно (free)

Данная публикация предназначена разработчикам 1С, которым приходиться разбирать данные формата JSON. Выложенный пример кода создает объект типа Структура, полностью повторяющий структуру данных формата JSON.

13.11.2019    9515    user665435_al.windstorm    15    

Git для 1С-ника и другие технологии групповой разработки

Инструментарий разработчика Git (GitHub, GitLab, BitBucket) v8 1cv8.cf Россия Бесплатно (free)

У многих специалистов в отношении Git сложились стереотипы, мешающие начать работу с этим прекрасным и удобным инструментом. Почему его не стоит бояться, и чем он может упростить жизнь 1С-никам, рассказал архитектор ГК «Невада» Станислав Ганиев.

28.10.2019    12803    stas_ganiev    16    

Подсистема "COMExchange", "Консоль запросов 1C + ADO" - сервис обработки выборки запроса: грузим курс «бакса» ЦБРФ из файла *.dbf или *.xlsx. Промо

Консоль запросов v8 КА1 УТ10 УПП1 Россия Бесплатно (free)

На примере загрузки курса валюты продемонстрированы возможности консоли запросов в составе подсистемы "COMExchange" для обработки данных из внешних файлов и их синхронизации с данными информационной базы 1С.

10.03.2013    33286    yuraos    3    

Фреймворк для создания бизнес web-приложений

Прочие инструменты разработчика Бесплатно (free)

Для создания систем, решающих узкие бизнес задачи, использовать 1С бывает нецелесообразно. Хочу представить альтернативу - web фреймворк katejs. Будет интересно также тем, кто интересуется web разработкой на современном javascript.

15.10.2019    5260    nep_i    25    

Про ТабДок или TabDoc Pro

Практика программирования Инструментарий разработчика v8 Бесплатно (free)

Табличный документ – всем знакомый и привычный компонент продукта 1С. Про оптимизацию работы табличного документа, его проблемы и недостатки в своем докладе на конференции Infostart Event 2019 Education рассказал ведущий программист BIA-Technologies Князьков Алексей.

11.09.2019    6600    AKnyazkov    26    

FastCode - сервис шаблонов кода 1С

Инструментарий разработчика v8 Бесплатно (free)

Удобный поиск по базе шаблонов кода, БСП, ответы на вопросы, помощь сообщества программистов 1С. Клиент для поиска прямо в Конфигураторе!

10.09.2019    10222    m.bolsun    23    

Подсистема "COMExchange", консоль запросов, сервис обработки выборки запроса: корректируем регистры или «Берём банк, кассу, экспроприируем экспроприаторов». Промо

Консоль запросов v8 1cv8.cf Россия Бесплатно (free)

На примере шуточного примера продемонстрированы не шуточные возможности консоли запросов в составе подсистемы "COMExchange" для работы с регистрами, подчинёнными регистратору («обнуление» регистров, ввод начальных итогов (сведений), корректировка итогов).

31.03.2013    22531    yuraos    7    

Конвейер проверки качества кода

Инструментарий разработчика Практика программирования Математика и алгоритмы v8 1cv8.cf Абонемент ($m)

Jenkinsfile для выполнения проверки качества кода. Собирает информацию с АПК, EDT и BSL-LS. Сопоставляет ошибки с гит-репозиторием, выгруженным ГитКонвертором. Отправляет в Сонар.

3 стартмани

04.09.2019    24319    22    Stepa86    45    

Кодогенерация и метагенерация в 1С

Практика программирования Инструментарий разработчика Бесплатно (free)

В своем докладе на конференции INFOSTART EVENT 2018 EDUCATION Дмитрий Белозеров рассказал о разработке инструмента, позволяющего программно работать с метаданными 1С и писать скрипты для выполнения тех же действий, которые выполняет разработчик в конфигураторе –  с какими сложностями и нюансами пришлось столкнуться, и что получилось в итоге.

26.08.2019    9064    kirovsbis    28    

Как мы разрабатываем в EDT

EDT Инструментарий разработчика v8 Бесплатно (free)

EDT – это новая среда разработки, на которую сейчас перешли разработчики фирмы «1С». Однако до сих пор существует ряд «белых пятен», касающихся как теоретической, так и практической части применения этого инструмента. Про опыт перехода на разработку в EDT на конференции INFOSTART EVENT 2018 EDUCATION рассказал начальник сектора разработки в компании «Группа Полипластик» Владимир Крючков.

23.08.2019    12539    ivanov660    24    

Гаджеты для одинэсника. Часть 2 Промо

Инструментарий разработчика Мобильная разработка ИТ-компания Бесплатно (free)

... ситуация с планшетами весь 2012-й год была достаточно запутана. То и дело всплывала какая-то модель, которая на некоторое время по отношению цена/качество привлекала к себе внимание. Я долго откладывал эту статью, ожидая лидеров, и они, наконец, обозначились...

20.03.2013    34967    O-Planet    61    

Быстрый ввод кода

Инструментарий разработчика v8 1cv8.cf Бесплатно (free)

Упрощение рутинного ввода кода.

19.08.2019    4712    ranis888    13    

1С:EDT. Первые шаги… или есть ли альтернатива конфигуратору?

EDT v8 Бесплатно (free)

Заменить конфигуратор сложно, а в некоторых случаях невозможно, если, например, нужно оперативно подправить код непосредственно в рабочей конфигурации…

15.08.2019    24488    ellavs    108    

Подходы, методы и инструменты UX/UI для разработки эффективных интерфейсов на 1С

Работа с интерфейсом Инструментарий разработчика v8 Бесплатно (free)

Интерфейсам в 1С обычно уделяют мало внимания. Это в итоге снижает востребованность платформы, делает ее неконкурентной, лишает большой доли рынка. Как не потерять старых клиентов и привлекать новых с помощью интерфейсов, а главное – как сделать «правильный» интерфейс, рассказал участникам конференции Infostart Event 2018 Education управляющий партнер и основатель консалтинговой группы WiseAdvice Иван Тягунов.

07.08.2019    11219    IvanAT1981    15    

Отказ от использования хранилищ 1С, переход на Git.

Инструментарий разработчика Разработка Бесплатно (free)

Валерий Максимов в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION делится опытом перехода нескольких команд (более 100 разработчиков) от использования хранилищ 1С на системы контроля версий Git.

25.07.2019    10764    theshadowco    31