Учебный курс. Повышение качества разработки. Ошибки программы

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

Разработка - Практика программирования

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекции № 3,4,5. Эти лекции посвящены ошибкам программ, их классификации и способам исправления

1 Методики поиска и классификации ошибок

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

Так как курс нацелен на повышение качества программы, нам необходимо понимание того что приводит к его снижению. Эта лекция в нескольких приближениях даст образы «врага». От простого и четкого, до более сложного и подробного. Помимо этого, в специальном разделе, будут приведены примеры типичных ошибок, способы исправления и обхода.
Хочу напомнить, что несмотря на то, что рекомендации так или иначе исходят их опыта работы отдела разработки или проектной команды, излагаемые принципы и методики легко масштабируются до отдельного программиста.

1.1 Что такое ошибка

В первой части вводной лекции, мы приняли простое определение качества программы, из которого мы можем вывести такое же простое определение ошибки:

Ошибка – это свойство программы, приводящее к ухудшению её качества по любому из трёх критериев качества: работоспособности, сопровождаемости, гибкости.

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

Крайне важно понимать, что ошибка — это имманентное свойство текущей версии программы, а не некоторое событие, явление или баг-репорт и уж тем более не исключение (exception), которое во многих случаях ошибкой не является.

1.2 Классификация ошибок

Классификация ошибок есть обобщение массива ошибок с целью облегчения работы с ними. Классификация является наглядным примером абстракции с её достоинствами и недостатками. Структурирование и обобщение больших объемов данных, позволяет их легче обрабатывать и осознавать. От осознания очень сильно зависит качество работы интуиции. Чем глубже понимание базиса вещей, тем чаще случаются "внезапные озарения". Но не стоит забывать о недостатках абстракций и всегда иметь их ввиду.
Видов классификации может быть больше чем число ошибок, поэтому обобщение классификаций для практических нужд я выполняю по функциональному назначению. В рамках такого подхода выделяются две основные функции классификации:

Управление процессом обнаружения и исправления ошибок. При значительном количестве ошибок, применение классификации многократно повышает эффективность их исправления. В основном это достигается за счет облегчения идентификации и локализации. При налаженной статистике появляется возможность работы на упреждение – исправление ошибок до их возникновения у конечного пользователя.
Распределение трудовых ресурсов (в том числе выстраивание приоритетов исправления). Является частным случаем управления ошибками, но ввиду распространенности и полезности не нуждающейся в особых доказательствах, я выделяю эту функцию отдельно. На больших проектах или в штате крупных предприятий суммарная трудоёмкость на исправление ошибок (если их действительно регистрировать) может существенно превышать ёмкость фонда рабочего времени. Также, разные специалисты с разной эффективностью решают различные проблемы: кто-то въедлив и усидчив и легче находит даже хорошо спрятанные ошибки, кто-то хорошо владеет языком и может превратить невнятный запутанный код в ясное изложение. Таким образом, классификация ошибок будет хорошим подспорьем в деле распределения трудовых ресурсов.

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

Базовая классификация

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

Классификация по терпимости ошибки

Данная классификация является расширением базовой классификации, т.к. наследует из нее всё те же критерии, но расчет интегральной стоимости ошибки производится по индивидуальному алгоритму, либо с использованием коэффициента.
Подобный подход, необходим для лучшей адресации усилий по исправлению ошибок. Несложно представить, что ошибки с одинаковой интегральной стоимостью могут находиться в разных разделах программы с разной чувствительностью к ошибкам. Например, для проектной команды, получающей оплату по итогам промежуточной приёмки, демонстрация функциональности или рабочий стол директора/собственника, это не то время и место, где они хотели бы увидеть ошибки. А фикси программист, будет иметь много проблем если из-за небольшой ошибки с низким приоритетом, остановился или замедлился важный процесс предприятия. Следовательно, необходима уточняющая классификация, позволяющая двигать действительно критичные ошибки вверх по шкале приоритетов. Даже при отсутствии автоматизированной оценки, всегда остаётся возможность принудительно сделать исправление ошибки сверхприоритетным. Если же углубиться в построение инструментов, то для места возникновения ошибки, можно определить коэффициент (0,5 или 2) или особую формулу («всегда самый высокий» или «ставим в самый низ»).
За скобками я оставляю концепцию управления рисками, но необходимо иметь ввиду, что управление рисками как система, напрямую взаимодействует с данной классификацией,  даже если управление рисками происходит только в голове единственного в штате фикси-разработчика.

Классификация по трудоёмкости исправления

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

В практике программирования, зачастую, это достаточно сложная для полноценного применения классификация. Сложность заключается в низкой точности предварительной оценки трудоёмкости. Чтобы точность повысить, отделу разработки необходимо перейти на качественно иной уровень, когда точность оценки достаточно высока для детального планирования. Но и с низкой точностью предсказания есть возможность использовать классификацию, как минимум, для определения приоритетов. Например, у вас есть 10 ошибок примерно одинаковой вредности. Но одна из них предварительно оценивается в 40 часов, тогда как остальные, даже по пессимистичным оценкам укладываются в 1-8 часов. В большинстве случаев, оптимальным решением будет «поискать под фонарём» - в первую очередь обработать те ошибки, которые можно быстро исправить. Причина проста - затратив те же 40 часов или меньше, вы исправите девять ошибок а не одну. При этом шанс выбиться из графика много ниже. Ведь не стоит забывать, что сложно оценить трудоёмкость более 16 часов без декомпозиции, и вполне возможно, что 40 часов это довольно оптимистичный прогноз. Также, большой объем изменений предполагает более объемное тестирование, и потенциально может увеличить затраты времени в несколько раз. Даже если затраты будут связаны с выявлением ранее не обнаруженных ошибок, которые в старом ошибочном коде не воспроизводились, то это всё равно затраты времени, вызванные исправлением одной ошибки.

Если же вы способны точно оценивать трудоёмкость, то все инструменты планирования становятся доступны. Наиболее ценными в моей практике являлись два инструмента:

   - составление графика релизов и план-графика по проектам. Речь идет о действительно точных графиках, а не о наборе пожеланий, обещаний и стоящими за нами авралах и превозмоганиях.

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

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

Классификация по пригодности к формализации

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

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

Приведу уровни формализации, обычно используемые в описанной схеме:

   - Не определен

   - Не поддаётся формализации. Стараться избегать такого определения. Это или лень или очень-очень плохой код.

   - Формализуется частично. Такой уровень пригоден для ручного использования.

   - Полностью формализуется. Этот уровень - показание к полной автоматизации поиска ошибки.

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

1.3 Как искать ошибки

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

Поиск в процессе разработки

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

Инспекция кода

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

Во-первых, инспектор может быть не погружен в контекст, но он как правило видит общую картину и глаз его не «замылен».

Во-вторых, сам факт наличия организованного процесса инспекции кода приводит к повышению качества выпускаемого кода.

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

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

Профилирование

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

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

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

- Поиск проблем в конвертации запросов из языка 1с в язык СУБД. Как многие из вас знают, запросы, написанные в 1с, интерпретируются в язык используемой СУБД. В процессе интерпретации неоптимальных запросов, могут рождаться «монстры». В MS SQL Server есть специальный инструмент, который так и называется «Profiler». С другими СУБД знаком слабо, но полагаю, аналогичные возможности есть и там.

Тестирование

Тестирование может быть, как простым, так и комплексным процессом. Элементы тестирования могут применяться уже на этапе разработки в виде синтаксического и семантического контроля кода. При этом синтаксический анализ выполняется автоматически, средствами платформы, а семантический требует либо отдельных инструментов, либо применения паттернов для поиска ошибок (см. раздел 1.2.4 текущей статьи). Но именно на семантическом уровне и расположены главные гнёзда ошибок.

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

Анализ логов работы и разбор исключений

Данный способ применяется уже не только к тестовым версиям, но и к продуктовым релизам. Общая схема такова:

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

Анализ ошибок (уровень регистрации) в журнале регистрации. Данный подход неплох сам по себе, при условии уверенного парсинга записей журнала. Рабочая база содержит очень много записей об ошибках, но ошибками являются далеко не все. Второй путь - перехват исключений и регистрация их в нужном формате. Первый подход безальтернативно для типовых, второй - для самописных конфигураций или новых подсистем в типовых.

Жалобы и пожелания пользователей

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

- Ошибка, найденная конечными пользователями, прямо означает, что IT со своей работой справляется плохо. Пусть это вызвано объективными причинами, и ребята не виноваты, но вывод простой и очевидный.

- Далеко не все ошибки регистрируются. Лишь самые надоедливые и мешающие работе дойдут до программистов. Упрощение отправки багрепорта или его автоматизация, несколько сглаживает проблему, но окончательно не устраняет.

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

Наблюдение за работой пользователей

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

1.4 Когда и как лучше всего исправлять ошибки

В предыдущем разделе мы уже частично ответили на этот вопрос – как можно раньше. Чем раньше ошибка обнаружена, тем меньше расходов понесет предприятие.
Да, грамотная организация процесса разработки, инспекции кода и тестирование сократят число ошибок в продуктовых релизах в десятки раз, но не сведет их до нуля. Поэтому не стоит расслабляться если вы организовали хороший контроль на первых этапах выпуска релиза – ошибки всё равно неизбежны. Разумеется, главная цель это найти и обезвредить ошибку до того, как она сможет нанести ущерб, но искать и регистрировать ошибки необходимо ВСЕГДА. Даже там, где ошибки быть не может, всё равно необходимо искать.

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

Планирование архитектуры приложения

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

Перманентный рефакторинг в процессе разработки.

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

Плановый рефакторинг

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

Обработка инцидентов в продуктовых базах

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

2 Примеры ошибок, их происхождение, способы обхода и исправления

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

Важно! Этот раздел является иллюстративным примером описания ошибок как явления, и не предполагался как исчерпывающий список ошибок или филиал лепрозория. Назначение раздела показать неоднозначность ошибки как явления:

   - Ошибки не настолько многочисленны если их классифицировать, и поддаются потоковой обработке

   - Исправление ошибки может ухудшить качество программы

   - Не все ошибки являются ошибками

 Но если Вы всё равно считаете что раздел нуждается в дополнении, то добро пожаловать в обсуждение.

2.1 Запрос в цикле

Формализуется, влияет на производительность, исправление влияет на сопровождаемость и гибкость

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

2.2 Неявный запрос

Формализуется, влияет на производительность, исправление влияет на сопровождаемость и гибкость

Неявные запросы в том числе в циклах, происходят всякий раз:
- при обращении к свойствам ссылки через точку
- при использовании методов «НайтиПо»
Сами по себе неявные запросы, позволяют сократить объем кода и повысить его читаемость. Именно ради этого разработчики языка 1С и задумывали подобные, небезопасные инструменты. Если данные методы сознательно используются, то за ними необходимо наблюдение – они могут стать узким местом.

2.3 Разыменование полей в запросах

Формализуется, влияет на производительность, исправление влияет на сопровождаемость и гибкость

Разыменование полей в запросах. Само по себе не слишком страшно если не злоупотреблять и не применять в блоке условий и соединений. Но нужно понимать, что разыменование поля приводит к созданию левого соединения с таблицей объектов к реквизитам которого идет обращение. Если разыменовывается составной тип (например, документ-регистратор), то будет создано столько соединений, сколько ссылочных типов предусмотрено в данном составном типе. В качестве обхода проблемы с созданием множества неявных соединений для составных типов можно использовать функцию "Выразить" для выбираемых полей запроса.

2.4 Неверное употребление функций в запросах

Формализуется, влияет на производительность и сопровождаемость

Наиболее частные ошибки происходят с функциями «Выразить» и «ТипЗначения». Если вы используете функции не только в блоке выбора, но и в блоке соединений или условий, то фактически отключаете работу индекса по данным полям. Дело в том, что для применения функции к полю записи, эту запись необходимо сначала прочитать, таким образом даже хороший запрос с соединениями по индексированным полям будет производить полное чтение записей, вместо работы с индексом. А ваш запрос вместо ускорения выполнения станет обрабатываться дольше.
Функция «Выразить» и «ТипЗначения» часто могут быть заменены оператором «Ссылка», а функция «ЕстьNull» на оператор «Есть Null»

2.5 Безусловная выгрузка запроса в ТЗ

Формализуется частично, влияет на производительность

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

  2.6 Неверное употребление оператора «Попытка…Исключение»

Формализуется частично, влияет на надёжность, быстродействие и сопровождаемость, исправление влияет на сопровождаемость

Как правило, такие вещи появляются при ошибках в выполнении кода и нежелании разбираться почему они происходят. Наиболее часто встречается попытка записи в БД. Здесь два варианта действий:

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

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

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

2.7  Оператор «Выполнить» и функция «Вычислить»

Необоснованное применение в нагруженных алгоритмах

Формализуется частично, влияет на производительность, исправление влияет на сопровождаемость и гибкость

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

Выполнение произвольного кода, введенного пользователем

Формализуется частично, влияет на безопасность, исправление влияет на сопровождаемость и гибкость

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

Получение именованных реквизитов

Формализуется частично, влияет на производительность

К числу типичных ошибок можно отнести использование указанных конструкций для получения именованных реквизитов объектов. Например, вместо правильного Результат = Объект[ИмяРеквизита] используется Выполнить("Результат = Объект." + ИмяРеквизита) или Результат = Вычислить("Объект." + ИмяРеквизита).

2.8 «Армейский» способ обработки объектов.

Возвращается парень из армии в деревню. Его спрашивают:
- Как там, в армии?
- Сплошная нервотрёпка!
- Как это?
- Завтра покажу...
На следующий день в пять утра деревня поднимается набатом:
Народ с изб повыскакивал и бегом к колокольне, а парень с высоты кричит:
- Мы с отцом за дровами, остальные – разойтись!

Формализуется частично, влияет на производительность, исправление влияет на сопровождаемость

Ситуация, когда при необходимости обработать небольшую часть данных, выполняется вызов всех объектов и последующий перебор. Либо применяется излишняя обработка объектов, в этом не нуждающихся. Подобные ошибки я встречал в том числе в нагруженных модулях с многократными выполнениями и большим числом итераций. Наглядный пример: Есть элемент справочника, изменение реквизитов которого должно сопровождаться синхронным изменением соответствующих реквизитов в подчиненных элементах. Разработчик поступает так - он отбирает ВСЕ подчиненные элементы и без всякой проверки просто перезаписывает их с правильным значением реквизита. Правильным подходом было бы уже в запросе отфильтровать элементы, нуждающиеся в перезаписи, в крайнем случае выполнять подобную проверку перед записью. Основное правило - старайтесь минимизировать операции, особенно если это операция перезаписи существующих объектов. Во-первых, это просто ненужная операция и она может спровоцировать еще много других ненужных операций (например, регистрация к обмену якобы изменившихся элементов). Во-вторых, операция перезаписи (update) очень тяжелая, и в зависимости от условий разница с записью нового объекта может различаться в несколько раз.

2.9 Поиск в не индексированных коллекциях

Формализуется частично, влияет на производительность, исправление влияет на сопровождаемость

В качестве таких коллекций чаще всего выступают массивы и таблицы значений.
Метод "найти" в коллекции с большим числом элементов нужно использовать с осторожностью, так как поиск производится полным перебором коллекции. Оптимальным вариантом для оптимизации поиска в массиве может быть использование соответствия (map) вместо массива. В этом случае накладные расходы на создание соответствия окупятся значительно более быстрым поиском нужного значения в коллекции.
Для таблицы значений, как правило, помогает индексация полей поиска вкупе с использованием метода «НайтиСтроки».

2.10 Клиент-сервер.

Необоснованные серверные вызовы

Формализуется частично, влияет на производительность

Частые контекстные серверные вызовы, там, где можно обойтись внеконтекстным. Например, нужно получить текущий курс валют. На форме есть ссылка на валюту. Чтобы получить курс на дату достаточно выполнить внеконтекстный вызов сервера и передать валюту и дату в качестве параметров. Здесь будет произведена передача одной ссылки и одного примитивного типа на сервер и возврат другого примитивного типа. В случае контекстного вызова сервера, на сервер вытягивается вся форма, при этом все её данные дважды пройдут процедуру сериализации/десериализации при миграции на сервер и обратно.
Необоснованная передача параметров по ссылке
Если вам не нужно редактировать переданные параметры, то передавать их нужно по значению. Иначе процедура сериализации/десериализации параметров будет выполнена дважды! И если для примитивных типов это фактически бесплатно, то для ссылочных типов это довольно дорогая операция. В любом случае, нужно взять за правило, что если параметр не должен измениться, то незачем передавать его по ссылке.

2.11 "Китайский" метод программирования.

Не формализуется, влияет на надёжность, сопровождаемость и гибкость, исправление влияет на быстродействие

Копирование фрагментов кода с нужным алгоритмом. Это грубая и опасная ошибка. Разумеется, в некоторых случаях копирование применимо и полезно. Но случаи это специфические и применение особых методов к ним должно быть обдумано и обосновано. В иных же случаях "копипаста" не только усложняет чтение и как следствие сопровождение кода, но и может привести к неожиданным и трудноуловимым ошибкам в программе. Например, когда потребности заказчика потребуют внести изменения в исходный алгоритм. В этом случае все созданные копии продолжат использовать старую версию алгоритма. Последствия непредсказуемы, но могут быть катастрофическими. Правильное решение - использование общих формул и алгоритмов - "выделение метода". Создаётся отдельная функция (или обработка с набором методов) и уже эти методы используются в разных частях программы. Для реализации "региональных" особенностей в разных участках кода добавляются особые параметры метода или (если особенности начинают разрастаться) выделяется новый метод или добавляется еще один уровень абстракции. Примерно в таком направлении должна проходить эволюция программы.

2.12 Использование изменчивых данных ИБ в качестве констант

Формализуется частично, влияет на надёжность, сопровождаемость и гибкость

Написание алгоритмов, опирающихся на изменчивые значения как на константы. Такой подход может привести к самым неожиданным и печальным результатам. Например, поиск элемента справочника по прямо прописанному в коде номеру, наименованию или GUID просто перестанет работать при даже незначительном изменении наименования или замене объекта обработкой по чистке дублей. В таких случаях, обычно или добавляют константу или заводят специальный справочник/РС где хранятся необходимые ссылки. В крайнем случае - если нет возможности менять структуру данных ИБ - заводят общий метод возвращающий нужное значение (или прописанное кодом или из хранилища значений). Когда появится возможность изменить структуру БД вы легко замените алгоритм в одном единственном общем методе.

2.13 Несоответствие наименования переменной хранимому значению.

Не формализуется, влияет на сопровождаемость

Причин может быть несколько: 
а) исходный алгоритм поменялся, разработчик поленился переименовать переменные; 
б) потребовалось записать куда-то необходимые данные - разработчик решил использовать ранее инициализированную и уже "отработавшую" переменную с принципиально другим значением.
в) разработчик поленился и завел одну или несколько переменных с ни о чем не говорящими названиями типа а1, а2 или Темп1-2, Врем1-2 и.т.д.

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

2.14 Длинные методы

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

Наиболее заметная, но зачастую самая сложная в исправлении ошибка. Главная проблема длинного метода, что он позволяет даже хорошему программисту ошибаться:
а) ошибаться с именованием и типизацией переменных;
б) забывать или даже не знать, что происходит с переменной в дебрях кода;
в) ошибаться в разделении уровней абстракции и сваливать всё в одну плохоразличимую кучу.

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

Метод "Здесь так заведено"

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

Метод "Облагороженный"

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

Метод "я длинный потому, что я удав"

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

 

3 Заключение

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

 

Условия распространения 
- разрешается перепечатка и «репостинг» в некоммерческих целях при сохранении исходного текста условий распространения и ссылки на источник
- разрешается цитирование с обязательным указанием источника.

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Hans 1 11.07.18 07:45 Сейчас в теме
Сделай видео лучше.
TreeDogNight; Kaspirovsky; olegtymko; +3 1 Ответить
2. Артано 673 11.07.18 08:35 Сейчас в теме
(1) прошу прощения, но зачем? Текстовый формат, на мой взгляд, это очевидное преимущество
Plotks2017; yaroslavkravets; Ashandy; АлександрЯрославичъ; Aleskey_K; y22-k; ddelphknn; mark_oilbass; Waanneek; v_den_v; Diplomat000; YAN; Shrayky2; support; 🅵🅾️🆇; starik-2005; AtPups000; amon_ra; FesenkoA; yogaga; Dem1urg; +21 Ответить
3. Dem1urg 316 11.07.18 09:04 Сейчас в теме
(2) Поддерживаю. Видео я бы смотреть не стал. А текст обязательно почитаю. Еще и цитат надергаю из особенно понравившихся мест.
albatros12; AtPups000; +2 Ответить
4. Hans 1 11.07.18 09:10 Сейчас в теме
(2) Пришел домой после трудового дня, легче видос посмотреть сидя на диване чем сидеть за компом и читать текст. Текстовый формат это недостаток. Прошлый век. Все курсы делаются в виде видео.
TreeDogNight; Yakud3a; Kaspirovsky; +3 Ответить
5. Артано 673 11.07.18 09:11 Сейчас в теме
(4) Если на диване и с пивком, то только за деньги :-D
46. neikist 12.07.18 12:12 Сейчас в теме
(4) Как говорится в подобных случаях: "Горите в аду!".
Вы серьезно считаете что видео удобней и проще для восприятия? А как в видео реализовать беглый просмотр (когда просто взглядом за секунды десятки предложений текста пробегаешь). А как без попытки угадать "на какой же секунде это было" возвращаться к нужному предыдущему фрагменту? А как цитаты вытаскивать? А что делать с тем что отдельное предложение хочется раза 3 перечитать, а соседнее мельком проскакиваешь поскольку объем информации в нем меньше на единицу текста?
user616910_ju_w; AlX0id; herfis; Iscarimet; +4 Ответить
47. herfis 372 12.07.18 12:32 Сейчас в теме
(46) +100500
Видео-курсы - это фаст-фуд. Поэтому и популярны. Пипл хавает, так как требуется меньше умственных усилий. Но ведь у нас задача прямо противоположная! При этом реальная полезность может легко подменяться на "нравится". Нравится преподаватель, нравится звук голоса, нравится картинка, нравится стиль общения, нравится уважительное и поощряющее отношение преподавателя.
Печатное слово (хорошее) требует усилий с обеих сторон. Требует наработки определенных навыков работы с ним (читать, опять же, надо уметь). Но его эффективность выше на ПОРЯДКИ. Я с ужасом представляю будущее, в котором больше не будет хороших книг. Потому что пиплу подавай видосики.
mityushov.vv; albatros12; alex-l19041; user616910_ju_w; Jestery; LordKim; AlX0id; acanta; +8 Ответить
48. spacecraft 12.07.18 12:40 Сейчас в теме
(47) видосики тоже полезны. Но не как только они.
Лично для себя нашел приемлемое обучение в таком формате:
1. Теоретические основы из книг, статей, документаций.
2. Видео-курсы.
3. закрепление материала по книгам, статьям, документации.

Именно в такой последовательности. Из книг не всегда удается сразу понять последовательность и сложные моменты. Только видео должно быть не просто пересказ книги с простыми примерами. Желательно еще с печатными материалами, хотя бы кода.
49. herfis 372 12.07.18 12:51 Сейчас в теме
(48) Я не против видосиков. Иногда они незаменимы. Недавно разбившийся экран телефона заменял по видосику. Есть виды знаний, при передаче которых визуализация значительно помогает. Но что касается передачи знаний, для которых видеоряд не критичен - мое мнение однозначно. Лучше хорошей книги/статьи/монографии - быть не может ничего.
"Из книг не всегда удается сразу понять последовательность и сложные моменты."
Просто-напросто навыков автора и твоих навыков не хватило для достижения взаимопонимания. Поэтому и потребовался альтернативный источник знаний. Это легко могла быть и другая книга. Еще лучше в закрытии частых дыр понимания, которые возникают у многих - форумы и системы вопрос/ответ. Поиск рулит. И работает гораздо быстрее и эффективнее видосиков. Ты сразу видишь ответ, а не ждешь пока кто-то прокашляется.
52. spacecraft 12.07.18 13:50 Сейчас в теме
(49)
Просто-напросто навыков автора и твоих навыков не хватило для достижения взаимопонимания

Почему в книгах по изучению ЯП обычно простые примеры? Потому что формат книги не удобен для показа большого листинга кода. Не воспринимается как единый. Да, основные навыки получить можно, но сложное взаимодействие не раскрывает. Во всяком случае для начинающих. Видео дает больше информации на единицу времени, при условии последовательности подачи информации, а не скачках и "прокашливаний". Но перед просмотром видео необходимо уже имень базовые знания по предмету.
Получение информации через один орган чувств человека обычно менее продуктивен, чем через несколько.
Ведь обучение у хорошего наставника дает больший профит, чем только книги. Не становятся мастером "шаолиня" только по книгам :)
Может просто-напросто видео-уроки были такого качества, что не воспринимались?
53. Артано 673 12.07.18 14:07 Сейчас в теме
(52) Не надо уходить в демагогию. Мы же тут не на телешоу. Вопрос в этой ветки предельно прост: Видео versus Текст. Наставник и очные курсы это вообще другой уровень обучения. Видео и текст могут быть сравнены, так как оба являются заочными. Выше по ветке уже сделали достаточно доводов в пользу текста: легкость возврата к нужному месту, легкость поиска (использование как справочного материала), легкость цитирования, легкость доработки, возможность самостоятельного выбора темпа изучения.

Насчет одного органа чувств - здесь или лукавство или очевидное непонимание. Тексту не принципилаьно ваше чувственное восприятие. Есть конечно приёмы психологические при построении фраз в тексте и самой структуры текста. Но главное в тексте, что он при прочтении целиком помещается в мозг и там окончательно обрабатывается и анализируется. А как текст читается: глазами или наощупь дело десятое.
55. spacecraft 12.07.18 14:19 Сейчас в теме
(53)
Насчет одного органа чувств - здесь или лукавство или очевидное непонимание.

А как текст читается: глазами или наощупь дело десятое.

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

А я не отделяю видео от текста. В смысле одно только видео бессодержательно.
См. (48). Именно такая последовательность. И "Только видео должно быть не просто пересказ книги с простыми примерами. Желательно еще с печатными материалами, хотя бы кода."
56. Артано 673 12.07.18 14:26 Сейчас в теме
(55) Чем видео отличается от очной лекции?! Листинги кода в видео?!

Пойду я из этой ветки.
57. pm74 177 13.07.18 17:53 Сейчас в теме
(49)
Я не против видосиков. Иногда они незаменимы. Недавно разбившийся экран телефона заменял по видосику.


мне кажется вы несколько утрируете.
безусловно для глубокого изучения материала нет ничего лучше хорошей книги,
но в плане быстроты "погружения" в новый материал (имо) нет ничего лучше просмотра видео , особенно если автор (диктор) имеет достаточный опыт очного преподавания.
на мой вкус лучше всего получается у преподавателей вузов возрастом over 50 .
59. herfis 372 16.07.18 09:16 Сейчас в теме
(57)
но в плане быстроты "погружения" в новый материал (имо) нет ничего лучше просмотра видео , особенно если автор (диктор) имеет достаточный опыт очного преподавания

Не готов согласиться. Эдакая вводная лекция, когда касаешься какой-то абсолютно новой для тебя обширной области - да, может быть очень полезна. Потому что книг много, книги разные, часть технологий устарела, появились новые, тренды меняются - а ты во всем этом ни в зуб ногой. Поэтому мнение опытного практика, который быстренько разложит по полочкам текущее состояние индустрии - сложно переоценить. Но это только потому, что такую информацию редко оформляют в виде статей. В виде статей я бы эту информацию потреблял с еще большим удовольствием.
60. pm74 177 16.07.18 09:45 Сейчас в теме
(59) я повторюсь , все зависит от диктора и подачи материала в видео
например недавно нашел в сети прекрасный курс лекций по основам GTL LTL, где автор излагает тему очень просто и ясно
61. herfis 372 16.07.18 09:54 Сейчас в теме
(60) Ясень пень. С этим спорить глупо.
Но я тоже повторюсь. При наличии сопоставимых по качеству и подаче материала источниках - я предпочту печатный вид. Потому что у него, на мой взгляд, масса преимуществ. Ессно если есть отличные видео-лекции, прямых аналогов которым не найдешь - буду смотреть, куда ж я денусь.
62. pm74 177 16.07.18 10:01 Сейчас в теме
(61) разница в напечатанном и записанном как видео , на мой взгляд , только в удобстве поиска при повторении
т.е. проще перевернуть страницу и заново прочитать и переосмыслить уже пройденный материал,
но при этом , видеоряд обладает возможностями недоступными для обычного текста
63. herfis 372 16.07.18 10:04 Сейчас в теме
(62) Это удобство невозможно переоценить. Намного легче держать новый сложный контекст.
67. pm74 177 16.07.18 10:22 Сейчас в теме
(63) давным давно и недолго , занимался рекламой и кое-что читал по сабжу
могу ошибиться в терминах , но существует показатель , что то вроде порога восприятия , т.е. количества повторов для запоминания. и , естественно, видеореклама в лидерах с большим отрывом
(64) это факт
68. herfis 372 16.07.18 10:42 Сейчас в теме
(67)
видеореклама в лидерах с большим отрывом

В контексте обсуждения это сравнение теплого с мягким. Потому как для обучения первично не запоминание, а понимание. Чем глубже понимание - тем легче запоминание, выстраивающееся вокруг ассоциативных цепочек. А глубокое понимание невозможно без самостоятельной проработки и переосмысления, которое с печатным словом гораздо эффективнее.
69. pm74 177 16.07.18 11:02 Сейчас в теме
(68)
Потому как для обучения первично не запоминание, а понимание

не всегда.
возьмем к примеру курс по скд от Гилева
конструктор скд весьма насыщен разными настройками, назначение которых нужно просто запомнить
70. herfis 372 16.07.18 11:05 Сейчас в теме
(69) Мне есть что ответить, но мне кажется что тема себя исчерпала и мы просто перебрасываемся мячиком.
71. pm74 177 16.07.18 11:06 Сейчас в теме
54. Артано 673 12.07.18 14:09 Сейчас в теме
(47) Спасибо, как с языка снял. Дополнил этот довод в (51)
50. Hans 1 12.07.18 13:24 Сейчас в теме
(46) Нет не серьезно. Но почему все нормальные курсы в виде видео выходят, а не в виде текста? Текст же лучше воспринимается. Если у тебя навыки фоточтения - поздравляю, читай дальше.
51. Артано 673 12.07.18 13:43 Сейчас в теме
(50)
Но почему все нормальные курсы в виде видео выходят, а не в виде текста?
из-за бабок. Бабло побеждает так как себестоимость и риски при производстве видеокурсов ниже, чем при производстве в текстовом формате. Чем ниже себестоимость тем проще штамповать видосы и снижать отпускные цены вытесняя с рынка более качественных, но менее успешных "текстовиков".
К счастью, забесплатно можно сохранить и экономически невыгодное производство. Тому кто делает что-то бесплатно безразличны прибыли.

Ну а если сильно нужно смотреть лекции на дома диване, то уже писал ранее - занеси денег автору, может и согласится =)
12. olegtymko 566 11.07.18 10:17 Сейчас в теме
(1) Идея сделать видео неплоха, есть разная аудитория. Кому-то просто легче прослушать, чем читать. Но это конечно уже совершенно другие затраты по времени.
14. yogaga 11.07.18 10:20 Сейчас в теме
(12) Видео намного сложнее изменять/дополнять, чем текст...
6. Hans 1 11.07.18 09:14 Сейчас в теме
Сделай один демо видос, сравнишь с просмотрами по тексту и по видео. Если хорошо видео будет заходить, будешь продавать. Текст ты точно никому не продашь.
7. yogaga 11.07.18 09:26 Сейчас в теме
Автор, а как вы считаете, использовать ВызватьИсключение для обработки ошибок это плохой стиль?
10. Артано 673 11.07.18 10:07 Сейчас в теме
(7) Зависит от контекста, и общей архитектуры. в п 2.6 (Неверное употребление оператора «Попытка…Исключение») приводил пример где очевидно это оправдано: перехват исключения, переопределения текста, вызов исключения с новым текстом
13. yogaga 11.07.18 10:19 Сейчас в теме
(10) Я имею в виду не перехват исключений, а генерация исключения в случае, если с точки зрения платформы все нормально, но с точки зрения логики программы произошла исключительная ситуация.
15. Артано 673 11.07.18 10:23 Сейчас в теме
(13) Почему бы и нет? Исключение это вполне легальное средство остановки выполнения программы. Но как уже писал выше сильно зависит от контекста где исключение вызывается. В широком смысле это вопрос архитектуры и принятой практики обработки исключительных ситуаций.
8. AlexeyPapanov 11.07.18 09:27 Сейчас в теме
9. FesenkoA 48 11.07.18 09:33 Сейчас в теме
а еще про комментарии стоит добавить. Когда 2 прораммиста работают без хранилища, один не ставит свой комментарий на код , а второй из своей базы ЦФ обновляет... Собственно после этого мне дали доступ к хранилищу)
А еще во всех статьях про правильность программирования нужно давать ссылку на
https://its.1c.ru/db/v8std
https://its.1c.ua/db/v8std
Светлый ум; +1 Ответить
11. Артано 673 11.07.18 10:14 Сейчас в теме
(9) Все главные ошибки связанные с комментариями описываются в п 2.13 (Несоответствие наименования переменной хранимому значению). При следующей правке дополню пункт.

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

В личной практике даже для проектов которые я веду один, всегда использую репозиторий с версионированием.
17. FesenkoA 48 11.07.18 10:30 Сейчас в теме
(11) нет, там описаны не правила документации изменений, а использования другой переменной. На это и вашу аналогию привожу реальный пример:

Крайне доработанная конфигурация БУ 1.2 (БУ 2 в РФ) крайне отставшего релиза предыдущий программист обновлял ее путем внесения кода, в ней кусок "Если налог = перечисление.ставкиНДС.НДС20 и ХХХ=УУУтогда...., иначеесли налог=перечисление.НДС20 тогда.... итд". Обновляю релиз до актуального. Комментариев не вижу, заменяю типовым куском (что то типа "если дата>ДатаХХХ и налог = УУУ тогда..", то есть вполне каардинально отличающимся), обновляю. Через 2 дня звонок "аааа, ничего не работает". Оказалось это была доработка программиста, он увидел типовое изменение с датой (дата НКУ, или как то так) но это под их специфику не подходило, и он добавил свое условие. При этом чуть выше комментарии его были, а тут ему было лень.
21. Артано 673 11.07.18 10:38 Сейчас в теме
(17) В данном случае проблема не в комментариях, а в методике доработки конфигурации на внешней поддержке. Если ваам необходимо переопределить поведение типовых модулей или свойства типовых объектов, то необходимо это делать в специально отведенных местах, а не там где застала нужда =)
32. Rustig 1550 11.07.18 17:05 Сейчас в теме
(21) прошу прощения, все так условно - каждый случай с клиентом индивидуален - иногда надо поправить в специально отведенном месте, иногда там где нужда застала...
33. Артано 673 12.07.18 05:36 Сейчас в теме
(32) "И ты, Брут, продался большевикам?!" (с)

Помню, как несколько лет назад ты экспериментировал с методами неразрушительной доработки типовых. Что случилось?
43. Rustig 1550 12.07.18 09:16 Сейчас в теме
(33) верно. случилось. в одном предложении не расскажу. наверное так скажу, столкнулся с разными ситуациями, в дальнейшем за годы сопровождения увидел последствия тех или иных решений. сделал выводы.
37. Ndochp 103 12.07.18 08:46 Сейчас в теме
(17) Так трёхстороннее объединение однозначно отделяет типовые куски от изменённых местными ребятами без всяких комментариев.
Это чистый косяк обновления, а не разработки.
Waanneek; zqzq; +2 Ответить
44. FesenkoA 48 12.07.18 10:14 Сейчас в теме
(37) Да, но предыдущий программист не пользовался обновлениями. Он просто брал кусок кода который ему нужен и закидывал в рабочую. Если ему что то казалось не нужным или неправильным - он убирал/менял. Трехстороннее сравнение показало почти все :( как это работало? А как программисту на (на то время) умирающем заводе ухватиться за место если у них одна торговая база?..
19. FesenkoA 48 11.07.18 10:34 Сейчас в теме
(11) или допустим код
попытка
Действие1(а,б,в);
Исключение
Действие1(а,б,в);
Конецпопытки

стоит снабжать комментариями. Причем чуть более подробными чем "// Иванов И.И 01.01.1234"
20. FesenkoA 48 11.07.18 10:35 Сейчас в теме
(19)что интересно - ошибкой было именно убрать 2й вызов из исключения
23. Артано 673 11.07.18 10:42 Сейчас в теме
(19) В данном примере выполняется две попытки выполнить действие, или внутри функции творится какой-то ужас, и она что-то меняет в базе. Так или иначе проблема в архитектуре.
Согласен, что неочевидные, нестандартные ходы нужно описывать специально. Почему-то был уверен, что уже писал об этом и много раз проговаривал.

UPD: да, в первой лекции. Вижу что стоит еще раз подробно на этом остановиться. Надеюсь, меня не закидают помидорами за повторы =)
24. FesenkoA 48 11.07.18 10:53 Сейчас в теме
(23) Ну на самом деле процедура вызывает СОМ объект Экселя, с нестандартным файлом. Файл открывается, но пустой, при попытке получить строки - исключение. Выполняется еще один вызов процедуры с етем же (или новым) ком объектом, и все открывается четенько и гладенько. Согласен, это ппц писать так, но раз уж пишешь и оно работает - черкни пару строк почему так.

Ну и ксати в последнее время начинаю комментариями создавать описание сложных процедур, помимо объединения их в области. Стам натолкнулся на "ааа, что это за фигня? кто это писал? а, я что ли?" и оно пришло...Тому кто будет сидеть после меня комментарии помогут
25. Артано 673 11.07.18 11:04 Сейчас в теме
(24)
(23) Ну на самом деле процедура вызывает СОМ объект Экселя, с нестандартным файлом. Файл открывается, но пустой, при попытке получить строки - исключение. Выполняется еще один вызов процедуры с етем же (или новым) ком объектом, и все открывается четенько и гладенько. Согласен, это ппц писать так, но раз уж пишешь и оно работает - черкни пару строк почему так.

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


Да хороший подход. В соответствующих лекциях посвященных непосредственно кодингу, более подробно остановлюсь на процессе написания кода.
16. CSiER 29 11.07.18 10:24 Сейчас в теме
Например, у вас есть 10 ошибок примерно одинаковой вредности. Но одна из них предварительно оценивается в 40 часов, тогда как остальные, даже по пессимистичным оценкам укладываются в 1-8 часов.

Как именно происходит предварительная оценка?
Ведь не стоит забывать, что сложно оценить трудоёмкость более 16 часов без декомпозиции

Уже не первый раз встречаю именно 16 часов - откуда это значение (тот же Спольски тоже пишет про 16 часов)?
18. Артано 673 11.07.18 10:33 Сейчас в теме
(16)
Как именно происходит предварительная оценка?
Это особая джедайская магия. И тема для отдельной статьи. На самом примитивном уровне оценивается из опыта решения подобных задач.


Уже не первый раз встречаю именно 16 часов - откуда это значение (тот же Спольски тоже пишет про 16 часов)?


Обычный житейский опыт. Сложно прогнозировать что-то более чем на два дня вперед. Т.е. я могу достаточно уверенно сказать что и как я буду делать сегодня-завтра или завтра-послезавтра. Но на более длительный срок прогнозировать сложно. Вообще даже 16 часов это много и на крупных проектах планку снижали до 4-8 часов.
22. CSiER 29 11.07.18 10:41 Сейчас в теме
(18)
до 4-8 часов.

Из моего опыта оптимально как раз 8 часов, 16 - уже перебор.
alex-l19041; +1 Ответить
26. TODD22 19 11.07.18 11:07 Сейчас в теме
(16)
Уже не первый раз встречаю именно 16 часов - откуда это значение

Все читают Спольски :)
27. Designer1C 341 11.07.18 11:30 Сейчас в теме
Предлагаю использовать фразу :
"Каждый дополнительный час потраченный на обдумывание структуры приложения до его разработки, экономит десятки часов на исправление ошибок или обход ограничений архитектуры и вызванные этим ошибки."
вместо фразы :
"Каждый лишний час потраченный на обдумывание структуры приложения до его разработки, экономит десятки часов на исправление ошибок или обход ограничений архитектуры и вызванные этим ошибки."
Rustig; olegtymko; Артано; yogaga; +4 Ответить
28. starik-2005 2195 11.07.18 11:55 Сейчас в теме
И много, интересно знать, 1С-ников, которые в принципе способны научиться на примере настоящего текста чему-либо? В ряде пунктов вообще дана достаточно сильная аргументация в пользу ООП, но ведь разработчики языка 1С вряд ли сделают нормальную объектную модель, а разработчики на 1С вряд ли когда смогут это освоить (не про всех говорю, конечно).
29. Артано 673 11.07.18 12:29 Сейчас в теме
(28) Вот так всегда. Стоит один раз написать статью в стиле "ООП для детей", так сразу евангелистом ООП обзывают ))

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

Насчет способностей - так не боги горшки обжигали. Каждый что-то своё вынесет в меру способностей и объективных ограничений практического применения. Сложно предположить что сразу, без практики, можно взять и освоить чужой опыт. Статья здесь не только и не столько набор методик и полезных советов, сколько пример организации мышления человека. Если во вводных лекциях об этом говорилось абстрактно, то начиная с этой статьи начались конкретные примеры.

Также не согласен с пренебрежительной оценкой способностей большинства программистов. В большинстве своём эти люде не глупые, а просто необразованные или слабохарактерные.
Большая часть хороших и крепких средних программистов стали такими потому что когда-то повезло им попасть в хорошую команду, где привили вкус прекрасному. Меньшая часть "выросли на помойке" за счет характера и выдержки. Основная же часть людей не готова бороться. Это не про интеллект, а вполне себе про психологию.

По этому поводу могу привести наглядную иллюстрацию из практики:
Был у меня небольшой проект на разработку подсистемы в самиписной конфе. В помощь дали одного штатного программиста. Так вот, когда я его код смотрел по проекту вообще не было нареканий, но как-то зашел в другие места и сразу глазам не поверил - словно другой человек писал. А разгадка простая была - на моём небольшом проекте изначально были чистота и порядок и человек интуитивно принял негласные правила этого места. А там где срач и бардак он вел себе соответственно месту. Когда спросил его как он переключается так легко (мне, признаюсь, было бы сложно) - он просто не понял меня. Мол просто пишу и всё. Такие дела...
mytg; Vladimir Litvinenko; +2 Ответить
30. starik-2005 2195 11.07.18 13:18 Сейчас в теме
(29)
Основная же часть людей не готова бороться.
Полезное замечание.
31. Rustig 1550 11.07.18 16:59 Сейчас в теме
(0) наконец-то в центре внимания сообщества нормальная картинка!
34. Synoecium 699 12.07.18 07:24 Сейчас в теме
"Если вам не нужно редактировать переданные параметры, то передавать их нужно по значению. "
тут может стоить пояснить, что если передача параметра происходит между процедурами одной стороны (клиента или сервера), то лучше передавать по ссылке, дабы не создавать лишних копий одного объекта.
LordKim; Артано; +2 Ответить
35. yogaga 12.07.18 08:06 Сейчас в теме
(34) А как вообще ссылочный объект по значению передать?
38. yogaga 12.07.18 09:01 Сейчас в теме
(36) Это с клиента на сервер и обратно, тут понятно, а только в контексте клиента или в контексте сервера?
39. Synoecium 699 12.07.18 09:03 Сейчас в теме
(38) а что вы понимаете под ссылочным объектом? Если кратко ответить - то просто добавить Знач перед параметром.
40. yogaga 12.07.18 09:06 Сейчас в теме
(39) Ссылка на элемент справочника, например. Что в этом случае даст Знач?
41. Synoecium 699 12.07.18 09:09 Сейчас в теме
(40) ничего, это же ссылка на запись в БД, а не объект в памяти
42. yogaga 12.07.18 09:13 Сейчас в теме
(41) А я уж подумал, что изменилось что-то.
45. Артано 673 12.07.18 11:12 Сейчас в теме
(34) Разумное замечание. Хотя потери здесь не такие существенные. Самое узкое место в этой проблеме - транспортные расходы
58. Alex_CheST 1 16.07.18 07:46 Сейчас в теме
Интересная лекция, спасибо. Не скажу что сильно новая информация, но читается легко и понятно.
64. herfis 372 16.07.18 10:08 Сейчас в теме
Не, можно, конечно, по-старинке. Сидеть как на лекции в универе и вести конспект. Если будешь успевать. Это зело увеличивает эффективность обучения, совмещая сразу несколько каналов восприятия, давая ретроспективу и смазывая недостатки "видеопотока".
65. Артано 673 16.07.18 10:09 Сейчас в теме
(64) Лектор, пожалуйста помедленнее, я записываю! =)
66. herfis 372 16.07.18 10:11 Сейчас в теме
Я когда-то ходил в радиокружок. Но если азбуку морзе я до сих пор помню, то стенографию успешно позабыл.
72. herfis 372 16.07.18 11:15 Сейчас в теме
Но, кстати, настройки СКД - как раз тот случай когда видео гораздо уместнее скупого текста с миллионом скриншотов. Специфика такая.
Хотя внятной статьи по механизмам работы СКД в стиле проф-разработки первой редакции ой как не хватает.
73. LordKim 23.07.18 17:01 Сейчас в теме
"Оптимальным вариантом для оптимизации поиска в массиве может быть использование соответствия (map) вместо массива" ©

Ограничение на количество элементов в соответствии - 99999, не универсальное решение
Массив не проверял, но он вроде как и ТЗ, не имеет ограничителя
TreeDogNight; +1 2 Ответить
74. Артано 673 23.07.18 17:05 Сейчас в теме
(73) Хорошее наблюдение, не знал. Не приходилось работать с настолько большими списками в памяти.
75. LordKim 23.07.18 17:12 Сейчас в теме
(74)
Я тоже не знал =)
Оптимизировал поиск по ТЗ (по составному ключу) и попервой хотел использовать соответствие (строковый составной ключ / строка ТЗ)
Мне повезло что ТЗ была 124к строк, и я практически сразу обнаружил проблему

В результате сделал индексирование по ТЗ (скорость поиска сопоставима, затраты на индексацию значительно меньше чем на формирование соответствия)
Хотя сам объект соответствия мне очень нравится, удобная штука, но редко кто ей умеет пользоваться
76. Артано 673 23.07.18 17:20 Сейчас в теме
(75) Если ТЗ уже есть на входе, то самый лучший способ это именно индексирование ТЗ. Кстати об этом написано в том же абзаце где говорится про соответствие )
78. herfis 372 23.07.18 17:55 Сейчас в теме
(75) Возможно ты столкнулся с ограничением нумерации строк табличной части и неправильно его интерпретировал по результатам работы своего алгоритма, так как начали дублироваться ключи соответствия.
77. herfis 372 23.07.18 17:53 Сейчас в теме
(73)(74) Так себе наблюдение.
Только что затестил наполнение и работу с соответствием на миллион элементов - никаких проблем не встретил.
Платформа 8.3.6, наполнение заняло 10 секунд.
Никогда не встречал ни в одном источнике упоминания явного ограничения на количество элементов ни в одной универсальной коллекции.
Патриот; LordKim; Артано; +3 Ответить
80. Артано 673 23.07.18 18:05 Сейчас в теме
(77) Кстати да, не обратил сразу внимания на магическое число 99999, скорее всего уши растут из табличной части
82. LordKim 23.07.18 21:05 Сейчас в теме
(77)
хз, завтра проверю, и заскриню, благо код наполнения соответствия остался
Платформа 8.3.6.2299

Не поленился, проверил сейчас
Действительно, в соответствие можно добавлять произвольное количество

Вероятно количество уникальных ключей в ТЗ было 99999 (отлаживал несколько раз, но видимо исходные данные не менялись в процессе)
Мне подумалось что есть ограничение (в структуре же есть), ненаучно подошел, признаю
83. herfis 372 24.07.18 09:13 Сейчас в теме
(82)
Мне подумалось что есть ограничение (в структуре же есть)

Да что ж это такое. Что еще за ограничение в структуре? :)
Еще раз - НИ У ОДНОЙ универсальной коллекции нет явных ограничений по размеру.
Тест с миллионом элементов по-прежнему чувствует себя хорошо.
Да и неоткуда взяться ограничению у структуры - это тоже самое соответствие, только с небольшим синтаксическим сахаром.
84. LordKim 24.07.18 13:58 Сейчас в теме
85. LordKim 24.07.18 14:12 Сейчас в теме
(84)
Сейчас проверил, действительно создает необходимое количество свойств, ну да, для карты было бы удивительно ограничение...
86. herfis 372 24.07.18 14:25 Сейчас в теме
(84) Да, что-то Ильдарович в тот раз прогнал.
"Проведя эксперименты, получим, что структура может хранить максимум 999 свойств" - вангую, что он генерил ключи в цикле и уперся в неразрывный пробел, как недопустимый символ для ключа структуры :)
Другое дело, что в качестве hash-map соответствие эффективнее структуры. Считать хэши по строкам, тем более длинным - менее эффективно чем по примитивным типам и ссылкам. То же заполнение миллиона элементов в соответствии по числовым ключам происходит ощутимо (но не разитильно) быстрее.
ЗЫ. Фраза в синтакс-помощнике касательно "Структура используется обычно для хранения небольшого количества значений, каждое из которых имеет некоторое имя" относится скорее к логике использования. Потому что именованных свойств не может быть слишком много по определению.
Патриот; +1 Ответить
81. grumagargler 666 23.07.18 18:30 Сейчас в теме
(73) у соответствия нет такого ограничения
79. herfis 372 23.07.18 17:56 Сейчас в теме
Соответствие - любимая универсальная коллекция. Ибо HashMap :)
user940969; +1 Ответить
87. Jestery 26.07.18 16:44 Сейчас в теме
Автору однозначно огромное спасибо и жирный плюс за труд. Обязательно нужно будет ознакомиться.
88. awk 718 27.08.18 14:24 Сейчас в теме
1. Определение ошибки есть, а определения качества нет. Хотя определение ошибки выводиться на основании качества.
2. Кластеризация смешана с классификацией.

Это по форме статьи.

По содержанию поставил бы два плюса если бы мог....
89. Артано 673 28.08.18 03:10 Сейчас в теме
(88) Спасибо

1. Определение качества в первой статье. Это третья
2. Классификация лишь метод, кластеризация результат. Но подумаю над формулировками, возможно стоит расставить акценты
90. user940969 28.08.18 10:18 Сейчас в теме
Однозначно полезная и интересная статья. Из комментариев не понял, зачем к данной статье видео... Лучше потратить некоторое количество времени и прочесть её вдумчиво и внимательно. Больше пользы будет, чем от видео.
91. Plotks2017 241 16.10.19 13:47 Сейчас в теме
А как конкретно "Выполнить" влияет на производительность? Откуда такая информация?
92. Артано 673 17.10.19 03:57 Сейчас в теме
(91)
А как конкретно "Выполнить" влияет на производительность?


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

Откуда такая информация?

Из знания как работают данные конструкции и из практики. Пруфы от вендора если и есть искать не буду. Исключение возможно гипотетически для случаев, когда сам код тяжелый и накладные затраты на динамическую компиляцию на его фоне незаметны =)
То есть, накладные расходы на использование Выполнить и Вычислить можно признать константой, суммарные затраты же складываются из особенностей алгоритма, использующего подобные конструкции.
Например код типа:
А = 0;
Для Сч = 1 По N Цикл
	Выполнить("А = А + 1");
КонецЦикла;


Будет выполняться в разы дольше чем

А = 0;
Выполнить("
|Для Сч = 1 По N Цикл
|	А = А + 1;
|КонецЦикла;");


И по мере увеличения N разница будет расти
Plotks2017; +1 Ответить
Оставьте свое сообщение

См. также

Использование программных перечислений, ч.1: строковые константы Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Часто ли у вас возникает необходимость в коде выполнять сравнение на строку?

10.12.2016    37197    unichkin    72    

«Варп-двигатель» для «среза последних»

Практика программирования Бесплатно (free)

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

10.08.2020    2681    hobi    45    

1С: Документооборот, Data Science и Python

Документооборот и делопроизводство Математика и алгоритмы ДО Бесплатно (free)

В статье рассказывается о создании и обучении модели Data Science на языке Python и интеграции с системой 1С: Документооборот

04.08.2020    1442    Vaganov_Alexey    4    

Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

29.06.2020    8097    WildHare    33    

Вспомогательные инструкции в коде 1С Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Помогаем редактору кода 1С помогать нам писать и анализировать код.

15.10.2018    30035    tormozit    100    

Не спеша, эффективно и правильно – путь разработки. Часть 2. Теория

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

22.06.2020    9243    WildHare    23    

Не спеша, эффективно и правильно – путь разработки. Часть 1. Парадигма

Практика программирования Бесплатно (free)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

15.06.2020    13320    WildHare    34    

Применение математических достижений в решении сложных задач бизнеса

Математика и алгоритмы Бесплатно (free)

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

25.05.2020    3300    Mishnov    17    

Оформление и рефакторинг сложных логических выражений Промо

Практика программирования v8 Россия Бесплатно (free)

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

20.09.2012    77770    tormozit    131    

JSON в запросах DaJet QL

Практика программирования Бесплатно (free)

Практические примеры работы с JSON непосредственно в языке запросов. Перенос курсов валют между УТ и БП. Требуется SQL Server 2016 и выше.

24.04.2020    3757    zhichkin    6    

Визионное программирование

Практика программирования Бесплатно (free)

Новый способ программирования и его практическая демонстрация.

22.04.2020    4447    mkalimulin    111    

Принципы разработки

Рефакторинг и качество кода Бесплатно (free)

Доброго дня и хорошего кода, коллега.

04.03.2020    3107    Правдин    27    

Запись значения в поле ввода/формы со срабатыванием события ПриИзменении Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Иногда возникает необходимость после записи значения в какое либо поле ввода/формы вызвать для него обработчик события ПриИзменении, а о вызове самого события приходится только мечтать. В этой статье приводится программный способ вызова этого события.

11.07.2007    48138    tormozit    41    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    5049    ildarovich    7    

Использование машинного обучения для решения инцидентов. Практическое применение

Практика программирования Бесплатно (free)

Продолжаю (и заканчиваю) тему с автоматическим решением инцидентов. Перейдем от теории к практике.

25.02.2020    4146    Repich    9    

Использование машинного обучения для решения инцидентов

Практика программирования Бесплатно (free)

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

18.02.2020    6717    Repich    17    

Как сделать из &НаКлиентеНаСервереБезКонтекста почти &НаКлиентеНаСервере Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Как сделать метод формы, доступный на клиенте и на сервере одновременно, и сохранить при этом удобство разработки

10.09.2017    44586    tormozit    74    

Качество кода: слабое связывание и высокая сопряженность (Low coupling and High Cohesion)

Рефакторинг и качество кода Бесплатно (free)

Поговорим о некоторых общепринятых подходах и принципах разработки кода.

10.02.2020    7605    ivanov660    90    

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

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

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

13.01.2020    6465    Scorpion4eg    8    

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

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

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

30.12.2019    8398    olegtymko    9    

Развитие 1С программиста Промо

Практика программирования Личная эффективность Бесплатно (free)

Делюсь своим опытом и видением развития 1С программиста.

17.10.2018    20621    pashamak    62    

Приватный блокчейн и 1С популярно

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

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

02.09.2019    6042    mkalimulin    140    

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

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

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

26.08.2019    8990    kirovsbis    28    

Как завести у себя в команде код-ревью. Отвечаем на вопросы

Рефакторинг и качество кода Бесплатно (free)

Дадим советы как начать использовать у себя в команде код-ревью (code-review), а также ответим на вопросы читателей.

17.07.2019    9340    ivanov660    29    

Выгрузка документа по условию Промо

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

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

25.04.2019    16004    m-rv    2    

Интеграция сценарного тестирования в процесс разработки

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

Разработчик системы «Тестер» Дмитрий Решитко в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION показывает, что процесс тестирования можно очень плотно интегрировать в процесс разработки, что внедрение тестирования – это возможность развития программиста как такового, позволяющая ему упорядочивать ход мыслей и оставаться «в фокусе». Навыки построения процесса кодирования на стыке с тестированием сокращают время на концентрацию, освобождают от страха перед изменениями и улучшают память разработчика.

08.07.2019    9124    grumagargler    7    

Управляй качеством кода 1С с помощью SonarQube

Практика программирования Россия Бесплатно (free)

Управляй техническом долгом проектов 1С с помощью SonarQube. В статье рассматривается пример применения SonarQube при разработке.

07.07.2019    39078    olegtymko    231    

Выдержки из книги Чистый код

Математика и алгоритмы Бесплатно (free)

Недавно я прочитал книгу "Чистый код" Роберта Мартина (Robert Cecil Martin). В ней описываются принципы организации и форматирование исходного кода программы так, чтобы в дальнейшем было легко поддерживать такой код. Эта книга является библией для многих программистов, но вот в среде программистов 1С, к сожалению, не очень распространено чтение подобной фундаментальной литературы. Книга более 400 страниц и так много порой лениво читать, да и времени всегда не хватает. По этому я решил выделить в виде цитирования по разделам самые важные моменты. А также снабдил текст своими примерами кода.

16.05.2019    10371    FreeArcher    105    

Как прикрутить ГУИД к регистру сведений Промо

Практика программирования Перенос данных из 1C8 в 1C8 Разработка v8 Бесплатно (free)

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

16.04.2019    20123    m-rv    17    

О времени и 1С

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

Основы и особенности работы со временем в 1С. Как избавиться от боли при работе в разных часовых поясах. Что такое момент времени. И другое.

01.04.2019    34465    YPermitin    61    

Пример создания bridge (http api - tcp) для ККТ "Касса №1" ("К1-Ф")

Практика программирования ККМ Кассовые операции Кассовые операции Разработка Россия Бесплатно (free)

Пример создания bridge (http api - tcp) для ККТ "Касса №1" ("К1-Ф"). Данная статья будет полезна интеграторам, программистам, тем кто работает (интегрирует, разрабатывает) различное ТО либо железки. Версия и релиз технологической платформы не имеет значения.

17.03.2019    6546    dmarenin    1    

Как сделать запрос на изменение данных Промо

Практика программирования v8 v8::Запросы 1cv8.cf Бесплатно (free)

В статье приведены особенности внутренней архитектуры и примеры работы с расширением языка запросов 1С.

01.06.2018    30439    m-rv    21    

Быстрее чем INSERT! BULK-операции и примеры использования

Производительность и оптимизация (HighLoad) Практика программирования Внешние источники данных Перенос данных из 1C8 в 1C8 Разработка Бесплатно (free)

Microsoft SQL Server поддерживает так называемые BULK-операции, используемые для быстрого изменения больших объемов данных в базе. В статье пойдет речь о практических примерах их использования. Все примеры сделаны в контексте платформы 1С (а как иначе).

09.03.2019    23909    YPermitin    40    

Как писать понятные коммиты

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

Как писать сообщения коммитов так, чтобы потом не было мучительно больно.

06.03.2019    12636    Scorpion4eg    35    

Метод формирования движений в типовых регистрах нетиповыми регистраторами Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Вариант решения задач с проведением по типовым регистрам нетиповыми регистраторами. Зачем - чтобы при сравнении конфигурации не обращать внимание на свойства регистров и исключить вероятность допущения горькой оплошности при обновлении информационных баз, заменив типы регистраторов основной конфигурации типами конфигурации поставщика. Для программных продуктов, имеющих в своем составе метаданных документ "Корректировка регистров"("Корректировка записей регистров").

05.12.2017    28189    itriot11    34    

Что такое алгоритм?

Математика и алгоритмы Бесплатно (free)

Как ответить на этот вопрос и не попасть пальцем в небо.

25.02.2019    8192    mkalimulin    274    

Подготовка ребёнка к ЕГЭ по информатике. Часть шестнадцатая

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

Поиск выигрышной стратегии, завершающая статья.

22.02.2019    5684    vasilev2015    0    

Использование классов .Net в 1С для новичков Промо

Практика программирования Разработка внешних компонент Универсальные функции v7.7 v8 Бесплатно (free)

Руководство для новичков. Написав статью http://infostart.ru/public/238584/, я понял, что многие не понимают того, что написано. Поэтому в этой статье постараюсь более подробно остановиться на азах и без кода на вражеском языке (C#)

27.01.2016    76139    Serginio    108    

Подготовка ребёнка к ЕГЭ по информатике. Часть тринадцатая

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

Исправление ошибок в программе, часть вторая.

20.02.2019    5746    vasilev2015    3    

Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С Промо

Математика и алгоритмы Практика программирования v8 v8::blocking 1cv8.cf Бесплатно (free)

Основные принципы работы с режимами автоматических и управляемых блокировок в 1С Предприятие 8. Теория и применение в типовых конфигурациях: БП, УТ, ЕРП

10.11.2018    34447    ids79    40    

Метод Кларка-Райта. Оптимальное планирование маршрутов грузоперевозок Промо

Математика и алгоритмы Бесплатно (free)

Одной из наиболее важных задач каждого предприятия, осуществляющего доставку грузов в крупных населенных пунктах, является сокращение издержек. Возможное решение данной проблемы заключается в сокращении пробега автотранспорта и, как следствие, уменьшении расхода ГСМ. Появляются такие вопросы ... - СКОЛЬКО НУЖНО МАШИН ДЛЯ РАЗВОЗКИ КОНКРЕТНОГО ОБЪЕМА ГРУЗА ПО АДРЕСАМ ДОСТАВКИ ? - КАК РАЗБИТЬ ТОЧКИ ДОСТАВКИ НА ОПТИМАЛЬНЫЕ ПО ПРОБЕГУ И ЗАГРУЗКЕ МАШИН МАРШРУТЫ ? ... В этой статье Вы найдете один из многих способов получить ответ на эти вопросы.

10.02.2016    59671    mi1man    20    

Подготовка ребёнка к ЕГЭ по информатике. Часть восьмая

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

Шифрование и дешифрование информации. Закон Фано

05.02.2019    5611    vasilev2015    1