Управление техническим долгом - Концепция 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 850 30.06.17 09:05 Сейчас в теме
Что такое Технический долг?

как изящно слово "**внокод" завуалировали :-D
texnic79; kolya_tlt; wowik; Vladimir Litvinenko; Berckk; Brawler; sorb; корум; Lem0n; artbear; Bazil; +11 Ответить
2. Артано 710 30.06.17 09:55 Сейчас в теме
(1) Речь не только о говнокоде, а в принципе о копро-методах в разработке. В известном мультике это обозначали фразой "и так сойдёт"
texnic79; wowik; Vladimir Litvinenko; Brawler; корум; nixel; +6 Ответить
3. nixel 1028 30.06.17 09:55 Сейчас в теме
(1) для *овнокода есть изящный "code smells" :)
Когда мы делали плагин локализации SonarQube, очень долго думали, как же его перевести эээ... по-корректнее :) и чтобы в интерфейсе легло
4. Stepa86 1426 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 2320 30.06.17 13:15 Сейчас в теме
+ чисто за воспоминание о теме. Не читал, но... )))
7. nixel 1028 30.06.17 13:37 Сейчас в теме
8. brr 179 30.06.17 15:26 Сейчас в теме
Условно, с точки зрения разработчика, количество технического долга при просмотре некачественного кода можно охарактеризовать, как количество воскликов «Что же здесь происходит?» в час.


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

жаль, что я не в вашей команде...
sulfur17; artbear; +2 Ответить
12. &rew 29 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 29 10.07.17 08:05 Сейчас в теме
(14)Вы знаете, любое утверждение верно только до конкретных значений элементов объектной природы. Мне кажется, что вы в курсе как именно уберечь обслуживаемый Вами бизнес.
Кстати, как там аукцион по 1С по присоединению вновь обретенных мощностей? Выполнили? (простите за моветон)
16. sulfur17 36 17.07.17 10:14 Сейчас в теме
Восхитительно! Добавил в избранное и очень надеюсь на развитие этой темы (ссылки на скачивание, мануалы). Один проект уже пришлось бросить из за чрезмерного тех.долга, хотелось бы научиться с этим бороться.
Оставьте свое сообщение

См. также

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

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

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

25.10.2017    24161    avk72    63    

Infostart Toolkit – инструмент, в котором сделано то, что давно просят от 1С

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

Лауреат Infostart Awards-2019, ведущий разработчик инструментов Infostart Toolkit Евгений Люлюк рассказывает о том, как развивается, какие задачи закрывает и какие проблемы решает представляемый им набор инструментов разработчика.

09.06.2021    1962    Evg-Lylyk    3    

Принципы разветвленной доработки конфигурации, находящейся на поддержке, и ее расширений. Объединение веток разработки

EDT Git (GitHub, GitLab, BitBucket) v8 Бесплатно (free)

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

02.06.2021    742    Алексей Воробьев    2    

Редактор кода, запроса, ... Infostart Toolkit (интеграция с MS Monaco)

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

Контекстная подсказка, подцветка синтаксиса в тонком клиенте. В платформе 1С редактор кода на управляемых формах обладает нулевой функциональностью, интеграция с MS Monaco позволяет запустится просто в космос.

28.05.2021    3048    Evg-Lylyk    14    

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

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

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

20.05.2015    31199    dj_serega    18    

re: Flowcon

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

Flowcon возвращается.

28.04.2021    1855    1c-intelligence    26    

10 полезных, но малоизвестных возможностей IS Toolkit

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

Будет полезно пользователям Toolkit, а также тем, кому интересны возможности данного инструмента.

23.04.2021    2115    Evg-Lylyk    0    

Редактор схемы компоновки для тонкого клиента

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

Аналог платформенного конструктора схемы компоновки данных для работы в тонком клиенте. Входит в состав набора "Универсальные инструменты 1С"

08.03.2021    2597    cprit    19    

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

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

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

09.02.2015    34523    boogie    21    

Структура запроса (Infostart Toolkit)

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

Описание механизма разбора запроса на части (дерево), используемого в IS Toolkit и Управляемой консоли отчетов

02.03.2021    1892    Evg-Lylyk    7    

Последний раз про срез последних (на каждую дату в запросе)

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

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

15.02.2021    6061    randomus    47    

Отладка логики запроса в консоли запросов ИР

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

Облегчаем поиск причины неожиданного результата запроса в консоли запросов из подсистемы "Инструменты разработчика" (ИР)

05.01.2021    5612    tormozit    8    

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

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

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

26.06.2015    20745    Infactum    23    

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

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

Сборка репозитория P2 на основе исходников плагина 1С:EDT для поставки пользователям.

27.12.2020    666    marmyshev    0    

Работа с СКД в продукте "Infostart Toolkit"

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

Infostart Toolkit обладает большим количеством уникальных возможностей для работы с СКД – это анализ исполняемых текстов запросов, работа с внешними источниками в схеме СКД, получение данных в отладке и многое другое. Обо всех этих возможностях рассказал разработчик продукта Евгений Люлюк.

24.12.2020    2502    Evg-Lylyk    2    

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

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

Описание процесса создания UI-плагина для EDT с Quick-Fix по проверке.

08.11.2020    772    marmyshev    0    

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

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

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

11.04.2015    78679    DitriX    297    

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

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

Описание процесса создания плагина для EDT по валидации с квикфиксом.

07.11.2020    1578    marmyshev    1    

Отладка в Infostart Toolkit

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

Отладка запросов, схем компоновки данных, просмотр содержимого менеджера временных таблиц.

05.11.2020    3387    Evg-Lylyk    16    

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

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

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

17.10.2020    3984    marmyshev    24    

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

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

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

07.11.2010    30960    Boris-Leleko    9    

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

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

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

07.09.2020    4710    Evg-Lylyk    17    

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

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

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

31.08.2020    10317    kuntashov    73    

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

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

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

21.08.2020    6485    salexdv    48    

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

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

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

13.08.2014    22776    m.bolsun    68    

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

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

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

19.08.2020    5958    pa240775    33    

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

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

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

17.08.2020    6884    orefkov    47    

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

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

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

07.08.2020    3687    Yashazz    6    

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

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

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

03.04.2014    26291    yuraos    2    

Редактор HTML

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

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

03.08.2020    2576    cprit    3    

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

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

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

03.08.2020    4766    tormozit    26    

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

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

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

27.07.2020    6217    Evg-Lylyk    47    

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

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

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

12.09.2013    52750    OLEG4120    32    

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

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

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

11.06.2020    5141    doublesun    8    

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

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

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

01.06.2020    1878    kuza2000    7    

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

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

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

02.05.2020    5099    pparshin    21    

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

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

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

07.06.2013    27790    m.bolsun    46    

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

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

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

12.04.2020    3523    awk    14    

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

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

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

10.04.2020    4988    capitan    8    

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

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

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

06.04.2020    9846    Evg-Lylyk    0    

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

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

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

10.03.2013    33539    yuraos    3    

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

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

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

24.02.2020    7114    check2    10    

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

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

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

20.02.2020    7568    theshadowco    13    

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

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

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

19.02.2020    4984    check2    2    

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

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

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

31.03.2013    22780    yuraos    7    

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

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

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

21.01.2020    5031    YuriYuriev    3    

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

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

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

20.01.2020    6798    nixel    22    

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

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

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

13.01.2020    8555    Scorpion4eg    8    

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

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

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

20.03.2013    35231    O-Planet    61    

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

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

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

09.01.2020    7074    YuriYuriev    32    

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

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

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

30.12.2019    10220    olegtymko    10    

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

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

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

28.12.2019    7371    YuriYuriev    8    

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

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

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

25.12.2019    11987    YuriYuriev    13